Note du Traducteur :

Le texte suivant est la traduction intégrale de la spécification TCP, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni
omissions. Ce document a valeur de "standard".

Concernant les droits de traduction de ce texte : Toute reproduction de cette traduction est autorisée à titre personnel ou éducatif. Par contre, étant
donné la quantité de travail que cette mise en œuvre représente, le traducteur se réserve le droit d'autoriser une reproduction partielle ou totale de cette
traduction dans tout ouvrage à caractère commercial. 

PREFACE

Ce document décrit le protocole DoD Standard Transmission Control Protocol (TCP). Neuf versions précédentes de la spécification ARPA TCP ont été éditées.
Ce texte s'appuie très fortement sur ces précédentes version. Ce texte réunit les contributions de nombreux rédacteurs et de développeurs. Cette édition clarifie
plusieurs détails et supprime le principe d'ajustement de taille de tampon, il décrit de nouveau le principe de courrier et l'entrée de pile.

Jon Postel
Editor

RFC: 793
Remplace: RFC 761
IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5 

1. INTRODUCTION

Ce document décrit les fonctions exécutées par TCP, les programmes qui les implémentent, et les interfaces entre ce dernier et les applications sensées utiliser ce service.

1.1. Motivation

Au fur et à mesure que les réseaux de communication informatiques à caractère stratégiques ou tactiques sont déployés, il devient essentiel de trouver un moyen d'interconnexion de ces réseaux, et des standards de transmission de données permettant de supporter une vaste gamme d'applications. Anticipant le besoin de tels standards, le député et sous-secrétaire d'état à la recherche de la Défense Américaine a officialisé le protocole décrit ici en tant que base pour la standardisation des processus d'intercommunication de données du Département de la Défense Américaine (DoD).

TCP est un protocole sécurisé orienté connexion conçu pour s'implanter dans un ensemble de protocoles multicouches, supportant le fonctionnement de réseaux hétérogènes. TCP fournit un moyen d'établir une communication fiable entre deux tâches exécutées sur deux ordinateurs autonomes raccordés à un réseau de données. Le protocole TCP s'affranchit le plus possible de la fiabilité intrinsèques des couches inférieures de communication sur lesquelles il s'appuie. TCP suppose donc uniquement que les couches de communication qui lui sont inférieures lui procurent un service de transmission de paquet simple, dont la qualité n'est pas garantie. En principe, TCP doit pouvoir supporter la transmission de données sur une large gamme d'implémentations de réseaux, depuis les liaisons filaires câblées, jusqu'aux réseaux commutés, ou asynchrones.

TCP s'intègre dans une architecture multicouche des protocoles, juste au-dessus du protocole Internet IP. Ce dernier permet à TCP l'envoi et la réception de segments de longueur variable, encapsulés dans un paquet Internet appelé aussi "datagramme". Le datagramme Internet dispose des mécanismes permettant l'adressage d'un service TCP source et un destinataire, quelles que soient leur position dans le réseau. Le protocole IP s'occupe aussi de la fragmentation et du réassemblage des paquets TCP lors de la traversée de réseaux de plus faibles caractéristiques. Le protocole IP transporte aussi les informations de priorité, compartimentation et classification en termes de sécurité relatives aux segments TCP. Ces informations se retrouvent alors transmises de bout en bout de la communication.

De grandes parties de ce document sont écrites dans un contexte où les implémentations TCP sont concomitantes à d'autres protocoles de haut niveau dans la même machine. Certains systèmes informatiques seront raccordés au réseau via un frontal qui accueillera les fonctions TCP et IP, ainsi que les protocoles réseau de bas niveau. La spécification TCP décrit une interface à destination des applications de niveau supérieur, y compris dans le cas d'une architecture avec un frontal, pour autant que les protocoles "poste vers frontal" soient implémentés.

1.2. Portée

1.3. A propos de ce document

1.4. Interfaces

L'interface avec les applicatifs consiste en un ensemble de commandes comme le ferait une application à un système d'exploitation pour la manipulation de fichiers. Par exemple, on trouvera des commandes pour établir et rompre une communication, pour envoyer ou recevoir des données sur une connexion ouverte. Il est aussi prévu que TCP puisse communiquer avec les applications sur un mode asynchrone. Bien qu'une grande liberté soit laissé aux développeurs pour la constructions d'interfaces TCP pour un environnement donné, des fonctionnalités minimales sont requises pour reconnaître la validité TCP de l'implémentation.

L'interface entre TCP et les protocoles de couche base restent largement non spécifiés excepté le fait qu'il doit y exister un mécanisme de transfert asynchrone de données. En général, c'est le protocole inférieur qui est sensé fournir la définition de cette interface. TCP assume un fonctionnement avec un large ensemble de protocoles réseau. Dans ce document, nous nous limiterons au fonctionnement avec IP.

1.5. Fonctionnement

• Transfert de données de base
• Correction d'erreur
• Contrôle de flux
• Multiplexage
• Gestion de connexions
• Priorité et Sécurité

Transfert de données de base:

TCP est capable de transférer un flux continu de données entre deux ordinateurs, en découpant ce flux en paquets ou datagrammes. En général, TCP décide de lui-même là où le flux de données doit être coupé.

Parfois les utilisateurs ont besoin de savoir que toutes les données soumises à TCP ont bien été émises. La fonction "push" a été prévue a cet effet. Pour s'assurer de la transmission complète de données jusqu'à un point spécifié, l'utilisateur activera la fonction "push" de TCP. Cette fonction oblige TCP à transmettre rapidement les données situées avant le point spécifié vers le destinataire. Il n'est nul besoin de fournir un marqueur spécifique pour ce point, dans la mesure ou le destinataire accepte ces données comme un transmission normale.

Contrôle d'erreur:

