Comme nous l'avons vu dasn l'article sur les flux TCP , ce protocole ne connaît pas la notion de dialogue. Si les données à échanger sont brèves, ce la n'a pas d'importance car elles peuvnet facilement être mises en mémoire pour être traitées. Il en va autrement pour les données volumineuses. Pour ces dernières, il nous faut un protocole de dialogue. Cet article en présente un possible.
Le segment est l'unité élémentaire de l'information transportée. Il est indispensable de lui allouer une taille maximale qui est fonction de la capacité mémoire des hôtes ainsi que des capacités du réseau traversé. Si cette taille est trop grande, elle risque de rapidement amener à la saturation de la mémoire vive d'un des hôtes. Si elle est trop petite, il y aura une baisse de performance liée à la fois à des échanges plus nombreux, au transport de données de service supplémentaires et à la multiplication des traitements. On aura donc intérêt à en faire une constante ajustable au moment de la configuration de l'application. Idéalement, la taille de notre segment devrait être identique à celle du paquet TCP de façon à éviter sa fragmentation. Or, dans un réseau maillé comme internet, la taille du paquet peut varier et TCP ne permet pas d'avoir connaissance de la taille du plus petit paquet rencontré lors du transport. De façon pragmatique, sur un réseau IP homogène, on fixe cette taille à celle du MTU (1500 octets en général). En présence de cartes qui acceptent les trames Jumbo (9100 octets), on peut augmenter cette taille. Pour des traverser de réseaux hétérogènes, on fixe généralement la taille des données du paquet à 546 octets (576 octets avec l'en-tête de paquet). Comme on le constate, la taille des paquets TCP est relativment faible. Nous prendrons comme valeur initiale SMAX=8192 octets pour des applications sur intranet basés Ethernet.
Le schéma ci-dessous illustre la structure du 1er segment du dialogue :
Tout segment commence par un octet de comande, suivi d'éventuels paramètres associés à cette commande puis le complément du segment est constitué des données. Les commandes sont, pour l'instant, au nombre de 5 mais cela pourrait évoluer dans le future puisqu'il y a une possibilité de création de 127 commandes (le bit b7 est réservé à l'indication du segment hors octet de commande). Le tableau qui suit les résume :
Remarque :
l'utilisation du chiffrement affecte la performance des transmissions. Par mesure de sécurité, la clef n'est pas échangée via ce protocole sur le réseau.
| Commande | Code | Paramètres |
|---|---|---|
| OK | 0 | Aucun |
| START | 1 | Paramètre obligatoire. Taille de l'ensemble des données "utiles" (codage sur 4 octets dans le boutisme "petit indien"). |
| END | 2 | Aucun |
| CANCEL | 3 | Paramètre obligatoire. ASCIIZ : cause de l'annulation. Si la chaîne qui précise la cause est vide, un octet 0 doit être passé dasn le paramètre (ASCIIZ). |
| ERROR | 4 | Paramètre obligatoire. ASCIIZ : détail de l'erreur rencontrée. |
Le dialogue est un peu plus compliqué qu'une simple requête suivie d'une réponse car requête comme réponse peuvent nécessiter l'envoi de plusieurs segments. Il est donc important de définir un protocole d'échange permettant à chacun des hôtes de savoir quand la requête ou la réponse sont achevées.
Le protocole répond à la structure suivante :
Un "échange" se définit comme l'ensemble des flux émis et reçus constituant une requête ou une réponse. Un "message" se définit comme une requête ou une réponse. Ainsi un message se base sur un échange. Comme le montre ce schéma, c'est toujours l'hôte destinataire (celui destinataire du message) qui achève l'échange. Dans le cas d'un message court (un seul segment), l'échange se limite à une émission suivie d'une réception :
Voici la représentation d'un échange nécessitant 3 segments pour transporter le message :
Une difficulté qui peut être rencontrée est que la somme des données utiles ne correspondent pas à la valeur indiquée par le segment émis avec la commande START. La raison peut en être une altération au cours du transport ou plus probablement une erreur applicative. L'altération au cours du transport est peu probable car TCP est censé la détecter et demander une nouvelle émission du paquet en défaut. Si on se place dans le cas précédent, voici le chronogramme de l"échange :
Il se peut aussi que l'erreur soit détectée en cours d'échange notamment en cas de chiffrement si le segment reçu ne peut pas être déchiffré. Voici alors le chronogramme :
Un autre cas utile est la demande d'annulation du message. Ce dernier peut intervenir à n'importe quel moment de l'échange, y compris dans le premier segment. Voici le chronogramme lorsque cette de mande intervinet en cours d'échange à l'initiative de l'émetteur :
Notez que l'émetteur ne peut pas émettre de commande d'erreur. A la place, il doit utiliser une commande d'annulation.
Il est possible à chacune des partie de demander au début, en cours ou en fin d'échange l'annulation de ce dernier via la commande CANCEL. Voici le chronogramme d'une demande d'annulation par l'émetteur en cours d'échange :
Cette annulation peut être aussi à l'initiative du destinataire :
Rédaction par Jean-Marie Piatte (1983-2021)