1 – Définition du protocole TCP

Le protocole TCP est basé en couche 4 du modèle OSI. Il ouvre une session et effectue lui-même le control d’erreur. Il est alors appelé  « mode connecté ». Vous trouverez tous les détails du protocole TCP dans la RFC 793.

2 – Structure de l’entête TCP

Voici la structure de l’entête TCP basé sur 20 octets.

Voici le complément de l’entête TCP qui est optionnelle basé sur 4 octets.

3 – Mode de transfert TCP

Voici les différents types de communication basés sur le mode connecté de TCP :

3.1 – Ouverture de session

==> SYN=1 – ACK=0 – SeqNum=100 – AckNum=xxx
<== SYN=1 – ACK=1 – SeqNum=300 – AckNum=101
==> SYN=0 – ACK=1 – SeqNum=101 – AckNum=301

3.2 – Transfert des données

==> ACK=1 – SeqNum=101 – AckNum=301 – Data=30 octets
<== ACK=1 – SeqNum=301 – AckNum=131 – Data=10 octets
==> ACK=1 – SeqNum=131 – AckNum=311 – Data=5 octets
<== ACK=1 – SeqNum=311 – AckNum=136 – Data=10 octets

3.3 – Fermeture de session

==> ACK=1 – FIN=1 – SeqNum=321 – AckNum=136
<== ACK=1 – FIN=0 – SeqNum=136 – AckNum=321

Puis le receveur de la demande de fermeture de session demande à son tour la fermeture de session :

<== ACK=1 – FIN=1 – SeqNum – AckNum
==> ACK=1 – FIN=0 – SeqNum – AckNum

3.4 – Fermeture brutale de connexion

1ère cas possible :

==> ACK=1 – RST=0 – SeqNum=200 – AckNum=400
<== ACK=0 – RST=1 – SeqNum=400 – ACKNum=xxx

2nd cas possible :

<== ACK=0 – RST=0 – SeqNum=200 – Data=30 octets
==> ACK=0 – RST=1 – SeqNum=230 – Data=xxx

4 – La fenêtre coulissante

La fenêtre coulissante, plus connue sous le nom de « Sliding Windows » est employée pour transférer des données entre les hôtes. La fenêtre définit le volume de données susceptibles d’être passées via une connexion TCP, avant que le récepteur n’envoie un accusé de réception. Chaque hôte comporte une fenêtre d’émission et une fenêtre de réception qu’il utilise pour buffériser les données en continu, sans devoir attendre un accusé de réception pour chaque paquet. Cela permet au récepteur de recevoir les paquets dans le désordre et de profiter des délais d’attente pour réorganiser les paquets. La fenêtre émettrice contrôle les données émises, si elle ne reçoit pas d’accusé de réception au bout d’un certain temps, elle retransmet le paquet.

Considérations sur le débit :

Le protocole TCP a été conçu pour offrir des performances optimales en présence de conditions de liaison variées et les systèmes d’exploitations comportent des améliorations telles que celles prenant en charge la RFC 1323. Le débit réel d’une liaison dépend d’un certain nombre de variables, mais les facteurs les plus importants sont les suivants :

• Vitesse de la liaison (bits par seconde pouvant être transmis)

• Retard de propagation

• Dimension de la fenêtre (quantité de données n’ayant pas fait l’objet d’un accusé de réception et qui peuvent être en attente sur une connexion TCP)

• Fiabilité de la liaison

• Encombrement du réseau et des périphériques intermédiaires

• MTU du parcours

Voici quelques considérations fondamentales sur le calcul du débit TCP : 

La capacité d’un canal de communication est égale à la bande passante multipliée par le temps de transmission aller-retour. Elle est connue sous le nom de produit bande passante-retard. Si la liaison est fiable, pour obtenir des performances optimales, la dimension de la fenêtre doit être supérieure ou égale à la capacité du canal de communication, de manière à permettre à la pile d’envoi de le remplir. La plus grande dimension de fenêtre pouvant être spécifiée, en raison du champ de 16 bits de l’entête TCP, est de 65535. Des fenêtres plus larges peuvent toutefois être négociées grâce au redimensionnement des fenêtres.

