TRANSMISSION CONTROL PROTOCOL
SPECIFICATION
2.
PHILOSOPHIE
2.1.
Eléments constitutifs du réseau
L'environnement
réseau est constitué de machines raccordées sur des réseaux, eux-mêmes
interconnectés par l'intermédiaire de routeurs. Ces réseaux peuvent être des
réseaux locaux (ex., Ethernet) ou réseaux étendus (ex., ARPAnet), mais sont
dans tous les cas des réseaux de type "à commutation de paquets" ou
"asynchrones". Les éléments actifs qui consomme et produisent des
paquets sont appelés des processus. Un certain nombre de niveaux de protocoles
réseau, au niveau des machines ou des routeurs, permettent d'établir une chaîne
complète de communication entre les processus actifs de n'importe quelle
machine.
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
Les
processus transmettent les données en faisant appel à TCP et en passant des
tampons de données comme arguments. TCP met en forme les données de ces
tampons, les segmente afin de les transférer au protocole Internet qui a son
tour les acheminera vers le TCP distant. Celui-ci reçoit les segments, les
copie dans un tampon temporaire, et en avise l'émetteur. Le protocole TCP
incluse les information nécessaires à la "reconstruction" en bon
ordre des données originales.
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
TCP
est conçu sous la forme d'un module du système d'exploitation. L'utilisateur
exploitera ses fonctions comme une autre ressource système (ex. le système de
fichiers). TCP pourra lui-même invoquer d'autres ressources système, par
exemple pour utiliser les structures de données locales. Actuellement,
l'interfaçage vers le réseau est implémentée sous la forme d'un pilote de périphérique.
TCP n'adresse pas le pilote directement, mais transfère le paquet à IP qui
prendra en charge à son tour les transactions avec le pilote.
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/application fournit l'accès à des commandes OPEN ou CLOSE pour l'ouverture
et la fermeture d'une communication, SEND ou RECEIVE pour l'émission ou la réception
de données, ou STATUS pour connaître l'état d'une communication. Ces
commandes seront appelées comme toute autre primitive système, par exemple
celle qui permet l'ouverture ou la fermeture de fichiers.
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
Le
diagramme suivant montre la place de TCP dans la hiérarchie de 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
Un
flux de donnée s'appuyant sur une connexion TCP doit être pouvoir considéré
comme "fiable".
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
TCP
indique un identificateur de port. Comme ces identificateurs sont choisis indépendamment
par chaque extrémité, ils peuvent se révéler identiques. L'adresse unique
d'une communication TCP est obtenue par la concaténation de l'adresse Internet
avec l'identificateur du port sélectionné, constituant ainsi ce que l'on nome
une "socket". Cette socket est alors unique dans l'ensemble du réseau.
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
Les
données circulant dans la connexion ouverte doivent être vues comme un flux
d'octets. L'application indique dans la commande SEND si les données soumises
lors de cet appel (et toutes celles en attente) doivent être immédiatement émises
par l'activation du flag PUSH.
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é
TCP
utilise le champ "type de service" et les options de sécurité du
protocole Internet pour fournir les fonctions relatives à la priorité et la sécurité
des communications TCP, sur un principe de "détection". Tous les
modules TCP ne fonctionneront pas nécessairement dans un environnement sécurisé
à plusieurs niveaux; certains pourront être limités à un fonctionnement sans
sécurité, d'autres ne pourront prendre en compte qu'un seul niveau à la fois.
Par conséquent, les implémentations TCP ne pourront répondre en termes de sécurité
qu'à un sous ensembles de cas du modèle sécurisé multi-niveaux.
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
Les
implémentations TCP devront suivre un principe de base: soyez rigoureux dans ce
que vous émettez, soyez tolérants dans ce que vous recevez de l'extérieur.