TCP doit considérer et traiter les cas de données perdues, erronées, dupliquées, ou arrivées dans le désordre à l'autre bout de la liaison Internet. Ceci est réalisé par l'insertion d'un numéro de séquence, et par l'obligation d'émission d'un "accusé de réception" (ACK) par le TCP destinataire. Si l'accusé de réception n'est pas reçu au bout d'un temps prédéfini, le paquet sera réémis. Côté récepteur, les numéros de séquence sont utilisés pour reconstituer dans le bon ordre le flux original, et éliminer les paquets dupliqués. L'élimination des erreurs physiques de transmission se fait par encodage d'un Checksum à l'émission, recalcul de ce Checksum par le destinataire, et élimination des paquets pour les quels les deux valeurs ne correspondent pas.

Tant que TCP fonctionne correctement, et que le réseau Internet n'est pas saturé, aucune faute de transmission ne devrait transparaître dans la communication. TCP est donc sensé récupérer les erreurs de la transmission Internet.

Contrôle de flux:

TCP fournit un moyen au destinataire pour contrôler le débit de données envoyé par l'émetteur. Ceci est obtenu en retournant une information de "fenêtre" avec chaque accusé de réception indiquant la capacité de réception instantanée en termes de numéros de séquence. Ce paramètre noté "window" indique le nombre d'octets que l'émetteur peut envoyer avant une autorisation d'émettre ultérieure.

Multiplexage:

Pour permettre à plusieurs tâches d'une même machine de communiquer simultanément via TCP, le protocole définit un ensemble d'adresses et de ports pour la machine. Un "socket" est défini par l'association des adresses Internet source, destinataire, ainsi que les deux adresses de port à chaque bout. Une connexion nécessite la mise en place de deux sockets. Une socket peut être utilisée par plusieurs connexions distinctes.

L'affectation des ports aux processus est établi par chaque ordinateur. Cependant, il semble judicieux de réserver certains numéros de ports pour des services caractérisés et souvent utilisés. Ces services standard pourront alors être atteints via ces ports "réservés". L'affectation, l'utilisation et l'apprentissage des ports associés à d'autres services moins courants ou propriétaires nécessitera l'utilisation de mécanismes plus dynamiques.

Connexions:

Les mécanismes de fiabilisation et de contrôle de flux décrits ci-dessus imposent à TCP l'initialisation et la maintenance de certaines informations pour chaque communication. La combinaison de ces informations, dont les sockets, les fenêtres, et les numéros de séquence formeront ce que nous appelons une connexion. Chaque connexion est identifiée de manière unique par sa paire de sockets, définissant chacun des deux sens de la communication.

Lorsque deux processus désirent communiquer, leur TCP respectifs doivent tout d'abord négocier et établir une connexion (initialiser ces informations d'état de part et d'autre). Lorsque la communication s'achève, elle sera fermée, en libérant ses ressources à d'autres usages.

Dans la mesure où l'on considère que les ordinateurs, ainsi que le réseau Internet n'est pas d'une fiabilité absolue, on utilise une méthode d'initialisation par négociation bilatérale basée sur une horloge pour les numéros de séquence.

Priorité et Sécurité:

Les exploitants de TCP peuvent indiquer le degré de sécurité et la priorité de la communication établie. TCP permet cependant de ne pas traiter ce besoin.

2. PHILOSOPHIE

2.1. Eléments constitutifs du réseau

Le terme paquet, générique, désigne les données d'une transaction unitaire entre un processus et le réseau. Le format physique des données à l'intérieur du réseau est en dehors du champ d'application de ce document.

Les "hosts" sont des ordinateurs raccordés au réseau, et, du point de vue de ce dernier, sont les sources et destinations des paquets. Les processus sont identifiés comme les éléments actifs dans ces machines (conformément à la définition courante de "programme en cours d'exécution"). Les terminaux, fichiers, et autres périphériques d'entrée/sortie peuvent être identifiés comme "éléments communicants" par l'intermédiaire d'un processus. De ce fait, toute communication reste identifiée comme un échange inter-processus.

Comme un processus particulier doit pouvoir discerner des communications distinctes avec d'autres processus, nous avons imaginé que chaque processus puisse disposer d'un certain nombre de "ports" d'entrée sortie, chacun attribué à une communication unique avec un autre processus.

2.2. Modèle de fonctionnement

Le modèle d'une communication Internet fait qu'il existe pour chaque TCP actif un module de protocole Internet chargé de l'acheminement de données. Ce module Internet "encapsule" à son tour les paquets TCP sous la forme de paquets Internet, transmis à un module Internet distant via des "routeurs". Pour transmettre le paquet ainsi constitué à travers un réseau local, une troisième couche de protocole, spécifique au réseau, est ajoutée.

Les paquets peuvent alors subir un grand nombre de transformations, fragmentations, ou autres opérations pendant leur acheminement au module Internet distant.

A l'arrivée dans un routeur, le paquet Internet est "désossé", puis ses informations sont examinées pour savoir vers quel réseau le paquet doit être acheminé. Un nouveau paquet Internet est constitué, selon les spécifications du segment de réseau désigné, puis transmis sur ce réseau.

Un routeur peut procéder à une segmentation plus fine des paquets, si le réseau en sortie n'a pas les performances suffisantes pour véhiculer le paquet d'origine. Pour réaliser ceci, le routeur exécute une nouvelle segmentation en "fragments". Ces mêmes fragments peuvent à leur tour être redécoupés en chemin par un autre routeur. Le format de paquets fragmentés est standardisé de sorte que le réassemblage soit toujours possible, étape par étape, jusqu'à restitution des données originales.

Le module Internet d'arrivée extrait le datagramme de niveau supérieur, pour nous, TCP (après défragmentation du paquet si nécessaire) et le passe à la couche TCP.

