Question 6 : Principes de TCP : timer, contrôle de flux, ouverture et

Question 6 : Principes de TCP : timer, contrôle de flux, ouverture et fermeture de connection
Connection TCP : TCP founi le multiplexing, le demultiplexing et les détections d'erreurs (mais pas leur récupération) exactement de la même manière que UDP. Mais TCP et UDP sont différents, notamment car TCP établit une connection tandis que UDP non. La ''connection TCP'' n'est pas un circuit TDM ou FDM entre deux hôtes comme dans un réseau avec communication par circuit. C'est un circuit virtuel car les états de connections se trouvent chez les deux hôtes (le protocole TCP fonctionne uniquement dans les hôtes et non dans les éléments intermédiaire du réseau, ceux­ ci ne sont pas au courant de la connection). La connection TCP fourni le full duplex (communication dans les deux sens sur une seule ligne) pour le transfert des données ainsi que le point­to­point (entre un envoyeur et un receveur).
Pour établir une connection TCP entre deux hôtes, il faut d'abord que le client envoie un segment spécial, le serveur répond avec un segment spécial lui aussi et finalement le client répond avec un troisième segment spécial. Les deux premiers segements n'envoient pas de ''charges utiles'', le dernier peut quant à lui en envoyer. Parce que 3 segments sont envoyés entre les deux hôtes, cette procédure d'établissement de connection est souvent appelée three­way handshake.
Lorsque la connection TCP est établie, les deux processus peuvent s'envoyer des données, en voici en exemple.
Le processus client passe un flot de données à travers le socket, dès que les données ont passé la porte, elles sont dans les mains du TCP fonctionnant chez le client. TCP dirige ces données vers le buffer d'envoi (qui est un des buffers qui sont mis sur le côté durant le three­way hanshake). De temps en temps, TCP va saisir des morceaux de données du buffer d'envoi. La taille maximum de données pouvant être saisies et placées dans un segment est limité par le MSS (Maximum Segement Size) qui dépend de l'implémentation de TCP. TCP encapsule chaque morceau de données du client avec des en­têtes TCP pour former des segments TCP. Lorsque TCP reçoit un segment du côté client, il est placé dans le buffer de réception et l'application lit le flot de données de ce buffer.
Timers : Lorsqu'un hôte envoie un segment dans une connection TCP, il démarre un timer. Si le timer expire avant que l'hôte ne reçoive un accusé pour les données contenues dans le segment, l'hôte retransmet le segment, cela est appelé le timeout du timer. Ce timeout doit être plus grand que la durée du RTT, Round Trip Timeout (durée entre l'envoi d'un segment et la réception de son acquittement) , sinon le segment sera renvoyé inutilement. Mais il ne doit pas être beaucoup plus grand que cette durée, sinon cela introduirait un délai sur le transfert des données dans l'application.
La valeur de RTT varie de segments en segments à cause de la congestion dans les routeurs et de la charge variable chez les hôtes. Donc pour estimer un RTT typique, il est naturel de faire une sorte de moyenne sur ces différentes valeurs (SampleRTT). TCP maintient une moyenne appelée EstimatedRTT à partir des valeurs SampleRTT. Lorsque TCP reçoit un acquittement, il obtient une nouvelle valeur SampleRTT et met à jour la valeur de EstimatedRTT avec la formule : EstimatedRTT = (1­x)*EstimatedRTT + x*SampleRTT
où une valeur typique de x est 0,125. EstimatedRTT est une moyenne pondérée des valeurs SampleRTT où cette moyenne pondérée accorde plus d'importance aux récents échantillons qu'aux vieux échantillons. En statistique, cette moyenne est appelée EWMA (Exponential Weighted Moving Average). Le mot Exponential apparaît car le poids d'un SampleRTT décroit de façon exponentielle avec les mises à jour.
Mettre le timeout
Le timeout est initialisé à EstimatedRTT plus une marge. La marge doit être grande lorsqu'il y a une grande fluctuation dans les valeurs de SampleRTT, et une petite lorsqu'il y a une petite fluctuation dans ces valeurs. Timeout = EstimatedRTT + 4*Deviation
Deviation = (1­x)*Deviation + x * |SampleRTT ­ EstimatedRTT| où Deviation est une estimation de combien SampleRTT dévie de EstimatedRTT et où x vaut typiquement 0,25.
Contrôle de flux : Lorsque la connection TCP reçoit des bytes, il place les données dans le buffer de réception. Le processus de l'application va lire les données dans ce buffer mais pas nécessairement au moment où les données arrivent, en fait, l'application peut­être occupée par d'autres tâches. Si l'application est relativement lente à la lecture des données, l'envoyeur peut relativement facilement déborder le buffer de réception du receveur en envoyant trop de données trop rapidement. TCP fournit donc un service de contrôle de flux à ses applications en éliminant la possibilité que l'envoyeur déborde le buffer de réception. Le contrôle de flux est donc un service faisant correspondre la vitesse d'envoi à la vitesse de lecture.
TCP fournit le contrôle de flux en maintenant une variable fenêtre de réception chez l'envoyeur. Cette fenêtre est utilisée pour donner à l'envoyeur une idée de l'espace libre dans le buffer de réception du receveur. Dans une connection full­duplex, l'envoyeur de chaque côté maintient une fenêtre de réception distincte. La fenêtre de réception est dynamique (change à travers l'avancement de la connection).
Supposons qu'un hôte A envoie un gros fichier à l'hôte B par une connection TCP. B alloue un buffer de réception à cette connection et dénote sa taille par RcvBuffer. De temps en temps, le processus de l'application de B lit son buffer. LastByteRead et LastByteRecvd sont également définis. Comme TCP ne permet pas de dépasser le buffer alloué, on doit avoir
LastByteRcvd – LastByteRead <= RcvBuffer
La fenêtre de réception, appelée RcvWindow, est initialisé à la place disponible dans le buffer.
RcvWindow = RcvBuffer – [LastByteRcvd – LastByteRead]
Comme la place disponible change avec le temps, RcvWindow est dynamique.
B informe A de la place disponible dans le buffer en plaçant la valeur courante de RcvWindow dans le champs fenêtre de chaque segment qu'il envoie à A (initialement RcvWindow = RcvBuffer). A garde trace de deux variables, LastByteSend et LastByteAcked où LastByteSend – LastByteAcked représente la quantité de données qui n'a pas encore été acquittée par B. En gardant cette valeur inférieure à celle de RcvWindow, A est assuré de ne pas dépasser le buffer de réception chez B.
Il y a un problème avec ce schéma. Supposons que le buffer de réception de B soit plein (RcvWindow = 0). Après avoir averti A de cela, supposons également que B n'ai rien à envoyer à A. Pendant que le processus de B lit le buffer et le vide, TCP n'envoie pas de nouveaux segments avec la nouvelle valeur de RcvWindow. Donc A n'est jamais informé qu'il y a de l'espace libre dans le buffer de réception de B : A est bloqué et ne peut plus envoyer des données. Pour résoudre ce problème, la spécification de TCP requiert que A continue d'envoyer des segments avec un byte de données lorsque la fenêtre de réception de B vaut 0. Ces segments vont être acquittés par B et A sera au courant quand il y aura de nouveau de la place dans le buffer de réception.
Ouverture et fermeture de connection : L'établissement de la connection TCP peut ajouter de manière significative des délais perceptibles.
Ouverture
1. Le côté client de la connection TCP envoie un segment appelé SYN car le flag de SYN est mis à 1. Le client choisi un numéro de séquence initial (client_isn) qui prendra place dans le champs du numéro de séquence. Ce segment est encapsulé dans un datagram IP.
2.
Lorsque le serveur reçoit le datagram contenant ce segment, il l'extrait, alloue les buffers et les variables et renvoie un segment appelé SYNACK. Dans ce segment le flag SYN est à 1, le champs acknowledgment est mis à isn+1 et le serveur choisit son numéro de séquence initial.
3.
Après avoir reçu le segment SYNACK, le client alloue également les buffers et les variables. Il envoie encore un segment qui acquitte le segment SYNACK. Le flag de SYN est à 0 dès que la connection est établie.
Fermeture
Lorsqu'un connection prend fin, les ressources chez les hôtes sont libérées.
Supposons que le client veuille fermer la connection à l'aide d'une commande de fermeture. Le client envoie un segment avec le flag FIN égal à 1. Lorsque le serveur reçoit ce segment, il envoie un accusé en retour et envoie son propre segment de fermeture (FIN = 1) au client. Finalement, le client acquitte le segment de fermeture du serveur.