TCP et la connexion fiable

Qu'est-ce que TCP ?

TCP (Transmission Control ProtocolTCPRéseauxProtocole de transport qui garantit que les données arrivent complètes, dans l'ordre et sans doublon. Il établit une connexion, numérote chaque segment et retransmet ce qui manque.Voir dans le glossaire) est le protocole de transport le plus utilisé sur Internet. Défini dans la RFC 793 en 1981, il offre un service de communication fiable, ordonné et full-duplex entre deux processus applicatifs.

Les caractéristiques fondamentales de TCP

TCP est utilisé par HTTP/HTTPSHTTPSRéseauxHTTP sécurisé par TLS : chiffre les échanges entre client et serveur et authentifie le serveur via un certificat.Voir dans le glossaire, SSHSSHRéseauxProtocole sécurisé d'accès distant à un serveur, chiffrant session et authentification (clé ou mot de passe).Voir dans le glossaire, SMTP, FTP, et tout protocole nécessitant une livraison garantie des données.

Structure du segment TCP

Un segment TCP est composé d'un en-tête de 20 octets minimum suivi des données applicatives.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────────────────────┬─────────────────────────────────────────┤
│    Port source (16 bits)│      Port destination (16 bits)         │
├─────────────────────────┴─────────────────────────────────────────┤
│                    Numéro de séquence (32 bits)                    │
├───────────────────────────────────────────────────────────────────┤
│                  Numéro d'acquittement (32 bits)                   │
├──────────┬──────────┬─────────────────────────────────────────────┤
│Offset(4) │Réservé(6)│ URG ACK PSH RST SYN FIN │  Fenêtre (16b)   │
├──────────┴──────────┴─────────────────────────┴──────────────────┤
│        Checksum (16 bits)        │    Pointeur urgent (16 bits)    │
├──────────────────────────────────┴──────────────────────────────-─┤
│                   Options (0-40 octets)                            │
├───────────────────────────────────────────────────────────────────┤
│                        Données                                     │
└───────────────────────────────────────────────────────────────────┘

Description des champs clés

Les flags TCP

Le Three-Way Handshake

Avant tout transfert de données, TCP établit une connexion via le three-way handshake (poignée de main en 3 étapes). Ce processus synchronise les numéros de séquence initiaux (ISN) des deux parties.

Les 3 étapes avec numéros de séquence

Client                                    Serveur
  │                                          │
  │──── [SYN] Seq=X ─────────────────────►  │  Étape 1
  │     "Je veux une connexion"              │  Client choisit ISN=X au hasard
  │                                          │
  │  ◄── [SYN-ACK] Seq=Y, Ack=X+1 ─────────│  Étape 2
  │     "D'accord, mon ISN=Y, j'attends X+1"│  Serveur choisit ISN=Y
  │                                          │
  │──── [ACK] Seq=X+1, Ack=Y+1 ───────────►│  Étape 3
  │     "Confirmé, j'attends Y+1"            │
  │                                          │
  │          [Connexion établie]             │

Exemple concret :

Client → Serveur : [SYN]     Seq=1000
Serveur → Client : [SYN-ACK] Seq=5000, Ack=1001
Client → Serveur : [ACK]     Seq=1001, Ack=5001

Pourquoi 3 étapes et pas 2 ?

Deux étapes suffiraient pour que le client sache que le serveur est prêt. Mais il faut aussi que le serveur sache que le client a reçu son SYN-ACK. Le troisième message (ACK du client) confirme cette bidirectionnalité. C'est le minimum mathématique pour synchroniser les deux ISN de manière fiable.

Observer le handshake avec tcpdump

# Capturer le handshake TCP vers un serveur web
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' port 80 -n

# Exemple de sortie :
# 14:30:01.001 IP 192.168.1.100.54321 > 93.184.216.34.80: Flags [S], seq 1234567890
# 14:30:01.052 IP 93.184.216.34.80 > 192.168.1.100.54321: Flags [S.], seq 9876543210, ack 1234567891
# 14:30:01.052 IP 192.168.1.100.54321 > 93.184.216.34.80: Flags [.], ack 9876543211

# Flags : [S]=SYN, [.]=ACK, [S.]=SYN-ACK, [F.]=FIN-ACK, [R]=RST

Transfert de données

Numérotation des octets

TCP traite le flux de données comme un flux d'octets numéroté. Chaque octet a un numéro de séquence. Si 500 octets de données sont envoyés dans un segment avec Seq=1001, le prochain segment aura Seq=1501.

Segment 1 : Seq=1001, 500 octets de données → octets 1001-1500
Segment 2 : Seq=1501, 500 octets de données → octets 1501-2000
Segment 3 : Seq=2001, 200 octets de données → octets 2001-2200

Acquittements cumulatifs

L'acquittement TCP est cumulatif : Ack=N signifie "J'ai reçu tous les octets jusqu'à N-1, j'attends l'octet N."

Envoi     : Seq=1001, 500 octets
Réception : ACK=1501  ("j'ai reçu jusqu'à 1500, j'attends 1501")

Envoi     : Seq=1501, 500 octets
Réception : ACK=2001  ("j'ai reçu jusqu'à 2000, j'attends 2001")

MSS — Maximum Segment Size

Le MSSMSSRéseauxTaille maximale des données utiles d'un segment TCP, soit la MTU moins les en-têtes IP et TCP. Elle vaut typiquement 1 460 octets sur un lien Ethernet.Voir dans le glossaire est la taille maximale des données dans un segment TCP (hors en-tête). Il est négocié lors du handshake via les options TCP.

MSS typique sur Ethernet : 1460 octets
(MTU Ethernet 1500 - En-tête IP 20 - En-tête TCP 20 = 1460)

Contrôle de flux — La fenêtre de réception

Le contrôle de flux protège le récepteur d'une inondation de données. Le récepteur annonce dans chaque ACK sa fenêtre de réceptionfenêtre de réceptionRéseauxVolume de données que le récepteur annonce pouvoir absorber. Elle protège le destinataire de la saturation, là où la fenêtre de congestion protège le réseau.Voir dans le glossaire (rwnd) : la quantité de données qu'il peut accepter sans saturer son tampon.

Récepteur → Émetteur : ACK, rwnd=8192
Signification : "Tu peux m'envoyer jusqu'à 8192 octets sans ACK"

L'émetteur NE PEUT PAS avoir plus de rwnd octets "en vol" sans ACK.

Fenêtre glissante

Flux de données (chaque bloc = 1 segment) :

[1][2][3][4][5][6][7][8][9]...
     │←──── fenêtre rwnd=4 ────→│
     ↑
     Prochain à envoyer

Après ACK du segment 1 :
   [1][2][3][4][5][6][7][8][9]...
          │←── fenêtre ──→│
          ↑
          La fenêtre "glisse" vers la droite

Si rwnd=0, l'émetteur s'arrête et envoie des sondes (Zero Window Probe) toutes les quelques secondes jusqu'à ce que la fenêtre s'ouvre à nouveau.

Contrôle de congestion

Ne confondez pas les deux fenêtres. La fenêtre de réception protège le récepteur de la saturation : il annonce ce qu'il peut absorber. La fenêtre de congestionfenêtre de congestionRéseauxEstimation, par l'émetteur TCP, du volume de données que le réseau peut absorber sans saturer. Elle croît tant que tout passe et chute dès qu'une perte est détectée.Voir dans le glossaire protège le réseau : l'émetteur l'estime seul, à partir des pertes observées. Le débit réel est le minimum des deux.

Le contrôle de congestion protège le réseau (pas seulement le récepteur) d'une surcharge. TCP maintient une fenêtre de congestion (cwnd) côté émetteur, indépendante de rwnd.

La quantité réelle de données en vol est limitée par : min(rwnd, cwnd).

Slow Start

Au démarrage d'une connexion, TCP ne connaît pas la capacité du réseau. Il démarre avec une cwnd petite (typiquement 10 MSS avec IW10) et double cwnd à chaque RTT jusqu'à atteindre un seuil (ssthresh).

RTT 1 : cwnd = 10 MSS  → envoie 10 segments
RTT 2 : cwnd = 20 MSS  → envoie 20 segments
RTT 3 : cwnd = 40 MSS  → envoie 40 segments
...jusqu'au ssthresh

AIMD — Additive Increase Multiplicative Decrease

Une fois le ssthresh atteint, TCP passe en mode évitement de congestion :

• Additive Increase : cwnd augmente de 1 MSS par RTT (progression linéaire)
• Multiplicative Decrease : en cas de perte détectée, cwnd est divisée par 2

Perte détectée (timeout) :
  ssthresh = cwnd / 2
  cwnd = 1 MSS (redémarre slow start)

Perte détectée (3 ACK dupliqués → fast retransmit) :
  ssthresh = cwnd / 2
  cwnd = ssthresh (fast recovery, sans repartir à 0)

Retransmission

TCP retransmet les segments perdus grâce à deux mécanismes :

Timer RTO (Retransmission Timeout)

Chaque segment envoyé déclenche un timer RTO. Si aucun ACK n'est reçu avant expiration, le segment est retransmis. Le RTO est calculé dynamiquement en fonction du RTT mesuré.

Fast Retransmit

Si l'émetteur reçoit 3 ACK dupliqués (même numéro d'ACK répété 3 fois), il infère qu'un segment est perdu et le retransmet immédiatement, sans attendre le RTO. C'est plus rapide que d'attendre le timer.