Cette description rapide du protocole ignore certains détails. Le type de service en est un d'importance. Celui-ci indique au routeur (ou au module Internet) quels paramètres de service doivent être utilisés pour traverser la section suivante. L'un de ces paramètres est la priorité du paquet. Un autre est le codage de sécurité du paquet, permettant aux réseaux traitant des aspects de sécurité de discriminer les paquets conformément aux exigences établies.

2.3. Les Hosts

Les mécanismes TCP n'interdisent pas l'implémentation de TCP dans un frontal. Cependant le frontal devra disposer d'un protocole vis à vis du central permettant la prise en compte de l'interface application vers TCP, telle que définie dans ce document.

2.4. Interfaces

L'interface TCP/Internet dispose de commandes pour recevoir et émettre des paquets vers des modules TCP où qu'ils soient sur le réseau. Ces appels ont des paramètres tels qu'adresses, type de service, priorité, sécurité, et autres informations de contrôle.

2.5. Relations avec d'autres protocoles

       +------+ +-----+ +-----+       +-----+                            |Telnet| | FTP | |Voice|  ...  |     |  Couche applicative         +------+ +-----+ +-----+       +-----+                                  |   |         |             |                                    +-----+     +-----+       +-----+                                 | TCP |     | RTP |  ...  |     |  Couche machine                     +-----+     +-----+       +-----+                                    |           |             |                                    +-------------------------------+                                 |    Internet Protocol & ICMP   |  Couche routage                  +-------------------------------+                                                |                                                    +---------------------------+                                     |   Local Network Protocol  |    Couche réseau                    +---------------------------+                          Relations interprotocoles - Figure 2.

TCP doit nécessairement supporter les niveaux de couches supérieures avec toute l'efficacité requise. L'interfaçage de protocoles tels que Telnet ARPAnet ou THP AUTODIN II doit demeurer aisée.

2.6. Fiabilité de communication

La fiabilité de cette transmission s'appuie sur l'utilisation de numéros de séquence et sur un mécanisme d'accusés de réception. Dans le concept, à chaque octet de données est attribué un numéro de séquence. Le numéro de séquence du premier octet transmis dans un segment est appelé le numéro de séquence du segment. Celui-ci est explicitement transmis avec le segment. En retour, l'accusé de réception est constitué du numéro de séquence du prochain octet à transmettre. Lorsque TCP transmet un segment contenant des données, celui-ci est copié dans une pile de réémission et une temporisation est lancée; lorsque l'accusé de réception est reçu, la copie dans la pile de retransmission est supprimée. Dans le cas contraire, le paquet est réémis une nouvelle fois.

L'accusé de réception ne garantit pas que les données sont effectivement arrivées à l'utilisateur final. Il indique simplement que le FTP destinataire à bien pris en charge ces données, en vue de les transmettre à cet utilisateur.

Pour contrôler le débit de données entre les deux TCP, un mécanisme dit de "contrôle de flux" est employé. Le TCP récepteur aménage une "fenêtre de réception" pour le TCP émetteur. Cette "fenêtre" indique le nombre d'octets, à partir du numéro de séquence inscrit dans l'accusé de réception, que le TCP distant est capable de recevoir.

2.7. Etablissement et rupture des connexions

Une connexion de base est définie par un couple de sockets, l'un définissant l'émetteur, l'autre le récepteur. Un socket peut devenir le destinataire ou la source pour plusieurs sockets distinctes. La connexion est résolument bidirectionnelle, et prend la dénomination de "full-duplex".

TCP est libre d'associer ses ports avec les processus exécutés sur sa machine. Cependant, quelques règles ont été établies pour l'implémentation. Ont été définis un certain nombre de sockets "réservés" que TCP ne doit associer qu'avec certains processus bien identifiés. Ceci revient à dire que certains processus peuvent s'attribuer la propriété de certains ports, et ne pourront initier de communication que sur ceux-ci. (Actuellement, cette "propriété" est issue d'une implémentation locale, mais nous envisageons une commande utilisateur Request Port, ou une autre méthode pour assigner automatiquement un ensemble de ports à une application, par exemple en utilisant quelques bits de poids fort du numéro de port pour coder l'application).

Une connexion est demandée par activation de la commande OPEN indiquant le port local et les paramètres du socket distant. En retour, TCP répond par un nom local (court) symbolique que l'application utilisera dans ses prochains appels. Plusieurs choses doivent être retenues à propos des connexions. Pour garder la trace de cette connexion, nous supposons l'existence d'une structure de données appelée Transmission Control Block (TCB). Une des stratégies d'implémentation est de dire que le nom local donné est un pointeur vers le TCB associé à cette connexion. La commande OPEN spécifie en outre si le processus de connexion doit être effectué jusqu'à son terme, ou s'il s'agit d'une ouverture en mode passif.

Une ouverture passive signifie que le processus de connexion se met en attente d'une demande de connexion plutôt que de l'initier lui-même. Dans la plupart des cas, ce mode est utilisé lorsque l'application est prête à répondre à tout appel. Dans ce cas, le socket distant spécifié n'est composé que de zéros (socket indéfini). Le socket indéfini ne peut être passé à TCP que dans le cas d'une connexion passive.

Un utilitaire désireux de fournir un service à un processus non identifié pourra initier une connexion passive. Tout appelant effectuant une requête de connexion sur le socket local sera reconnu. Il sera bon de garder en mémoire que ce socket est associé à ce service.

Les sockets "réservés" sont un bon moyen d'associer à priori des ports à des applications standard. Par exemple, le serveur "Telnet" est en permanence associé à un socket particulier, d'autres étant réservés pour les transferts de fichiers, sessions de terminal distant, générateur de texte, écho (ces deux pour des besoins de test), etc. Un socket peut être réservé à la fonction de serveur de domaines, transcodant les "noms explicites" de services en sockets Internet. Si le concept même de l'assignation à priori de sockets fait partie de TCP, l'assignation concrète des sockets "réservés" est définie dans un autre document.