Le débit ne peut jamais excéder la taille de la fenêtre divisée par le temps de transmission aller-retour. Si la liaison n’est pas fiable ou est encombrée et que des paquets sont perdus, l’utilisation fenêtre de taille supérieure ne garantit pas nécessairement un meilleur débit. Windows 2000 prend en charge non seulement le dimensionnement des fenêtres, mais également les accusés de réception sélectifs (SACK, décrits dans la RFC 2018) pour améliorer les performances au sein d’environnements qui présentent des pertes de paquets. Il prend également en charge l’horodatage (décrit dans la RFC 1323) pour une meilleure évaluation RTT.

Le retard de propagation dépend de la vitesse de la lumière, des latences de l’équipement de transmission, etc. Le retard de transmission dépend donc de la vitesse du support.

Pour un parcours spécifique, le retard de propagation est fixe, mais le retard de transmission dépend de la taille du paquet. À des vitesses réduites, le retard de transmission constitue un facteur limitatif. À des vitesses élevées, le retard de propagation peut devenir un facteur de limitation.

En résumé, les piles TCP/IP peuvent s’adapter à la plupart des conditions de réseau et fournir dynamiquement le meilleur débit et la meilleure fiabilité possibles pour chaque connexion. Les essais de mise au point manuelle sont souvent contre-productifs, sauf lorsqu’un ingénieur réseau qualifié procède préalablement à une étude précise du flux de données.

5 – Définition des différents champs

5.1 – Port source TCP

Le champ Port source est codé sur 16 bits et correspond au port relatif à l’application en cours sur la machine source.

5.2 – Port destination TCP

Le champ Port destination est codé sur 16 bits et correspond au port relatif à l’application en cours sur la machine de destination.

Vous trouverez la liste des ports TCP officialisées par l’IANA, organisation gérant mondialement les adressage IP.

5.3 – Numéro de séquence

Le champ Numéro de séquence est codé sur 32 bits et correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.

5.4 – Numéro de l’accusé de réception

Le champ Numéro de séquence est codé sur 32 bits et définit un acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les Datagrammes <1500 ont été reçus

5.5 – Offset

Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits dans l’entête TCP. Ce champ indique donc où les données commencent.

5.6 – Réservé

Le champ Réservé est codé sur 6 bits et il servira pour des besoins futurs. Ce champ doit être marqué à 0. Au jour d’aujourd’hui, on peut considérer que les besoins futurs se transforment en un champ non utilisé.

• 3 bits – Réservé
• 1 bit  – ECN/NS
• 1 bit  – CWR
• 1 bit  – ECE

5.7 – Flags

Voici la liste des flags :

• Le champ URG est codé sur 1 bit et indique que le champ Pointeur de donnée urgente est utilisé.
• Le champ ACK est codé sur 1 bit et indique que le numéro de séquence pour les acquittements est valide.
• Le champ PSH est codé sur 1 bit et indique au récepteur de délivrer les données à l’application  et de ne pas attendre le remplissage des tampons.
• Le champ RST est codé sur 1 bit et demande la réinitialisation de la connexion.
• Le champ SYN est codé sur 1 bit et indique la synchronisation des numéros de séquence.
• Le champ FIN est codé sur 1 bit et indique fin de transmission.

Voici les valeurs en hexa du champs Flags pour les combinaisons intéressantes suivantes :

