Avant qu’une page web ne s’affiche, qu’un fichier ne soit téléchargé ou qu’une API ne réponde, une étape discrète se joue souvent en quelques millisecondes : le handshake TCP en trois étapes. Ce mécanisme, essentiel au fonctionnement d’Internet, permet à deux machines de s’accorder avant d’échanger des données de manière fiable.
Le handshake TCP, ou « poignée de main » TCP, est la procédure utilisée pour établir une connexion entre un client et un serveur. TCP, pour Transmission Control Protocol, est l’un des protocoles fondamentaux de la suite Internet. Il est conçu pour transmettre des données dans le bon ordre, détecter les pertes et demander la retransmission des segments manquants.
Contrairement à UDP, qui envoie des datagrammes sans vérifier si le destinataire est prêt, TCP commence par négocier une connexion. Cette phase repose sur trois messages successifs : SYN, SYN-ACK et ACK. Une fois ces trois échanges terminés, les deux machines considèrent que la session est ouverte et peuvent envoyer des données applicatives, par exemple une requête HTTP.
TCP cherche à offrir une communication fiable sur un réseau qui, lui, ne l’est pas toujours. Des paquets peuvent être perdus, retardés, dupliqués ou arriver dans le désordre. Le handshake sert donc à initialiser plusieurs paramètres indispensables, notamment les numéros de séquence, qui permettront ensuite de reconstituer correctement le flux de données.
Cette phase permet aussi de vérifier que le client et le serveur sont tous deux joignables et capables de communiquer. À l’échelle d’Internet, d’autres protocoles contribuent à cette stabilité générale : le rôle du protocole ICMP dans le diagnostic réseau illustre par exemple comment les équipements signalent certaines erreurs ou indisponibilités.
Tout commence lorsque le client veut ouvrir une connexion vers un serveur, par exemple sur le port 443 pour accéder à un site en HTTPS. Il envoie alors un segment TCP avec le drapeau SYN activé. SYN signifie « synchronize » : le client demande à synchroniser les numéros de séquence avec son interlocuteur.
Ce premier message contient un numéro de séquence initial, choisi de façon pseudo-aléatoire par le client. Ce choix n’est pas anodin : il limite certains risques de prédiction et permet d’identifier précisément les octets échangés au cours de la session. À ce stade, le client passe généralement dans l’état TCP appelé SYN-SENT, en attente d’une réponse du serveur.
Si le serveur écoute bien sur le port demandé et accepte la tentative de connexion, il répond avec un segment portant deux drapeaux : SYN et ACK. Le SYN du serveur indique son propre numéro de séquence initial. L’ACK, pour acknowledgment, confirme qu’il a bien reçu le SYN du client.
Concrètement, si le client a envoyé un numéro de séquence 1000, le serveur répondra avec un accusé de réception 1001. Cette logique d’incrémentation permet à TCP de suivre précisément la progression du flux. La précision temporelle peut aussi jouer un rôle dans l’analyse réseau, et la synchronisation horaire assurée par NTP facilite la comparaison de journaux entre plusieurs machines.
La dernière étape est l’envoi, par le client, d’un segment ACK. Il confirme ainsi la réception du SYN envoyé par le serveur. Si le serveur a utilisé le numéro de séquence 5000, le client indiquera typiquement un accusé de réception 5001. Les deux extrémités disposent alors de leurs repères de séquence respectifs.
À partir de ce moment, la connexion est considérée comme établie. Le client peut transmettre une requête HTTP, le serveur peut répondre, et TCP se charge de découper, ordonner et retransmettre les données si nécessaire. Dans certains usages modernes, une autre négociation peut suivre, comme le processus d’ouverture propre à WebSocket, qui intervient à un niveau applicatif différent.
Le handshake TCP établit une connexion fiable, mais il ne chiffre pas les échanges et n’authentifie pas à lui seul l’identité du serveur. Lorsqu’un site utilise HTTPS, le handshake TCP se produit d’abord, puis vient la négociation TLS, qui gère le chiffrement, les certificats et les clés de session.
Il ne faut donc pas confondre fiabilité du transport et sécurité applicative. Dans le domaine de l’email, par exemple, des dispositifs distincts vérifient l’authenticité des messages : les politiques DMARC publiées dans le DNS encadrent le traitement des courriels suspects, tandis que la signature DKIM des emails aide à confirmer qu’un message n’a pas été altéré.
Un handshake peut échouer pour plusieurs raisons. Le serveur peut être indisponible, le port fermé, un pare-feu peut bloquer la connexion, ou un équipement intermédiaire peut supprimer certains paquets. Côté client, l’utilisateur voit souvent un message générique indiquant que le site est inaccessible ou que la connexion a expiré.
Les administrateurs réseau analysent ces situations avec des outils comme tcpdump, Wireshark, netstat ou ss. Si l’on observe un SYN envoyé sans réponse, le problème se situe peut-être sur le chemin réseau ou côté serveur. Si un SYN-ACK revient mais que l’ACK final n’est jamais envoyé, la cause peut venir d’un filtrage local, d’une asymétrie de routage ou d’une mauvaise configuration.
Le handshake TCP ajoute un aller-retour réseau avant l’échange de données. Sur un réseau local, ce délai est presque imperceptible. Sur une connexion longue distance, notamment entre continents, il peut représenter une part visible du temps de chargement initial. C’est pourquoi la latence reste un facteur important dans la performance web.
Pour limiter cet impact, les applications réutilisent souvent les connexions existantes. HTTP keep-alive, HTTP/2 et certaines optimisations côté navigateur évitent de refaire un handshake pour chaque ressource. Les réseaux de diffusion de contenu rapprochent aussi les serveurs des utilisateurs, réduisant le temps nécessaire à l’établissement de la connexion.
Le handshake TCP en trois étapes repose sur une logique claire : le client demande l’ouverture avec SYN, le serveur accepte et confirme avec SYN-ACK, puis le client valide avec ACK. Ce dialogue court permet d’initialiser les numéros de séquence, de vérifier la disponibilité des deux parties et de préparer un échange fiable.
Invisible pour l’utilisateur, ce mécanisme reste pourtant au cœur de la plupart des communications en ligne. Comprendre son fonctionnement aide à mieux lire un diagnostic réseau, à distinguer transport et sécurité, et à mesurer l’importance de la latence. Derrière la simplicité apparente d’une page qui se charge se cache souvent cette première conversation, brève mais décisive.