Les processus peuvent ouvrir une connexion passive et attendre qu'une connexion active les impliquant provienne d'une autre machine. TCP aura la charge d'avertir l'application qu'une communication est établie. Deux processus émettant au même moment une requête de connexion l'un vers l'autre se retrouveront normalement connectés. Cette souplesse est indispensable pour assurer un bon fonctionnement du réseau composé d'éléments totalement asynchrones.

Les deux cas de conclusion d'une communication impliquant une connexion passive et une active sont les suivants. Soit le socket distant a été précisé lors de la requête de connexion passive, auquel cas seule une requête de connexion du distant attendu vers le local peut aboutir à l'établissement d'une communication. Soit le socket distant a été laissé indéfini, et toute requête de connexion sur le socket local, d'où qu'elle vienne aboutit à une communication valide. D'autres fonctionnalités permettront une acceptation sur correspondance partielle entre sockets.

Si plusieurs requêtes de connexion passive sont en attente (enregistrées dans la table de TCBs) pour le même socket local, et qu'une demande de connexion active provient de l'extérieur, le protocole prévoit de d'abord chercher s'il l'une des requêtes dont le socket distant a été clairement exprimé correspond à celui de la demande. Si tel est le cas, ce socket sera activé. Sinon, c'est une requête "indéfinie" qui sera activée.

La procédure de connexion utilise le bit de contrôle de synchronisation (SYN) et suppose la transmission de trois messages. Cet échange est appelé "négociation ternaire".

La connexion suppose le rendez-vous d'un segment marqué du bit SYN et d'une requête locale (TCB), chacun des deux étant créé par l'exécution d'une commande de connexion. La correspondance entre le socket arrivé et le socket attendu détermine l'opportunité de la connexion. Celle-ci ne devient réellement établie que lorsque les deux numéros de séquence ont été synchronisés dans les deux directions.

La rupture d'une connexion suppose l'émission de segments, marqués du bit FIN.

2.8. Communication de données

Par défaut, TCP reste libre de stocker les données soumises par l'application pour les émettre à sa convenance, jusqu'à ce que le signal PUSH soit activé. Dans ce dernier cas, toutes les données non émises doivent être envoyées. Symétriquement, lorsque le TCP récepteur voit le flag PUSH marqué, il devra passer immédiatement toutes les données collectées à l'application destinataire.

Il n'y a à priori aucune corrélation entre la fonction PUSH et les limites des segments. Les données d'un segment peuvent être le résultat d'une seule commande SEND, en tout ou partie, ou celui de plusieurs appels SEND.

La fonction de la fonction push et du flag PUSH est de forcer la transmission immédiate de toutes les données latentes entre les deux TCP. Il ne s'agit aucunement d'une fonction d'enregistrement (Cf. langage Perl).

Il y a par contre une relation entre la fonction push et l'usage des tampons dans l'interface TCP/application. Chaque fois qu'un flag PUSH est associé à des données stockées dans le tampon de réception, celui-ci est intégralement transmis à l'application même s'il n'est pas plein. Si le tampon est rempli avant qu'un flag PUSH soit vu, les données sont transmises à l'application par éléments de la taille du tampon.

TCP dispose d'un moyen d'avertir l'application que, dans le flux de données qu'il est en train de lire, au delà de la position de lecture courante, des données de caractère urgent sont apparues. TCP ne définit pas ce que l'application est sensée faire lorsqu'elle est avisée de la présence de ces données. En général, c'est l'implémentation de l'application qui traitera ces données urgentes selon ses besoins propres.

2.9. Priorité et Sécurité

Les modules TCP opérant dans un environnement sécurisé à plusieurs niveaux devront correctement renseigner les segments sortants en termes de sécurité, niveau de sécurité, et priorité. De tels modules TCP doivent fournir aux applications supérieures telles que Telnet ou THP une interface leur permettant de spécifier ces paramètres.

2.10. Principe de robustesse

3. SPECIFICATION FONCTIONNELLE

3.1. Format de l'en-tête

Port source: 16 bits 1000

Le numéro de port de la source.

Port Destinataire: 16 bits

Le numéro de port du destinataire.

Numéro de séquence: 32 bits

Le numéro du premier octet de données par rapport au début de la transmission (sauf si SYN est marqué). Si SYN est marqué, le numéro de séquence est le numéro de séquence initial (ISN) et le premier octet à pour numéro ISN+1.

Accusé de réception: 32 bits

Si ACK est marqué ce champ contient le numéro de séquence du prochain octet que le récepteur s'attend à recevoir. Une fois la connexion établie, ce champ est toujours renseigné.

Data Offset: 4 bits

La taille de l'en-tête TCP en nombre de mots de 32 bits. Il indique là ou commence les données. L'en-tête TCP, dans tous les cas à une taille correspondant à un nombre entier de mots de 32 bits.

Réservé: 6 bits

Réservés pour usage futur. Doivent nécessairement être à 0.

Bits de contrôle: 6 bits (de gauche à droite):

• URG: Pointeur de données urgentes significatif
• ACK: Accusé de réception significatif
• PSH: Fonction Push
• RST: Réinitialisation de la connexion
• SYN: Synchronisation des numéros de séquence
• FIN: Fin de transmission

Le nombre d'octets à partir de la position marquée dans l'accusé de réception que le récepteur est capable de recevoir.

Checksum: 16 bits

Le Checksum est constitué en calculant le complément à 1 sur 16 bits de la somme des compléments à 1 des octets de l'en-tête et des données pris deux par deux (mots de 16 bits). Si le message entier contient un nombre impair d'octets, un 0 est ajouté à la fin du message pour terminer le calcul du Checksum. Cet octet supplémentaire n'est pas transmis. Lors du calcul du Checksum, les positions des bits attribués à celui-ci sont marqués à 0.

