L’en-tête TCP fait 20 octets, comme l’en-tête IP, c’est plus facile à retenir.
Cependant, il y a une différence notoire, c’est que l’en-tête TCP comporte très souvent des options. Les données ne se trouvent donc pas toujours 20 octets après l’en-tête IP, mais souvent à un nombre supérieur.
Voici l’en-tête, dans le même mode de présentation que nous l’avons fait pour IP :
Nous allons bien sûr décortiquer chacun de ces éléments.
Nous connaissons déjà le port source et le port destination, qui identifient les applications qui entrent en jeu dans la communication. Ils sont codés chacun sur deux octets, ce qui est conforme à ce que nous connaissons.
Viennent ensuite deux champs de 4 octets chacun, qui ont un rôle très proche l’un de l’autre. On remarquera au passage qu’étant codés sur 4 octets, ils pourront prendre près de 4 milliards de valeurs, ce qui est beaucoup !
Sequence number, ou numéro de séquence, en français. Ce chiffre sert à représenter le nombre d’octets qui ont été envoyés par la machine émettrice. Cela permet d’informer la machine avec qui nous dialoguons du nombre d’octets envoyés.
Acknowledgement number, ou numéro d’acquittement. Ce chiffre sert à représenter le nombre d’octets que nous avons reçus de la part de l’autre machine. Il nous permet d’indiquer à l’autre machine combien d’octets nous avons actuellement reçus de sa part.
Pour l’instant, ces définitions ne sont peut-être pas encore très parlantes pour vous, mais nous allons faire des exercices pour essayer de rendre leur compréhension plus aisée.
Vient ensuite le champ :
Data Offset, qui indique à partir de quel octet les données applicatives commencent. Comme pour l’en-tête IP, cette information étant codée sur trois bits, elle ne peut pas contenir directement le nombre d’octets de l’en-tête, mais elle contient le nombre de groupes de 4 octets. La valeur du Data Offset est donc quasiment toujours 5, étant donné que l’en-tête TCP fait 20 octets de longueur s’il n’y a pas d’options.
Viennent ensuite trois bits qui ne sont pas utilisés, et potentiellement réservés pour une utilisation ultérieure... qui n’est jamais venue et ne viendra peut-être jamais !
Reserved, réservé pour rien ! Ou pour des utilisations avancées...
Vous reconnaissez ensuite les flags, que nous n’expliciterons pas ici puisqu’ils ont été présentés en détail dans le chapitre 2 de la partie 3 du précédent cours.
Vient ensuite la
Window, ou fenêtre en français. Ce champ est très intéressant et souvent méconnu des personnes travaillant dans les réseaux, car on peut tout à fait comprendre le fonctionnement de TCP sans avoir à s’attarder sur celui de la fenêtre. La fenêtre indique la quantité de données qu’une machine peut accepter sans exiger d’accusé de réception.
On peut voir cela comme une personne qui parle très très vite et une autre qui comprend lentement. Pour qu’elles puissent dialoguer, il faudra que la personne qui parle très vite ralentisse son débit pour que l’autre personne puisse la comprendre.
La fenêtre TCP agit de la même façon pour les échanges de données au niveau TCP. Une machine peut dire à l’autre d’envoyer ses informations plus vite ou plus lentement, en fonction de ses capacités de réception.
Pratiquement, comment cela fonctionne ?
Nous n’allons pas voir le vrai fonctionnement de la fenêtre TCP, car il est très complexe, mais nous allons en faire un exemple simplifié pour que vous en compreniez les principes généraux. Ceux qui veulent en savoir plus peuvent lire la RFC 793 qui a normalisé le protocole TCP à sa création, mais je vous le déconseille, vous n’êtes pas encore prêt !
Nous allons prendre le cas d’un serveur web qui, à un instant donné, reçoit trop de connexions simultanées pour pouvoir les traiter correctement. Il voudrait donc pouvoir demander aux clients qui se connectent de ralentir leurs débits afin de pouvoir traiter les demandes. Et c’est là que la fenêtre entre en scène. Le serveur va pouvoir, pour chaque connexion, baisser la taille de fenêtre TCP dans chacun des segments TCP qu’il renvoie, afin de demander aux clients de ralentir leur débit. Il peut diminuer cette taille de fenêtre jusqu’à 0 afin de leur dire de stopper leur débit en attendant qu’il ait assez de capacités pour traiter les informations.
Aujourd’hui, la fenêtre TCP peut-être utilisée pour améliorer le fonctionnement de nombreux réseaux. Dans un réseau où la bande passante est saturée, on peut installer un matériel qui va lui-même modifier la taille des fenêtres TCP afin de lisser le trafic, ou de prioritiser un trafic par rapport à un autre.
Ainsi, si vous voulez que votre jeu vidéo ne soit pas ralenti quand votre petit frère regarde une série en streaming tout en téléchargeant en torrent, vous pouvez mettre en place de la QOS afin de prioriser les échanges de votre jeu vidéo par rapport aux flux web et torrent. Quand la bande passante sera saturée, votre routeur qui sait gérer la QOS pourra réduire la taille de fenêtre TCP des connexions web et torrent afin que votre jeu reste fluide.
Nous pouvons continuer l’étude de notre en-tête avec le
Checksum, dont nous connaissons le principe déjà puisqu’il est le même que pour le protocole IP.
Et enfin,
Urgent Pointer, qui est le pointeur sur les données urgentes. Ce pointeur est utilisé si le flag URG est positionné et indique dans ce cas jusqu’à quel octet vont les données urgentes. Cependant, même si ces options existent toujours dans TCP, elles ne sont quasiment jamais utilisées...
Nous allons regarder ces éléments dans la réalité, donc en examinant le contenu d’un segment TCP issu d’une connexion web :
Nous voyons bien ici chacun des champs que nous attendions.
Si nous faisons l’analyse de ce segment TCP :
Il s’agit vraisemblablement d’une réponse à une demande de connexion, car les flags SYN et ACK sont positionnés.
C’est une réponse à une requête web, car le port source est le port 80.
Nous pouvons voir aussi une taille de fenêtre TCP de 5 792, ce qui n’est pas le maximum de 65 536 possible, donc la machine semble ne pas vouloir qu’on la submerge de paquets.
Enfin, nous voyons que cet en-tête possède 20 octets d’options, ce qui porte l’ensemble de l’en-tête à 40 octets et non aux 20 habituels. Vous verrez que ceci est relativement fréquent !
Voilà, nous avons fait le tour de l’en-tête TCP, nous allons maintenant nous pencher plus précisément sur le suivi détaillé des connexions.
