La procédure de connexion

Le protocole TCP n’empêche pas deux hôtes d’ouvrir et de fermer plusieurs fois une connexion, ce qui soulève le problème de la reconnaissance par chacun d’eux des messages provenant d’une instance antérieure de la connexion ou session.

Il faut pour cela disjoindre les numéros de séquence utilisés dans des sessions différentes, afin d’éviter que lorsqu’un paquet de données provenant d’une an- cienne session (qui se trouverait encore sur le réseau) arrive au client, celui-ci ne considère qu’il s’agit de données répondant à sa dernière requête. L’initia- lisation de la connexion correspond donc à l’envoi par le serveur du premier numéro de séquence qu’il utilisera, celui-ci convenant de n’utiliser par la suite que des numéros de séquence strictement supérieurs au numéro initial.

Afin de permettre à chacune des parties d’amorcer la procédure d’initialisa- tion, et d’éviter que celle-ci soit perturbée par l’arrivée inopinée de messages ayant trait à une tentative de connexion caduc (ce qui pourrait aboutir à une mésentente quand au numéro initial choisi), on utilise un deuxième numéro de

86 Jeux et spécification de protocoles réseaux séquence. Celui-ci est initialisé par le client.

L’initialisation de la connexion correspond à l’échange des numéros de sé- quence initiaux choisis par chacun des hôtes : c’est l’opération de synchroni-

sation, qui s’effectue encore avec le principe de l’acquittement afin de fiabiliser

la transmission. On appelle dans la suite émetteur celui qui initie la procédure, et récepteur la partie adverse. On utilise la méthode dite du three-way handshake, dont voici le principe :

– L’émetteur envoie d’abord un message (où un bit SYN présent dans l’en- tête signale qu’il s’agit d’un message de synchronisation) contenant un numéro de séquence x, qui est son numéro de séquence initial.

– A réception de celui-ci, le récepteur envoie un acquittement (ACK) qui contient en plus son propre numéro de séquence initial y (SYN), ce qui indique que le prochain message qu’il s’attend à recevoir devra contenir y comme numéro d’acquittement.

– Enfin, l’émetteur acquitte ce dernier message : le numéro de séquence associé est incrémenté (soit x+1).

récepteur émetteur SYN,SEQ=x SYN,ACK=x, SEQ=y ACK = y, SEQ=x+1 DATA, SEQ=x+2 te m p s

Fig. 4.3 – Le three-way handshake.

4.1 Notions de protocole de transport 87 demande de synchronisation à laquelle il vient de répondre a été acceptée, et donc de savoir quels seront les numéros de séquence utilisés dans la session qui s’amorce. En effet, au cours de l’initialisation d’une connexion, il est possible que l’un des hôtes reçoive un message de synchronisation provenant d’une an- cienne tentative d’initialisation : c’est alors le dernier acquittement qui permet d’assurer la fiabilité de la transmission, les hôtes pouvant ajouter à l’en-tête des messages un bit de contrôle (RST) qui force la réinitialisation de la connexion en cas de problème. Il est en effet essentiel que le numéro initial choisi par chacun des hôtes au terme de la session soit le plus grand des numéros proposés par celui-ci, afin d’éviter toute confusion ultérieure (sinon, un paquet de donnée pourrait porter le même numéro de séquence qu’un message de synchronisa- tion).

TCP assure ainsi la fiabilité de la transmission même si l’un des hôtes n’a plus en mémoire les numéros de séquence utilisés précédemment. Observons par exemple la situation décrite par la figure 4.4. Dans ce cas, l’émetteur envoie une demande de connexion avec le numéro de séquence 100. Celle-ci n’arrive pas à destination, mais le récepteur reçoit une demande de connexion obsolète contenant le numéro initial 90 qu’il accepte. Il renvoie alors un acquittement de cette demande, mais l’émetteur détecte à réception de cet acquittement qu’il s’agit d’une réponse à une tentative obsolète de connexion, grâce au numéro d’acquittement de celui-ci. Il décide donc d’envoyer un message de réinitiali- sation. Celui-ci est affublé du numéro de séquence correspondant au numéro d’acquittement du message l’ayant déclenché, puisque c’est celui qu’attend le récepteur (sinon il n’aurait pas lui-même envoyé cet acquittement, car il aurait détecté de suite qu’il s’agissait d’un message obsolète).

Le cas dual, où l’émetteur reçoit un message obsolète qu’il ne sait détec- ter, est corrigé grâce à la présence d’un numéro de séquence initial du côté du récepteur. La figure 4.5 en présente un exemple. Le numéro de séquence du message RST envoyé par le récepteur est dans cet exemple 291, puisque c’est le numéro de séquence que s’attend à recevoir l’émetteur : il doit donc accom- pagner la demande de réinitialisation afin que celle-ci soit prise en compte par l’émetteur.

Remarque : Chacun des acquittements envoyés par le client possède en fait un numéro de séquence, calculé à partir du numéro de séquence initial que celui-ci a choisi. De plus, chacun des messages envoyés par le serveur contient également un numéro d’acquittement, qui est égal au numéro de séquence du dernier message provenant du client qu’à reçu le serveur, si bien que tout mes- sage en acquitte un autre. Le numéro de séquence du client ainsi utilisé renforce la fiabilité du protocole, en permettant notamment au serveur de détecter les demandes de réinitialisation obsolètes.

88 Jeux et spécification de protocoles réseaux

récepteur émetteur

SYN, SEQ=100(message perdu)

SYN, SEQ=90(message obsolète)

ACK=90,SYN, SEQ=300 RST, SEQ=91 te m p s

4.1 Notions de protocole de transport 89

ACK=80,SYN, SEQ=290

récepteur émetteur

ACK=100,SYN, SEQ=300(message perdu)

SYN, SEQ=100 ACK=290, SEQ=101 RST, SEQ=291 te m p s

90 Jeux et spécification de protocoles réseaux