Le Checksum couvre de plus une pseudo en-tête de 96 bits préfixée à l'en-tête TCP. Cette pseudo en-tête comporte les adresses Internet source et destinataires, le type de protocole et la longueur du message TCP. Ceci protège TCP contre les erreurs de routage. Cette information sera véhiculée par IP, et est donnée comme argument par l'interface TCP/Réseau lors des appels d'IP par TCP.

Pointeur de données urgentes: 16 bits

Communique la position d'une donnée urgente en donnant son décalage par rapport au numéro de séquence. Le pointeur doit pointer sur l'octet suivant la donnée urgente. Ce champs n'est interprété que lorsque URG est marqué.

Options: variable

Les champs d'option peuvent occuper un espace de taille variable à la fin de l'en-tête TCP. Ils formeront toujours un multiple de 8 bits. Toutes les options sont prises en compte par le Checksum. Un paramètre d'option commence toujours sur un nouvel octet. Il est défini deux formats types pour les options:

Cas 1: Option mono-octet.

Cas 2: Octet de type d'option, octet de longueur d'option, octets de valeurs d'option.

La longueur d'option prend en compte l'octet de type, l'octet de longueur lui-même et tous les octets de valeur et est exprimée en octets.

Notez que la liste d'option peut être plus courte que ce que l'offset de données pourrait le faire supposer. Un octet de remplissage (padding) devra être dans ce cas rajouté après le code de fin d'options. Ce octet est nécessairement à 0.

TCP doit implémenter toutes les options.

Actuellement, les options définies sont (type indiqué en octal):

      Type     Longueur  Description       ----     ------    -------        0         -       Fin de liste d'option        1         -       Nop        2         4       Taille de segment maximalDéfinition des options spécifiques

Fin de liste d'options

Ce code indique la fin du champ d'options. Sa position peut ne pas coïncider avec l'indication du début du champ de données marqué dans l'Offset de données. Il doit être placé après toutes les options, et non après chaque option. Il ne doit être utilisé que dans le cas ou la fin des options ne coïncide pas avec le début du champ de données.

No-Operation

Cette option peut être utilisée entre deux options, par exemple pour aligner le début d'une option sur un début de mot de 16 bits. L'utilisation de ce séparateur n'est pas une obligation. L'implémentation doit donc prévoir de pouvoir prendre en compte un option même au milieu d'un mot.

Taille maximale de segment

Donnée d'option : Taille maximale de segment: 16 bits

Si cette option est présente, elle communique à l'émetteur la taille maximale des segments qu'il pourra envoyer. Ce champ doit être envoyé dans la requête de connexion initiale (avec SYN marqué). Si cette option est absente, le segment pourra être pris de n'importe quelle taille.

Bourrage (padding): variable

Les octets de bourrage terminent l'en-tête TCP:

• de sorte que le nombre d'octet de celle-ci soit toujours multiple de 4 (32 bits)
• de sorte que l'offset de données marqué dans l'en-tête corresponde bien au début des données applicatives.

3.2. Terminologie

Variables de séquence d'émission

• SND.UNA - "unacknowledge" - envoi sans accusé de réception
• SND.NXT - "next" - envoi du suivant
• SND.WND - "window" - envoi de la fenêtre
• SND.UP - "urgent pointer" - pointeur de données urgentes
• SND.WL1 - "window last 1" - dernier numéro de séquence de segment envoyé
• SND.WL2 - "window last 2" - dernier accusé de réception
• ISS - "initial send sequence" - premier numéro de séquence du message

• RCV.NXT - "next" - réception du suivant
• RCV.WND - "window" - réception de fenêtre
• RCV.UP - "urgent pointer" - pointeur de données urgentes
• IRS - "initial receive sequence" - premier numéro de séquence en réception

Visualisation de la séquence d'émission (vue à plat du tampon d'émission)

                   1         2          3          4                     ----------|----------|----------|----------                      SND.UNA    SND.NXT    SND.UNA                                                   +SND.WND

1. - anciens numéros de séquence ayant été acquittés
2. - numéros de séquences non acquittés
3. - numéros de séquence autorisés pour une nouvelle émission
4. - futurs numéros de séquence non encore autorisés

Visualisation de la séquence de réception (vue à plat du tampon de réception)

                       1          2          3                          ----------|----------|----------                            RCV.NXT    RCV.NXT                                             +RCV.WND

1. - numéros de séquence reçus et acquittés
2. - numéros de séquence autorisés en réception (fenêtre)
3. - numéros de séquences futurs non encore autorisés en réception

On trouvera enfin des variables dont les valeurs sont déduites des données inscrites dans le segment courant.

Variables du segment courant

• SEG.SEQ - "sequence" - numéro de séquence du segment courant
• SEG.ACK - "acknowledge" - numéro de séquence inscrit dans l'accusé de réception
• SEG.LEN - "length" - longueur du segment courant
• SEG.WND - "window" - fenêtre inscrite dans le segment courant
• SEG.UP - "urgent pointer" - pointeur de données urgentes du segment courant
• SEG.PRC - "precedence" - valeur de priorité courante

LISTEN - La connexion reste en attente d'une requête de connexion externe par un TCP distant. Cet état est atteint après une demande de connexion passive.

SYN-SENT - La connexion se met en attente d'une requête de connexion, après avoir envoyé elle-même une requête à un destinataire.

SYN-RECEIVED - Les deux requêtes de connexion se sont croisées. La connexion attend confirmation de son établissement.

ESTABLISHED - La connexion a été confirmé de part et d'autre et les données peuvent transiter sur la voie de communication. C'est l'état stable actif de la connexion.

FIN-WAIT-1 - Sur requête de déconnexion émise par l'application, la connexion demande la confirmation d'une requête de déconnexion qu'elle a elle-même émise vers le distant.

FIN-WAIT-2 - La connexion se met en attente d'une requête de déconnexion par le distant, une fois reçue la confirmation de sa propre requête.

