Résumé

  • Data Offset compte l’en-tête TCP complet en mots de 32 bits et indique où commencent les données.
  • EOL arrête l’interprétation des options, mais le remplissage qui suit reste dans l’en-tête.
  • NOP peut faciliter l’alignement sans le rendre obligatoire.

L’en-tête TCP minimal mesure cinq mots, soit vingt octets. Les options l’allongent ; le récepteur a donc besoin d’une limite extérieure qui ne dépende pas de la compréhension de chaque option. Le champ Data Offset, large de quatre bits, indique le nombre de mots de 32 bits de l’en-tête entier. Sa valeur multipliée par quatre donne l’octet où commence la charge utile. Une valeur de cinq décrit l’en-tête de base ; les valeurs supérieures englobent options et éventuel remplissage, jusqu’à quinze mots, soit soixante octets.

Lorsque Data Offset dépasse cinq, RFC 9293 exprime la zone d’options par (DOffset-5)*32 bits. Ce total comprend aussi le remplissage placé après les options réelles.

EOL marque la fin de la liste d’options, pas nécessairement la fin de l’en-tête. Les octets restants doivent être un remplissage nul. NOP, lui aussi codé sur un octet, peut séparer ou aligner des options, mais celles-ci peuvent commencer à n’importe quelle frontière d’octet. Les autres options indiquent leur longueur, ce qui permet d’ignorer une option inconnue lorsqu’elle est bien formée.

Data Offset fixe la limite que ce parcours ne doit jamais dépasser. Options et remplissage participent au contrôle de somme TCP, tout en restant distincts des données applicatives. Une longueur illégale doit être traitée ; la RFC 9293 mentionne notamment la réinitialisation et la consignation comme procédure suggérée.

Sources