RFC 793 : Transmission Control Protocol (TCP) - Spécification
| Document au format HTML 4.01 |
Traduction : Valéry G. FREMAUX |
RFC: 793
Remplace: RFC 761
IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5 |
Jon Postel
ISI
September 1981 |
Table des matières
Retour... partie I
| 3.5. Fermeture d'une connexion |
 |
CLOSE est une opération signifiant "Je n'ai plus d'autre données à envoyer". La notion de fermeture d'une communication bidirectionnelle peut être sujette à une interprétation ambiguë. L'analyse à faire du côté réception n'est pas de la plus grande simplicité. Nous avons choisi de l'expliquer de la façon la plus simple. L'application demandant la fermeture peut continuer à recevoir jusqu'à être
averti que l'autre extrémité à fermé à son tour la connexion. Ainsi, un programme pourrait émettre plusieurs SEND suivi d'un CLOSE, et ensuite continuer à recevoir des données jusqu'à ce que TCP lui signale que le distant a fermé sa connexion. Du moins supposons nous que TCP le fera, même si aucune commande RECEIVE ne reste pendante, et ce dès que l'autre extrémité ferme la connexion,
et permette à l'extrémité locale de terminer ses opérations proprement. TCP devra émettre toutes les données qui lui auront été passées par l'application avant l'activation de la commande CLOSE. Ainsi, une application peut sans problème fermer une connexion qui continuera à émettre des données et lancer une autre tâche. Par contre il faudra toujours lire les tampons de réception,
jusqu'à ce que le TCP distant indique qu'il n'a plus de données à envoyer.
On distingue trois cas de figure principaux:
| 1 |
L'application demande la fermeture au TCP en activant la commande CLOSE. |
| 2 |
La connexion est rompue par le distant qui marque son flag FIN |
| 3 |
Les deux applications coupent simultanément la connexion |
Cas 1: L'application locale déclenche la déconnexion
Dans ce cas, un segment FIN est constitué et inscrit au bas de la pile d'émission. Aucune commande SEND ne sera plus acceptée par TCP, celui-ci passant à l'état FIN-WAIT-1. Les commandes RECEIVE restent acceptées dans cet état, la demi-connexion inverse fonctionnant toujours. Tous les segments présents dans la pile, y compris le dernier segment FIN seront retransmis jusqu'à acquittement. Lorsque le TCP a acquitté le
FIN, et envoyé son FIN propre, le local acquitte le FIN distant à son tour. Notez qu'un TCP recevant un segment FIN peut l'acquitter, mais n'enverra son propre segment FIN que lorsque son application aura exécuté la commande CLOSE.
Cas 2: TCP reçoit un segment FIN du distant
Si un segment FIN arrive inopinément par le réseau, TCP peut l'acquitter et avertit l'application de la notification de fermeture. L'application émettra une commande CLOSE après avoir pris ses dispositions, suite à laquelle TCP peut alors envoyer son propre FIN au TCP distant, une fois toutes les données restantes émises. TCP attend alors l'acquittement de ce FIN pour effacer le TCB de cette connexion. Si aucun acquittement ne survient
après un certain laps de temps, la connexion est coupée et l'application en est avisée.
Cas 3: les deux applications ferment simultanément
Une commande CLOSE simultanée aux deux extrémités provoque un échange de segments FIN. Tous les segments de données restants, y compris le dernier FIN seront émis et acquittés, chaque TCP pourra acquitter le segment FIN reçu. Les deux côtés, sur acquittement, effaceront chacun le TCB de cette connexion.
|
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL) CLOSED |
Séquence de fermeture normale
Figure 13. |
|
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close) (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
<-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
<-- <SEQ=301><ACK=101><CTL=ACK> <--
... <SEQ=101><ACK=301><CTL=ACK> -->
4. TIME-WAIT TIME-WAIT
(2 MSL) (2 MSL)
CLOSED CLOSED |
Séquence de fermeture bilatérale
Figure 14. |
| 3.6. Priorité et Sécurité |
|
Le propos de ce chapitre est de ne permettre l'établissement d'une connexion qu'entre deux ports fonctionnant exclusivement avec les mêmes valeurs de sécurité et compartiment, et la priorité la plus élevée des deux côtés.
Les paramètres de priorité et de sécurité utilisés dans TCP sont exactement ceux définis par le protocole Internet (IP). Dans la présente spécification, le couple "sécurité/compartiment" désigne l'ensemble des paramètres de sécurité d'IP dont le niveau de sécurité, le compartiment, le groupe d'utilisateur, et les restrictions d'usage.
Une tentative de connexion avec des valeurs de sécurité/compartiment non concordantes, ou un niveau de priorité plus faible devra être rejetée via un segment de réinitialisation "reset". Le rejet d'une connexion uniquement du à une priorité plus faible ne pourra être exécuté qu'après acquittement en bonne et due forme du segment SYN..
Notez qu'un module TCP travaillant à la priorité par défaut devra néanmoins surveiller la priorité des segments entrants, et augmenter son niveau de priorité si requis.
Les paramètres de sécurité peuvent être exploités y compris en dehors d'un environnement sécurisé (les valeurs indiquent des données non classifiées), Ainsi, les ordinateurs doivent toujours être en mesure, dans un environnement sécurisé, de lire les informations de sécurité, même s'ils n'ont pas l'obligation de les transmettre.
| 3.7. Transfert de données |
|
Une fois la connexion établie, les données peuvent commencer à être échangées dans des segments. Ceux-ci pouvant être rejetés (erreur de Checksum), ou perdus dans le réseau (congestion du réseau), TCP utilise un principe de retransmission (au bout d'une temporisation) pour garantir l'acheminement de tous les segments de données. Ce principe de retransmission peut conduire à la réception de "doublons".
Comme il a été précisé dans les paragraphes consacrés aux numéros de séquence, TCP effectue un certain nombre de tests sur les séquences et les acquittements afin de déduire l'acceptabilité des données reçues.
L'émetteur des données garde toujours en mémoire le prochain numéro de séquence à utiliser dans la variable SND.NXT. Le récepteur garde en mémoire le prochain numéro de séquence à recevoir dans la variable RCV.NXT. L'émetteur garde en mémoire la valeur du plus ancien numéro de séquence non acquitté dans la variable SND.UNA. Si le flux de données s'interrompt
pendant un temps suffisant pour que tous les segments sur le réseau soient parvenus à destination, ces trois valeurs doivent être égales.
Lorsque l'émetteur constitue un segment et le transmet, il incrémente la valeur de SND.NXT (souvenez-vous: modulo 2**32 !). Lorsque le récepteur reçoit un segment, il incrémente la valeur de RCV.NXT et envoie un acquittement. Lorsque l'émetteur reçoit cet acquittement, il incrémente SND.UNA. L'écart moyen entre ces variables est une mesure du "temps de propagation" à l'intérieur du réseau. A chaque
fois, c'est la longueur du paquet qui est ajouté à ces variables. Notez que dans un état ESTABLISHED tous les segments transporteront l'information d'acquittement courant.
Le déclenchement d'une commande CLOSE impose l'utilisation de la fonction push, et l'ajout final d'un segment FIN à la pile de transmission.
Temporisation de retransmission
Du fait de la grande variété de réseaux formant Internet, et l'emploi massif de connexions TCP à travers ce réseau la valeur de temporisation de retransmission doit être déterminée dynamiquement. Nous donnons ici un exemple de procédure permettant de définir cette temporisation.
Exemple de procédure de calcul de temporisation de retransmission
Mesurer tout d'abord le temps entre l'envoi d'un octet de numéro de séquence particulier (appelons le "marqueur") et la réception d'un acquittement englobant ce numéro de séquence (les plages de séquence dans les deux segments n'ont pas à être identique). Ceci mesure ce que nous appellerons le "temps de boucle" (RTT = Round Trip Time). Puis calculez un "temps de boucle" corrigé (SRTT = Smoothed Round Trip Time), par
la formule:
|
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) |
et enfin, calculer la temporisation de retransmission (RTO = Retransmission Time Out) comme suit:
|
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]] |
où UBOUND est une valeur limite de la temporisation (ex. 1 minute), LBOUND une valeur limite inférieure (ex.1 seconde), ALPHA le facteur de correction (ex. 0,8 à 0,9), et BETA est un facteur de variance du temps de propagation (ex., 1,3 à 2,0).
Transmission d'informations urgentes
L'objectif du mécanisme d'urgence de TCP est de fournir un moyen à l'application émettrice d'inciter le récepteur à prendre en compte des données urgentes, et un moyen pour signaler en retour que ces données urgentes ont bien été prise en compte par le récepteur.
Ce mécanisme permet de marquer un numéro de séquence particulier comme étant la fin d'un bloc de données urgentes. Lorsque ce marqueur pointe sur un numéro de séquence non encore reçu (RCV.NXT) par le TCP récepteur, ce dernier doit prévenir l'application de passer en "mode d'urgence"; et lorsque le numéro de séquence reçu rattrape ce marqueur, le TCP doit signifier à l'application
de repasser en "mode normal". Si le pointeur d'urgence est réactualisé en "mode d'urgence", l'application utilisatrice ne pourra en avoir connaissance.
Ce mécanisme utilise un champ dédié dans chaque segment émis, appelé "pointeur urgent". Le bit de contrôle URG indique que ce champ contient une information valide. Le TCP récepteur ajoutera la valeur de ce champ au numéro de séquence du segment concerné pour obtenir le "marqueur". Lorsque le bit URG n'est pas marqué, ce champs n'est pas marqué, aucune mention d'urgence n'est contenue dans le segment.
Pour signifier l'état d'urgence, le segment émis doit au moins contenir un octet de données. Si l'émetteur utilise de plus la fonction push, le temps de transmission des données urgentes sera optimisé.
Gestion de la fenêtre de transmission
La fenêtre transmise dans chaque segment indique la plage de numéros de séquence que l'émetteur de la fenêtre (celui qui reçoit les données) est prête à accepter. La taille de cette fenêtre est en relation avec la taille disponible des tampons de données associés à cette connexion.
Une grande taille de fenêtre encourage l'émission. Si le nombre de données reçues est supérieur à ce que la fenêtre indique, les données hors fenêtre seront rejetées. Cette déperdition entraîne un grand nombre de retransmissions et surcharge inutilement le réseau et les TCP. L'usage d'une petite taille de fenêtre morcelle le débit en ajoutant un certain retard supplémentaire
au "temps de boucle", mais en limitant la surcharge du réseau due aux retransmissions.
Le mécanisme instauré n'interdit pas à un TCP de signifier une largeur de fenêtre importante, puis beaucoup plus mince dans le segment suivant sans avoir reçu pour autant la quantité de données qui le justifie. Cette technique dit "d'étranglement de fenêtre," est fortement déconseillée. Le principe de robustesse nous dicte qu'un TCP ne doit pas de lui même étrangler une fenêtre, mais
devra être préparé à accepter un tel comportement de la part d'autres TCP.
Le TCP émetteur doit être prêt à accepter de l'application et à envoyer au moins un octet de nouvelles données même lorsque la fenêtre de transmission est de largeur nulle. L'émetteur devra retransmettre régulièrement le segment au TCP récepteur. L'intervalle recommandé entre deux retransmissions, lorsque la largeur de fenêtre est nulle est d'environ 2 minutes. Cette retransmission est
essentielle pour s'assurer que la réouverture de la fenêtre par le récepteur sera bien signifiée au TCP émetteur.
A l'autre bout, lorsque le TCP récepteur affiche une largeur de fenêtre nulle et qu'un segment arrive, il doit nécessairement répondre an acquittant le segment, un bon moyen de confirmer régulièrement le nouveau numéro de séquence attendu et la largeur de fenêtre courante (zéro).
Le TCP émetteur met en forme les données afin de constituer des segments à émette tenant dans l'espace de séquence autorisé par la fenêtre, et répète la même opération pour inscrire les copies de segments dans la pile de retransmission. Cette dernière opération n'est pas obligatoire, mais cependant très utile.
Pour une connexion n'utilisant qu'un seul flux de données unidirectionnel (mais nécessairement "ouverte" en bidirectionnel), la largeur de fenêtre est envoyée dans les acquittements sous un numéro de séquence unique (un segment ACK ne "consomme" pas d'espace de séquence). Il n'est donc pas possible de remettre dans l'ordre l'historique de la largeur de fenêtre. Cela ne représente pas un problème critique, bien
qu'il signifie que le TCP émetteur puisse se baser sur d'anciennes valeurs de largeur de fenêtre lors d'une émission. Une technique pour s'affranchir de ce problème est de toujours récupérer l'information de fenêtre dans l'accusé de réception contenant le plus grand numéro de séquence (une méthode indirecte de numérotation des segments ACK !).
La gestion de la largeur de fenêtre a une influence importante sur les performances de la communication. Les commentaires qui suivent sont à destination des développeurs.
Suggestion pour gestion de la largeur de fenêtre
L'ouverture d'une toute petite fenêtre réduit les performances en augmentant le poids des en-têtes par rapport aux données.
Côté récepteur: Une suggestion pour éviter des fenêtres trop petites est de ne différer l'ouverture de la fenêtre jusqu'à ce qu'un certain pourcentage minimum X de l'espace total des tampons alloués à la communication n'ait été libéré (X peut être pris entre 20 et 40%).
Côté émetteur: L'émetteur peut attendre que la fenêtre atteigne une certaine largeur avant de commencer à envoyer des données. La fonction push permettra d'envoyer un reliquat de données même si la largeur de fenêtre est inférieure à la limite choisie.
Notez qu'il n'est pas une bonne stratégie de retarder l'émission des acquittements, au risque de provoquer des retransmissions inutiles et coûteuses en termes de performances. Une stratégie est d'émettre des acquittements dès qu'un segment court arrive (sans modifier la largeur de fenêtre), la largeur de fenêtre étant transmise dans les acquittements donnés pour des segments de taille supérieure.
Le segment envoyé pour tester une largeur de fenêtre nulle peut conduire à une "atomisation" de la transmission. Lorsque le segment testant cette information et contenant un seul octet de données est accepté (à la réouverture de la fenêtre), il consomme un octet du nouvel espace ouvert. Si l'émetteur envoie systématiquement autant de données qu'il peut lorsque la fenêtre est ouverte, la transmission
va se stabiliser en une succession de petits et longs segments. Au fur et à mesure du temps, les variations de débit interne entre les tampons et la connexion conduit à une séquence de segments courts et "pas si longs que ça". Après un certain temps, la connexion est principalement constituée de segments courts.
La suggestion faite ici est que les implémentations de TCP doivent gérer attentivement la variation de largeur de fenêtre, les versions les plus simplistes conduisant toujours à une fragmentation excessive de la transmission.
| 3.8. Interfaces |
|
Deux interfaces sont concernées dans ce chapitre: l'interface application/TCP et l'application TCP/réseau (la dernière via le protocole de niveau inférieur). Nous définirons assez précisément le protocole entre l'application et l'interface, et passerons sous silence l'interface entre TCP et la couche inférieure, dans la mesure où celle-ci est parfaitement définie dans la spécification de ce protocole.
Dans le cas où ce protocole est IP, on remarquera quelques paramètres communs à ces deux protocoles.
Interface application/TCP
La description à suivre des commandes à envoyer à TCP sera tout au plus une spécification d'intention, dans la mesure où les ressources système et leur forme diffèrent considérablement d'un système à l'autre. Par conséquent, nous devons prévenir le lecteur que différentes implémentations de TCP peuvent présenter des interfaces distinctes. Cependant, il existera toujours un
noyau de fonctions que TCP devra fournir à toute application, afin d'assurer la compatibilité globale du système multicouches. Ce chapitre décrit les commandes essentielles qu'un TCP se doit d'accepter.
Commandes applicatives vers TCP
Les paragraphes suivants décrivent les aspects fonctionnels de l'interface Application/TCP. La notation utilisée est très proche de la syntaxe habituellement acceptée pour les appels de fonctions par les langages de haut niveau, mais cet usage n'interdit pas l'utilisation d'appels sous forme condensée (ex., SVC, UUO, EMT).
Les commandes de base décrites ici sont essentielles pour qu'un TCP puisse supporter une communication inter-processus. Chaque implémentation concrète pourra adopter sa propre syntaxe, et pourra y adjoindre des combinaisons ou fonctions partielles issues de ces fonctions de base. Par exemple, certains utilisateurs souhaiteront qu'une premier appel à la fonction SEND puisse automatiquement ouvrir la connexion (OPEN).
Dans son rôle d'intermédiaire de communication, TCP doit non seulement accepter des commandes, mais doit retourner un certain nombre d'informations à l'application, soit en réponse à une commande, soit de façon unilatérale. Ces dernières consistent en:
(a) une information générale sur la connexion (ex., interruptions, fermeture distante, connexion sur tel socket passif en attente).
(b) des réponses à des commandes applicatives, indiquant le succès ou l'échec pour telle ou telle raison.
Convention : Dans la formulation des commandes qui suivent, nous adoptons la convention de notation suivante pour les paramètres :
| • |
Les paramètres de type bit (sémaphores) sont notés en MAJUSCULE. |
| • |
Les paramètres d'un autre type (adresse, entier, long, etc. sont notés en minuscule. |
OPEN
Format:
| OPEN (port_local, socket_distant, ACTIF/PASSIF [, tempo] [, priorité] [, sécurité/compartiment] [, options]) -> nom_local |
Nous supposons ici que le TCP local connaît l'identité du processus qu'il sert, et vérifiera que ce processus est bien autorisé à ouvrir une connexion sur le socket spécifié. Suivant l'implémentation de TCP, les identificateurs TCP et réseau d'adresse source seront soit fournis par TCP soit par le protocole de routage (ex. IP). Ces considérations découlent d'une réflexion sur la sécurité,
dont le but est d'interdire à un TCP de se faire passer pour un autre. De même, aucun processus ne peut se faire passer pour un autre sans la complicité des couches inférieures.
Si le paramètre ACTIF/PASSIF est marqué "passif", TCP se mettra dans l'état LISTEN et "écoutera" le réseau. Dans ce cas, le socket distant pourra soit être spécifié soit laissé "indéfini". Si le socket est spécifié, seule une demande de connexion provenant de ce socket pourra réveiller la connexion. Si le socket est laissé "indéfini", toute tentative de connexion distante sur
cette connexion sera prise en compte. Une connexion passive peut être rendue active par l'envoi d'une commande SEND ultérieure.
Un bloc de contrôle de transmission (TCB) est créé, partiellement renseigné avec les paramètres passés par la commande OPEN.
Sur commande OPEN active, TCP démarrera immédiatement la procédure de synchronisation (c'est-à-dire, l'établissement).
Le paramètre de temporisation tempo, si précisé, permet de régler la limite maximale admise pour la transmission de données par TCP. Si les données n'ont pu être transmises au destinataire avant ce temps, TCP aura la charge de couper la communication. La valeur par défaut actuelle pour cette temporisation est de 5 minutes.
TCP ou un autre composant du système d'exploitation aura la charge de vérifier les droits de l'application à ouvrir une communication sur la priorité, la sécurité et le compartiment demandés. L'absence de paramètres à ce niveau implique l'utilisation des valeurs "par défaut".
TCP ne pourra accepter de requête entrante que dans la mesure où les informations de sécurité/compartiment correspondent exactement à celles précisées dans la commande OPEN, et la priorité y est au moins égale ou supérieure.
La priorité choisie pour la connexion sera la valeur maximum entre celle pr&eacut 1000 e;cisée dans la commande OPEN et celle arrivée par le réseau. Elle sera fixée pour toute la durée de vie de la connexion. Certains développeurs voudront pouvoir donner à l'application le pouvoir de négocier cette priorité. Par exemple, l'application pourra souhaiter de n'accepter la connexion que sur le même niveau
de priorité, ou souhaitera que toute augmentation du niveau de priorité soit soumis à son approbation.
Un nom local sera retourné par TCP pour la connexion. Ce nom symbolique pourra être par la suite utilisé comme raccourci dans les appels faits à cette connexion définie par la paire <socket local, socket distant>.
SEND
Format:
| SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo]) |
Cet appel permet l'envoi des données contenues dans le tampon de taille compte débutant à l'adresse_tampon sur la connexion définie par nom_local. Dans le cas général, si la connexion n'a pas été ouverte auparavant, cette commande génère une erreur. Certaines implémentations permettront l'usage direct de la commande SEND; celles-ci demanderont les paramètres supplémentaires
utiles à l'établissement préalable de la connexion. Si l'application demanderesse n'est pas autorisée à ouvrir la connexion demandée, une erreur sera retournée.
Si l'indicateur PUSH est marqué, les données doivent être émises sans attendre vers le destinataire, et le flag PUSH du dernier segment TCP créé à partir de ce tampon sera marqué. Dans le cas contraire, les données pourront être momentanément stockées par TCP pour être assemblées à celles provenant des SEND suivants, si l'efficacité de la transmission le demande.
Si l'indicateur URGENT est marqué, les segments envoyés au TCP distant auront le flag URG marqué, indiquant la validité du "pointeur urgent". Le TCP récepteur signalera à l'application distante l'état d'urgence tant que toutes les données urgentes n'ont pas été récupérées par l'application destinataire. Le but de ce mécanisme et d'inciter l'application à traiter ces données
en priorité, et d'aviser le récepteur que toutes les données de ce type ont été prises en compte. Le nombre de fois que le TCP émetteur signale le caractère d'urgence n'est pas nécessairement le même que celui que l'application reçoit du TCP distant.
Si aucun socket distant n'a été spécifié dans la commande OPEN, et la connexion établie malgré tout (ex. à la suite d'une requête de connexion quelconque arrivée sur ce socket), alors le tampon désigné est envoyé vers ce socket "implicite". Les applications utilisant la commande SEND sur une telle connexion n'ont pas le besoin de connaître la valeur du socket distant.
Par contre, si une commande SEND est exécutée avant que le socket distant ait été explicité, une erreur est retournée. L'application peut exécuter la commande STATUS pour déterminer l'état de la connexion. Dans certaines implémentations TCP indiquera à l'application lorsqu'une connexion passive "indéfinie" est explicitée.
Lorsqu'une tempo est présente, la valeur courante de la temporisation définie à la commande OPEN est remplacée par la nouvelle valeur.
Dans les implémentations les plus simples, la commande SEND ne rendra pas la main au processus appelant tant que la transmission n'est pas achevée ou, à défaut, la temporisation n'est pas écoulée. Cependant, cette technique simpliste provoque de nombreux temps morts, voire blocages (par exemple, si les deux côtés d'une transmission essaient d'envoyer des données avant de demander la première réception).
Elle est donc déconseillée. Une technique plus sophistiquée rendra la main immédiatement à l'application, de sorte qu'elle continue son traitement concurrentiellement avec les routines d'entrées/sorties réseau, et, de plus permettre le lancement de plusieurs émissions successives (une sorte de "batch"). Des envois successifs seront traités dans ce cas sur le mode FIFO (premier arrivé premier servi), et TCP devra
aménager une pile pour ceux qu'il ne pourra traiter immédiatement.
Nous venons implicitement de définir une interface de type "asynchrone" dans laquelle une commande SEND induit un SIGNAL ultérieur ou une pseudo interruption provenant du TCP. Une autre alternative est de répondre immédiatement à l'application. Par exemple, TCP peut donner un acquittement local immédiat en réponse à la commande SEND de l'application, même si lui-même n'a pas encore reçu l'acquittement de
réception par le distant, ni même envoyé les données. Nous pouvons avec optimisme penser que le succès est quasi garanti. Si nous avons été vraiment trop optimiste, la temporisation nous indiquera vite que nous nous sommes trop avancé, et coupera la connexion. Une implémentation de ce type (synchrone) ne pourra s'affranchir de quelques signaux asynchrones, mais ceci concernent l'état global de la connexion, plutôt
que des informations particulières sur les tampons.
Afin que l'application puisse distinguer les retours d'erreur ou de succès de multiples SENDs, il paraît approprié d'ajouter à la réponse l'adresse du tampon concerné (celui qui aura été transmis par la commande SEND correspondante).
La signalisation TCP vers application est décrite ci-après, indiquant le type d'information qui doit être retourné à l'application appelante.
RECEIVE
Format:
| RECEIVE (nom_local, adresse_tampon, compte) -> compte, URGENCE, PUSH |
Cette commande alloue un tampon de réception à la connexion spécifiée. Si la connexion n'a pas été ouverte au préalable par une commande OPEN, ou l'application n'a pas l'autorisation d'utiliser une telle connexion, une erreur sera renvoyée.
Dans une implémentation simpliste, la main ne sera pas redonnée à l'application tant que le tampon n'aura pas été rempli, ou une erreur survenue. Ce schéma est malheureusement souvent bloquant. Une implémentation plus sophistiquée consisterait à pouvoir mettre en attente plusieurs commandes de réception. Les tampons associés se remplissent alors dès que les segments concernés arrivent par
le réseau. Cette stratégie permet un débit d'information plus rapide, au prix d'un mécanisme plus élaboré (éventuellement asynchrone) destiné à avertir l'application qu'une fonction push a été activée, ou que le tampon est plein.
Si une quantité de données suffisante est reçue avant qu'un flag PUSH n'apparaisse, l'indicateur PUSH ne sera pas marqué dans la réponse à la commande RECEIVE. Le tampon contiendra autant de données qu'il peut en contenir. Si un flag PUSH arrive du réseau, le tampon sera retourné partiellement rempli, et l'indicateur PUSH marqué dans la réponse.
Si des données urgentes sont présentées par le réseau, l'application en sera avertie immédiatement par un signal asynchrone de l'interface TCP vers application. Cette dernière doit passer en "mode urgent". Tant que l'indicateur URGENCE est marqué dans la réponse à une commande RECEIVE, des données urgentes restent latentes dans les tampons de TCP. Lorsque l'indicateur URGENCE n'est plus marqué, les dernières
données urgentes ont été transférées dans le tampon associé et l'application peut repasser en "mode normal". Notez que les données "normales" suivantes ne peuvent être transmises dans le même tampon (mais seront disponibles via la commande RECEIVE suivante), à moins que la limite ne soit clairement marquée.
Pour discriminer la réponse à plusieurs commandes RECEIVE en instance et pour s'assurer que les tampons à récupérer ont été complètement remplis, la réponse émise sous forme de signal, après réception, est accompagnée d'un pointeur sur le tampon et de la taille occupée dans celui-ci.
D'autres implémentations de la commande RECEIVE peuvent directement adresser l'espace mémoire alloué en interne par TCP au tampon de réception, ou encore mettre en place le partage d'un tampon tournant par les deux partenaires.
CLOSE
Format:
Cette commande demande la fermeture de la connexion spécifiée. Si la connexion n'existe pas, ou l'application n'a pas l'autorisation nécessaire pour utiliser cette connexion, une erreur est renvoyée. La fermeture de connexions est prévue pour se dérouler de façon "propre" dans la mesure ou toutes les émissions en instance seront menées à leur terme (et retransmises si nécessaire),selon les impératifs
du contrôle de flux. Ainsi, il est légitime de lancer plusieurs commandes SEND successives suivies d'une commande CLOSE, et de considérer que le message a été correctement et complètement transmis. Il est aussi clair que la communication doit être toujours "écoutée", afin de récupérer tout ce que le distant a à transmettre. De ce fait, la commande CLOSE signifie "je n'ai plus rien à transmettre",
et non pas "je ne veux plus rien recevoir". Il peut arriver (notamment si le protocole au niveau application n'est pas suffisamment complet) que le côté fermant la connexion ne puisse se débarrasser de toutes ses données avant intervention de la temporisation. Dans ce cas, la commande CLOSE revient à une commande ABORT, et TCP finit le travail de fermeture.
L'application doit pouvoir fermer la connexion à tout moment de sa propre initiative, ou en réponse à des signaux venant de TCP (ex. signal de déconnexion distante, temporisation de transmission écoulée, destination inaccessible).
Comme la fermeture d'une connexion demande un échange avec le TCP distant, celle-ci peut rester dans l'état "encours de fermeture" (CLOSING) pendant un petit laps de temps. Toute tentative de réouverture de cette connexion avant que TCP n'ait pu répondre à la commande CLOSE générera une erreur.
L'exécution d'une commande CLOSE déclenche implicitement une fonction push.
STATUS
Format:
| STATUS (nom_local) -> état |
Cette commande dépend de l'implémentation et peut être "oubliée" sans conséquence majeure. L'information renvoyée est essentiellement issue des données du TCB associé à la connexion.
Cette commande renvoie habituellement une structure de données comprenant les information suivantes:
|
socket local,
socket distant,
nom local de la connexion,
fenêtre en réception,
fenêtre en émission,
état de la connexion,
nombre de tampons attendant un acquittement,
nombre de tampons en attente de réception,
état d'urgence,
priorité,
sécurité/compartiment,
temporisation de transmission courante. |
Suivant l'état courant de la connexion ou l'implémentation, certaines de ces données ne peuvent être obtenues, ou significatives. Si l'application n'a pas l'autorisation pour adresse cette connexion, une erreur est renvoyée. Ceci permet d'éviter de diffuser des informations sur une connexion à une application non autorisée.
ABORT
Format:
Cette commande abandonne toutes les commandes SEND et RECEIVE en cours. Le TCB est effacé, et un message d'abandon est envoyé au TCP distant. Suivant l'implémentation, l'application recevra des indications en retour sur chacune des émissions et réceptions abandonnées, ou simplement un acquittement global de l'abandon. Messages TCP vers utilisateur
Il est prévu que le système d'exploitation fournisse un moyen pour que TCP puisse signaler des événements de façon asynchrone à l'application qui l'utilise. Lorsque TCP envoie un tel signal, des informations y prennent place. Il arrivera souvent qu'on y trouve un statut d'erreur. Dans les autres cas, on y trouvera un rapport concernant le succès de telle ou telle commande SEND, RECEIVE, ou autre.
Les information suivantes y apparaissent:
|
nom local de connexion Toujours
Libellé de la réponse Toujours
Adresse du tampon SEND & RECEIVE
compteur (taille reçue) RECEIVE
Indicateur PUSH RECEIVE
Indicateur URGENCE RECEIVE |
Interface TCP vers couche inférieure
TCP effectue des appels vers une couche inférieure du protocole de communication, chargée de "router" les segments. Les réseaux ARPAnet et Internet s'appuient sur le protocole Internet (IP).
Lorsque le protocole de niveau inférieur est I, TCP ajoute aux segments deux informations: le type de service et la durée de vie. TCP donne pour ces informations les valeurs suivantes:
Type de service = Priorité: routine, Delay: normal, Débit: normal, Fiabilité: normal; soit 00000000.
Durée de vie = une minute, soit 00111100.
Notez que la durée de vie maximale encodable pour un segment est de deux minutes. Par cette information, nous indiquons de manière explicite que tout segment doit être détruit s'il n'a pas été acheminé au bout d'une minute.
Si le protocole inférieur est IP (ou tout autre protocole disposant de cette fonction) et le "routage retour" (vers la source) est exploité, L'interface doit permettre de communiquer le chemin pris. Ceci est fondamental pour que les adresses source et destinataire utilisées pour le décodage du Checksum TCP soient bien les adresses originales de l'émetteur et celle de l'expéditeur (et non l'adresse du dernier routeur par lequel a transité le
message). Il est aussi important de garder la trace du chemin pour permettre d'établir la connexion inverse.
Tout protocole sur lequel s'appuiera TCP doit pouvoir fournir l'adresse source, destinataire, les champs de protocole, et une façon de déterminer la longueur "TCP length", lesquels garantissent ainsi une compatibilité avec les services offerts par IP, et nécessaires au calcul du Checksum.
| 3.9. Traitement des événements |
|
Les procédures décrites dans ce chapitre ne sont qu'un exemple d'implémentation possible. D'autres implémentations pourront s'appuyer sur des séquences différentes, mais seulement en détail, et non dans l'intention.
Le principal de l'activité de TCP peut être assimilé comme la réponse à des événements. Les événements pouvant survenir peuvent être répartis en trois catégories: commandes de l'application, arrivée de segments, et écoulement de temporisations. Ce chapitre décrit dans le détail tout ce que TCP exécute sur réception de chacun de ces événements.
Dans la plupart des cas, la réaction de TCP dépendra de l'état de la connexion.
Evénements susceptibles de survenir:
| Appels applicatifs |
Arrivée d'un segment |
Temporisations |
| OPEN |
SEGMENT ARRIVES |
USER TIMEOUT |
| SEND |
|
RETRANSMISSION TIMEOUT |
| RECEIVE |
|
TIME-WAIT TIMEOUT |
| STATUS |
|
|
| CLOSE |
|
|
| ABORT |
|
|
Le modèle choisi pour l'interface TCP/application est celui où TCP répond immédiatement à la commande, quitte à fournir un complément de réponse différé par le biais d'un événement ou d'une pseudo-interruption. Dans tout ce qui suit, on nommera "réponse" la réponse immédiate, et "signal" la réponse
différée.
Les messages d'erreur sont indiqués sous leur forme explicite. Par exemple, une application émettant une commande pour une connexion inexistante recevra le message d'erreur "erreur: connexion inexistante".
Notez que dans tout ce qui suit, l'arithmétique utilisée pour les calculs sur les numéros de séquence, numéros d'acquittement, fenêtres, etc., est modulo 2**32 (la taille de l'espace de numérotation). Notez que le symbole "=<" signifie inférieur ou égal modulo 2**32.
Le traitement des segments entrants suppose qu'ils ont été au préalable validés en termes de séquence (c'est-à-dire que leur plage de séquence est effectivement incluse dans la fenêtre de transmission courante) et qu'ils sont de ce fait empilés, puis traités par ordre de séquence.
Lorsqu'un segment reçu affiche une plage de séquence qui recoupe celle d'un segment précédemment reçu, nous reconstituons ce segment en ne gardant que les "nouvelles" données, et réajustons les paramètres de son en-tête en conséquence.
Notez enfin qu'en l'absence d'une mention explicite de changement d'état, TCP reste dans l'état où il était avant l'événement.
Commande OPEN
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Créer un nouveau bloc de contrôle de transmission (TCB) pour mémoriser les informations sur la connexion. |
| • |
Remplit l'identificateur du socket local, du socket distant, la priorité, la sécurité/compartiment, et la temporisation "application". Certaines sous adresses du socket distant peuvent ne pas être remplies lorsque la commande OPEN est exécutée en mode "passif". Celles-ci seront explicitées lors de l'arrivée d'une requête de
connexion via le réseau. |
| • |
Vérifie les autorisations système pour la priorité et la sécurité m |
| |
si non autorisée |
|
• |
Répondre "erreur: priorité non attribuée" ou "erreur: sécurité/compartiment non autorisé". |
|
|
Retour |
Si passive,
| • |
entre dans le mode LISTEN. |
|
Retour |
Si active,
| • |
si le socket distant est non spécifié, ou "indéfini", |
|
• |
Répondre "erreur: socket distant non spécifié". |
|
• |
Retour |
| • |
si le socket distant est valide, |
|
• |
Composer un segment SYN. Choisir un numéro initial de séquence (ISS). |
|
• |
Emettre un segment SYN de forme <SEQ=ISS><CTL=SYN>. |
|
• |
Renseigner SND.UNA par l'ISS, SND.NXT par ISS+1, |
|
• |
Entrer en mode SYN-SENT. |
|
• |
Retour |
| • |
si l'application n'a pas le droit d'accès au socket spécifié, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
si manque de mémoire pour créer la connexion, |
| |
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
Etat précédent : LISTEN
Si active
| • |
Si le socket distant est spécifié, |
|
• |
Changer la connexion de passive à active. |
|
• |
Choisir un ISS. |
|
• |
Envoyer un segment SYN. |
|
• |
Renseigner SND.UNA par l'ISS, SND.NXT par ISS+1. |
|
• |
Entrer dans l'état SYN-SEN. Des données arrivées par une première commande SEND peuvent être envoyées dans le segment SYN ou empilées pour transmission après passage à l'état ESTABLISHED. Le bit URG doit être marqué si spécifié dans le première commande SEND. |
|
• |
Retour |
| • |
Si manque de mémoire pour empiler cette commande, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Si le socket distant non spécifié ou "indéfini", |
| |
• |
Répondre "erreur: socket distant non spécifié". |
|
• |
Retour |
Etats précédents : SYN-SENT STATE, SYN-RECEIVED STATE, ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE, CLOSE-WAIT STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
| • |
Répondre "erreur: la connexion existe déjà". |
| • |
Retour |
Commande SEND
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Si l'application n'a pas l'autorisation d'accès à cette connexion, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
Autrement |
|
• |
Répondre "erreur: connexion inexistante". |
|
• |
Retour |
Etat précédent : LISTEN
| • |
Si manque de mémoire pour empiler les données, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Si le socket distant non spécifié ou "indéfini" |
|
• |
Répondre "erreur: socket distant non spécifié". |
|
• |
Retour |
| • |
Si le socket distant est spécifié, |
|
• |
Passer la connexion de l'état passif à actif. |
|
• |
Choisir un ISS. |
|
• |
Emettre un segment SYN. |
|
• |
Renseigner SND.UNA par l'ISS, SND.NXT par ISS+1. |
|
• |
Entrer dans l'état SYN-SENT. Les données jointes peuvent être envoyées dans le segment SYN ou empilées pour transmission après passage à l'état ESTABLISHED. Le bit URG doit être marqué si spécifié dans le première commande SEND. |
| |
• |
Retour |
Etats précédents : SYN-SENT STATE, SYN-RECEIVED STATE
| • |
Si manque de mémoire pour empiler les données, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Sinon |
|
• |
Empiler les données pour transmission une fois l'état ESTABLISHED établi. |
|
• |
Retour |
Etats précédents : ESTABLISHED STATE, CLOSE-WAIT STATE
| • |
Si manque de mémoire pour conserver les données, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Segmenter le tampon et l'envoie avec un acquittement (valeur = RCV.NXT). |
| • |
Si l'indicateur URGENT est marqué, alors SND.UP <- SND.NXT-1 et le pointeur d'urgence est activé dans les segments sortants. |
|
• |
Retour |
Etats précédents : FIN-WAIT-1 STATE, FIN-WAIT-2 STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
|
• |
Répondre "erreur: connexion en fermeture" et ignorer les requêtes ultérieure. |
Commande RECEIVE
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Si l'application n'a pas l'autorisation d'accès à cette connexion, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
Autrement |
|
• |
Répondre "erreur: connexion inexistante". |
|
• |
Retour |
Etats précédents : LISTEN STATE, SYN-SENT STATE, SYN-RECEIVED STATE
| • |
Si manque de mémoire pour empiler cette requête, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Empiler la requête pour traitement une fois l'état ESTABLISHED établi. |
Etats précédents : ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE
| • |
Si un nombre insuffisant de segments sont arrivés, |
|
• |
Empiler la requête. |
|
• |
Retour |
| • |
Si manque de mémoire pour empiler cette requête, |
|
• |
Répondre "erreur: ressources insuffisantes". |
|
• |
Retour |
| • |
Réassembler les segments empilés dans le tampon de réception et donner la réponse à l'application. Marquer "push seen" (PUSH) le cas échéant. |
| • |
Si RCV.UP pointe sur des données non encore reçues, notifier l'application de la présence de données urgentes. |
Lorsque TCP prend la responsabilité de passer des données à l'application, il doit envoyer un acquittement à l'émetteur. La construction de cet acquittement est traitée ci-après aux paragraphes concernant l'arrivée d'un segment.
Etat précédent : CLOSE-WAIT STATE
Comme le distant a déjà envoyé son segment FIN, la commande passe à l'application les données encore stockées par TCP.
| • |
Si plus aucune donnée n'est à délivrer, |
|
• |
Répondre "erreur: déconnexion en cours". |
|
• |
Retour |
| • |
Autrement toute les données restantes sont utilisables pour satisfaire la requête. |
Etats précédents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
|
• |
Répondre "erreur: déconnexion en cours". |
|
• |
Retour |
Commande CLOSE
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Si l'application n'a pas l'autorisation d'accès à cette connexion, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
Autrement |
|
• |
Répondre "erreur: connexion inexistante". |
|
• |
Retour |
Etat précédent : LISTEN
|
• |
Toute requête RECEIVE empilée provoque une sortie d'erreur, |
|
• |
Répondre "erreur: déconnexion". |
|
• |
Effacer le TCB. |
|
• |
Passer la connexion à l'état CLOSED. |
| |
• |
Retour |
Etat précédent : SYN-SENT STATE
|
• |
Efface le TCB et retourne "erreur: déconnexion" pour chaque requête SEND ou RECEIVE latente. |
Etat précédent : SYN-RECEIVED STATE
| • |
Si aucune commande SEND n'a été lancée et qu'il ne reste plus de données à transmettre, |
|
• |
Constituer un segment FIN et l'émettre. |
|
• |
Passer dans l'état FIN-WAIT-1. |
|
• |
Retour |
| • |
Autrement |
|
• |
Empiler la requête en attente de passage dans l'état ESTABLISHED. |
|
• |
Retour |
Etat précédent : ESTABLISHED STATE
|
• |
Place la requête en attente, le temps de segmenter toutes les requêtes SEND en attente, |
|
• |
Forme un segment FIN et l'envoie. |
|
• |
Passe la connexion à l'état FIN-WAIT-1 dans tous les cas. |
Etats précédents : FIN-WAIT-1 STATE, FIN-WAIT-2 STATE
| • |
Strictement parlant, il s'agit d'une erreur et devrait provoquer une sortie "erreur: déconnexion en cours". Une réponse "OK" serait aussi bien acceptable, jusqu'à ce que le deuxième FIN soit émis (le premier segment Fin peut encore être retransmis). |
Etat précédent : CLOSE-WAIT STATE
|
• |
Placer la requête en attente, le temps de segmenter toutes les requêtes SEND en attente, |
|
• |
Former un segment FIN et l'envoie. |
|
• |
Passer la connexion à l'état CLOSING. |
|
• |
Retour |
Etats précédents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
|
• |
Retourner "erreur: déconnexion en cours". |
|
• |
Retour |
Commande : ABORT
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Si l'application n'a pas d'autorisation d'accès à cette connexion, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
Autrement |
|
• |
Répondre "erreur: connexion inexistante". |
|
• |
Retour |
Etat précédent : LISTEN
|
• |
Toute requête RECEIVE en attente recevra un signal "erreur: abandon" en réponse. |
|
• |
Effacer le TCB. |
|
• |
Passer la connexion à l'état CLOSED. |
|
• |
Retour |
Etat précédent : SYN-SENT STATE
|
• |
Toute requête SEND ou RECEIVE en attente recevra un signal "erreur: abandon" en réponse. |
|
• |
Effacer le TCB. |
|
• |
Passer la connexion à l'état CLOSED. |
|
• |
Retour |
Etats précédents : SYN-RECEIVED STATE, ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE, CLOSE-WAIT STATE
|
• |
Envoyer un segment de réinitialisation: <SEQ=SND.NXT><CTL=RST> |
|
• |
Toute requête SEND ou RECEIVE en attente recevra un signal "erreur: abandon" en réponse. |
|
• |
Libérer tous les tampons liés aux commandes RECEIVE et SEND en attente, |
|
• |
Supprimer les segments constitués excepté le segment RST ci-dessus. |
|
• |
Effacer le TCB. |
|
• |
Passer la connexion dans l'état CLOSED. |
|
• |
Retour |
Etat précédent : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
|
• |
Répondre "OK", |
|
• |
Effacer le TCB, |
|
• |
Passer la connexion en mode CLOSED. |
|
• |
Retour |
Commande STATUS
Etat précédent : CLOSED STATE (TCB inexistant)
| • |
Si l'application n'a pas d'autorisation d'accès à cette connexion, |
|
• |
Répondre "erreur: connexion illégale pour cette application". |
|
• |
Retour |
| • |
Autrement |
|
• |
Répondre "erreur: connexion inexistante". |
|
• |
Retour |
Etat précédent : LISTEN
| • |
Renvoie "état = LISTEN", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : SYN-SENT STATE
| • |
Renvoie "état = SYN-SENT", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : SYN-RECEIVED STATE
| • |
Renvoie "état = SYN-RECEIVED", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : ESTABLISHED STATE
| • |
Renvoie "état = ESTABLISHED", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : FIN-WAIT-1 STATE
| • |
Renvoie "état = FIN-WAIT-1", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : FIN-WAIT-2 STATE
| • |
Renvoie "état = FIN-WAIT-2", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : CLOSE-WAIT STATE
| • |
Renvoie "état = CLOSE-WAIT", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : CLOSING STATE
| • |
Renvoie "état = CLOSING", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : LAST-ACK STATE
| • |
Renvoie "état = LAST-ACK", et un pointeur sur le TCB. |
|
Retour |
Etat précédent : TIME-WAIT STATE
| • |
Renvoie "état = TIME-WAIT", et un pointeur sur le TCB. |
|
Retour |
Arrivée réseau : SEGMENT ARRIVES
Etat précédent : CLOSED (c'est-à-dire, TCB n'existe pas)
| • |
Toutes les données du segment sont ignorées. Un segment RST est ignoré.. Un segment autre que RST entraîne l'émission d'un segment RST en réponse. Le numéro de séquence et l'accusé de réception sont renseignés de façon à ce que le segment soit acceptable par le TCP qui a envoyé le segment
erroné. |
|
• |
Si le bit ACK n'est pas marqué, [SEQ=0][ACK=SEG.SEQ+SEG.LEN][CTL=RST,ACK] |
|
• |
Si le bit ACK est marqué, [SEQ=SEG.ACK][CTL=RST] |
|
• |
Retour |
Etat précédent : LISTEN
| • |
Vérifier le marquage du bit RST |
|
• |
Un segment RST entrant sera ignoré. |
|
• |
Retour |
| • |
Vérifier le marquage du bit ACK |
|
• |
Un accusé de réception reçu par une connexion à l'état LISTEN représente une faute. Un segment RST acceptable doit être constitué pour tout acquittement hors contexte. Le RST doit être constitué comme suit: <SEQ=SEG.ACK><CTL=RST> |
|
• |
Retour |
| • |
Vérifier le marquage de SYN |
|
• |
Si le bit SYN est marqué, |
|
• |
vérifier la sécurité : |
|
• |
Si la donnée de sécurité/compartiment sur le segment entrant ne correspond pas exactement à celle marquée dans le TCB, |
|
• |
Envoi d'un segment RST au distant. : [SEQ=SEG.ACK][CTL=RST] |
|
• |
Retour |
|
• |
Si SEG.PRC est supérieur à TCB.PRC (test de priorité) |
|
• |
si non autorisé, |
|
• |
envoi d'un segment RST: [SEQ=SEG.ACK][CTL=RST]. |
|
• |
Retour |
|
• |
si autorisé par le système et l'application TCB.PRC<-SEG.PRC. |
|
• |
Continuer. |
|
• |
Si SEG.PRC est inférieur à TCB.PRC |
|
• |
Continuer. |
| • |
Renseigner RCV.NXT par SEG.SEQ+1, IRS par SEG.SEQ tous les autres contrôles et données doivent être empilés pour traitement ultérieur. Un ISS doit être choisi et un segment SYN émis, sous la forme: [SEQ=ISS][ACK=RCV.NXT][CTL=SYN,ACK] Renseigner SND.NXT par ISS+1 et SND.UNA par ISS. Passer la connexion à l'état SYN-RECEIVED.
Tous les autres contrôle ou données seront examinés et traités dans l'état SYN-RECEIVED, sauf SYN et ACK qui auront déjà été traités. Si la connexion était totalement ou partiellement indéfinie, la connexion est alors explicitée à ce moment. |
4. Autres données et contrôles
| • |
Tout autre contrôle ou segments portant des données (sans SYN) sont nécessairement marqués en tant que ACK et seront donc écartés par le traitement des acquittements. Un segment RST entrant ne peut pas être valide, car il ne peut correspondre à aucune émission faite par cette instance de la connexion. Ce cas ne devrait jamais
arriver. Si par hasard il se produit, rejetez le segment. |
| • |
Retour |
Etat précédent : SYN-SENT
1. vérifier le marquage du bit ACK
| • |
Si ACK est marqué, |
|
• |
Si SEG.ACK =\< ISS, ou SEG.ACK \> SND.NXT, envoyer un RST (sauf si le segment est lui meme un RST auquel cas il doit etre ignoré et Retour) [SEQ=SEG.ACK][CTL=RST] |
|
• |
détruire le segment. |
|
• |
Retour |
| • |
Si SND.UNA =< SEG.ACK =< SND.NXT l'acquittement est acceptable. |
2. vérifier le marquage du bit ACK
| • |
Si RST est marqué, |
|
• |
Si l'acquittement est conforme, |
|
• |
avertir l'application par "erreur: abandon distant", |
|
• |
détruire le segment, |
|
• |
passer la connexion en état CLOSED, |
|
• |
effacer le TCB |
|
• |
Retour |
|
• |
Sinon (non ACK) |
|
• |
Ignorer le segment. |
|
• |
Retour |
| • |
Vérifier la sécurité et la priorité, |
|
• |
Si la valeur de sécurité compartiment ne correspond pas à celle inscrite dans le TCB, |
|
• |
Si ACK est marqué, |
|
• |
Envoi d'un RST : [SEQ=SEG.ACK][CTL=RST] |
|
• |
Sinon |
|
• |
Envoi d'un RST : [SEQ=0][ACK=SEG.SEQ+SEG.LEN][CTL=RST,ACK |
|
• |
Sinon |
|
• |
Si ACK est marqué, |
|
• |
Si la priorité dans le segment ne correspondre pas à celle inscrite dans le TCB |
|
• |
envoi d'un segment RST: [SEQ=SEG.ACK][CTL=RST] |
|
• |
Sinon |
|
• |
Si la priorité du segment est supérieure à celle inscrite dans le TCB et |
|
• |
si le système et l'application le permettent, |
|
• |
remonter la priorité de la connexion inscrite dans le TCB au niveau de celle trouvée dans le segment, |
|
• |
Si il n'est pas autorisé de monter le niveau de priorité, |
|
• |
envoyer un RST [SEQ=0][ACK=SEG.SEQ+SEG.LEN][CTL=RST,ACK] |
|
• |
Si la priorité dans le segment est inférieure à celle inscrite dans le TCB |
|
• |
continuer. |
| • |
Si un RST a été envoyé, |
|
• |
détruire le segment, |
|
• |
Retour |
3. Vérifier le marquage du bit SYN
Cette étape ne peut être atteinte que si l'ACK est valide, ou il ne s'agit pas d'un ACK ni d'un segment RST.
| • |
Si le bit SYN est marqué et les conditions de sécurité/compartiment et priorité sont vérifiées, |
|
• |
RCV.NXT prend la valeur SEG.SEQ+1, |
|
• |
IRS prend la valeur SEG.SEQ. |
|
• |
Si ACK est marqué : SND.UNA est incrémenté jusqu'à la valeur SEG.ACK tous les segments de la pile de retransmission qui ont de ce fait été acquittés sont supprimés. |
|
• |
Si SND.UNA > ISS (notre propre SYN a été acquitté), |
|
• |
passer la connexion à l'état ESTABLISHED, |
|
• |
Emettre l'accusé de réception [SEQ=SND.NXT][ACK=RCV.NXT][CTL=ACK] |
|
• |
Les données et contrôles en attente dans la pile d'émission peuvent être transmis dans ce segment. |
|
• |
Si des données sont contenues dans le segment, |
|
• |
Aller au pas 6 ci-après, où le bit URG est vérifié, |
|
• |
Sinon |
|
• |
Retour |
|
• |
Autrement (notre SYN n'est pas encore acquitté) |
|
• |
passer en mode SYN-RECEIVED, |
|
• |
former un segment SYN,ACK sous la forme [SEQ=ISS][ACK=RCV.NXT][CTL=SYN,ACK] et l'envoyer. |
|
• |
Si d'autres contrôles ou données sont présentes dans le segment, |
|
• |
les empiler en attendant le passage à l'état ESTABLISHED. |
|
• |
Retour |
| • |
Si aucun des bits SYN ou RST n'est marqué, |
|
• |
rejeter le segment. |
|
• |
Retour |
| • |
Autrement, |
Etats précédents : SYN-RECEIVED STATE,ESTABLISHED STATE, FIN-WAIT-1 STATE,FIN-WAIT-2 STATE,CLOSE-WAIT STATE,CLOSING STATE,LAST-ACK STATE,TIME-WAIT STATE
1. Tester le numéro de séquence
Les segments sont traités dans l'ordre de la séquence. Les premiers tests servent à éliminer les anciennes données dupliquées, les traitements suivants sont faits selon l'ordre des SEG.SEQ. Si segment transporte des données dont une partie est ancienne et l'autre nouvelle, seule la partie nouvelle sera prise en compte. Il y a quatre cas d'acceptabilité des segments :
|
Longueur du Fenêtre de Test
Segment Réception
------- ------- ----------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 non acceptable
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND |
Si RCV.WND vaut zéro, aucun segment ne peut être accepté, mais des dérogations doivent être prévues pour des segments ACK, URG et RST valides.
| • |
Si le segment n'est pas acceptable, |
|
• |
s'il s'agit d'un segment RST |
|
• |
Jeter le segment |
|
• |
Retour |
|
• |
sinon, |
|
• |
Emettre un acquittement [SEQ=SND.NXT][ACK=RCV.NXT][CTL=ACK] Jeter le segment |
|
• |
Retour |
Dans la suite, nous traitons le cas d'un segment "idéal" de premier numéro de séquence RCV.NXT et dont la longueur n'excède pas la largeur de la fenêtre. Il serait possible, si cette longueur était supérieure, de découper ce segment en deux parties, l'une de longueur égale à la largeur fenêtre (y compris pour les segments SYN
et FIN), et traiter le segment commençant à RCV.NXT. L'autre partie "hors fenêtre" serait alors empilée pour traitement ultérieur.
2. Vérifier le bit RST,
Etat précédent : SYN-RECEIVED STATE
| • |
Si le bit RST est marqué, |
| • |
Si l'ouverture de connexion était passive (c'est-à-dire, était passée par un état LISTEN) |
|
• |
Retourne la connexion à l'état passif LISTEN. |
|
• |
L'application n'en est pas nécessairement avisée. |
| • |
Si l'ouverture de la connexion était active (c'est-à-dire, étant passée par l'état SYN-SENT) alors la requête de connexion a été refusée par le distant. |
|
• |
TCP signale à l'application "Connexion rejetée". |
|
• |
Passer la connexion à l'état CLOSED |
|
• |
Supprimer le TCB. |
| • |
Dans les deux cas, |
|
• |
Supprimer tous les segments de la pile de retransmission. |
|
• |
Retour |
Etats précédents : ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT
| • |
Si le bit RST est marqué, |
|
• |
Signaler "erreur : abandon" pour toute commande SEND ou RECEIVE en instance. |
|
• |
Vider toutes les piles internes. |
|
• |
L'application peut de plus recevoir un signal "abandon" global. |
|
• |
Passer la connexion à l'état CLOSED, |
|
• |
Supprimer le TCB. |
|
• |
Retour |
Etats précédents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT
| • |
Si le bit RST est marqué, |
|
• |
Passer la connexion à l'état CLOSED Supprimer le TCB |
|
• |
Retour |
3. Vérifier la sécurité et la priorité
Etat précédent : SYN-RECEIVED
| • |
Si la valeur de sécurité/compartiment ne correspond pas exactement à celle inscrite dans le TCB, |
|
• |
mettre un segment RST |
|
• |
Retour |
Etat précédent : ESTABLISHED STATE
| • |
Si la valeur de sécurité/compartiment ne correspond pas exactement à celle inscrite dans le TCB, |
|
• |
Emettre un segment RST |
|
• |
Signaler "erreur : abandon" pour toute commande SEND ou RECEIVE en instance. |
|
• |
Vider toutes les piles internes. |
|
• |
L'application peut de plus recevoir un signal "abandon" global. |
|
• |
Passer la connexion à l'état CLOSED, |
|
• |
Supprimer le TCB. |
|
• |
Retour |
| |
Notez que ce test est placé après le test de séquence, afin d'éviter qu'un segment d'une ancienne connexion entre ces deux ports, avec un niveau de priorité et de sécurité distinct ne vienne provoquer l'abandon intempestif de la connexion courante. |
4. Vérifier le bit SYN
Etats précédents : SYN-RECEIVED, ESTABLISHED STATE, FIN-WAIT STATE-1, FIN-WAIT STATE-2, CLOSE-WAIT STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
| • |
Si le segment SYN est dans la fenêtre, ce ne peut être qu'une erreur, |
|
• |
Emettre un RST, |
|
• |
Signaler "erreur : abandon" pour toute commande SEND ou RECEIVE en instance. |
|
• |
Vider toutes les piles internes. |
|
• |
L'application peut de plus recevoir un signal "abandon" global. |
|
• |
Passer la connexion à l'état CLOSED |
|
• |
Supprimer le TCB |
|
• |
Retour |
Le cas où le segment SYN n'est pas dans la fenêtre correspond à celui où un ACK a été renvoyé dans le premier pas (vérification des numéros de séquence).
5. Vérifier le marquage du bit ACK
| • |
Si le bit ACK n'est pas marqué, |
|
• |
Jeter le segment |
|
• |
Retour |
| • |
Si le bit ACK est marqué, |
Etat précédent : SYN-RECEIVED STATE
| • |
Si SND.UNA =< SEG.ACK =< SND.NXT |
|
• |
Passer la connexion à l'état ESTABLISHED |
|
• |
continuer |
| • |
Si l'accusé de réception n'est pas acceptable, |
|
• |
Emettre un RST : [SEQ=SEG.ACK][CTL=RST |
Etat précédent : ESTABLISHED STATE
| • |
Si SND.UNA < SEG.ACK =< SND.NXT |
|
• |
SND.UNA = SEG.ACK. |
|
• |
Retirer de la pile de retransmission tous les segments acquittés. |
|
• |
Renvoyer un signal d'aquittement à l'application pour chaque commande SEND complètement envoyée et |
|
• |
acquittée (en renvoyant le tampon SEND avec la mention "OK"). |
| • |
Si le segment ACK est un doublon (SEG.ACK < SND.UNA) |
|
• |
Ignorer le segment |
| • |
Si l'accusé de réception acquitte des données non encore émises (SEG.ACK > SND.NXT) |
|
• |
Emettre un ACK |
|
• |
Jeter le segment |
|
• |
Retour |
| • |
Si SND.UNA < SEG.ACK =< SND.NXT, |
|
• |
Remettre à jour la fenêtre d'émission |
| • |
Si (SND.WL1 < SEG.SEQ ou (SND.WL1 = SEG.SEQ et SND.WL2 =< SEG.ACK)), |
|
• |
SND.WND = SEG.WND, |
|
• |
SND.WL1 = SEG.SEQ, |
|
• |
SND.WL2 = SEG.ACK. |
Notez que SND.WND représente un décalage relatif par rapport à SND.UNA, que SND.WL1 enregistre le numéro de séquence du dernier segment ayant servi à remettre SND.WND à jour, et que SND.WL2 enregistre le numéro d'acquittement du dernier segment ayant permis de remettre SND.WND à jour. Ce test permet d'éviter de considérer des
segments "anciens" pour remettre à jour la fenêtre.
Etat précédent : FIN-WAIT-1 STATE
En plus du traitement effectué pour l'état ESTABLISHED,
| • |
Si le segment FIN émis (local) a été acquitté, |
|
• |
Passer la connexion à l'état FIN-WAIT-2 |
|
• |
Continuer dans cet état. |
Etat précédent : FIN-WAIT-2 STATE
En plus du traitement effectué pour l'état ESTABLISHED,
| • |
Si la pile de retransmission est vide |
|
• |
La commande CLOSE de l'application peut être acquittée ("OK"), mais le TCB doit rester en place. |
Etat précédent : CLOSE-WAIT STATE
Etat précédent : CLOSING STATE
En plus du traitement effectué pour l'état ESTABLISHED,
| • |
Si le segment ACK acquitte le segment FIN émis (local) |
|
• |
Passer la connexion à l'état TIME-WAIT |
| • |
Sinon |
|
• |
Ignorer le segment. |
Etat précédent : LAST-ACK STATE
Le seul événement attendu dans cet état est l'acquittement de notre segment FIN.
| • |
Dès que cet événement se produit, |
|
• |
Supprimer le TCB, |
|
• |
Passer la connexion à l'état CLOSED |
|
• |
Retour |
Etat précédent : TIME-WAIT STATE
Le seul segment attendu dans cet état est la retransmission du segment FIN distant.
| • |
Dès que cet événement se produit, |
|
• |
L'acquitter |
|
• |
Relancer la temporisation de 2 MSL. |
|
• |
Retour |
6. Vérifier le bit URG
Etats précédents : ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE
| • |
Si le bit URG est marqué, |
|
• |
RCV.UP = max(RCV.UP,SEG.UP), |
|
• |
Si le pointeur urgent (RCV.UP) pointe sur des données non consommées, |
|
• |
Si l'application n'est pas déjà dans le mode "urgent" |
|
• |
- Signaler à l'application la présence de données urgentes.
|
Etats précédents : CLOSE-WAIT STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT
Ce cas ne devrait pas se produire, car un segment FIN a été reçu du distant.
7. Récupérer les données,
Etats précédents : ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE
Une fois la connexion entrée dans l'état ESTABLISHED, il est possible de livrer des données dans les tampons RECEIVE de l'utilisateur. Les données peuvent être extraites du segment et rangées dans le tampon jusqu'à ce que celui-ci soit plein, ou le segment soit vide. Si le segment est vide (moins de données arrivées que d'espace libre dans le tampon) et que le flag PUSH est marqué, alors l'application en est
informée lorsque le tampon lui est renvoyé.
Lorsque TCP prend la responsabilité de transmettre des données vers l'utilisateur, il est supposé acquitter la réception de ces données.
Une fois que TCP a pris cette responsabilité, il doit avancer RCV.NXT du nombre d'octets acceptés, et ajuste RCV.WND de façon à tenir compte de l'espace de tampon restant. La somme de RCV.NXT et RCV.WND ne peut être réduit.
Reportez vous aux suggestions sur la gestion de fenêtre au paragraphe 3.7.
Envoyer un accusé de réception sous la forme: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
Cet accusé de réception pourra profiter de la transmission d'un segment d'émission, dans la mesure où cela n'engendre pas un retard trop important.
Etats précédents : CLOSE-WAIT STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE
Ce cas ne devrait pas survenir, dans la mesure où un segment FIN a été reçu du côté distant. Ignorer les données du segment dans ce cas.
8. vérifier le bit FIN,
| • |
Ne traitez pas le bit FIN si l'état est CLOSED, LISTEN ou SYN-SENT puisque SEG.SEQ ne peut pas être validé, |
|
• |
Jeter le segment |
|
• |
Retour |
| • |
Si le bit FIN est marqué, |
|
• |
signaler à l'application "déconnexion en cours" |
|
• |
Renvoyez un message identique pour chaque RECEIVE en instance, |
|
• |
Avancer RCV.NXT au delà de FIN, |
|
• |
Envoyer un acquittement pour ce FIN. |
Notez que ce FIN force le PUSH de tout segment non encore délivré à l'application.
Etats précédents : SYN-RECEIVED STATE, ESTABLISHED STATE
| • |
Passer dans l'état CLOSE-WAIT. |
| • |
Retour |
Etat précédent : FIN-WAIT-1 STATE
| • |
Si notre propre FIN a été acquitté (peut être dans ce segment), alors |
|
• |
Passer dans l'état TIME-WAIT, |
|
• |
Amorcer la temporisation d'attente |
|
• |
Arrêter toutes les autres temporisations; |
|
• |
Retour |
| • |
Sinon |
|
• |
Passer dans l'état CLOSING |
Etat précédent : FIN-WAIT-2 STATE
| • |
Passer dans l'état TIME-WAIT. |
| • |
Amorcer la temporisation d'attente |
| • |
Arrêter toutes les autres temporisations; |
| • |
Retour |
Etat précédent : CLOSE-WAIT STATE
Reste dans l'état CLOSE-WAIT.
Etat précédent : CLOSING STATE
Reste dans l'état CLOSING.
Etat précédent : LAST-ACK STATE
Reste dans l'état LAST-ACK.
Etat précédent : TIME-WAIT STATE
| • |
Reste dans l'état TIME-WAIT. |
| • |
Relance de 2 MSL la temporisation. |
| • |
Retour |
Temporisation : USER TIMEOUT
| • |
Dans tous les états, si la temporisation utilisateur s'écoule complètement, |
|
• |
Vider toutes les piles |
|
• |
Renvoyer "erreur: abandon sur non réponse" à l'application, en général, et pour chacune des commandes en instance. |
|
• |
Supprimer le TCB |
|
• |
Passer à l'état CLOSED |
|
• |
Retour |
Temporisation : RETRANSMISSION TIMEOUT
| • |
Si la temporisation de retransmission expire pour un segment de la pile de retransmission, |
|
• |
Renvoyer de nouveau ce segment en tête de pile. |
|
• |
Réinitialiser la temporisation |
|
• |
Retour |
Temporisation : TIME-WAIT TIMEOUT
| • |
Lorsque la temporisation d'attente de déconnexion expire, |
|
• |
Supprimer le TCB |
|
• |
Passer dans l'état CLOSED |
|
• |
Retour |
| Glossaire |
|
1822
BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". La spécification de l'interface entre un ordinateur et ARPAnet.
Accusé de réception
Le numéro de séquence indiqué dans le champ d'accusé de réception du segment entrant.
ACK
Un bit de contrôle (acquittement) ne consommant pas d'espace séquence, indiquant que le champ d'accusé de réception de ce segment indique le prochain numéro de séquence attendu par l'émetteur de ce segment, acquittant implicitement tous l'espace de séquence inférieur à ce nombre.
Adresse de destination
L'adresse de destination spécifie le numéro de la "branche" de réseau et le numéro de l'ordinateur cible sur cette branche.
Adresse source
L'adresse Internet de la source, constituée d'une adresse réseau et de l'adresse de l'ordinateur sur ce réseau.
ARPAnet, message
L'unité de transmission entre un ordinateur et un IMP d'ARPAnet. La taille maximale du message est d'environ 1012 octets (8096 bits).
ARPAnet, paquet
Unité de transmission utilisée sur ARPAnet entre IMP. La taille maximale du paquet est de 126 octets (1008 bits).
Connexion
Une communication logique définie par une paire de sockets.
Datagramme
Un message envoyé sur un réseau de transmission de données à commutation de paquets.
Fenêtre d'émission
Représente la plage de séquence que le TCP distant est prêt à recevoir. Elle correspond à la valeur de fenêtre reçue dans les segments transmis par le TCP distant. La plage de numéro de séquence qu'il est possible d'émettre est nécessairement incluse dans l'intervalle [SND.NXT, SND.UNA + SND.WND - 1] et, en général commence sur SND.NXT. (Les retransmissions de segments dans une plage de SND.UNA à SND.NXT
sont bien entendu acceptés).
Fenêtre de réception
Représente la plage de numéros de séquence (en réception) que TCP s'attend à recevoir. Ainsi, tout segment dont la plage est incluse dans l'intervalle [RCV.NXT, RCV.NXT + RCV.WND - 1] est recevable. Tout segment dont la plage est intégralement en dehors de cet intervalle est supposé être un doublon et est rejeté.
FIN
Un bit de contrôle (finis) occupant consommant un numéro de séquence, indiquant que l'émetteur n'enverra plus de données ni de contrôles occupant de l'espace de séquence.
Fragment
Une portion d'une unité de transmission de données, en particulier, un fragment Internet est une portion d'un datagramme Internet.
FTP
Protocole de transfert de fichiers.
Header (en-tête)
Ensemble d'informations de contrôle placé en tête d'un datagramme, segment, fragment, paquet ou bloc de données.
Host
Un ordinateur. Peut être source ou destination du point de vue d'un réseau de données. On distingue les Hosts des stations de travail ou terminaux, lesquels ne sont pas autonomes et nécessitent justement les ressources d'un Host.
Identification
Un champ du protocole IP. Cette valeur d'identification aide à recomposer les fragments d'un même datagramme.
IMP
Interface Message Processor, le "routeur" du réseau ARPAnet.
Internet, adresse
Une adresse de 32 bits spécifiant l'adresse unique d'un host sur un réseau.
Internet, datagramme
L'unité d'échange de données entre la couche Internet et les couches supérieures comprenant l'en-tête Internet.
Internet, fragment
Une portion d'un datagramme Internet complété d'une en-tête Internet.
IP
Protocole Internet
IRS
Initial Receive Sequence. Le tout premier numéro de séquence attendu par un récepteur.
ISN
Initial Sequence Number. Le premier numéro de séquence utilisé lors d'une connexion, (ISS ou IRS). Choisi en fonction d'une horloge.
ISS
Initial Send Sequence. Le tout premier numéro de séquence émis par un émetteur.
Leader (en-tête)
Information de contrôle placé en tête d'un bloc de données. En particulier, dans ARPAnet, l'information de contrôle de message ARPAnet à la hauteur de l'interface host/IMP.
Longueur de segment
La plage de numéro de séquence transmise par le segment, y compris les numéros consommés par certains bits de contrôle.
Module
L'implémentation, généralement logicielle, d'une fonction particulière.
MSL
Maximum Segment Lifetime, Le temps pendant lequel un segment TCP peut exister à l'intérieur du réseau de transmission. Arbitrairement : 2 minutes.
Numéro de séquence
Un index numérique servant à identifier un octet de données dans le flux de transmission. Cet index est calculé sur 32 bits, et reboucle modulo 2**32.
Octet
Huit bits.
Options
Un champ d'option peut en contenir plusieurs, chacune des options pouvant avoir une longueur de plusieurs octets. Les options sont à l'origine utilisées pour des fonctions de test; par exemple, pour véhiculer des étiquettes temporelles. Les deux protocoles Internet Protocol et TCP disposent de champs d'option.
Paquet
Un paquet est un terme très général désignant très exactement une section d'un flux de données encapsulé dans divers protocoles. En général, on parlera de paquet une entité physique, plutôt que logique. Mais l'usage fait utiliser ce terme dans le cas le plus général.
Paquet local
L'unité de transmission dans un réseau local.
Pointeur de données urgentes
Un champ de contrôle qui n'a de signification que lorsque le bit URG est marqué. Ce champ communique le numéro de séquence du dernier octet 'urgent' sur réception duquel l'application pourra repasser en mode "normal".
Port
La portion d'un socket qui définit l'entrée ou la sortie "logique" qu'utilise un processus pour véhiculer ses données.
Processus
Un programme en cours d'exécution. Une source ou destination, du point de vue du réseau ou de toute autre protocole de communication "host-to-host".
PUSH
Un bit de contrôle ne consommant pas d'espace séquence, indiquant que ce segment contient des données à transférer immédiatement à l'utilisateur.
RCV.NXT
Prochain numéro de séquence à recevoir.
RCV.UP
Pointeur de données urgentes.
RCV.WND
Fenêtre de réception
RST
Un bit de contrôle (reset) ne consommant pas d'espace séquence, indiquant au récepteur que celui-ci doit abandonner la connexion sans autre interaction ultérieure. Le récepteur doit déterminer, selon le numéro de séquence et la valeur de l'accusé de réception, s'il doit prendre en compte cette demande ou l'ignorer. En aucun cas la réception d'un segment RST n'entraîne une réponse du type RST.
RTP
Real Time Protocol: un protocole de communication inter-processus pour la transmission de données à contraintes temporelles fortes.
SEG.ACK
Accusé de réception du segment.
SEG.LEN
Longueur du segment.
SEG.PRC
Valeur de priorité du segment.
SEG.SEQ
Séquence du segment.
SEG.UP
Pointeur de données urgentes du segment.
SEG.WND
Fenêtre dans le segment.
Segment
Une unité logique de base, un segment TCP est l'unité de transmission entre deux agents TCP.
Séquence d'émission
Prochain numéro de séquence émis par l'émetteur. Il est initialisé par une fonction génératrice renvoyant un numéro de séquence initial (ISN) et est incrémenté pour chaque octet ou bit de contrôle (certains seulement) émis.
Séquence gauche
Le prochain numéro de séquence à être acquitté par le TCP récepteur (ou le numéro d'acquittement courant le plus bas) parfois référencé comme le bord gauche de la fenêtre de transmission.
SND.NXT
Séquence à l'émission.
SND.UNA
Numéro de séquence du premier octet non acquitté.
SND.UP
Pointeur de données urgentes à l'émission.
SND.WL1
Numéro de séquence du dernier segment ayant servi à remettre à jour l'information de fenêtre.
SND.WL2
Numéro d'acquittement du dernier segment ayant servi à remettre à jour l'information de fenêtre.
SND.WND
Fenêtre d'émission.
Socket
Une adresse réseau constituée par la concaténation d'une adresse Internet avec un numéro de port TCP.
SYN
Un bit de contrôle consommant un numéro de séquence, utilisé pendant la phase d'initialisation de la connexion pour indiquer à quel numéro de séquence la transmission de données débute.
TCB
Transmission Control Block. La structure de données enregistrant les paramètres d'une connexion.
TCB.PRC
Le niveau de priorité d'une connexion.
TCP
Transmission Control Protocol: Un protocole de communication inter-processus fiabilisé dans un environnement multiréseaux.
TOS
Type Of Service. Un champ IP indiquant le type de service du fragment IP.
URG
Un bit de contrôle ne consommant pas d'espace séquence, utilisé pour indiquer que des données urgentes sont transportées par le segment. L'application réceptrice doit en être informée, basculer en mode "d'urgence", et y rester tant que le numéro de séquence des données reste inférieur à la valeur du pointeur de données urgentes.
| Bibliographie |
|
[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974. [2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. [3] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols", Computer Networks,
Vol. 2, No. 6, pp. 454-473, December 1978. [4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences Institute, September 1981. |