CLOSE-WAIT - La connexion se met en attente d'une requête de déconnexion émise par l'application.

CLOSING - La connexion attend la confirmation de sa requête de déconnexion par le TCP distant, lequel avait auparavant émis sa propre requête de déconnexion.

LAST-ACK - La connexion attend la confirmation de sa requête de déconnexion, émise suite à une requête similaire à l'initiative du distant.

TIME-WAIT - Un temps de latence avant fermeture complète du canal, pour s'assurer que toutes les confirmations ont bien été reçues.

CLOSED - La connexion n'existe plus. C'est un pseudo-état.

Le changement d'état d'une connexion TCP intervient sur réception d'un certain nombre de signaux, appelée "événement". Les événements peuvent être des commandes émises par l'application, OPEN, SEND, RECEIVE, CLOSE, ABORT, et STATUS; la réception d'un flag dans un segment en provenance du distant SYN, ACK, RST et FIN; la fin d'une temporisation.

Le diagramme suivant montre l'enchaînement des états, en fonction des événements reçus, ainsi que les événements produits. Il occulte par contre le traitement des fautes, ainsi que tous les autres événements qui ne sont pas en relation avec les changements d'état. Un descriptif plus détaillé des événements et de leur fonctionnement sera exposé plus avant.

NOTA BENE: ce diagramme est un résumé et ne doit pas être compris comme une spécification complète.

3.3. Numéros de séquence

Un des points essentiels à se souvenir est que l'espace de numérotation de séquence est fini, bien que très grand. Cet espace, codé sur 32 bits permet le comptage de 0 à 2**32 - 1 octets. Comme ce champ est de taille finie, toute opération arithmétique sur les numéros de séquence doit se faire modulo 2**32. Cette arithmétique non signée permet de préserver la continuité de numérotation, celle-ci repartant à 0 après la valeur 2**32 - 1. Toute opération arithmétique opérée sur les numéros de séquence devra être programmée avec beaucoup de précautions du fait de l'aspect cyclique de la numérotation, en particulier les comparaisons de numéros de séquence aux alentours de la limite supérieure.

Les principales comparaisons de numéro de séquence par TCP ont pour fonction:

(a) de déterminer qu'un accusé de réception reçu concerne bien des données émises et non encore confirmées.

(b) de déterminer que tous les numéros de séquence (donc, toutes les données) d'un segment ont bien été reçues (par exemple, pour purger la pile de retransmission).

(c) de déterminer qu'un segment reçu contient bien des numéros de séquence (et donc des données) attendues (c'est à dire que le principe de fenêtre de réception a bien été respecté par l'émetteur).

En réponse à l'émission de données, TCP reçoit des "accusés de réception". La confirmation de transmission doit s'appuyer sur les comparaisons suivantes:

SND.UNA = dernier numéro de séquence non acquitté
SND.NXT = prochain numéro de séquence à émettre
SEG.ACK = valeur d'accusé de réception (prochain numéro de séquence attendu par le distant)
SEG.SEQ = premier numéro de séquence du segment
SEG.LEN = la taille des données en octets dans le segment (y compris pour des segments SYN et FIN)
SEG.SEQ+SEG.LEN-1 = dernier numéro de séquence du segment

Un nouvel accusé de réception (appelé "ack acceptable"), est un accusé de réception pour lequel l'inégalité ci-dessous est vérifiée:

SND.UNA < SEG.ACK =< SND.NXT

