La différence entre développeur et expert technique
J’ai toujours aimé la programmation pour sa facilité d’apprentissage ne necessitant pas de longues années d’études.
Il faut cependant nuancer le propos car ce qui fera la différence entre un développeur et un expert technique est bien dans des connaissances acquisent durant de longues années!
Il était une fois Azure et sa gateway HTTP
L’envie d’écrire cet article fait suite à une séquence d’investigation particulièrement compliqué pour un client hébergeant son application sur Azure.
Lorsque des requêtes étaient faite à l’application, la requête n+1 se terminait en erreur 500. Cette application est déployée sur Azure et les requêtes passent donc par la gateway Azure avant d’être redirigées sur l’application.
Après moult recherches sur la gateway HTTP Azure, dans notre framework, dans la couche applicative du client, dans nos services dépendants (Elasticsearch et Redis), nous sommes dans une impasse: impossible de trouver la raison de cette erreur.
Heureusement, l’ingénieur de chez Azure a eu la bonne idée de nous fournir une capture des paquets réseaux transitants entre la gateway et l’application. Cela prend la forme d’un fichier PCAP qui contient l’historique des trames réseaux TCP échangées.
Je réinstalle donc notre bon vieux Wireshark afin d’analyser les paquets moi même dans une interface familière, voila ce que je remarque:
- Réponse de Kuzzle vers la gateway pour la requête N. La connexion utilisait le port TCP 60786.
- Requête de la gateway vers Kuzzle.
- Le même port TCP a été utilisé
Je trouve cela étrange alors je compare avec une capture réseau que je réalise moi même en local:
- Réponse de Kuzzle vers le client
- Le client ferme la connexion avec un paquet TCP FIN
- Kuzzle confirme la fermeture en renvoyant un paquet TCP FIN
On conclut donc que le client est responsable de la fermeture de la connexion après avoir reçu la réponse à sa requête, si il ne le fait pas alors c’est qu’il peut vouloir envoyer plusieurs requêtes à la suite. C’est ce qu’on appelle HTTP Pipelining.
Il se trouve que la librairie HTTP que l’on utilisait ne supportait pas cette feature (oui je sais, ne pas respecter la RFC c’est inconcevable normalement 🙄)
En parcourant la RFC, on apprend que le serveur peut demander au client de forcer la connexion avec le header Close.
Finalement le bug qui nous aura demandé plusieurs semaines d’investigations aura été corrigé en 3 lignes.
La programmation requiert des compétences globales
En prenant cet exemple, on se rend compte que la correction d’erreurs nécessite des connaissances plus larges que celles que l’on peut avoir sur un langage ou un framework.
Il faut être capable de compendre les interactions entre l’ensembles des couches et protocoles qui composent une application, et la complexité de ces couches ne cesse d’augmenter avec l’ajout de nouvelles abstractions.
Il n’y a pas de recette miracle pour acquérir ces compétences, cela tiens en 1 seul mot: curiosité.
Alors passez du temps à lire Wikipedia, abonnez vous à des blogs techniques, écoutez des podcast, regardez des vidéos et surtout lisez les RFC (LOL je dec pour le dernier).
Merci aux autres membres de l’équipe Kuzzle pour leur aide dans l’investigation et la correction de ce bug
Image d’entête: Gare de Galle, Sri Lanka