Le protocole de contrôle de transmission (TCP) est l'un des principaux protocoles de la suite Internet. Souvent cité avec IP sous la forme "TCP/IP", il complète le protocole Internet (IP) : tandis que l'IP s'occupe de l'acheminement des paquets vers la bonne adresse, le TCP garantit la transmission fiable, ordonnée et contrôlée des données entre deux applications communicantes.
Qu'est‑ce que TCP ?
TCP est un protocole orienté connexion et fiable qui fonctionne au-dessus d'IP. Il offre aux applications un flux de données continu et géré, en prenant en charge :
- la mise en ordre des paquets reçus ;
- la détection et la retransmission des données perdues ;
- le contrôle de flux pour éviter d'inonder le récepteur ;
- le contrôle de congestion pour limiter l'impact sur le réseau.
Fonctionnement général
Avant d'échanger des données, deux hôtes établissent une connexion TCP. Les données sont découpées en segments, chacun comportant un en‑tête TCP et une portion de données. Chaque segment est identifié par un numéro de séquence ; le destinataire envoie des accusés de réception (ACK) indiquant le prochain numéro de séquence attendu. En cas de segments manquants ou corrompus, le destinataire ne progressera pas dans l'accusé, ce qui déclenche une retransmission du côté émetteur.
Établissement et terminaison d'une connexion
Le processus d'établissement suit le mécanisme dit du "three‑way handshake" :
- L'émetteur envoie un segment SYN (synchronize) avec un numéro de séquence initial.
- Le destinataire répond par un segment SYN+ACK confirmant le SYN et fournissant son propre numéro de séquence initial.
- L'émetteur envoie un ACK final et la connexion est établie.
La terminaison peut être réalisée de façon ordonnée à l'aide de segments FIN (fin de transmission) échangés puis accusés, ou brusquement par un RST (reset) en cas d'erreur ou d'interruption.
Contrôle de flux et contrôle de congestion
TCP met en œuvre deux mécanismes distincts mais complémentaires :
- Contrôle de flux : le récepteur annonce une fenêtre (window) qui indique combien d'octets il peut recevoir sans envoyer d'ACK. L'émetteur s'ajuste à cette fenêtre pour ne pas déborder le tampon du destinataire.
- Contrôle de congestion : l'émetteur adapte sa vitesse en fonction de l'état du réseau. Les algorithmes usuels incluent Slow Start, Congestion Avoidance, et les mécanismes de Fast Retransmit / Fast Recovery. L'idée générale est d'augmenter progressivement le débit jusqu'à détecter une perte (signe de congestion), puis de réduire temporairement la fenêtre de congestion pour laisser le réseau se rétablir.
Format d'un segment TCP (champs essentiels)
Un en‑tête TCP contient plusieurs champs importants :
- Ports source et destination : identifient les applications (ex. HTTP sur le port 80).
- Numéro de séquence et numéro d'accusé de réception (ACK) : pour ordonner et confirmer les données.
- Data offset : taille de l'en‑tête TCP.
- Flags : bits de contrôle (SYN, ACK, FIN, RST, PSH, URG).
- Window : taille de la fenêtre de réception.
- Checksum : vérification d'intégrité de l'en‑tête et des données.
- Options : par exemple MSS (Maximum Segment Size), Window Scale, SACK, timestamps.
La somme de contrôle couvre l'en‑tête TCP, les données et un pseudo‑entête IP afin d'améliorer la détection d'erreurs.
Retransmission et gestion des pertes
TCP calcule un délai d'attente de retransmission (RTO) basé sur les mesures du temps aller‑retour (RTT). Si un segment n'est pas accusé avant le RTO, il est retransmis. Les optimisations modernes incluent :
- SACK (Selective Acknowledgment) : permet au récepteur d'indiquer précisément quels blocs de données ont été reçus, évitant des retransmissions inutiles.
- Retransmission rapide : déclenchée par la réception de plusieurs ACKs dupliqués (souvent trois), ce qui permet de réagir plus vite qu'en attendant le RTO.
Ports et applications
TCP utilise des ports pour distinguer les services. Exemples courants :
- HTTP/HTTPS (web) : ports 80 et 443
- SMTP (mail) : port 25
- FTP : ports 20/21
- SSH : port 22
Les sockets TCP (adresse IP + port) représentent l'extrémité de la communication et permettent aux applications d'envoyer/recevoir des flux de données fiables.
Différences entre TCP et UDP
- TCP : orienté connexion, fiable, contrôle de flux/congestion, plus lent et avec surcharge d'en‑tête.
- UDP : sans connexion, non fiable, faible latence et moindre surcharge — adapté aux flux temps réel (voix, vidéo, jeux) où la perte occasionnelle est tolérable.
Aspects pratiques et limites
- TCP est stateful : les routeurs NAT ou pare‑feux conservent l'état des connexions ; si cet état est perdu, la connexion peut échouer.
- La performance TCP dépend du MSS et du MTU ; le fractionnement (fragmentation) peut impacter la latence.
- Certaines applications choisissent UDP avec des mécanismes applicatifs pour contourner les limites de TCP (par ex. QUIC pour HTTP/3 qui repose sur UDP).
- Les extensions récentes (window scaling, SACK, timestamps) améliorent le comportement de TCP sur les réseaux modernes à haute latence ou haut débit.
Historique et normalisation
Le fonctionnement de TCP a été défini initialement dans la RFC 793 (1981) et a fait l'objet de nombreuses extensions et améliorations depuis. De nombreuses RFCs décrivent les algorithmes de contrôle de congestion, les options et les optimisations utilisées aujourd'hui.
Points à retenir
- TCP garantit une transmission fiable et ordonnée des données entre applications.
- Il utilise un établissement de connexion (three‑way handshake), des numéros de séquence et des ACK pour suivre l'état de la communication.
- Il combine contrôle de flux et contrôle de congestion pour adapter le débit aux capacités du récepteur et du réseau.
- Malgré son overhead, TCP reste le choix privilégié pour les applications nécessitant la fiabilité (web, mail, transferts de fichiers).