Cours : TCP et le bit alterné

Le protocole TCP

Plusieurs protocoles peuvent être utilisés pour la couche transport. Parmi eux, on peut citer UDP (User Datagram Protocol) et TCP (Transfer Control Protocol), tous deux capables de communiquer avec le protocole IP de la couche inférieure, c’est-à-dire la couche réseau. Cependant, contrairement à UDP, TCP contrôle les erreurs de transmission grâce à un système d’accusé de réception. Nous allons nous intéresser ici à TCP.

La communication d’application à application

Les protocoles Ethernet et IP permettent la communication de machine à machine. En pratique, les éléments qui ont besoin de communiquer ne sont pas les machines mais les programmes qui s’y exécutent.

Exemple

Lorsqu’un internaute se connecte à un site internet, un échange d’informations s’établit entre le navigateur internet côté client et le programme qui diffuse le site web côté serveur.
D’autres types de communications peuvent intervenir au même moment, par exemple entre un logiciel de messagerie côté client et un service de messagerie côté serveur. Ainsi, sur une même machine, telle qu’un serveur, peuvent cohabiter des services différents qui ont chacun besoin de communiquer. Il peut en être de même, côté client.

• Il est par conséquent nécessaire d’identifier, pour une adresse IP donnée, chacun de ces services afin d’y aiguiller les flux d’informations qui leur sont destinés.

C’est le premier rôle joué par la couche transport dont l’un des protocoles est TCP (Transmission Control Protocol). Des numéros de port TCP d’écoute, appelés ports « bien connus » ou ports réservés, sont ainsi définis.

Exemple

Pour aiguiller le flux d’informations vers le programme qui diffuse le site web, il faut que celui-ci s’adresse au port TCP 80 (ou un autre numéro de port si le serveur a été configuré autrement).
Et pour aiguiller les échanges vers le service de messagerie, le flux doit être dirigé vers le port TCP 993 (ou un autre numéro suivant les messageries).

• Notons que lors d’un échange entre deux applications, un port TCP est utilisé au niveau de chaque partenaire.

Côté client, le système d’exploitation alloue dynamiquement des numéros de ports aléatoires pour répondre aux besoins des applications utilisées par l’internaute. Ces ports appelés ports dynamiques, ports privés ou encore ports éphémères, se situent pour les systèmes d’exploitation récents entre 49152 et 65355.

Rappel

La connexion TCP est identifiée par quatre éléments : l’adresse IP et le port du serveur d’un côté, et l’adresse IP et le port du client de l’autre. Chaque ensemble adresse IP et numéro de port d’un côté de la connexion est appelé socket.

Définition

Protocole TCP :

Le protocole TCP est dit en « mode connecté » car il exige l’établissement d’une connexion avant tout échange de données ainsi que la fermeture de la connexion après échange. C’est aussi parce qu’il est en mesure de retransmettre des données perdues.

À retenir

Une communication TCP s’établit selon le principe d’une connexion en trois temps (en anglais « three way handshake »), également appelé poignée de main à trois temps ou encore négociation en trois étapes.

• Le client envoie d’abord au serveur un numéro de séquence généré aléatoirement (dans notre exemple 1010) dans un paquet TCP particulier (SYN).
• Le serveur qui reçoit alors le paquet SYN génère à son tour un numéro aléatoire (dans notre exemple 3002) qu’il va renvoyer dans un paquet particulier (SYN-ACK) qui contient également le numéro du client incrémenté de 1 (1011 dans notre exemple). Ce paquet est à la fois un accusé de réception pour le client et une synchronisation au niveau des numéros d’échange côté serveur et client.
• Le client qui reçoit ce paquet se considère connecté au serveur et envoie un dernier paquet particulier (ACK) dans lequel le numéro de séquence serveur aura été incrémenté (3003 dans l’exemple). Le serveur qui reçoit ce paquet se considère à son tour connecté au client.
• Ce processus en trois temps permet ainsi au serveur et au client de se synchroniser en s’échangeant leurs numéros de séquences avant de commencer leurs échanges de segments.

Notons qu’un autre processus, en quatre temps celui-ci, est défini pour mettre fin à la communication.

Le découpage des messages en segments et leur réassemblage

• Le protocole TCP assure une autre tâche : le découpage en segments des informations que les applications lui demandent de transmettre.

Propriété

Chacun de ces segments est alors encapsulé dans un paquet TCP comprenant en particulier les numéros de ports des applications sources et destinataires. Ce paquet TCP est alors transmis à la couche réseau qui l’encapsule dans un datagramme IP. Celui-ci est ensuite transmis à la couche liaison de données qui l’encapsule dans une trame Ethernet. Celle-ci est transmise à la couche physique qui la code selon un signal physique.

Les différentes couches de l’interface réseau du côté de la machine réceptrice décapsuleront tour à tour la trame Ethernet, puis le datagramme IP. TCP quant à lui devra réassembler les segments avant de les transmettre à l’application destinataire. Pour que les segments puissent être correctement réassemblés, ceux-ci doivent nécessairement être numérotés.

• En effet, la couche IP peut très bien les avoir acheminés dans le désordre, en particulier s’ils n’ont pas emprunté le même chemin entre la machine émettrice et la machine destinatrice. TCP réalise leur ordonnancement avant de les confier à la couche application.

Le contrôle du débit d’informations et le contrôle d’erreur

On a vu que TCP découpait les informations à transmettre en segments. C’est un mécanisme nécessaire à la régulation du volume des échanges entre deux applications qui communiquent. Par ailleurs, en plus de ce découpage, TCP numérote les segments. Cette numérotation sert à remettre les segments dans l’ordre, mais aussi à contrôler la bonne réception des segments. Voyons cela de plus près.