• 0x00 NULL
• 0x01 FIN
• 0x02 SYN
• 0x03 FIN-SYN
• 0x08 PSH
• 0x09 FIN-PSH
• 0x0A SYN-PSH
• 0x0B FIN-SYN-PSH
• 0x10 ACK
• 0x11 FIN-ACK
• 0x12 SYN-ACK
• 0x13 FIN-SYN-ACK
• 0x18 PSH-ACK
• 0x19 FIN-PSH-ACK
• 0x1A SYN-PSH-ACK
• 0x1B FIN-SYN-PSH-ACK
• 0x40 ECE
• 0x41 FIN-ECE
• 0x42 SYN-ECE
• 0x43 FIN-SYN-ECE
• 0x48 PSH-ECE
• 0x49 FIN-PSH-ECE
• 0x4A SYN-PSH-ECE
• 0x4B FIN-SYN-PSH-ECE
• 0x50 ACK-ECE
• 0x51 FIN-ACK-ECE
• 0x52 SYN-ACK-ECE
• 0x53 FIN-SYN-ACK-ECE
• 0x58 PSH-ACK-ECE
• 0x59 FIN-PSH-ACK-ECE
• 0x5A SYN-PSH-ACK-ECE
• 0x5B FIN-SYN-PSH-ACK-ECE
• 0x80 CWR
• 0x81 FIN-CWR
• 0x82 SYN-CWR
• 0x83 FIN-SYN-CWR
• 0x88 PSH-CWR
• 0x89 FIN-PSH-CWR
• 0x8A SYN-PSH-CWR
• 0x8B FIN-SYN-PSH-CWR
• 0x90 ACK-CWR
• 0x91 FIN-ACK-CWR
• 0x92 SYN-ACK-CWR
• 0x93 FIN-SYN-ACK-CWR
• 0x98 PSH-ACK-CWR
• 0x99 FIN-PSH-ACK-CWR
• 0x9A SYN-PSH-ACK-CWR
• 0x9B FIN-SYN-PSH-ACK-CWR
• 0xC0 ECE-CWR
• 0xC1 FIN-ECE-CWR
• 0xC2 SYN-ECE-CWR
• 0xC3 FIN-SYN-ECE-CWR
• 0xC8 PSH-ECE-CWR
• 0xC9 FIN-PSH-ECE-CWR
• 0xCA SYN-PSH-ECE-CWR
• 0xCB FIN-SYN-PSH-ECE-CWR
• 0xD0 ACK-ECE-CWR
• 0xD1 FIN-ACK-ECE-CWR
• 0xD2 SYN-ACK-ECE-CWR
• 0xD3 FIN-SYN-ACK-ECE-CWR
• 0xD8 PSH-ACK-ECE-CWR
• 0xD9 FIN-PSH-ACK-ECE-CWR
• 0xDA SYN-PSH-ACK-ECE-CWR
• 0xDB FIN-SYN-PSH-ACK-ECE-CWR

5.8 – Fenêtre

Le champ Fenêtre « Windows » est codé sur 16 bits et correspond au nombre d’octets à partir de la position marquée dans l’accusé de réception que le récepteur est capable de recevoir. Le destinataire ne doit donc pas envoyer les paquets après Numéro de séquence + Window.

5.9 – Checksum

Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 4 TCP. 

Le Checksum est constitué en calculant le complément à 1 sur 16 bits de la somme des compléments à 1 des octets de l’entête et des données pris deux par deux (mots de 16 bits). Si le message entier contient un nombre impair d’octets, un 0 est ajouté à la fin du message pour terminer le calcul du Checksum. Cet octet supplémentaire n’est pas transmis. Lors du calcul du Checksum, les positions des bits attribués à celui-ci sont marquées à 0.

Le Checksum couvre de plus, une pseudo entête de 96 bits préfixée à l’entête TCP. Cette pseudo entête comporte les adresses Internet sources et destinataires, le type de protocole et la longueur du message TCP (incluant la data). Ceci protège TCP contre les erreurs de routage.

La longueur TCP compte le nombre d’octets de l’entête TCP et des données du message, en excluant les 12 octets de la pseudo entête. 

Voici un exemple de fonction permettant le calcul du checksum TCP. Elle est identique à celle de UDP.