Un segment ne peut être effacé de la pile de retransmission que si la somme de son numéro de séquence (premier octet de donnée) et sa longueur est inférieure au numéro de séquence du dernier accusé de réception reçu (ceci revient à dire en clair que l'acquittement doit pointer une donnée au delà de la fin du segment).

Lorsque des données sont reçues, les conditions ou affectations suivantes doivent être remplies:

RCV.NXT = numéro de séquence détecté sur le segment entrant. Doit être la limite gauche (ou inférieure) de la fenêtre de réception.
RCV.NXT+RCV.WND-1 = plus grand numéro de séquence admis sur le segment entrant. Est la limite droite (ou supérieure) de la fenêtre de réception.
SEG.SEQ = premier numéro de séquence du segment entrant
SEG.SEQ+SEG.LEN-1 = dernier numéro de séquence du segment entrant.

Un segment est considéré comme à l'intérieur de l'espace de réception si:

RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

et

RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Le premier test détermine si le premier octet des données du segment est dans la fenêtre. Le deuxième test vérifie que le dernier octet de données du segment reçu est aussi à l'intérieur de la fenêtre.

En pratique, cette vérification est un peu plus compliquée. Quatre cas d'acceptabilité sont discernable, à cause de la possibilité d'une largeur 0 pour la fenêtre et d'une longueur nulle de segment:

    Longueur      Fenêtre           Test     du segment    de 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                                      ou                                     RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WNDNotez que lorsque la largeur de fenêtre est nulle, aucun segment excepté un acquittement (sans données) ne peut être reçu. Il est donc possible à un TCP de maintenir une largeur de fenêtre à zéro, tout en transmettant des données et recevant des accusés de réception. Cependant, même lorsque la fenêtre à une largeur nulle, TCP doit examiner les champs RST et URG pour tous les segments entrants.

Le mécanisme de numérotation nous permet en outre de protéger quelques informations de contrôle. Ceci est réalisé en introduisant implicitement des flags de contrôle dans la séquence (ou plus explicitement, attribuer un numéro de séquence à un contrôle).Ces contrôles pourront alors être retransmis et acquittés sans confusion (ex., une instance unique du contrôle sera traitée). Mais les informations de contrôle ne sont pas physiquement transmises dans le champ de données, le seul à être numéroté. Il faudra donc mettre en place une technique pour assigner ce numéro de séquence au contrôle. Les bits SYN et FIN sont les seuls contrôles pouvant nécessiter cette protection. Ceux-ci ne sont émis que pendant une phase d'établissement ou de rupture d'une connexion. Pour des raisons de numérotation, SYN est toujours considéré arriver avant le premier octet de données du segment dans lequel il est marqué. A l'inverse FIN est toujours considéré arriver après le dernier octet du segment. La longueur du segment (SEG.LEN) prend en compte l'espace de données ainsi que celui des contrôle. Lorsque SYN est marqué SEG.SEQ est alors le numéro de séquence du associé au contrôle SYN.

Sélection du premier numéro de séquence

Le protocole n'impose pas de restrictions à l'établissement simultané de plusieurs connexions identiques. Un connexion est définie par une paire de sockets. De nouvelles instances d'une connexion peuvent être ouvertes. Le problème qui en découle est -- "comment TCP identifie les segments dupliqués lorsqu'ils arrivent d'instances différentes d'une connexion?" Ce problème devient apparent lorsqu'une connexion s'ouvre et se ferme à une cadence rapide, ou si une connexion se coupe par manque de mémoire et se rétablit par la suite.

Pour éviter toute confusion, il faut éviter que les numéros de séquence utilisés par une instance de connexion ne soient utilisés lorsque les mêmes numéros de séquence sont émis sur le réseau par une autre instance. Ceci doit être assuré y compris si TCP se bloque et perd toute connaissance des numéros de séquence qu'il utilisait. Lorsqu'une connexion est établie, un générateur de numéro de séquence initial (ISN) est utilisé, qui génère un nouvel ISN sur 32 bits. Ce générateur est basé sur une horloge (qui peut être virtuelle) 32 bit dont le bit de poids faible est incrémenté environ toutes les 4 microsecondes. De ce fait, le cycle des ISN dure environ 4,55 heures. Comme nous supposons qu'un segment ne peut être présent dans le réseau plus longtemps que sa durée de vie maximale (Maximum Segment Lifetime = MSL) et que MSL est inférieur à 4,55 heures, il est raisonnable de penser que l'ISN sera unique.

Pour chaque connexion, on met en place un numéro de séquence d'émission et un numéro de séquence de réception. Le numéro initial d'émission (ISS) est choisi par le TCP émetteur, le numéro de séquence initial de réception (IRS) est "appris" par le récepteur durant la phase d'établissement.

Pour qu'une connexion puisse être considérée comme établie, les deux TCPs doivent auparavant avoir pu synchroniser leurs numéros de séquence respectifs. Ceci est réalisé grâce à l'émission de segments particuliers de synchronisation avec le bit SYN marqué et les numéros de séquence initiaux. Par extension, les segments marqués du bit SYN seront nommés aussi SYN. La solution demande donc un mécanisme pour "prendre" un numéro de séquence initial, ainsi qu'un dialogue pour se communiquer les ISNs.

La solution consiste à faire envoyer par chaque extrémité son propre numéro de séquence initiale, à charge de l'autre bout d'acquitter cette information.

1) A --> B SYN "mon numéro de séquence est X"
2) A <-- B ACK "ton numéro de séquence est X"
3) A <-- B SYN "mon numéro de séquence est Y"
4) A --> B ACK "ton numéro de séquence est Y"

Comme les étapes 2 et 3 peuvent être rassemblées dans le même segment, ce dialogue s'appelle "ternaire".

