Commencer→
Retour au cours

infra / reseaux-tcp-ip

Three-way handshake TCP en détail

Leçon 61 exercice

Explication

Ce que vous allez apprendre

  • Décrire précisément les trois étapes du handshake TCP (SYN, SYN-ACK, ACK)
  • Comprendre pourquoi TCP a besoin de cette poignée de main avant d'échanger la moindre donnée
  • Lire les états d'une connexion TCP (LISTEN, ESTABLISHED, TIME-WAIT...) avec ss -tan
  • Observer un handshake réel avec tcpdump et reconnaître les flags SYN/ACK/FIN/RST
  • Repérer un signe d'attaque (SYN flood) ou de perte de paquets (retransmissions) via les métriques TCP

Dans quel contexte ?

Un administrateur système remarque que son serveur web devient très lent à répondre alors que le CPU et la mémoire semblent normaux. En lançant ss -tan state syn-recv | wc -l, il découvre des milliers de connexions bloquées en SYN-RECV : quelqu'un envoie des paquets SYN sans jamais terminer le handshake, un schéma typique d'attaque par déni de service (SYN flood) qui épuise les ressources du serveur en connexions à moitié ouvertes.

Pourquoi une connexion doit être "établie" avant d'échanger des données

TCP promet la fiabilité : aucune donnée perdue, dans le bon ordre. Pour tenir cette promesse, les deux machines doivent d'abord se mettre d'accord sur les règles de base de leur échange (à partir de quel numéro de séquence commencer à compter, par exemple). C'est précisément le rôle du three-way handshake : une poignée de main en trois étapes qui établit cet accord avant que la moindre donnée applicative ne circule.

État TCPSignification
LISTENEn attente de connexions entrantes
SYN-RECVSYN-ACK envoyé, attend l'ACK final
ESTABLISHEDConnexion pleinement ouverte
TIME-WAITFermeture terminée, port bientôt libéré

Piège fréquent

Un grand nombre de connexions en TIME_WAIT n'est PAS forcément une anomalie : c'est un comportement normal et volontaire de TCP après une fermeture. En revanche, un grand nombre de connexions bloquées en SYN-RECV est un signal d'alerte bien plus sérieux, souvent révélateur d'une attaque en cours.

Pourquoi trois étapes, ni plus ni moins

Deux étapes ne suffiraient pas : le client proposerait un numéro de départ, le serveur répondrait avec le sien, mais le serveur n'aurait alors aucune confirmation que le client a bien reçu sa réponse. La troisième étape (l'accusé de réception final du client) referme cette boucle de confirmation mutuelle. C'est un principe qu'on retrouve dans beaucoup de protocoles fiables : chaque partie doit savoir que l'autre a bien reçu son dernier message.

Les états d'une connexion racontent son histoire

Une connexion TCP passe par plusieurs états successifs (en attente, en cours d'établissement, établie, en cours de fermeture...). Observer ces états sur un serveur donne des indices précieux : trop de connexions bloquées en attente d'établissement peut trahir une attaque, trop de connexions en attente de fermeture peut trahir une application qui ne ferme pas proprement ses ressources.

Le lien avec le diagnostic réseau

Cette mécanique interne, invisible en temps normal, redevient centrale dès qu'un problème de connexion survient : savoir lire ces états et repérer des retransmissions permet de distinguer un problème de réseau (paquets perdus) d'un problème applicatif (le serveur ne répond simplement pas).

Commandes & code

Three-way handshake TCP en détail

text
Client                                          Serveur
  |                                                 |
  |------------- SYN (seq=x) --------------------->|   1. Client demande l'ouverture
  |                                                 |
  |<----- SYN-ACK (seq=y, ack=x+1) ----------------|   2. Serveur accepte + demande à son tour
  |                                                 |
  |------------- ACK (ack=y+1) --------------------->|   3. Client confirme, connexion ÉTABLIE
  |                                                 |
  |============ échange de données ================|

# Fermeture (four-way, TCP est full-duplex donc chaque sens se ferme séparément)
  |------------- FIN ------------------------------>|
  |<------------ ACK -------------------------------|
  |<------------ FIN -------------------------------|
  |------------- ACK ------------------------------->|   connexion fermée, client passe en TIME_WAIT
bash
# Observer le handshake réellement avec tcpdump
sudo tcpdump -i eth0 -n 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)' -c 6
# Flags visibles dans la sortie :
# [S]    = SYN
# [S.]   = SYN-ACK  (le point = ACK combiné)
# [.]    = ACK simple
# [F.]   = FIN-ACK
# [R]    = RST (réinitialisation brutale, ex: port fermé ou connexion refusée)

# Vérifier les états d'une connexion TCP sur la machine
ss -tan
# État        Signification
# LISTEN      en attente de connexions entrantes
# SYN-SENT    SYN envoyé, attend le SYN-ACK
# SYN-RECV    SYN-ACK envoyé, attend l'ACK final
# ESTABLISHED connexion pleinement ouverte
# FIN-WAIT-1/2 fermeture initiée localement
# TIME-WAIT   fermeture terminée, attend un délai avant de libérer le port
# CLOSE-WAIT  l'autre côté a fermé, en attente que l'appli locale ferme aussi

# Un grand nombre de connexions en SYN-RECV = signe possible d'une attaque SYN flood
ss -tan state syn-recv | wc -l

# Numéro de séquence et fenêtre de réception (contrôle de flux)
sudo tcpdump -i eth0 -n -v port 443 -c 1
# seq 1:1461, win 65535 -> "win" = taille de fenêtre annoncée, limite le volume envoyable
# sans attendre d'accusé de réception (impacte directement le débit sur liens à forte latence)

# Retransmissions : signe de perte de paquets ou de congestion
ss -ti           # affiche des infos TCP internes (rtt, cwnd, retrans) par connexion
nstat -az TcpRetransSegs      # compteur cumulé de segments retransmis

Résumé

  • Trois étapes pour ouvrir une connexion (SYN, SYN-ACK, ACK), quatre pour la fermer (FIN/ACK de chaque côté).
  • TIME_WAIT est normal et volontaire : la connexion attend un délai avant de libérer le port.
  • Beaucoup de SYN-RECV ou de retransmissions TCP indiquent respectivement une possible attaque ou de la perte de paquets.

Exercices pratiques

1 disponible
1

Mission : confirmer un SYN flood en cours

Objectif : Utiliser les états de connexion TCP pour distinguer une attaque par déni de service d'une simple charge de trafic légitime.

Contexte

Le serveur web d'une entreprise devient très lent, sans que le CPU ni la mémoire ne semblent en cause. En inspectant les connexions TCP, tu observes 5000 connexions à l'état SYN-RECV et seulement 3 à l'état ESTABLISHED. Un collègue pense que c'est simplement "beaucoup de trafic".

Résoudre l’exercice →