# Observer les retransmissions avec ss
ss -tn | head -20

# Observer avec tcpdump (recherche de segments avec flag RST ou retransmissions)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

# Statistiques TCP globales (retransmissions, erreurs)
netstat -s | grep -i retrans
# ou
ss -s

The Four-Way Teardown (fermeture propre)

La fermeture d'une connexion TCP nécessite 4 échanges car chaque sens de communication doit être fermé indépendamment.

Client                              Serveur
  │                                    │
  │──── [FIN] Seq=X ─────────────────►│  Client ferme son côté émission
  │                                    │
  │  ◄── [ACK] Ack=X+1 ───────────────│  Serveur confirme
  │                                    │  (le serveur peut encore envoyer des données)
  │                                    │
  │  ◄── [FIN] Seq=Y ─────────────────│  Serveur ferme son côté émission
  │                                    │
  │──── [ACK] Ack=Y+1 ───────────────►│  Client confirme
  │                                    │

L'état TIME_WAIT

Après avoir envoyé le dernier ACK, le client entre en état TIME_WAIT pendant 2 × MSL (Maximum Segment Lifetime, typiquement 60 secondes, soit 2 minutes de TIME_WAIT).

Pourquoi ? Pour s'assurer que :

1. Le dernier ACK est bien arrivé (sinon le serveur renvoie son FIN)
2. Les anciens segments en transit dans le réseau expirent et ne perturbent pas une future connexion sur les mêmes ports

