La négociation TCP et la vie d’une connexion

Avant que votre Mac n’envoie le moindre octet d’une requête de page web, il a déjà échangé trois courts messages avec le serveur. Cet échange, la négociation en trois temps de TCP (three-way handshake), est ce qui transforme les promesses de fiabilité de TCP vues dans la leçon précédente en une connexion réelle et traçable entre deux machines.

Trois messages avant le premier mot

La RFC 9293, la spécification actuelle de TCP, décrit le processus comme un échange synchronisé : « la synchronisation exige que chaque côté envoie son propre numéro de séquence initial et reçoive un accusé de réception de celui-ci de la part du pair TCP distant ».

1. SYN. L’appareil qui ouvre la connexion envoie un segment avec le drapeau SYN activé, portant un numéro de séquence de départ.
2. SYN-ACK. L’autre côté répond avec son propre SYN, plus un accusé de réception du premier numéro.
3. ACK. Le premier appareil accuse réception de cette réponse. La RFC 9293 note que « comme les étapes 2 et 3 peuvent être combinées en un seul message, on appelle cela la négociation en trois temps (ou en trois messages) ». Une fois qu’elle est terminée, les deux côtés considèrent la connexion comme ÉTABLIE et commencent à envoyer de vraies données.

Le centre d’apprentissage de Cloudflare donne une version en langage simple de la même idée, en prenant un e-mail comme exemple : « d’abord, la source envoie un paquet SYN de « requête initiale » au serveur cible pour démarrer le dialogue. Ensuite, le serveur cible envoie un paquet SYN-ACK pour accepter le processus. Enfin, la source envoie un paquet ACK à la cible pour confirmer le processus, après quoi le contenu du message peut être envoyé. »

Terminer une connexion proprement

Fermer une connexion est plus délibéré que l’ouvrir. La RFC 9293 explique que « la séquence de fermeture normale de TCP livre les données mises en mémoire tampon de façon fiable dans les deux sens » avant que la connexion ne se termine : chaque côté envoie un segment FIN une fois qu’il n’a plus de données à envoyer, l’autre côté en accuse réception, et ce n’est qu’une fois les deux sens terminés que la connexion se ferme complètement. Une courte période d’attente (TIME-WAIT) suit, afin qu’un paquet égaré et retardé de l’ancienne connexion ne puisse pas être confondu avec une partie d’une nouvelle.

Ce que voit un pare-feu placé au milieu

Un pare-feu à état (stateful), le type intégré dans la plupart des routeurs et dans macOS lui-même, n’a pas besoin d’inspecter chaque paquet pour prendre une décision. L’explication de Cloudflare sur les pare-feux le décrit ainsi : il « enregistre des informations concernant les connexions ouvertes et utilise ces informations pour analyser le trafic entrant et sortant, plutôt que d’inspecter chaque paquet ». En pratique, cela signifie qu’il surveille le SYN qui ouvre une connexion, se souvient que cette appli a demandé une réponse, puis laisse discrètement passer le SYN-ACK correspondant ; une réponse qui ne correspond à aucun SYN sortant est rejetée. C’est aussi ainsi qu’un pare-feu peut distinguer une réponse normale d’une tentative de connexion non sollicitée arrivant de nulle part, ce qui est la base du blocage du trafic entrant indésirable.

Rien de cet échange n’est chiffré par TCP lui-même ; SYN, SYN-ACK et ACK sont visibles en clair par tout ce qui observe le chemin réseau, y compris votre routeur Wi-Fi. Ce qui est caché ou non dépend de la couche au-dessus de TCP, comme TLS pour un site HTTPS, que le cours sur le fonctionnement d’Internet traite séparément.