struct pseudo_entete
     {
     unsigned long ip_source; // Adresse ip source
     unsigned long ip_destination; // Adresse ip destination
     char mbz; // Champs à 0
     char type; // Type de protocole (6->TCP et 17->UDP)
     unsigned short length; // htons( Entete TCP ou UDP + Data )
     };
 
 unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
     {
     unsigned long checksum=0;
     // ********************************************************
     // Complément à 1 de la somme des complément à 1 sur 16 bits
     // ********************************************************
     while(taille>1)
         {
         if (liberation==TRUE)
             liberation_du_jeton(); // Rend la main à la fenêtre principale
         checksum=checksum+*data++;
         taille=taille-sizeof(unsigned short);
         }
 
     if(taille)
         checksum=checksum+*(unsigned char*)data;
 
     checksum=(checksum>>16)+(checksum&0xffff);
     checksum=checksum+(checksum>>16);
 
     return (unsigned short)(~checksum);
     }
 
 unsigned short calcul_du_checksum_tcp(bool liberation, unsigned long ip_source_tampon, unsigned long ip_destination_tampon, struct tcp tcp_tampon, char data_tampon[65535])
     {
     struct pseudo_entete pseudo_tcp;
     char tampon[65535];
     unsigned short checksum;
 
     // ********************************************************
     // Initialisation du checksum
     // ********************************************************
     tcp_tampon.checksum=0; // Doit être à 0 pour le calcul
 
     // ********************************************************
     // Le calcul du Checksum TCP (Idem à UDP)
     // ********************************************************
     // Le calcul passe par une pseudo entete TCP + l'entete TCP + les Data
     pseudo_tcp.ip_source=ip_source_tampon;
     pseudo_tcp.ip_destination=ip_destination_tampon;
     pseudo_tcp.mbz=0;
     pseudo_tcp.type=IPPROTO_TCP;
     pseudo_tcp.length=htons((unsigned short)(sizeof(struct tcp)+strlen(data_tampon)));
     memcpy(tampon,&pseudo_tcp,sizeof(pseudo_tcp));
     memcpy(tampon+sizeof(pseudo_tcp),&tcp_tampon,sizeof(struct tcp));
     memcpy(tampon+sizeof(pseudo_tcp)+sizeof(struct tcp),data_tampon,strlen(data_tampon));
     checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(pseudo_tcp)+sizeof(struct tcp)+strlen(data_tampon));
 
     return(checksum);
     }

5.10 – Pointeur de donnée urgente

Le champ Pointeur de donnée urgente est codé sur 16 bits et communique la position d’une donnée urgente en donnant son décalage par rapport au numéro de séquence. Le pointeur doit pointer sur l’octet suivant la donnée urgente. Ce champ n’est interprété que lorsque le Flag URG est marqué à 1. Dès que cet octet est reçu, la pile TCP doit envoyer les données à l’application.

5.11 – Options

Les champs d’options peuvent occuper un espace de taille variable à la fin de l’entête TCP. Ils formeront toujours un multiple de 8 bits. Toutes les options sont prises en compte par le Checksum. Un paramètre d’option commence toujours sur un nouvel octet. Il est défini deux formats types pour les options: 

• Cas 1 – Option mono-octet. 
• Cas 2 – Octet de type d’option, octet de longueur d’option, octet de valeur d’option.

La longueur d’option prend en compte l’octet de type, l’octet de longueur lui-même et tous les octets de valeur et est exprimée en octet. 
La liste d’option peut être plus courte que ce que l’offset de données pourrait le faire supposer. Un octet de remplissage « Bourrage » devra être dans ce cas rajouté après le code de fin d’options.

5.12 – Bourrage

Le champ Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler le champ option afin d’obtenir une entête TCP multiple de 32 bits. La valeur des bits de bourrage est 0.

6 – Les vidéos

