Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 010-deep:030-transport [le 08/02/2025 à 18:18] – [Le segment] prof
+++ 010-deep:030-transport [le 14/02/2025 à 17:41] (Version actuelle) – [Séquence TCP] prof
@@ Ligne 2: / Ligne 2: @@
 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.
 {{:010-deep:segment.svg |Segment TCP}}
-Autrement-dit TCP. L'en-tête a toujours une dimension multiple de 32 bits. Elle contient:
+L'en-tête a toujours une dimension multiple de 32 bits. Elle contient:
   - Le port source (16 bits).
   - Le port destination (16 bits).
@@ Ligne 9: / Ligne 12: @@
   - 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 éservés à un usage «futur». C'est un champ de 0. Les 3 derniers sont effectivement réservés et ont une signification:
+  - 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 8-o et le padding est un bourrage de bits pour que la taille de l'ensemble doit un multiple de 32 bits.
+==== Séquence TCP ====
+{{ :010-deep:tcpsend.svg|}}
+Les champs ''Sequence number'' et ''Acknowledgment number'' sont calculés de façon tout-à-fait logique comme le montre l'illustration d'un client qui ouvre une session TCP pour envoyer des données à un serveur. Les valeurs numériques ne sont que des exemples:
+  - le premier ''Sequence number'' côté client = 1. Soit la longueur du segment = 669.
+  - le serveur dans sa réponse ACK Va calculer l' ''Acknowledgment number'' = 1 + 669.
+  - le client va reprendre comme ''Sequence number'' l' ''Acknowledgment number'' que lui a envoyé le serveur.
+  - et ainsi de suite jusqu'à la fin de la session.
+Notons que les longueurs indiquées sont les longueurs du segment TCP.
+Cette façon de faire permet au serveur de garantir qu'il classera les segments reçus dans le bon ordre, même si IP avait fait que ces segments avaient été transportés dans le désordre.
+==== Agrandir la fenêtre ====
+Comprenons bien l'utilité de la fenêtre.
+Lorsqu'un nœud transmet des informations à un nœud, que ces informations sont contenues dans plusieurs paquets, il n'est pas nécessaire que le destinataire envoie un ACK à chaque paquet reçu. Dit autrement, l'émetteur n'est pas contraint d'attendre un ACK après chaque émission d'un paquet.
+Les deux nœuds disposent d'un tampon de réception d'une certaine taille et l'ACK ne devient vraiment nécessaire que lorsque le tampon va déborder. Nous avons vu que la taille de ce tampon est définie sur 16 octets soit 2<sup>16</sup> octets soit 65535 octets. Si cette taille de tampon pouvait sembler largement suffisante pour les performances du matériel dans les années 1990, Compte tenu des progrès  des capacités de stockage, des vitesses de transmission et de la qualité de ces transmissions, il s'est avéré nécessaire de trouver une astuce pour définit des tailles de tampon largement supérieures.
+Comme il n'est pas possible, à l'échelle mondiale, de changer la structure de l'en-tête TCP, l'astuce consiste à utiliser une option, puisqu'un espace d'options est prévu. Cette option s'appelle «Window Scalling» définie dans le RFC 1323.
+Les deux nœuds négocient ce paramètre ''WS'' lors de l'établissement de la connexion (SYN,SYN+ACK). Ce ''WS'' permet de calculer un multiplicateur de la taille définie dans le paramètre ''Window'' de la façon suivante: 2<sup>WS</sup> x Window. avec  0 <= WS <= 14.
+Ceci permet de bien ouvrir la fenêtre...
 ===== Le datagramme =====
-Autrement-dit UDP
+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.
+Compte tenu de l’extrême simplicité de ce type de transport, il est principalement utilisé pour des données intégralement insérées dans un datagramme. Dans tous les cas de figure, si l'application qui a émis la donnée s'inquiète de savoir si elle est bien arrivée, il faudra espérer qu l'application destinataire elle-même lui fasse part de la nouvelle.