7. Protocole TCP▲
7-1. TCP - Transmission Control Protocol▲
TCP est l'acronyme de « Transmission Control Protocol », il est défini dans la RFC 793 [Postel 1981c]. Les données encapsulées dans un entête TCP sont des « paquets TCP ».
7-1-1. Caractéristiques de TCP▲
TCP est bien plus compliqué(57) qu'UDP examiné au chapitre précédent, il apporte en contrepartie des services beaucoup plus élaborés.
Cinq points principaux caractérisent ce protocole :
- 1/ TCP contient un mécanisme pour assurer le bon acheminement des données. Cette possibilité est absolument indispensable dès lors que les applications doivent transmettre de gros volumes de données et de façon fiable.
- Il faut préciser que les paquets de données sont acquittés de bout en bout et non de point en point. D'une manière générale le réseau assure l'acheminement et les extrémités le contrôle (Dave Clark).
- 2/ Le protocole TCP permet l'établissement d'un circuit virtuel entre les deux points qui échangent de l'information. On dit aussi que TCP fonctionne en mode connecté (par opposition à UDP qui est en mode non connecté ou encore mode datagramme).
- Avant le transfert les 2 applications se mettent en relation avec leurs OS(58) respectifs, les informent de leurs désirs d'établir ou de recevoir une communication.
- Pratiquement, l'une des deux applications doit effectuer un appel que l'autre doit accepter.
- Les protocoles des 2 OS communiquent alors en s'envoyant des messages au travers du réseau pour vérifier que le transfert est possible (autorisé) et que les deux applications sont prêtes pour leurs rôles.
- Une fois ces préliminaires établis, les modules de protocole informent les applications respectives que la connexion est établie et que le transfert peut débuter.
- Durant le transfert, le dialogue entre les protocoles continue, pour vérifier le bon acheminement des données.
Conceptuellement, pour établir une connexion -- un circuit virtuel -- il faut avoir réuni les éléments du quintuplet :
- le protocole : c'est TCP, mais il y pourrait y avoir d'autres transports qui assurent le même service...
- IP locale : adresse de la machine qui émet ;
- port local : le numéro de port associé au processus. Il est imposé ou est déterminé automatiquement comme nous le verrons dans le cours de programmation ;
- IP distante : adresse de la machine distante ;
- port distant : le numéro de port associé au service à atteindre. Il est obligatoire de le connaître précisément.
L'ensemble de ces cinq éléments définit un circuit virtuel unique. Que l'un d'eux change et il s'agit d'une autre connexion !
- 3/ TCP a la capacité de mémoriser des données :
- aux deux extrémités du circuit virtuel, les applications s'envoient des volumes de données absolument quelconques, allant de 0 octet à des centaines (ou plus) de Mo,
- à la réception, le protocole délivre les octets exactement comme ils ont été envoyés,
- le protocole est libre de fragmenter le flux de données en paquets de tailles adaptées aux réseaux traversés. Il lui incombe cependant d'effectuer le réassemblage et donc de stocker temporairement les fragments avant de les présenter dans le bon ordre à l'application,
- aux deux extrémités du circuit virtuel, les applications s'envoient des volumes de données absolument quelconques, allant de 0 octet à des centaines (ou plus) de Mo,
- à la réception, le protocole délivre les octets exactement comme ils ont été envoyés,
- le protocole est libre de fragmenter le flux de données en paquets de tailles adaptées aux réseaux traversés. Il lui incombe cependant d'effectuer le réassemblage et donc de stocker temporairement les fragments avant de les présenter dans le bon ordre à l'application.
- 4/ TCP est indépendant vis-à -vis des données transportées, c'est un flux d'octets non structuré sur lequel il n'agit pas.
- 5/ TCP simule une connexion en « full duplex ». Pour chacune des deux applications en connexion par un circuit virtuel, l'opération qui consiste à lire des données peut s'effectuer indépendamment de celle qui consiste à en écrire.
Le protocole autorise la clôture du flot dans une direction tandis que l'autre continue à être active. Le circuit virtuel est rompu quand les deux parties ont clos le flux.
7-1-2. Description de l'entête▲
La figure suivante montre la structure d'un entête TCP. Sa taille normale est de 20 octets, à moins que des options soient présentes.
TCP SOURCE PORT : le numéro de port de l'application locale.
TCP DESTINATION PORT : le numéro de port de l'application distante.
SEQUENCE NUMBER : c'est un nombre qui identifie la position des données à transmettre par rapport au segment original. Au démarrage de chaque connexion, ce champ contient une valeur non nulle et non facilement prévisible, c'est la séquence initiale où ISN(60) TCP numérote chaque octet transmis en incrémentant ce nombre 32 bits non signé. Il repasse à 0 après avoir atteint 232 - 1 (4 294 967 295). Pour le premier octet des données transmises ce nombre est incrémenté d'un, et ainsi de suite...
ACKNOWLEDGEMENT NUMBER : c'est un numéro qui identifie la position du dernier octet reçu dans le flux entrant. Il doit s'accompagner du drapeau ACK (voir plus loin).
OFF pour OFFSET : il s'agit d'un déplacement qui permet d'atteindre les données quand il y a des options. Codé sur 4 bits, il s'agit du nombre de mots de 4 octets qui composent l'entête. Le déplacement maximum est donc de 60 octets (24-1 x 4 octets). Dans le cas d'un entête sans option, ce champ porte la valeur 5. 10 mots de 4 octets sont donc possibles pour les options.
RESERVED : Six bits réservés pour un usage futur !
CODE Six bits pour influer sur le comportement de TCP en caractérisant l'usage du segment :
- URG : le champ « URGENT POINTER » doit être exploité ;
- ACK : le champ « ACNOWLEDGMENT NUMBER » doit être exploité ;
- PSH : c'est une notification de l'émetteur au récepteur, pour lui indiquer que toutes les données collectées doivent être transmises à l'application sans attendre les éventuelles données qui suivent ;
- RST : réinitialisation de la connexion ;
- SYN : le champ « SEQUENCE NUMBER » contient la valeur de début de connexion ;
- FIN : l'émetteur du segment a fini d'émettre.
En fonctionnement normal un seul bit est activé à la fois, mais ce n'est pas une obligation. La RFC 1024 [Postel 1987] décrit l'existence de paquets tcp dénommés « Christmas tree » ou « paquet kamikaze » comprenant les bits SYN+URG+PSH+FIN !
WINDOW : le flux TCP est contrôlé de part et d'autre pour les octets compris dans une zone bien délimitée et nommée « fenêtre ». La taille de celle-ci est définie par un entier non signé de 16 bits, qui en limite donc théoriquement la taille à 65 535 octets (ce n'est pas complètement exact, voir plus loin l'option wscale). Chaque partie annonce ainsi la taille de son buffer de réception. Par construction, l'émetteur n'envoie pas plus de données que le récepteur ne peut en accepter. Cette valeur varie en fonction de la nature du réseau et surtout de la bande passante devinée à l'aide de statistiques sur la valeur du RTT. Nous y reviendrons au paragraphe 4.
CHECKSUM : un calcul qui porte sur la totalité du segment, entête et données.
URGENT POINTER : ce champ n'est valide que si le drapeau URG est armé. Ce pointeur contient alors un offset à ajouter à la valeur de SEQUENCE NUMBER du segment en cours pour délimiter la zone des données urgentes à transmettre à l'application. Le mécanisme de transmission à l'application dépend du système d'exploitation.
OPTIONS : c'est un paramétrage de TCP. Sa présence est détectée dès lors que l'OFFSET est supérieur à 5. Les options utilisées :
- MSS : la taille maximale du segment(61) des données applicatives que l'émetteur accepte de recevoir. Au moment de l'établissement d'une connexion (paquet comportant le flag SYN), chaque partie annonce sa taille de MSS. Ce n'est pas une négociation. Pour de l'Ethernet la valeur est 1460 (= MTU - 2 x 20) ;
- timestamp pour calculer la durée d'un aller et retour (RTT ou « round trip time ») ;
- wscale : facteur d'échelle (« shift ») pour augmenter la taille de la fenêtre au-delà des 16 bits du champ WINDOW (> 65535). Quand cette valeur n'est pas nulle, la taille de la fenêtre est de 65535 x 2shift. Par exemple si « shift » vaut 1, la taille de la fenêtre est de 131072 octets soit encore 128 ko ;
- NOP : les options utilisent un nombre quelconque d'octets par contre les paquets TCP sont toujours alignés sur une taille de mot de quatre octets ; à cet effet une option « No Operation » ou NOP, codée sur 1 seul octet, est prévue pour compléter les mots.
PADDINGÂ : remplissage pour se caler sur un mot de 32 bits.
DATAS : les données transportées. Cette partie est de longueur nulle à l'établissement de la connexion, elle peut également être nulle par choix de l'application.
7-2. Début et clôture d'une connexion▲
7-2-1. Établissement d'une connexion▲
L'établissement d'une connexion TCP s'effectue en trois temps, comme le schéma de la figure 3 l'explicite.
On suppose que l'émetteur du premier paquet avec le bit SYN a connaissance du couple (adresse IP du récepteur, numéro de port du service souhaité).
L'émetteur du premier paquet est à l'origine de l'établissement du circuit virtuel, c'est une attitude généralement qualifiée de « cliente ». On dit aussi que le client effectue une « ouverture active » (active open).
Le récepteur du premier paquet accepte l'établissement de la connexion, ce qui suppose qu'il était prêt à le faire avant que la partie cliente en prenne l'initiative. C'est une attitude de « serveur ». On dit aussi que le serveur effectue une « ouverture passive » (passive open).
- Le client envoie un segment comportant le drapeau SYN, avec sa séquence initiale (ISN = x) ;
- Le serveur répond avec sa propre séquence (ISN = y), mais il doit également acquitter le paquet précédent, ce qu'il fait avec ACK (seq = x + 1) ;
- Le client doit acquitter le deuxième segment avec ACK (seq = y + 1).
Une fois achevée cette phase nommée « three-way handshake », les deux applications sont en mesure d'échanger les octets qui justifient l'établissement de la connexion.
7-2-2. Clôture d'une connexion▲
7-2-2-1. Clôture canonique▲
Un échange de trois segments est nécessaire pour l'établissement de la connexion ; il en faut quatre pour qu'elle s'achève de manière canonique (« orderly release »).
La raison est qu'une connexion TCP est « full-duplex », ce qui implique que les données circulent indépendamment dans un sens et dans l'autre. Les deux directions doivent donc pouvoir être interrompues indépendamment l'une de l'autre.
L'application qui envoie un paquet avec le drapeau FIN indique à la couche TCP de la machine distante qu'elle n'enverra plus de données. La machine distante doit acquitter ce segment, comme il est indiqué sur la figure VII.04, en incrémentant d'une unité le « sequence number ».
La connexion est véritablement terminée quand les deux applications ont effectué ce travail. Il y a donc échange de 4 paquets pour terminer la connexion.
Au total, sans compter les échanges propres au transfert des données, les deux couches TCP doivent gérer 7 paquets, il faut en tenir compte lors de la conception des applications ! Sur la figure on constate que le serveur continue d'envoyer des données bien que le client ait terminé ses envois. Le serveur a détecté cette attitude par la réception d'un caractère de EOF (en C sous Unix).
Cette possibilité a son utilité, notamment dans le cas des traitements distants qui doivent s'accomplir une fois toutes les données transmises, par exemple pour un tri.
7-2-2-2. Clôture abrupte▲
Au lieu d'un échange de quatre paquets comme précédemment, un mécanisme de reset est prévu pour terminer une connexion au plus vite (abortive release).
Ce type d'arrêt est typiquement géré par la couche TCP elle-même quand l'application est brutalement interrompue sans avoir effectué un appel à la primitive close(2), par exemple lors d'un appel à la primitive abort(2), ou après avoir rencontré une exception non prise en compte (« core dump »...).
L'extrémité qui arrête brutalement la connexion émet un paquet assorti du bit RST, après avoir (ou non) envoyé les derniers octets en attente(62). Ce paquet clôt l'échange. Il ne reçoit aucun acquittement.
L'extrémité qui reçoit le paquet de reset (bit RST), transmet les éventuelles dernières données à l'application et provoque une sortie d'erreur du type « Connection reset par peer » pour la primitive de lecture réseau. Comme c'est le dernier échange, si des données restaient à transmettre à l'application qui a envoyé le RST elles peuvent être détruites.
7-3. Contrôle du transport▲
Le bon acheminement des données applicatives est assuré par un mécanisme d'acquittement des paquets, comme nous avons déjà pu l'examiner partiellement au paragraphe précédent.
7-3-1. Mécanisme de l'acquittement▲
- Au départ du paquet i une horloge se déclenche. Si cette horloge dépasse une valeur limite avant réception de l'ACK le paquet i est retransmis cette valeur limite est basée sur la constante MSL(63) qui est un choix d'implémentation, généralement de 30 secondes à 2 minutes. Le temps maximum d'attente est donc de 2 x MSL.
- Le temps qui s'écoule entre l'émission d'un paquet et la réception de son acquittement est le RTT(64), il doit donc être inférieur à 2 x MSL. Il est courant sur l'Internet actuel d'avoir un RTT de l'ordre de la seconde. Il faut noter que le RTT est la somme des temps de transit entre chaque routeur et du temps passé dans les diverses files d'attente sur les routeurs.
- L'émetteur conserve la trace du paquet i pour éventuellement le renvoyer.
Si on considère des délais de transmission de l'ordre de 500 ms (voire plus), un tel mécanisme est totalement inadapté au transfert de flux de données. On peut aussi remarquer qu'il sous-emploie la bande passante du réseau.
7-3-2. Fenêtres glissantes▲
Cette attente de l'acquittement est pénalisante, sauf si on utilise un mécanisme de « fenêtres glissantes(65) », comme le suggère la figure VII.07 :
Avec ce principe, la bande passante du réseau est beaucoup mieux employée.
- Si l'un des paquets doit être réémis, la couche TCP du destinataire aura toute l'information pour le replacer dans le bon ordre.
- À chaque paquet est associée une horloge comme sur la figure VII.06.
- Le nombre de paquets à envoyer avant d'attendre le premier acquittement est fonction de deux paramètres :
- 1/ La largeur de la fenêtre précisée dans le champ WINDOW de l'entête. Des valeurs courantes sont de l'ordre de 4096, 8192 ou 16384. Elle change dynamiquement pour deux raisons :
- l'application change la taille du « buffer de la socket » qui correspond à la taille de cette fenêtre,
- chaque acquittement ACK envoyé est assorti d'une nouvelle valeur de taille de la fenêtre, permettant ainsi à l'émetteur d'ajuster à tout instant le nombre de segments qu'il peut envoyer simultanément. Celle valeur peut être nulle, par exemple lorsque l'application cesse de lire les données reçues. C'est ce mécanisme qui assure le contrôle de flux de TCP ;
- 2/ La taille maximale des données, où MSS vaut 512 octets par défaut. C'est la plus grande taille du segment de données que TCP enverra au cours de la session. Le datagramme IP a donc une taille égale au MSS augmentée de 40 octets (20 + 20), en l'absence d'option de TCP. Cette option apparaît uniquement dans un paquet assorti du drapeau SYN, donc à l'établissement de la connexion. Comme de bien entendu cette valeur est fortement dépendante du support physique et plus particulièrement du MTU(66). Sur de l'Ethernet la valeur maximale est 1500 - 2 x 20 = 1460, avec des trames l'encapsulation 802.3 de l'IEEE un calcul similaire conduit à une longueur de 1452 octets. Chaque couche TCP envoie sa valeur de MSS en même temps que le paquet de synchronisation, comme une option de l'entête. Cette valeur est calculée pour éviter absolument la fragmentation de IP au départ des datagrammes.
Le débit obtenu dépend de la taille de la fenêtre et bien sûr de la bande passante disponible. On conçoit aisément qu'entre la situation de la figure VII.06 et celle de la figure VII.07 l'usage de la bande passante s'améliore. Par contre l'agrandissement de la taille de la fenêtre ne se conçoit que jusqu'à une limite optimale au-delà de laquelle des paquets sont perdus parce qu'envoyés trop rapidement pour être reçus par le destinataire. Or, pour fonctionner de manière optimale, TCP se doit de limiter au maximum la perte de paquets et donc leur réémission.
Cette taille limite optimale de la largeur de la fenêtre est, comme on peut le deviner, fonction de la bande passante théorique du réseau et surtout de son taux d'occupation instantané. Cette dernière donnée est fluctuante, aussi TCP doit-il asservir continuellement les tailles de fenêtre pour en tenir compte.
7-4. Compléments sur le fonctionnement de TCP▲
L'usage du protocole TCP diffère considérablement en fonction des applications mises en œuvre et des réseaux à parcourir.
D'après [W. Richard Stevens], 10 % des données échangées sur le réseau concernent des applications interactives et 90 % des applications qui échangent des flux de données.
Si le protocole TCP reste le même pour tous, les algorithmes qui le pilotent s'ajustent en fonction de l'usage.
Pour le trafic en volume (« bulk data »), TCP tente d'utiliser des paquets les plus larges possible pour maximiser le débit, alors que le trafic interactif utilise des paquets quasiment vides émis le plus souvent à la fréquence de frappe des utilisateurs ou au rythme des mouvements d'une souris.
Un exemple typique est celui de l'application Telnet pour laquelle les caractères sont envoyés un à un dans un paquet différent, chaque caractère étant à l'origine de quatre paquets : émission d'un caractère, acquittement, retour de l'écho du caractère, acquittement.
Si ce comportement n'est absolument pas pénalisant sur un réseau rapide (LAN) par contre dès que la bande passante commence à être saturée il est préférable de regrouper un maximum d'octets (deux ou trois en pratique) dans un seul paquet pour en diminuer le nombre. C'est ce que fait l'algorithme de Nagle.
7-4-1. Algorithme de Nagle▲
Pour réduire le trafic de ces « tinygrams » (RFC 896), l'algorithme de Nagle (1984) dit qu'une connexion TCP ne peut pas attendre plus d'un acquittement. Deux cas se présentent donc :
- Le réseau est lent. Dans ce cas TCP accumule dans un même buffer les octets en partance. Dès réception de l'acquittement, il y a émission du contenu du buffer en un seul paquet ;
- Le réseau est rapide. Les acquittements arrivent rapidement les agrégats d'octets peuvent tendre vers un seul caractère par paquet.
La qualité lente/rapide du réseau est calculée à partir du « timestamp » envoyé dans les options de TCP et qui est établi dès le premier échange (puis réévaluée statistiquement par la suite).
L'élégance de cet algorithme est qu'il est très simple et qu'il s'autorégule suivant le délai de propagation.
Certaines applications désactivent cet algorithme(67) comme le serveur Apache ou le système de multifenêtrage X11.
7-4-2. Départ lent▲
Un paquet est réémis parce qu'il arrive corrompu ou parce qu'il n'arrive jamais. Une réémission entraîne un blocage de l'avancement de la « fenêtre glissante », pénalisant pour le débit (cf conclusion du chapitre page).
TCP considère qu'un paquet perdu est la conséquence d'un routeur (ou plus) congestionné, c'est-à -dire pour lequel les files d'attente ne sont pas assez larges pour absorber tous les paquets entrants(68)
Dans ce contexte, on comprend bien qu'il vaut mieux ne pas envoyer la totalité du contenu de la fenêtre dès le début de la connexion. Au contraire, TCP utilise un algorithme nommé « slow start » qui asservit l'émission des paquets au rythme de la réception de leurs acquittements, plutôt que de les émettre d'un coup aussi rapidement que l'autorise le système ou le débit théorique du réseau.
Ainsi, au début de chaque connexion ou après une période de calme (« IDLE ») l'émetteur envoie un premier paquet de taille maximale (le « MSS » du destinataire), et attend son acquittement. Quand celui-ci est reçu, il envoie deux paquets, puis quatre, et ainsi de suite jusqu'à atteindre l'ouverture maximale de la fenêtre.
Durant cette progression, si des paquets sont perdus, il y a congestion supposée sur l'un des routeurs franchis et l'ouverture de la fenêtre est réduite pour retrouver un débit qui minimise le taux de retransmission.
L'ouverture de la fenêtre est nommée fenêtre de congestion ou encore « congestion window ».
7-4-3. Évitement de congestion▲
Le contrôle du flux évoqué précédemment, pour éviter la congestion des routeurs, est implémenté à l'aide d'une variable (CWND) nommée « congestion window » que l'on traduit par fenêtre de congestion.
Concrètement, le nombre maximum de segments de données (x MSS en octets) que l'émetteur peut envoyer avant d'en recevoir le premier acquittement est le minimum entre cette variable (cwnd) et la taille de la fenêtre annoncée par le récepteur à chaque acquittement de paquet.
Le contenu de cette variable est piloté par les algorithmes de départ lent -- « slow start », voir 4.2 -- et d'évitement de congestion (« congestion avoidance ») examiné ici.
La limite de croissance de la variable CWND est la taille de la fenêtre annoncée par le récepteur. Une fois la capacité de débit maximale atteinte, si un paquet est perdu l'algorithme d'évitement de congestion en diminue linéairement la valeur (contrairement au « slow start » qui l'augmente exponentiellement).
7-5. Paquets capturés, commentés▲
Le premier exemple montre un échange de paquets de synchronisation (SYN) et de fin (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. L'établissement de la connexion se fait à l'aide de la commande Telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est à l'origine de l'établissement de la connexion est dite cliente, et celle qui est supposée prête à répondre, serveur. Pour information, le service discard peut-être considéré comme l'équivalent du fichier /dev/null sur le réseau : les octets qu'on lui envoie sont oubliés (« discard »).
L'utilisateur tape :
$ telnet srv discard
Trying...
Connected to srv.chezmoi.
Escape character is '^]'.
Telnet> quit
Connection closed.Et l'outil d'analyse réseau(69) permet la capture pour l'observation des échanges suivants. Le numéro qui figure en tête de chaque ligne a été ajouté manuellement, le nom de domaine « chezmoi » a été retiré, le tout pour faciliter la lecture :
0 13:52:30.274009 clnt.1159 > srv.discard: S 55104001:55104001(0) win 8192 <mss 1460>
1 13:52:30.275114 srv.discard > clnt.1159: S 2072448001:2072448001(0) ack 55104002 win 4096 <mss 1024>
2 13:52:30.275903 clnt.1159 > srv.discard: . ack 1 win 8192
3 13:52:33.456899 clnt.1159 > srv.discard: F 1:1(0) ack 1 win 8192
4 13:52:33.457559 srv.discard > clnt.1159: . ack 2 win 4096
5 13:52:33.458887 srv.discard > clnt.1159: F 1:1(0) ack 2 win 4096
6 13:52:33.459598 clnt.1159 > srv.discard: . ack 2 win 8192Plusieurs remarques s'imposent :
- Pour améliorer la lisibilité les numéros de séquences « vrais » ne sont indiqués qu'au premier échange. Les suivants sont relatifs. Ainsi l'ack 1 de la ligne 2 doit être lu 2072448002 (2072448001 + 1). À chaque échange la valeur entre parenthèses indique le nombre d'octets échangés ;
- Les tailles de fenêtre (win) et de segment maximum (MSS) ne sont pas identiques. Le Telnet du client fonctionne sur HP-UX alors que le serveur telnetd fonctionne sur une machine BSD ;
- Le symbole > qui marque le sens du transfert ;
- Le port source 1159 et le port destination discard ;
- Les flags F et S. L'absence de flag, repéré par un point.
Le deuxième exemple montre une situation de transfert de fichier avec l'outil ftp(70).
Il faut remarquer que l'établissement de la connexion TCP est ici à l'initiative du serveur, ce qui peut laisser le lecteur perplexe... L'explication est simple. En fait le protocole ftp fonctionne avec deux connexions TCP, la première, non montrée ici, est établie du client vers le serveur, supposé à l'écoute sur le port 21. Elle sert au client pour assurer le contrôle du transfert. Lorsqu'un transfert de fichier est demandé via cette première connexion, le serveur établit une connexion temporaire vers le client. C'est cette connexion que nous examinons ici. Elle est clôturée dès que le dernier octet demandé est transféré.
Extrait du fichier /etc/services, concernant ftp :
ftp-data 20/tcp #File Transfer [Default Data]
ftp-data 20/udp #File Transfer [Default Data]
ftp 21/tcp #File Transfer [Control]
ftp 21/udp #File Transfer [Control]Dans cet exemple nous pouvons suivre le fonctionnement du mécanisme des fenêtres glissantes. Les lignes ont été numérotées manuellement et la date associée à chaque paquet supprimé.
0 srv.20 > clnt.1158: S 1469312001:1469312001(0) win 4096 <mss 1024> [tos 0x8]
1 clnt.1158 > srv.20: S 53888001:53888001(0) ack 1469312002 win 8192 <mss 1460>
2 srv.20 > clnt.1158: . ack 1 win 4096 [tos 0x8]
3 srv.20 > clnt.1158: P 1:1025(1024) ack 1 win 4096 [tos 0x8]
4 clnt.1158 > srv.20: . ack 1025 win 8192
5 srv.20 > clnt.1158: . 1025:2049(1024) ack 1 win 4096 [tos 0x8]
6 srv.20 > clnt.1158: . 2049:3073(1024) ack 1 win 4096 [tos 0x8]
7 clnt.1158 > srv.20: . ack 3073 win 8192
8 srv.20 > clnt.1158: . 3073:4097(1024) ack 1 win 4096 [tos 0x8]
9 srv.20 > clnt.1158: P 4097:5121(1024) ack 1 win 4096 [tos 0x8]
10 srv.20 > clnt.1158: P 5121:6145(1024) ack 1 win 4096 [tos 0x8]
11 clnt.1158 > srv.20: . ack 5121 win 8192
12 srv.20 > clnt.1158: P 6145:7169(1024) ack 1 win 4096 [tos 0x8]
13 srv.20 > clnt.1158: P 7169:8193(1024) ack 1 win 4096 [tos 0x8]
14 clnt.1158 > srv.20: . ack 7169 win 8192
15 srv.20 > clnt.1158: P 8193:9217(1024) ack 1 win 4096 [tos 0x8]
16 srv.20 > clnt.1158: P 9217:10241(1024) ack 1 win 4096 [tos 0x8]
17 clnt.1158 > srv.20: . ack 9217 win 8192
18 srv.20 > clnt.1158: P 10241:11265(1024) ack 1 win 4096 [tos 0x8]
19 srv.20 > clnt.1158: P 11265:12289(1024) ack 1 win 4096 [tos 0x8]
20 clnt.1158 > srv.20: . ack 11265 win 8192
... ... ...
21 srv.20 > clnt.1158: P 1178625:1179649(1024) ack 1 win 4096 [tos 0x8]
22 clnt.1158 > srv.20: . ack 1178625 win 8192
23 srv.20 > clnt.1158: P 1212417:1213441(1024) ack 1 win 4096 [tos 0x8]
24 srv.20 > clnt.1158: P 1213441:1214465(1024) ack 1 win 4096 [tos 0x8]
25 srv.20 > clnt.1158: P 1214465:1215489(1024) ack 1 win 4096 [tos 0x8]
26 clnt.1158 > srv.20: . ack 1213441 win 8192
27 clnt.1158 > srv.20: . ack 1215489 win 8192
28 srv.20 > clnt.1158: P 1215489:1215738(249) ack 1 win 4096 [tos 0x8]
29 srv.20 > clnt.1158: F 1215738:1215738(0) ack 1 win 4096 [tos 0x8]
30 clnt.1158 > srv.20: . ack 1215739 win 8192
31 clnt.1158 > srv.20: F 1:1(0) ack 1215739 win 8192
32 srv.20 > clnt.1158: . ack 2 win 4096 [tos 0x8]Remarques :
- Le P symbolise le drapeau PSH. La couche TCP qui reçoit un tel paquet est informée qu'elle doit transmettre à l'application toutes les données reçues, y compris celles transmises dans ce paquet. Le positionnement de ce drapeau est à l'initiative de la couche TCP émettrice et non à l'application ;
- Le type de service (« Type Of service » tos 0x8) est demandé par l'application pour maximiser le débit (consulter le cours IP page). Figure
7-6. Conclusion sur TCP▲
Le protocole TCP a été conçu à une époque où l'usage de la commande ligne était universel, et les applications graphiques utilisant le réseau étaient très rares...
Une trentaine d'années plus tard, on peut faire le constat pratiquement inverse : les applications textes interactives (beaucoup de petits messages applicatifs) disparaissent au profit d'applications moins interactives et qui sont plus orientées flux de données (vidéo, audio, téléphonie...) avec des échanges plus volumineux et des besoins en transport qui ont évolué.
Le principe de la fenêtre glissante, si performant qu'il soit pour assurer le bon acheminement des données, est bloquant pour certaines applications comme le web. En effet, si le paquet de données de tête n'est pas acquitté, les suivants, même reçus, sont en attente avant d'être délivrés à l'application.
Si la réponse comporte par exemple de nombreuses zones graphiques et textuelles différentes la fluidité de la consultation est considérablement amoindrie, et tenter de la compenser en établissant un grand nombre de connexions simultanées pour récupérer individuellement les éléments de la page, consomme beaucoup de ressources système et réseaux (celles de l'établissement des connexions) qui ne compense que partiellement ce souci.
L'indépendance de TCP vis-à -vis de la structure des données est également un inconvénient dans certaines applications comme la téléphonie pour laquelle la notion de messages successifs est bien plus intéressante.
Depuis le début des années 2000, l'IETF met au point le protocole SCTP qui fournit des services similaires à ceux de TCP, en abandonne certains et apporte les nouvelles fonctionnalités adaptées aux nouveaux besoins.
7-7. Bibliographie▲
- RFC 793 « Transmission Control Protocol. » J. Postel. Sep-01-1981. (Format: TXT=177957 bytes) (Status: STANDARD)
- RFC 1025 « TCP and IP bake off. » J. Postel. Sep-01-1987. (Format: TXT=11648 bytes) (Status: UNKNOWN)
- RFC 1700 « ASSIGNED NUMBERS. » J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: STANDARD)
Sans oublier :
- W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley
- Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice-Hall
- McKusick - Bostic - Karels - Quaterman -- « The Design and implementation of the 4.4 BSD Operating System » (chapitre 13) -- Addison-Wesley - 1996