Cet échange en trois étapes est nécessaire dans la mesure où le choix des numéros de séquence initiaux ne dépend pas d'une horloge commune à l'ensemble du réseau, et les diverses implémentations de TCP peuvent recourir à des méthodes diverses pour choisir un ISN. Le récepteur d'un premier segment SYN n'a aucun moyen de déterminer qu'il ne s'agit pas d'un ancien segment "perdu" sur le réseau, sauf s'il se "souvient" du dernier numéro de séquence utilisé par la dernière connexion (ce qui n'est pas toujours possible). Il doit donc demander à l'émetteur de vérifier ce segment SYN.

Savoir ne rien émettre

Pour être certain que TCP n'utilise pas un numéro de séquence déjà contenu dans un segment "perdu" en cours de transmission sur le réseau, TCP doit attendre au moins la durée d'un MSL (durée de vie maximale des segments) avant toute assignation d'un nouvel ISN pour une nouvelle connexion ou sur récupération d'une connexion dont l'historique de la numérotation de séquence a été perdue. Dans le cadre de cette spécification, MSL vaut 2 minutes. Cette valeur résulte de l'expérimentation, et est susceptible de changer si le besoin s'en fait sentir. Notez que si un TCP est réinitialisé en ayant pu conserver l'historique de séquence, alors cette attente ne sera pas nécessaire; il lui suffira de produire des numéros de séquence supérieurs aux dernier émis.

Le concept de "silence" TCP

Cette spécification prévoit que des ordinateurs en faute ayant perdu toute trace des numéros de séquence sur les connexions non fermées ne puisse émettre sur le réseau Internet des segments TCP pendant au minimum la durée MSL. Dan ce qui suit, une explication détaillée de cette spécification est fournie. Les développeurs implémentant TCP pourront toujours ne pas tenir compte de ce principe, mais au risque de voir des anciens segments acceptés comme nouveaux, ou des nouveaux rejetés car apparaissant comme des doubles d'anciens segments.

TCP consomme l'espace de numérotation des séquences chaque fois qu'un nouveau segment est constitué et placé dans la pile d'émission du pilote de réseau. La détection de doublons, et l'algorithme de séquence du protocole TCP s'appuie sur le champ de numérotation fini en supposant que la séquence est suffisamment longue pour que tous les segments, y compris toutes ses réémissions ou doublons aient été retirés du réseau avant que la séquence ne reboucle. Sans ce principe, deux segments TCP pourraient se voir attribuer des plages de séquence superposées, provoquant une extrême difficulté au récepteur pour savoir quelle donnée est ancienne et quelle donnée est récente. Souvenez vous ici que dans une transmission normale, les segments successifs d'une transmission utilisent des plages de séquence disjointes et contiguës.

En temps normal, TCP garde la trace du numéro de séquence à émettre, et du plus ancien acquittement attendu. Ceci lui permet de ne pas utiliser un numéro de séquence attribué à un segment en attente d'acquittement. Ceci ne garantit pas que d'anciens doublons de paquets aient été totalement retirés du réseau. Le champ de numérotation a donc été choisi très grand pour éviter qu'un paquet "fantôme" ne vienne perturber une réception. A 2 megabits/seconde, l'utilisation des 2**32 valeurs de l'espace de numérotation prend environ 4,5 heures. Comme la durée de vie d'un paquet dans le réseau ne peut excéder quelques dizaines de secondes, on considère que cette protection est largement suffisante même lorsque la vitesse de transmission atteint 10 megabits/seconde. A 100 megabits/seconde, le cycle dure 5,4 minutes, ce qui peut paraître assez court, mais laisse encore une marge raisonnable. L'algorithme de détection de doublons et de séquencement de TCP peut cependant être mis en défaut, dans le cas où TCP perd la mémoire du numéro de séquence qu'il utilisait pour les dernières transmissions. Un exemple de ceci serait un TCP initiant toutes ses connexion au numéro de séquence 0, puis sur faute et réinitialisation, rétablit une connexion (ex. en exécutant l'analyse d'une demi connexion restée ouverte) et émet des paquets avec des plages de séquences recoupant celles de paquets toujours en transit dans le réseau, et provenant de la connexion avant la rupture. Lorsque cette synchronisation de séquence est perdue, la spécification TCP recommande de respecter un délai de MSL secondes avant de réemettre des segments sur la connexion, afin de permettre à tous les anciens segments encore en transit d'être éliminés du réseau.

Même les ordinateurs avec horloge interne absolue, et utilisant cette horloge pour le choix d'un ISN ne sont pas immunisés contre ce problème.

Supposons, pat exemple, qu'une connexion soit ouverte, disons, en partant du numéro de séquence S. Supposons de plus que cette connexion est très peu chargée et qu'en plus, la fonction de génération des numéros de séquence initiaux (ISN(t)) prenne comme base la valeur du numéro de séquence, disons S1, du dernier segment émis par ce TCP sur une connexion particulière, qui se trouve être cette celle-ci. Supposons enfin que l'ordinateur redémarre et qu'une connexion soit restaurée. Le numéro de séquence initial repris sera S1 = ISN(t) -- le même numéro que celui du dernier paquet envoyé par l'instance précédente de la connexion ! Pour peu que la récupération soit suffisamment rapide, tous les paquets sur le réseau portant un numéro de séquence proche de S1 risquent d'être compris comme des nouveau paquets, même s'ils proviennent de l'ancienne instance de la connexion.

Le problème est que l'ordinateur ayant eu la défaillance ne sait absolument pas combine de temps celle-ci a duré, et par conséquent si des paquets de l'ancienne connexion ne se trouvent pas encore en transit dans le réseau.

L'une des façons de se sortir de ce problème est d'imposer un silence d'au moins un MSL après récupération sur faute - C'est la spécification dite de "silence TCP". Les implémentation qui ne tiennent pas compte de ce temps de silence et l'ignorent risquent de provoquer des confusions entre nouveaux et anciens segments dans les TCP récepteurs. Au minimum, il est conseillé que les développeurs prévoient de laisser à l'utilisateur la possibilité d'ignorer le temps de silence connexion par connexion, ou, encore mieux, de systématiser de manière informelle ce fonctionnement. Bien évidemment, même lorsque l'attente TCP est implémentée, elle n'est pas indispensable lorsque la défaillance intervient quelques MSL après que la connexion ait cessé d'émettre.

Pour résumer: chaque segment occupe une plage de séquence à l'intérieur de l'espace de numérotation, tous les numéros à l'intérieur de ces plages sont "occupés" pendant MSL secondes. Après une défaillance, un bloc temporel est pris par la plage de séquence du dernier segment émis. Si une connexion reprend trop tôt, réémettant un segment utilisant un numéro de séquence compris dans la plage de séquence précédente, il y aura risque pour le récepteur de mal interpréter la séquence de segments et produire une erreur de réassemblage de données.

3.4. Etablissement d'une connexion

Plusieurs exemples d'initialisation d'une connexion suivent. Aucun de ces exemples ne montrent des segments d'initialisation transportant des données, ce qui est parfaitement légitime, dans la mesure où TCP n'envoie pas de donnée tant qu'il n'est pas sûr de la stabilité du canal (c'est-à-dire que TCP est sensé tamponner les données qui lui sont transmises par l'application tant que l'état ESTABLISHED n'a pas été atteint). La négociation "ternaire" réduit le risque de fausses connexions. L'implémentation des échanges entre la mémoire et les messages apportera les informations nécessaires à cette vérification.

La transaction ternaire la plus simple est décrite en figure 7. Ces figures doivent être interprétées de la façon suivante. Chaque ligne est numérotée pour référence. La flèche vers la droite (-->) indique le départ d'un paquet TCP du TCP A vers le TCP B, ou l'arrivée en B d'un segment issu de A. La flèche inverse (<--), la transmission dans le sens opposé. L'ellipse (...) indique un segment toujours sur le réseau (retardé). Un "XXX" indique un segment perdu, ou rejeté. Les commentaires apparaissent entre parenthèse. L'état TCP représente l'état obtenu APRES le départ ou l'arrivée du segment (dont le contenu est mentionné au centre de la ligne). Le contenu des segments est montré sous forme abrégée, avec son numéro de séquence, les flags marqués, et le champ ACK. Les autres champs tels qu'adresses, fenêtres, offset, etc. ne sont pas montrés par souci de clarté.

      TCP A