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.

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.

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

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

==> 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

==> 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

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

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.

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

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.

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.

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

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.

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

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

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.

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.

https://www.frameip.com/entete-tcp/