Différences

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

--- 010-deep:030-transport [le 08/02/2025 à 19:05] – [Le segment] prof
+++ 010-deep:030-transport [le 14/02/2025 à 17:41] (Version actuelle) – [Séquence TCP] prof
@@ Ligne 21: / Ligne 21: @@
   - 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.