Les états TCP (machine d'états)

TCP est une machine d'états. Voici les états principaux :

CLOSED → [SYN envoyé] → SYN_SENT → [SYN-ACK reçu] → ESTABLISHED
                                                            │
CLOSED ← [FIN-ACK reçu] ← TIME_WAIT ← [FIN reçu] ← FIN_WAIT_2
                                                            │
                                          FIN_WAIT_1 ← [FIN envoyé]

# Voir tous les états TCP en temps réel
ss -tn

# Compter les connexions par état
ss -tn | awk '{print $1}' | sort | uniq -c | sort -rn

# Voir les connexions ESTABLISHED avec le processus propriétaire
ss -tnp state established

# Voir les sockets en TIME_WAIT (indicateur de charge sur un serveur web)
ss -tn state time-wait | wc -l

# Surveiller en temps réel
watch -n 1 'ss -tn | awk "{print \$1}" | sort | uniq -c'

L'algorithme de Nagle

L'algorithme de Nagle (RFC 896) empêche l'envoi de très petits segments ("tinygrams") en regroupant les petites écritures applicatives. TCP attend que :

• Il y ait assez de données pour remplir un segment de taille MSS, ou
• Tous les segments précédemment envoyés ont été acquittés

Cela améliore l'efficacité réseau mais ajoute de la latence. Pour des protocoles interactifs (SSH, gaming), Nagle est souvent désactivé :

# Désactiver Nagle en Python
import socket
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

# Désactiver Nagle avec netcat
nc -N ...

Commandes pratiques complètes

# Observer le trafic TCP sur le port 80
sudo tcpdump -i eth0 tcp port 80 -n

# Afficher toutes les connexions TCP avec processus
ss -tnp

# Tester la connectivité TCP sur un port
nc -zv google.com 443
# Connected to google.com port 443 [tcp/https] succeeded!

# Tester avec timeout
nc -zv -w 3 192.168.1.50 22

# Simuler un client HTTP simple avec netcat
echo -e "GET / HTTP/1.0\r\nHost: example.com\r\n\r\n" | nc example.com 80

# Afficher les statistiques TCP du kernel
cat /proc/net/tcp

# Voir les connexions TCP en détail (verbose)
ss -tnip

# Surveiller les connexions d'un port spécifique
watch -n 1 'ss -tnp | grep :443'

Récapitulatif

Passez maintenant au chapitre suivant : UDP : la vitesse avant tout — le protocole sans connexion qui privilégie la rapidité à la fiabilité.

TCP = connexion + ACK + retransmission + fenêtres. La fiabilité a un coût de latence.

Lisez les retransmissions et fenêtres (ss / capture) avant d'accuser le réseau.

Flux ≠ congestion : l'un protège le récepteur, l'autre le chemin.

Handshake et états : lire ss / netstat

SYN, SYN-ACK, ACK établissent la connexion. FIN/ACK et variantes ferment. Les états LISTEN, ESTABLISHED, TIME_WAIT, CLOSE_WAIT racontent une histoire. Trop de CLOSE_WAIT côté serveur suggère une application qui ne ferme pas. Des TIME_WAIT nombreux côté client à fort turnover sont souvent normaux.

Fenêtre, congestion, retransmission

TCP ajuste le débit au réseau et au récepteur. Pertes → retransmissions → débit qui chute. Ce n’est pas « TCP lent par nature » : c’est TCP qui privilégie fiabilité et équité approximative. Sur un lien lossy (Wi-Fi saturé), le ressenti applicatif peut s’effondrer.

Middleboxes

NATNATRéseauxMécanisme qui permet à plusieurs machines d'un réseau privé de partager une seule adresse IP publique. Il compense la pénurie d'adresses IPv4 mais complique les connexions entrantes.Voir dans le glossaire, firewalls stateful, balanceurs cassent parfois les hypothèses (timeouts idle, ALG, reset). Un long flux idle peut mourir silencieusement ; les keepalive applicatifs aident. Documentez les timeouts de votre chemin.

Un SYN sans SYN-ACK oriente vers filtre, service down, ou asymétrie de routage — pas vers « DNSDNSRéseauxSystème qui traduit un nom de domaine en adresse IP, par interrogations successives de la racine, des serveurs de premier niveau puis des serveurs faisant autorité.Voir dans le glossaire ».

TLS au-dessus de TCP

Beaucoup d’incidents « TCP » sont en réalité des échecs de handshake TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire (certificat, SNI, version). Séparez clairement connectivité TCP et négociation crypto dans votre méthode.

Capturer seulement 5 secondes autour de l’échec vaut mieux qu’un fichier de 2 Go sans hypothèse.

Timeouts et applications bavardes

Les applis qui ouvrent des milliers de connexions courtes stressent NAT et stacks. Le pooling HTTP, les keepalive, et des timeouts cohérents entre client, proxy et serveur réduisent les surprises. Alignez les valeurs : un proxy à 60s devant un serveur à 30s crée des 502 cryptiques.

En diag, comparez une connexion locale au serveur et une depuis le client distant. Si local OK et distant KO, le réseau path est suspect. Si les deux KO, regardez le service.

Les resets (RST) abondants méritent une capture courte : qui reset, à quel moment du handshake ou du flux ?

Lecture d’une capture handshake

Filtrez tcp.flags.syn==1 pour voir les tentatives. Un SYN retransmis signe perte ou filtre. Un SYN-ACK puis silence signe souvent un problème de chemin retour ou de checksum middlebox. Un handshake complet puis RST applicatif oriente vers le service. Apprendre à lire ces motifs évite d’acheter de la bande passante pour un bug d’appli.

Paramètres somaxconn, files d’accept, et exhaustion de file descriptors côté serveur produisent des symptômes « réseau » alors que c’est l’hôte saturé. Regardez aussi ss -s et les métriques OS.

Performance TCP en langage simple

Bande passante × délai (BDP) explique pourquoi des fenêtres trop petites sous-utilisent un lien longue distance. Les pertes sur liens à fort RTT coûtent cher. Ce n’est pas toujours « il faut plus de débit » : parfois il faut moins de perte, un meilleur wifi, ou du TCP modern (BBR) côté serveur contrôlé.

Côté appli, les petites écritures sans regroupement multiplient les paquets. Les Nagle/delayed ACK mal compris créent des latences étranges. Mesurez avant de tunner des sysctls au jugé.

Pour les LB, le mode proxy TCP vs pass-through change ce que voient les backends (IP source réelle). Documentez le mode : cela affecte ACL et journaux.

Timeouts applicatifs vs timeouts réseau

Dressez la table des timeouts : client HTTP, reverse proxy, LB, firewallpare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire idle, serveur applicatif. L’écart crée des erreurs intermittentes aux heures creuses (connexions idle). Harmonisez. Ajoutez des healthchecks qui ne sont pas que des pings TCP : un accept sans worker prêt ment.

Pour les API longues, préférez patterns async (job + polling) plutôt que d’allonger tous les timeouts jusqu’à l’infini. Les timeouts longs masquent des pannes et monopolisent des workers.

En diag, un curl -v --connect-timeout 3 --max-time 10 borne le test et évite d’attendre une minute « pour voir ».

Checklist handshake en trois minutes

1. ss côté serveur : LISTEN sur la bonne IP ? 2) Depuis client : connect timeout ou reset ? 3) Middlebox logs. 4) Capture 5s si besoin. 5) Si TCP OK, montez à TLS/HTTP. Cette checklist évite de commencer par recompiler une appli alors que le security group est fermé. Affichez-la dans le channel ops.

Les load balancers en mode drain doivent finir les connexions existantes : comprenez les états pendant un déploiement. Un reset massif au deploy n’est pas une fatalité TCP, c’est souvent un timeout de drain trop court.

Approfondissement terrain — tcp-connexion

Dans le chapitre tcp-connexion, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau. Si vous ne pouvez pas la reformuler, la notion n’est pas encore opérationnelle. Fermez chaque session d’étude par une question ouverte que vous résoudrez la fois suivante. Gardez une liste de « myths » à déconstruire : port élevé = sécurité, ping OK = service OK, etc. Ces myths coûtent cher en production ; les tuer est un objectif pédagogique explicite. Mesurez votre temps moyen pour classer un ticket réseau simple : il doit baisser au fil des chapitres.