Maintenant que la connexion TCP est établie entre les deux partenaires, l’échange des données peut commencer. Voici un exemple qui illustre un échange au cours duquel un segment est perdu (le segment 3).

On découvre dans cet exemple :

• la notion de fenêtre d’envoi : l’émetteur des données peut envoyer plusieurs segments sans attendre l’acquittement (accusé de réception) individuel de chacun d’eux, mais dans une certaine limite (ici, 560 octets). Cette fenêtre, qui s’adapte dynamiquement au cours de la communication est un moyen de gérer le débit des données échangées ;
• la notion de délai d’attente d’accusé de réception, au-delà duquel un segment est automatiquement renvoyé, ce qui permet d’éviter la perte de segments. Ce délai s’ajuste également au cours de la communication selon les événements qui s’y produisent ;
• l’acquittement du récepteur qui fournit un numéro construit ainsi : numéro de séquence fourni par l’émetteur + longueur du segment + 1. Ce numéro correspond finalement au prochain numéro de séquence attendu. Grâce à ce numéro, le récepteur peut identifier les segments en double ou manquants ;
• la capacité du récepteur à reconstituer l’information de manière ordonnée à partir de segments reçus dans le désordre (ici : 1, 2, 4 puis 3) ;
• l’intérêt de segmenter l’information à envoyer qui évite d’avoir à la retransmettre intégralement en cas de non-réception.

Voilà autant d’aspects qui font de TCP un protocole d’échange de données très fiable qui s’est imposé pour le web.

Attention

Le protocole TCP n’est toutefois pas adapté à la diffusion en flux en continu tels que les vidéos en streaming, où la vitesse de transmission est privilégiée en acceptant de possibles pertes de données marginales.

Nous allons voir dans le chapitre qui suit un autre système d’accusé de réception, dans une version un peu plus simple.

À retenir

Le protocole TCP permet la communication d’application à application. Il permet :

• d’aiguiller les flux d’informations vers les bonnes applications via les ports TCP ;
• de découper les informations à transmettre en segments, de les réordonner et les réassembler lors de leur réception ;
• de gérer les pertes de transmission de segments ainsi que les doublons grâce au contrôle des numéros de séquence accompagnant les segments ;
• de gérer le débit des données échangées.

Le protocole du bit alterné

Un numéro de séquence réduit à 1 bit

Pour contrôler la bonne réception des segments, TCP s’appuie sur un système de numéros de séquence. Ces numéros figurent dans l’encapsulation TCP de l’information et viennent donc alourdir les échanges avec des données techniques. Les numéros de séquence étant codés chacun sur 4 octets, ce sont 8 octets de données techniques transmis à la couche réseau en plus des informations envoyées par les applications.
Notez que d’autres éléments techniques TCP sont également transmis à la couche réseau, dont les ports TCP, mais nous ne les détaillons pas ici.

Le mécanisme que nous allons aborder n’utilise quant à lui qu’un seul bit pour coder le numéro de séquence. Le numéro de séquence ne peut donc prendre que les valeurs $0$ ou $1$. Comment est-il possible alors de mettre en place un système de contrôle de réception ? Grâce au principe du bit alterné.

Cas où l’échange se passe correctement

À retenir

Dans le protocole du bit alterné, l’émetteur envoie les données encapsulées dans des trames contenant, entre autres informations techniques, le bit de séquence.

Quand tout se passe bien, chaque trame émise est reçue par le destinataire qui envoie un accusé de réception dans lequel le bit de séquence correspond à celui de la trame reçue. La couche émettrice alterne la valeur du bit de séquence d’une trame émise à l’autre. Et de son côté, le récepteur attend un bit de séquence dont la valeur est censée alterner d’une trame reçue à l’autre.

Notons qu’en début d’échange, l’émetteur et le récepteur sont synchronisés sur un bit de séquence à 0.

Voici une illustration de ce procédé :

Cas où la trame émise est rejetée par le récepteur

La trame émise contient une donnée technique particulière : le CRC pour le contrôle de redondance cyclique (empreinte numérique des données calculée par l’émetteur). Cette information permet au récepteur de la trame de vérifier que celle-ci n’a pas été altérée pendant son transit. Si le récepteur constate une altération, celui-ci va simplement envoyer à l’émetteur une trame de non-acquittement. L’émetteur renverra alors la trame. Voici une illustration d’un tel échange :

Cas où une trame n’est pas reçue

Dans le cas où une trame émise n’est pas reçue par son destinataire, l’émetteur réagit. En effet, il constate qu’il n’a pas reçu d’accusé de réception dans les délais et décide alors de renvoyer la trame dont il n’a pas reçu d’accusé de réception. Cela correspond à l’illustration suivante :

Cas du chevauchement de messages

C’est le cas où l’émetteur renvoie une trame dont il n’a pas reçu l’accusé de réception. La seconde trame envoyée arrive à l’émetteur avant la première. Le récepteur reçoit finalement deux trames identiques, mais écartera la seconde car son bit de séquence ne correspondra pas au bit attendu. Heureusement qu’il en est ainsi, sinon le récepteur admettrait la même trame deux fois !

Cas du chevauchement d’acquittements

C’est le cas où l’acquittement d’un message met trop longtemps à parvenir à l’émetteur. Le message est alors transmis à nouveau après le dépassement du délai ; mais le récepteur va rejeter ce message réémis car le bit de séquence de celui-ci ne correspondra pas à celui qu’il attend. Comme précédemment, le mécanisme du bit alterné évite ainsi la réception de doublons.

Nous avons observé des cas classiques. On peut en imaginer d’autres, en particulier certains ou le protocole n’empêchera pas la perte de données. Cela peut être l’occasion de s’exercer !