• 6.1 - What is QUIC ?

  Among the many problems with TCP is that the approach to reliably delivering data between machines is one-size-fits-all. But not every connection has the same needs, and some have extra information that can be used to improve reliable transport. Partly to enable innovation and customization at the transport layer (and partly to address well-understood problems with TPC), Google has created and is rolling out QUIC: Quick UDP Internet Connection. QUIC enables secure connections to be established using fewer round-trips, reducing connection latency—​particularly when reconnecting to servers that have been used before. QUIC is also designed to fetch all of the multiple resources typically needed to render a web page using a single connection while avoiding the head-of-the-line that TCP would cause.

  

• 6.2 - What is the TCP ?

  Cette video en anglais vous présente le protocole TCP. The transmission control protocol (TCP) is today’s most widely used transport protocol. It adds three pieces of important functionality to the best effort internet protocol (IP). First, TCP enables reliable delivery between two internet connected computers. Second, TCP allows multiple clients and connections to share network resources with some degree of fairness. Third, TCP adds a layer of naming that separates multiple connections between the same computers into logical connections. The details of how TCP accomplishes these tasks are complex, but the design principles are fairly simple.

  

• 6.3 - What are some problems with TCP ?

  Cette video en anglais vous présente les inconvénients du protocole TCP (Transmission Control Protocol). TCP is an old, very well tested, and venerable protocol. It has enabled reliable internet connections for decades. And yet, it has well-known problems that are causing researchers and engineers to develop new transport-layer protocols. Some of these problems are being exacerbated by changes to the internet’s architecture, including the growing number of slow and high-latency wireless connections generated by mobile devices.

  

• 6.4 - Detect TCP Delays with Wireshark

  Cette vidéo en anglais vous montre comment detecter et analyser le délay dans le protocole TCP (Transmission Control Protocol). Use the tcp.time_delta field to quickly locate slow points inside separate TCP streams in your trace files.

  

• 6.5 - Session TCP animée et en musique

  Vidéo présentant, de manière très dynamique, la session du protocole TCP. The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite (IP), and is so common that the entire suite is often called TCP/IP.

  

• 6.6 - UDP and TCP: Comparison of Transport Protocols

  Video en anglais présentant, avec de beaux slides, la comparaison entre les protocoles TCP et UDP.

• 6.7 - UDP, TCP, IP and Ethernet Header

  Video en anglais présentant en détail l'ensemble des champs des entêtes UDP, TCP, IP et Ethernet.

  

• 6.8 - TCP header

  Video en anglais présentant en détail l'ensemble des champs de l'entête TCP.

  

• 6.9 - Cours sur la session TCP, numéro de séquence et ACK

  Cette video vous explique de manière pragmatique le fonctionnement d'une session TCP (handshake), du numéro de séquence et des ACK (Acknowledgment).

  

• 6.10 - Cours réseaux sur TCP, UDP via netstat

  A l'aide de la commande netstat, voici une video claire expliquant la différence entre TCP et UDP.

  

• 6.11 - Détection d'erreur et retransmission

  Cette vidéo présente les différentes méthodes de contrôle d'erreur et de retransmission dans le monde Ethernet et IP.

  

• 6.12 - La couche Transport TCP

  TCP, UDP : quelle utilité ? quelles similitudes? quelles différences ? ... une réponse en 5 minutes.

  

7 – Suivi du document

Création et suivi de la documentation par _SebF

Modification de la documentation par _SebF

• Ajout du schéma de la pseudo entête.

Modification de la documentation par _SebF

• Ajout de la référence aux port TCP assignés par l’Iana.

Modification de la documentation par _SebF

• Ajout du paragraphe « Considérations sur le débit »  dans le chapitre 4  « La fenêtre coulissante ».

Modification de la documentation par _SebF

• Ajout du paragraphe « Voici les valeurs en hexa du champs Flags pour les combinaisons intéressantes suivantes » dans le chapitre « 5.7 – Flags ».

8 – Discussion autour de l’entête TCP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’entête TCP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :