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 :
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 :
Voici les valeurs en hexa du champs Flags pour les combinaisons intéressantes suivantes :
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.