Le protocole TCP est défini dans le but de fournir un service de transfert de données de haute fiabilité entre deux ordinateurs "maîtres" raccordés sur un réseau de type "paquets commutés", et sur tout système résultant de l'interconnexion de ce type de réseaux.
La communication entre systèmes d'information joue un rôle croissant dans les domaines militaires, institutionnels, scientifiques et commerciaux.
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.
TCP prétend fournir un service de communication de processus à processus, dans un environnement réseau complexe. TCP est défini comme un protocole de communication "host to host", c'est à dire de maître à maître (par opposition à "central à terminal").
Spécifications fonctionnelles de TCP
Port source: 16 bits 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
Fenêtre : 16 bits 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.
La longueur TCP compte le nombre d'octets de l'en-tête TCP et des données du message, en excluant les 12 octets de la pseudo en-tête.
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 maximal
Dé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.
Etablissement et rupture des connexions TCP
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.
Communication de données avec TCP
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.
Priorité et sécurité dans TCP
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.