Ceci est une ancienne révision du document !
Table des matières
Transport
Ici, deux formats d'en-tête, suivant que l'on a affaire à des segments ou des datagrammes.
Le segment
Autrement-dit TCP.
C'est le mode connecté qui utilise TCP. Pratiquement, c'est un mode utilisé systématiquement lorsque l'application au dessus génère des données qui nécessitent d'être découpées avant leur envoi. Nous avons vu lors de l'étude de la couche d'accès réseau que les trames ne peuvent théoriquement pas contenir plus de 1500 octets de charge utile. Les applications qui génèrent des données pouvant entrer dans un seul segment utiliseront plutôt UDP.
L'en-tête a toujours une dimension multiple de 32 bits. Elle contient:
- Le port source (16 bits).
- Le port destination (16 bits).
- Sequence Number (32 bits). Chaque segment est numéroté de manière à ce que le message soit reconstitué dans l'ordre à l'arrivée.
- Acknowledgment Number (32 bits). Lorsqu'un segment arrive à destination, le destinataire renvoie un segment «ACK» avec son «sequence number» dans ce champ. Ainsi l'émetteur sait que le segment a bien été remis.
- Offset (4 bits) définit le nombre de mots de 32 bits présents dans l'en-tête, de manière à trouver le début de la charge utile, quelle que soit la longueur des options.
- 6 bits dont les 3 premiers sont réservés à un usage «futur». C'est un champ de 0. Les 3 derniers sont effectivement réservés et ont une signification. Ils devraient permettre de signaler à l'émetteur un engorgement du lien :
- ECN/NS
- CWR
- ECE
- ces bits ne sont pas systématiquement utilisés car tous les protagonistes d'une transmission doivent être capables de gérer l'algorithme AQM (Active Queue Management, décrit dans le RFC 7567 et dans la section 4 de notre RFC 3168).
- Window (16 bits). Pour éviter de devoir attendre un accusé-réception après l'envoi de chaque segment, le destinataire envoie dans ce champ le nombre de segments que l'émetteur peut envoyer sans attendre d'ACK. Il faudra voir tout ceci sur des exemples pour bien comprendre.
- Checksum (16 bits) est une somme de contrôle de l'e-tête TCP complet.
- Urgent pointer (16 bits) concerne l'émetteur. Si le flag URG est mis à 1, ce pointeur indique le premier octet qui suit la partie urgente des données à envoyer. Ces informations viennent bien sûr de l'application qui a généré les données.
- Enfin, le champ Options + padding contient des options
et le padding est un bourrage de bits pour que la taille de l'ensemble doit un multiple de 32 bits.
Le datagramme
Autrement-dit UDP.
Alors là, pas de chichi ! Même pas besoin de faire un dessin. L'en-tête UDB, c'est 8octets:
- 2 octets pour le port source.
- 2 octets pour le port destination
- 2 octets pour la longueur de tout le datagramme.
- 2 octets pour le checksum. Lui est un peu plus complexe. Il est calculé en tenant compte d'une partie de l'en-tête de transport. Peu importe. Pour nous il suffit de savoir qu'un mécanisme existe pour s'assurer que de datagramme n'est pas corrompu.