RFC 793 : Transmission Control Protocol (TCP) Specification

Crdits : Jon Postel / ISI Traduction : Valry G. FREMAUX / Ingnieur Professeur / EISTI Statut : Standard PREFACE 1. INTRODUCTION 2. PHILOSOPHIE 3. SPECIFICATION FONCTIONNELLE GLOSSAIRE REFERENCES

AVANT-PROPOS
Note du Traducteur : Le texte suivant est la traduction intgrale de la spcification TCP, telle qudite 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 autorise titre personnel ou ducatif. Par contre, tant donn la quantit de travail que cette mise en ?uvre reprsente, le traducteur se rserve le droit dautoriser une reproduction partielle ou totale de cette traduction dans tout ouvrage caractre commercial.

PREFACE
Ce document dcrit le protocole DoD Standard Transmission Control Protocol (TCP). Neuf versions prcdentes de la spcification ARPA TCP ont t dites. Ce texte sappuie trs fortement sur ces prcdentes version. Ce texte runit les contributions de nombreux rdacteurs et de dveloppeurs. Cette dition clarifie plusieurs dtails et supprime le principe dajustement de taille de tampon, il dcrit de nouveau le principe de courrier et lentre de pile. Jon Postel Editor RFC: 793 Remplace: RFC 761 IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5

1. INTRODUCTION
Le protocole TCP est dfini dans le but de fournir un service de transfert de donnes de haute fiabilit entre deux ordinateurs "matres" raccords sur un rseau de type "paquets commuts", et sur tout systme rsultant de linterconnexion de ce type de rseaux. Ce document dcrit les fonctions excutes par TCP, les programmes qui les implmentent, et les interfaces entre ce

dernier et les applications senses utiliser ce service.

1.1. Motivation
La communication entre systmes dinformation joue un rle croissant dans les domaines militaires, institutionnels, scientifiques et commerciaux. Ce document prend en compte en tout premier lieu les exigences du secteur militaire, en particulier les exigences de fonctionnement avec des communications peu fiables et dans une situation de congestion du rseau. La plupart de ces problmes sont rencontrs aussi dans les domaines non militaires. Au fur et mesure que les rseaux de communication informatiques caractre stratgiques ou tactiques sont dploys, il devient essentiel de trouver un moyen dinterconnexion de ces rseaux, et des standards de transmission de donnes permettant de supporter une vaste gamme dapplications. Anticipant le besoin de tels standards, le dput et sous-secrtaire dtat la recherche de la Dfense Amricaine a officialis le protocole dcrit ici en tant que base pour la standardisation des processus dintercommunication de donnes du Dpartement de la Dfense Amricaine (DoD). TCP est un protocole scuris orient connexion conu pour simplanter dans un ensemble de protocoles multicouches, supportant le fonctionnement de rseaux htrognes. TCP fournit un moyen dtablir une communication fiable entre deux tches excutes sur deux ordinateurs autonomes raccords un rseau de donnes. Le protocole TCP saffranchit le plus possible de la fiabilit intrinsques des couches infrieures de communication sur lesquelles il sappuie. TCP suppose donc uniquement que les couches de communication qui lui sont infrieures lui procurent un service de transmission de paquet simple, dont la qualit nest pas garantie. En principe, TCP doit pouvoir supporter la transmission de donnes sur une large gamme dimplmentations de rseaux, depuis les liaisons filaires cbles, jusquaux rseaux commuts, ou asynchrones. TCP sintgre dans une architecture multicouche des protocoles, juste au-dessus du protocole Internet IP. Ce dernier permet TCP lenvoi et la rception de segments de longueur variable, encapsuls dans un paquet Internet appel aussi "datagramme". Le datagramme Internet dispose des mcanismes permettant ladressage dun service TCP source et un destinataire, quelles que soient leur position dans le rseau. Le protocole IP soccupe aussi de la fragmentation et du rassemblage des paquets TCP lors de la traverse de rseaux de plus faibles caractristiques. Le protocole IP transporte aussi les informations de priorit, compartimentation et classification en termes de scurit relatives aux segments TCP. Ces informations se retrouvent alors transmises de bout en bout de la communication. Couches de protocoles +-------------------------------+ | Niveaux suprieurs | +-------------------------------+ | TCP | +-------------------------------+ | IP | +-------------------------------+ | Couche rseau | +-------------------------------+ De grandes parties de ce document sont crites dans un contexte o les implmentations TCP sont concomitantes dautres protocoles de haut niveau dans la mme machine. Certains systmes informatiques seront raccords au rseau via un frontal qui accueillera les fonctions TCP et IP, ainsi que les protocoles rseau de bas niveau. La spcification TCP dcrit une interface destination des applications de niveau suprieur, y compris dans le cas dune architecture avec un frontal, pour autant que les protocoles "poste vers frontal" soient implments.

1.2. Porte
TCP prtend fournir un service de communication de processus processus, dans un environnement rseau complexe. TCP est dfini comme un protocole de communication "host to host", cest dire de matre matre (par opposition "central terminal").

1.3. A propos de ce document

Ce document spcifie en dtail le comportement de toute implmentation TCP, tant dans ses transactions avec les couches applicatives suprieures, quavec dautres TCPs. Le reste de cette section offre une vue densemble des fonctions ralises et des interfaces proposes. La Section 2 rsume le concept "philosophique" ayant aboutit au design TCP. La Section 3 dcrit en dtail les ractions de TCP face divers vnements (arrive dun nouveau segment, appel dutilisateur, erreurs, etc.) ainsi que le format dtaill des segments TCP.

1.4. Interfaces
TCP sinterface avec un processus utilisateur ou applicatif et un protocole de niveau infrieur du type Internet Protocol. Linterface avec les applicatifs consiste en un ensemble de commandes comme le ferait une application un systme dexploitation pour la manipulation de fichiers. Par exemple, on trouvera des commandes pour tablir et rompre une communication, pour envoyer ou recevoir des donnes sur une connexion ouverte. Il est aussi prvu que TCP puisse communiquer avec les applications sur un mode asynchrone. Bien quune grande libert soit laiss aux dveloppeurs pour la constructions dinterfaces TCP pour un environnement donn, des fonctionnalits minimales sont requises pour reconnatre la validit TCP de limplmentation. Linterface entre TCP et les protocoles de couche base restent largement non spcifis except le fait quil doit y exister un mcanisme de transfert asynchrone de donnes. En gnral, cest le protocole infrieur qui est sens fournir la dfinition de cette interface. TCP assume un fonctionnement avec un large ensemble de protocoles rseau. Dans ce document, nous nous limiterons au fonctionnement avec IP.

1.5. Fonctionnement
Comme notifi ci-avant, TCP est conu pour fournir un service de transmission de donnes scuris entre deux machines raccords sur un rseau de paquets. Pour pouvoir assurer ce service mme au dessus dune couche de protocole moins fiable, les fonctionnalits suivantes sont ncessaires: Transfert de donnes de base Correction derreur Contrle de flux Multiplexage Gestion de connexions Priorit et Scurit Ces fonctionnalits sont dcrites en grandes lignes dans les paragraphes qui suivent. Transfert de donnes de base: TCP est capable de transfrer un flux continu de donnes entre deux ordinateurs, en dcoupant ce flux en paquets ou datagrammes. En gnral, TCP dcide de lui-mme l o le flux de donnes doit tre coup. Parfois les utilisateurs ont besoin de savoir que toutes les donnes soumises TCP ont bien t mises. La fonction "push" a t prvue a cet effet. Pour sassurer de la transmission complte de donnes jusqu un point spcifi, lutilisateur activera la fonction "push" de TCP. Cette fonction oblige TCP transmettre rapidement les donnes situes avant le point spcifi vers le destinataire. Il nest nul besoin de fournir un marqueur spcifique pour ce point, dans la mesure ou le destinataire accepte ces donnes comme un transmission normale. Contrle derreur: TCP doit considrer et traiter les cas de donnes perdues, errones, dupliques, ou arrives dans le dsordre lautre bout de la liaison Internet. Ceci est ralis par linsertion dun numro de squence, et par lobligation dmission dun "accus de rception" (ACK) par le TCP destinataire. Si laccus de rception nest pas reu au bout dun temps prdfini, le paquet sera rmis. Ct rcepteur, les numros de squence sont utiliss pour reconstituer dans le bon ordre le flux original, et liminer les paquets dupliqus. Llimination des erreurs physiques de transmission se fait par

encodage dun Checksum lmission, 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 rseau Internet nest pas satur, aucune faute de transmission ne devrait transparatre dans la communication. TCP est donc sens rcuprer les erreurs de la transmission Internet. Contrle de flux: TCP fournit un moyen au destinataire pour contrler le dbit de donnes envoy par lmetteur. Ceci est obtenu en retournant une information de "fentre" avec chaque accus de rception indiquant la capacit de rception instantane en termes de numros de squence. Ce paramtre not "window" indique le nombre doctets que lmetteur peut envoyer avant une autorisation dmettre ultrieure. Multiplexage: Pour permettre plusieurs tches dune mme machine de communiquer simultanment via TCP, le protocole dfinit un ensemble dadresses et de ports pour la machine. Un "socket" est dfini par lassociation des adresses Internet source, destinataire, ainsi que les deux adresses de port chaque bout. Une connexion ncessite la mise en place de deux sockets. Une socket peut tre utilise par plusieurs connexions distinctes. Laffectation des ports aux processus est tabli par chaque ordinateur. Cependant, il semble judicieux de rserver certains numros de ports pour des services caractriss et souvent utiliss. Ces services standard pourront alors tre atteints via ces ports "rservs". Laffectation, lutilisation et lapprentissage des ports associs dautres services moins courants ou propritaires ncessitera lutilisation de mcanismes plus dynamiques. Connexions: Les mcanismes de fiabilisation et de contrle de flux dcrits ci-dessus imposent TCP linitialisation et la maintenance de certaines informations pour chaque communication. La combinaison de ces informations, dont les sockets, les fentres, et les numros de squence formeront ce que nous appelons une connexion. Chaque connexion est identifie de manire unique par sa paire de sockets, dfinissant chacun des deux sens de la communication. Lorsque deux processus dsirent communiquer, leur TCP respectifs doivent tout dabord ngocier et tablir une connexion (initialiser ces informations dtat de part et dautre). Lorsque la communication sachve, elle sera ferme, en librant ses ressources dautres usages. Dans la mesure o lon considre que les ordinateurs, ainsi que le rseau Internet nest pas dune fiabilit absolue, on utilise une mthode dinitialisation par ngociation bilatrale base sur une horloge pour les numros de squence. Priorit et Scurit: Les exploitants de TCP peuvent indiquer le degr de scurit et la priorit de la communication tablie. TCP permet cependant de ne pas traiter ce besoin.

2. PHILOSOPHIE
2.1. Elments constitutifs du rseau
Lenvironnement rseau est constitu de machines raccordes sur des rseaux, eux-mmes interconnects par lintermdiaire de routeurs. Ces rseaux peuvent tre des rseaux locaux (ex., Ethernet) ou rseaux tendus (ex., ARPAnet), mais sont dans tous les cas des rseaux de type " commutation de paquets" ou "asynchrones". Les lments actifs qui consomme et produisent des paquets sont appels des processus. Un certain nombre de niveaux de protocoles rseau, au niveau des machines ou des routeurs, permettent dtablir une chane complte de communication entre les processus actifs de nimporte quelle machine.

Le terme paquet, gnrique, dsigne les donnes dune transaction unitaire entre un processus et le rseau. Le format physique des donnes lintrieur du rseau est en dehors du champ dapplication de ce document. Les "hosts" sont des ordinateurs raccords au rseau, et, du point de vue de ce dernier, sont les sources et destinations des paquets. Les processus sont identifis comme les lments actifs dans ces machines (conformment la dfinition courante de "programme en cours dexcution"). Les terminaux, fichiers, et autres priphriques dentre/sortie peuvent tre identifis comme "lments communicants" par lintermdiaire dun processus. De ce fait, toute communication reste identifie comme un change inter-processus. Comme un processus particulier doit pouvoir discerner des communications distinctes avec dautres processus, nous avons imagin que chaque processus puisse disposer dun certain nombre de "ports" dentre sortie, chacun attribu une communication unique avec un autre processus.

2.2. Modle de fonctionnement

Les processus transmettent les donnes en faisant appel TCP et en passant des tampons de donnes comme arguments. TCP met en forme les donnes de ces tampons, les segmente afin de les transfrer au protocole Internet qui a son tour les acheminera vers le TCP distant. Celui-ci reoit les segments, les copie dans un tampon temporaire, et en avise lmetteur. Le protocole TCP incluse les information ncessaires la "reconstruction" en bon ordre des donnes originales. Le modle dune communication Internet fait quil existe pour chaque TCP actif un module de protocole Internet charg de lacheminement de donnes. 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 rseau local, une troisime couche de protocole, spcifique au rseau, est ajoute. Les paquets peuvent alors subir un grand nombre de transformations, fragmentations, ou autres oprations pendant leur acheminement au module Internet distant. A larrive dans un routeur, le paquet Internet est "dsoss", puis ses informations sont examines pour savoir vers quel rseau le paquet doit tre achemin. Un nouveau paquet Internet est constitu, selon les spcifications du segment de rseau dsign, puis transmis sur ce rseau. Un routeur peut procder une segmentation plus fine des paquets, si le rseau en sortie na pas les performances suffisantes pour vhiculer le paquet dorigine. Pour raliser ceci, le routeur excute une nouvelle segmentation en "fragments". Ces mmes fragments peuvent leur tour tre redcoups en chemin par un autre routeur. Le format de paquets fragments est standardis de sorte que le rassemblage soit toujours possible, tape par tape, jusqu restitution des donnes originales. Le module Internet darrive extrait le datagramme de niveau suprieur, pour nous, TCP (aprs dfragmentation du paquet si ncessaire) et le passe la couche TCP. Cette description rapide du protocole ignore certains dtails. Le type de service en est un dimportance. Celui-ci indique au routeur (ou au module Internet) quels paramtres de service doivent tre utiliss pour traverser la section suivante. Lun de ces paramtres est la priorit du paquet. Un autre est le codage de scurit du paquet, permettant aux rseaux traitant des aspects de scurit de discriminer les paquets conformment aux exigences tablies.

2.3. Les Hosts

TCP est conu sous la forme dun module du systme dexploitation. Lutilisateur exploitera ses fonctions comme une autre ressource systme (ex. le systme de fichiers). TCP pourra lui-mme invoquer dautres ressources systme, par exemple pour utiliser les structures de donnes locales. Actuellement, linterfaage vers le rseau est implmente sous la forme dun pilote de priphrique. TCP nadresse pas le pilote directement, mais transfre le paquet IP qui prendra en charge son tour les transactions avec le pilote. Les mcanismes TCP ninterdisent pas limplmentation de TCP dans un frontal. Cependant le frontal devra disposer dun protocole vis vis du central permettant la prise en compte de linterface application vers TCP, telle que dfinie

dans ce document.

2.4. Interfaces
Linterface TCP/application fournit laccs des commandes OPEN ou CLOSE pour louverture et la fermeture dune communication, SEND ou RECEIVE pour lmission ou la rception de donnes, ou STATUS pour connatre ltat dune communication. Ces commandes seront appeles comme toute autre primitive systme, par exemple celle qui permet louverture ou la fermeture de fichiers. Linterface TCP/Internet dispose de commandes pour recevoir et mettre des paquets vers des modules TCP o quils soient sur le rseau. Ces appels ont des paramtres tels quadresses, type de service, priorit, scurit, et autres informations de contrle.

2.5. Relations avec dautres protocoles

Le diagramme suivant montre la place de TCP dans la hirarchie de protocoles +------+ +-----+ +-----+ +-----+ |Telnet| | FTP | |Voice| ... | | +------+ +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ | TCP | | RTP | ... | | +-----+ +-----+ +-----+ | | | +-------------------------------+ | Internet Protocol & ICMP | +-------------------------------+ | +---------------------------+ | Local Network Protocol | +---------------------------+ Relations interprotocoles - Figure 2. TCP doit ncessairement supporter les niveaux de couches suprieures avec toute lefficacit requise. Linterfaage de protocoles tels que Telnet ARPAnet ou THP AUTODIN II doit demeurer aise.

Couche applicative

Couche machine

Couche routage

Couche rseau

2.6. Fiabilit de communication

Un flux de donne sappuyant sur une connexion TCP doit tre pouvoir considr comme "fiable". La fiabilit de cette transmission sappuie sur lutilisation de numros de squence et sur un mcanisme daccuss de rception. Dans le concept, chaque octet de donnes est attribu un numro de squence. Le numro de squence du premier octet transmis dans un segment est appel le numro de squence du segment. Celui-ci est explicitement transmis avec le segment. En retour, laccus de rception est constitu du numro de squence du prochain octet transmettre. Lorsque TCP transmet un segment contenant des donnes, celui-ci est copi dans une pile de rmission et une temporisation est lance; lorsque laccus de rception est reu, la copie dans la pile de retransmission est supprime. Dans le cas contraire, le paquet est rmis une nouvelle fois. Laccus de rception ne garantit pas que les donnes sont effectivement arrives lutilisateur final. Il indique simplement que le FTP destinataire bien pris en charge ces donnes, en vue de les transmettre cet utilisateur. Pour contrler le dbit de donnes entre les deux TCP, un mcanisme dit de "contrle de flux" est employ. Le TCP rcepteur amnage une "fentre de rception" pour le TCP metteur. Cette "fentre" indique le nombre doctets, partir du numro de squence inscrit dans laccus de rception, 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 indpendamment par chaque extrmit, ils peuvent se rvler identiques. Ladresse unique dune communication TCP est obtenue par la concatnation de ladresse Internet avec lidentificateur du port slectionn, constituant ainsi ce que lon nome une "socket". Cette socket est alors unique dans lensemble du rseau. Une connexion de base est dfinie par un couple de sockets, lun dfinissant lmetteur, lautre le rcepteur. Un socket peut devenir le destinataire ou la source pour plusieurs sockets distinctes. La connexion est rsolument bidirectionnelle, et prend la dnomination de "full-duplex". TCP est libre dassocier ses ports avec les processus excuts sur sa machine. Cependant, quelques rgles ont t tablies pour limplmentation. Ont t dfinis un certain nombre de sockets "rservs" que TCP ne doit associer quavec certains processus bien identifis. Ceci revient dire que certains processus peuvent sattribuer la proprit de certains ports, et ne pourront initier de communication que sur ceux-ci. (Actuellement, cette "proprit" est issue dune implmentation locale, mais nous envisageons une commande utilisateur Request Port, ou une autre mthode pour assigner automatiquement un ensemble de ports une application, par exemple en utilisant quelques bits de poids fort du numro de port pour coder lapplication). Une connexion est demande par activation de la commande OPEN indiquant le port local et les paramtres du socket distant. En retour, TCP rpond par un nom local (court) symbolique que lapplication utilisera dans ses prochains appels. Plusieurs choses doivent tre retenues propos des connexions. Pour garder la trace de cette connexion, nous supposons lexistence dune structure de donnes appele Transmission Control Block (TCB). Une des stratgies dimplmentation est de dire que le nom local donn est un pointeur vers le TCB associ cette connexion. La commande OPEN spcifie en outre si le processus de connexion doit tre effectu jusqu son terme, ou sil sagit dune ouverture en mode passif. Une ouverture passive signifie que le processus de connexion se met en attente dune demande de connexion plutt que de linitier lui-mme. Dans la plupart des cas, ce mode est utilis lorsque lapplication est prte rpondre tout appel. Dans ce cas, le socket distant spcifi nest compos que de zros (socket indfini). Le socket indfini ne peut tre pass TCP que dans le cas dune connexion passive. Un utilitaire dsireux de fournir un service un processus non identifi pourra initier une connexion passive. Tout appelant effectuant une requte de connexion sur le socket local sera reconnu. Il sera bon de garder en mmoire que ce socket est associ ce service. Les sockets "rservs" sont un bon moyen dassocier priori des ports des applications standard. Par exemple, le serveur "Telnet" est en permanence associ un socket particulier, dautres tant rservs pour les transferts de fichiers, sessions de terminal distant, gnrateur de texte, cho (ces deux pour des besoins de test), etc. Un socket peut tre rserv la fonction de serveur de domaines, transcodant les "noms explicites" de services en sockets Internet. Si le concept mme de lassignation priori de sockets fait partie de TCP, lassignation concrte des sockets "rservs" est dfinie dans un autre document. Les processus peuvent ouvrir une connexion passive et attendre quune connexion active les impliquant provienne dune autre machine. TCP aura la charge davertir lapplication quune communication est tablie. Deux processus mettant au mme moment une requte de connexion lun vers lautre se retrouveront normalement connects. Cette souplesse est indispensable pour assurer un bon fonctionnement du rseau compos dlments totalement asynchrones. Les deux cas de conclusion dune communication impliquant une connexion passive et une active sont les suivants. Soit le socket distant a t prcis lors de la requte de connexion passive, auquel cas seule une requte de connexion du distant attendu vers le local peut aboutir ltablissement dune communication. Soit le socket distant a t laiss indfini, et toute requte de connexion sur le socket local, do quelle vienne aboutit une communication valide. Dautres fonctionnalits permettront une acceptation sur correspondance partielle entre sockets. Si plusieurs requtes de connexion passive sont en attente (enregistres dans la table de TCBs) pour le mme socket local, et quune demande de connexion active provient de lextrieur, le protocole prvoit de dabord chercher sil lune des requtes dont le socket distant a t clairement exprim correspond celui de la demande. Si tel est le cas, ce socket sera activ. Sinon, cest une requte "indfinie" qui sera active.

La procdure de connexion utilise le bit de contrle de synchronisation (SYN) et suppose la transmission de trois messages. Cet change est appel "ngociation ternaire". La connexion suppose le rendez-vous dun segment marqu du bit SYN et dune requte locale (TCB), chacun des deux tant cr par lexcution dune commande de connexion. La correspondance entre le socket arriv et le socket attendu dtermine lopportunit de la connexion. Celle-ci ne devient rellement tablie que lorsque les deux numros de squence ont t synchroniss dans les deux directions. La rupture dune connexion suppose lmission de segments, marqus du bit FIN.

2.8. Communication de donnes

Les donnes circulant dans la connexion ouverte doivent tre vues comme un flux doctets. Lapplication indique dans la commande SEND si les donnes soumises lors de cet appel (et toutes celles en attente) doivent tre immdiatement mises par lactivation du flag PUSH. Par dfaut, TCP reste libre de stocker les donnes soumises par lapplication pour les mettre sa convenance, jusqu ce que le signal PUSH soit activ. Dans ce dernier cas, toutes les donnes non mises doivent tre envoyes. Symtriquement, lorsque le TCP rcepteur voit le flag PUSH marqu, il devra passer immdiatement toutes les donnes collectes lapplication destinataire. Il ny a priori aucune corrlation entre la fonction PUSH et les limites des segments. Les donnes dun segment peuvent tre le rsultat dune 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 immdiate de toutes les donnes latentes entre les deux TCP. Il ne sagit aucunement dune fonction denregistrement (Cf. langage Perl). Il y a par contre une relation entre la fonction push et lusage des tampons dans linterface TCP/application. Chaque fois quun flag PUSH est associ des donnes stockes dans le tampon de rception, celui-ci est intgralement transmis lapplication mme sil nest pas plein. Si le tampon est rempli avant quun flag PUSH soit vu, les donnes sont transmises lapplication par lments de la taille du tampon. TCP dispose dun moyen davertir lapplication que, dans le flux de donnes quil est en train de lire, au del de la position de lecture courante, des donnes de caractre urgent sont apparues. TCP ne dfinit pas ce que lapplication est sense faire lorsquelle est avise de la prsence de ces donnes. En gnral, cest limplmentation de lapplication qui traitera ces donnes urgentes selon ses besoins propres.

2.9. Priorit et Scurit

TCP utilise le champ "type de service" et les options de scurit du protocole Internet pour fournir les fonctions relatives la priorit et la scurit des communications TCP, sur un principe de "dtection". Tous les modules TCP ne fonctionneront pas ncessairement dans un environnement scuris plusieurs niveaux; certains pourront tre limits un fonctionnement sans scurit, dautres ne pourront prendre en compte quun seul niveau la fois. Par consquent, les implmentations TCP ne pourront rpondre en termes de scurit qu un sous ensembles de cas du modle scuris multi-niveaux. Les modules TCP oprant dans un environnement scuris plusieurs niveaux devront correctement renseigner les segments sortants en termes de scurit, niveau de scurit, et priorit. De tels modules TCP doivent fournir aux applications suprieures telles que Telnet ou THP une interface leur permettant de spcifier ces paramtres.

2.10. Principe de robustesse

Les implmentations TCP devront suivre un principe de base: soyez rigoureux dans ce que vous mettez, soyez tolrants dans ce que vous recevez de lextrieur.

3. SPECIFICATION FONCTIONNELLE
3.1. Format de len-tte
Les paquets TCP sont envoys sous forme de datagrammes Internet. Len-tte IP transmet un certain nombre de paramtres, tels que les adresses Internet source et destinataires. Len-tte TCP est place la suite, contenant les informations spcifiques au protocole TCP. Cette division permet lutilisation de protocoles autres que TCP, au dessus de la couche IP. En-tte TCP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port source | Port destinataire | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Numro de squence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accus de rception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Rserv |R|C|S|S|Y|I| Fentre | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Pointeur de donnes urgentes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | donnes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notez quune case reprsente une position bit. Port source: 16 bits 1000 Le numro de port de la source. Port Destinataire: 16 bits Le numro de port du destinataire. Numro de squence: 32 bits Le numro du premier octet de donnes par rapport au dbut de la transmission (sauf si SYN est marqu). Si SYN est marqu, le numro de squence est le numro de squence initial (ISN) et le premier octet pour numro ISN+1. Accus de rception: 32 bits Si ACK est marqu ce champ contient le numro de squence du prochain octet que le rcepteur sattend recevoir. Une fois la connexion tablie, ce champ est toujours renseign. Data Offset: 4 bits La taille de len-tte TCP en nombre de mots de 32 bits. Il indique l ou commence les donnes. Len-tte TCP, dans tous les cas une taille correspondant un nombre entier de mots de 32 bits.

Rserv: 6 bits Rservs pour usage futur. Doivent ncessairement tre 0. Bits de contrle: 6 bits (de gauche droite): URG: Pointeur de donnes urgentes significatif ACK: Accus de rception significatif PSH: Fonction Push RST: Rinitialisation de la connexion SYN: Synchronisation des numros de squence FIN: Fin de transmission Fentre: 16 bits Le nombre doctets partir de la position marque dans laccus de rception que le rcepteur est capable de recevoir. Checksum: 16 bits Le Checksum est constitu en calculant le complment 1 sur 16 bits de la somme des complments 1 des octets de len-tte et des donnes pris deux par deux (mots de 16 bits). Si le message entier contient un nombre impair doctets, un 0 est ajout la fin du message pour terminer le calcul du Checksum. Cet octet supplmentaire nest pas transmis. Lors du calcul du Checksum, les positions des bits attribus celui-ci sont marqus 0. Le Checksum couvre de plus une pseudo en-tte de 96 bits prfixe len-tte TCP. Cette pseudo en-tte comporte les adresses Internet source et destinataires, le type de protocole et la longueur du message TCP. Ceci protge TCP contre les erreurs de routage. Cette information sera vhicule par IP, et est donne comme argument par linterface TCP/Rseau lors des appels dIP par TCP. +--------+--------+--------+--------+ | Adresse source | +--------+--------+--------+--------+ | Adresse destinataire | +--------+--------+--------+--------+ | zro | PTCL | Longueur TCP | +--------+--------+--------+--------+ La longueur TCP compte le nombre doctets de len-tte TCP et des donnes du message, en excluant les 12 octets de la pseudo en-tte. Pointeur de donnes urgentes: 16 bits Communique la position dune donne urgente en donnant son dcalage par rapport au numro de squence. Le pointeur doit pointer sur loctet suivant la donne urgente. Ce champs nest interprt que lorsque URG est marqu. Options: variable Les champs doption peuvent occuper un espace de taille variable la fin de len-tte TCP. Ils formeront toujours un multiple de 8 bits. Toutes les options sont prises en compte par le Checksum. Un paramtre doption commence toujours sur un nouvel octet. Il est dfini deux formats types pour les options: Cas 1: Option mono-octet. Cas 2: Octet de type doption, octet de longueur doption, octets de valeurs doption.

La longueur doption prend en compte loctet de type, loctet de longueur lui-mme et tous les octets de valeur et est exprime en octets. Notez que la liste doption peut tre plus courte que ce que loffset de donnes pourrait le faire supposer. Un octet de remplissage (padding) devra tre dans ce cas rajout aprs le code de fin doptions. Ce octet est ncessairement 0. TCP doit implmenter toutes les options. Actuellement, les options dfinies sont (type indiqu en octal): Type ---0 1 2 Longueur -----4 Description ------Fin de liste doption Nop Taille de segment maximal

Dfinition des options spcifiques Fin de liste doptions +--------+ |00000000| +--------+ Type=0 Ce code indique la fin du champ doptions. Sa position peut ne pas concider avec lindication du dbut du champ de donnes marqu dans lOffset de donnes. Il doit tre plac aprs toutes les options, et non aprs chaque option. Il ne doit tre utilis que dans le cas ou la fin des options ne concide pas avec le dbut du champ de donnes. No-Operation +--------+ |00000001| +--------+ Type=1 Cette option peut tre utilise entre deux options, par exemple pour aligner le dbut dune option sur un dbut de mot de 16 bits. Lutilisation de ce sparateur nest pas une obligation. Limplmentation doit donc prvoir de pouvoir prendre en compte un option mme au milieu dun mot. Taille maximale de segment +--------+--------+---------+--------+ |00000010|00000100| Taille max. seg | +--------+--------+---------+--------+ Type=2 Longueur=4

Donne doption : Taille maximale de segment: 16 bits Si cette option est prsente, elle communique lmetteur la taille maximale des segments quil pourra envoyer. Ce champ doit tre envoy dans la requte de connexion initiale (avec SYN marqu). Si cette option est absente, le

segment pourra tre pris de nimporte quelle taille. Bourrage (padding): variable Les octets de bourrage terminent len-tte TCP: de sorte que le nombre doctet de celle-ci soit toujours multiple de 4 (32 bits) de sorte que loffset de donnes marqu dans len-tte corresponde bien au dbut des donnes applicatives.

3.2. Terminologie
Avant de prciser en profondeur le fonctionnement de TCP, nous devons tout dabord prendre quelques conventions sur la terminologie. La maintenance dune connexion TCP ncessite la mmorisation dun certain nombre de variables. Nous avons prvu que ces donnes soient enregistres dans une structure nomme "Transmission Control Block" ou TCB. Parmi les donnes enregistres dans ce TCB, on trouvera les sockets local et distant, les informations de scurit et de priorit de la connexion, les pointeurs vers les tampons de rception et dmission, les pointeurs vers la pile de retransmission et vers le segment courant. On y trouvera de plus quelques donnes relatives la gestion des numro de squence : Variables de squence dmission SND.UNA - "unacknowledge" - envoi sans accus de rception SND.NXT - "next" - envoi du suivant SND.WND - "window" - envoi de la fentre SND.UP - "urgent pointer" - pointeur de donnes urgentes SND.WL1 - "window last 1" - dernier numro de squence de segment envoy SND.WL2 - "window last 2" - dernier accus de rception ISS - "initial send sequence" - premier numro de squence du message Variables de squence de rception RCV.NXT - "next" - rception du suivant RCV.WND - "window" - rception de fentre RCV.UP - "urgent pointer" - pointeur de donnes urgentes IRS - "initial receive sequence" - premier numro de squence en rception Le diagramme suivant montre une vue des tampons dmission et de rception et limplication des donnes de contrle de squence ainsi dfinis. Visualisation de la squence dmission (vue plat du tampon dmission) 1 2 3 4 ----------|----------|----------|---------SND.UNA SND.NXT SND.UNA +SND.WND

1. 2. 3. 4.

- anciens numros de squence ayant t acquitts - numros de squences non acquitts - numros de squence autoriss pour une nouvelle mission - futurs numros de squence non encore autoriss

On notera que la fentre dmission donne par le rcepteur reprsente la portion de lespace de squence not 3. Les segments symboliss en gras ont dj t mis sur le rseau, les autres segments nont pas encore t mis et sont toujours dans le tampon.

Visualisation de la squence de rception (vue plat du tampon de rception) 1 2 3 ----------|----------|---------RCV.NXT RCV.NXT +RCV.WND

1. - numros de squence reus et acquitts 2. - numros de squence autoriss en rception (fentre) 3. - numros de squences futurs non encore autoriss en rception
La fentre de rception est la portion de squence note 2. Les segments symboliss en gras ont dj t reus via le rseau. Les autres restent encore " recevoir". On trouvera enfin des variables dont les valeurs sont dduites des donnes inscrites dans le segment courant. Variables du segment courant SEG.SEQ - "sequence" - numro de squence du segment courant SEG.ACK - "acknowledge" - numro de squence inscrit dans laccus de rception SEG.LEN - "length" - longueur du segment courant SEG.WND - "window" - fentre inscrite dans le segment courant SEG.UP - "urgent pointer" - pointeur de donnes urgentes du segment courant SEG.PRC - "precedence" - valeur de priorit courante Une connexion connat plusieurs tats durant sa dure de vie. Les tats dfinis sont: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, et ltat fictif CLOSED. CLOSED est dit fictif car il correspond une situation o la connexion elle-mme nexiste plus (son TCB non plus). Nous donnons ci-dessous un descriptif rapide des tats cits: LISTEN - La connexion reste en attente dune requte de connexion externe par un TCP distant. Cet tat est atteint aprs une demande de connexion passive. SYN-SENT - La connexion se met en attente dune requte de connexion, aprs avoir envoy elle-mme une requte un destinataire. SYN-RECEIVED - Les deux requtes de connexion se sont croises. La connexion attend confirmation de son tablissement. ESTABLISHED - La connexion a t confirm de part et dautre et les donnes peuvent transiter sur la voie de communication. Cest ltat stable actif de la connexion. FIN-WAIT-1 - Sur requte de dconnexion mise par lapplication, la connexion demande la confirmation dune requte de dconnexion quelle a elle-mme mise vers le distant. FIN-WAIT-2 - La connexion se met en attente dune requte de dconnexion par le distant, une fois reue la confirmation de sa propre requte. CLOSE-WAIT - La connexion se met en attente dune requte de dconnexion mise par lapplication. CLOSING - La connexion attend la confirmation de sa requte de dconnexion par le TCP distant, lequel avait auparavant mis sa propre requte de dconnexion. LAST-ACK - La connexion attend la confirmation de sa requte de dconnexion, mise suite une requte similaire

linitiative du distant. TIME-WAIT - Un temps de latence avant fermeture complte du canal, pour sassurer que toutes les confirmations ont bien t reues. CLOSED - La connexion nexiste plus. Cest un pseudo-tat. Le changement dtat dune connexion TCP intervient sur rception dun certain nombre de signaux, appele "vnement". Les vnements peuvent tre des commandes mises par lapplication, OPEN, SEND, RECEIVE, CLOSE, ABORT, et STATUS; la rception dun flag dans un segment en provenance du distant SYN, ACK, RST et FIN; la fin dune temporisation. Le diagramme suivant montre lenchanement des tats, en fonction des vnements reus, ainsi que les vnements produits. Il occulte par contre le traitement des fautes, ainsi que tous les autres vnements qui ne sont pas en relation avec les changements dtat. Un descriptif plus dtaill des vnements et de leur fonctionnement sera expos plus avant. NOTA BENE: ce diagramme est un rsum et ne doit pas tre compris comme une spcification complte. +---------+ ---------\ active OPEN | CLOSED | \ ----------+---------+<---------\ \ create TCB | ^ \ \ snd SYN passive OPEN | | CLOSE \ \ ------------ | | ---------\ \ create TCB | | delete TCB \ \ V | \ \ +---------+ CLOSE | \ | LISTEN | ---------- | | +---------+ delete TCB | | rcv SYN | | SEND | | ----------| | ------| V +---------+ snd SYN,ACK / \ snd SYN +---------+ | |<---------------------------------->| | | SYN | rcv SYN | SYN | | RCVD |<-----------------------------------------------| SENT | | | snd ACK | | | |------------------------------------| | +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ | -------------| | ----------| x | | snd ACK | V V | CLOSE +---------+ | ------| ESTAB | | snd FIN +---------+ | CLOSE | | rcv FIN V ------| | ------+---------+ snd FIN / \ snd ACK +---------+ | FIN |<---------------------------------->| CLOSE | | WAIT-1 |-----------------| WAIT | +---------+ rcv FIN \ +---------+ | rcv ACK of FIN ------| CLOSE | | -------------snd ACK | ------- | V x V snd FIN V +---------+ +---------+ +---------+ |FINWAIT-2| | CLOSING | | LAST-ACK| +---------+ +---------+ +---------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN -------------- | Timeout=2MSL -------------- | | ------x V -----------x V \ snd ACK +---------+delete TCB +---------+ ------------------------>|TIME WAIT|------------------>| CLOSED |

+---------+ Diagramme dtat dune connexion TCP

+---------+

3.3. Numros de squence

Une notion fondamentale dans le design du protocole TCP est lattribution chaque octet de donnes dun numro de squence. Cette technique de "marquage" permet de confirmer chaque octet individuellement. Le mcanisme dacquittement est cumulatif, en ce sens que la confirmation de loctet de numro de squence X indique que tous les octets prcdents ont bel et bien t reus. Ce mcanisme permet en outre llimination de toute donne reue en double par le principe de retransmission de squences en faute. La technique de numration commence ds le premier octet de donne, qui reoit le numro de squence le plus faible. Les autres octets sont numrots en squence par ordre croissant. Un des points essentiels se souvenir est que lespace de numrotation de squence est fini, bien que trs grand. Cet espace, cod sur 32 bits permet le comptage de 0 2**32 - 1 octets. Comme ce champ est de taille finie, toute opration arithmtique sur les numros de squence doit se faire modulo 2**32. Cette arithmtique non signe permet de prserver la continuit de numrotation, celle-ci repartant 0 aprs la valeur 2**32 - 1. Toute opration arithmtique opre sur les numros de squence devra tre programme avec beaucoup de prcautions du fait de laspect cyclique de la numrotation, en particulier les comparaisons de numros de squence aux alentours de la limite suprieure. Les principales comparaisons de numro de squence par TCP ont pour fonction: (a) de dterminer quun accus de rception reu concerne bien des donnes mises et non encore confirmes. (b) de dterminer que tous les numros de squence (donc, toutes les donnes) dun segment ont bien t reues (par exemple, pour purger la pile de retransmission). (c) de dterminer quun segment reu contient bien des numros de squence (et donc des donnes) attendues (cest dire que le principe de fentre de rception a bien t respect par lmetteur). En rponse lmission de donnes, TCP reoit des "accuss de rception". La confirmation de transmission doit sappuyer sur les comparaisons suivantes: SND.UNA = dernier numro de squence non acquitt SND.NXT = prochain numro de squence mettre SEG.ACK = valeur daccus de rception (prochain numro de squence attendu par le distant) SEG.SEQ = premier numro de squence du segment SEG.LEN = la taille des donnes en octets dans le segment (y compris pour des segments SYN et FIN) SEG.SEQ+SEG.LEN-1 = dernier numro de squence du segment Un nouvel accus de rception (appel "ack acceptable"), est un accus de rception pour lequel lingalit ci-dessous est vrifie: SND.UNA < SEG.ACK =< SND.NXT Un segment ne peut tre effac de la pile de retransmission que si la somme de son numro de squence (premier octet de donne) et sa longueur est infrieure au numro de squence du dernier accus de rception reu (ceci revient dire en clair que lacquittement doit pointer une donne au del de la fin du segment). Lorsque des donnes sont reues, les conditions ou affectations suivantes doivent tre remplies: RCV.NXT = numro de squence dtect sur le segment entrant. Doit tre la limite

gauche (ou infrieure) de la fentre de rception. RCV.NXT+RCV.WND-1 = plus grand numro de squence admis sur le segment entrant. Est la limite droite (ou suprieure) de la fentre de rception. SEG.SEQ = premier numro de squence du segment entrant SEG.SEQ+SEG.LEN-1 = dernier numro de squence du segment entrant. Un segment est considr comme lintrieur de lespace de rception si: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND et RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND Le premier test dtermine si le premier octet des donnes du segment est dans la fentre. Le deuxime test vrifie que le dernier octet de donnes du segment reu est aussi lintrieur de la fentre. En pratique, cette vrification est un peu plus complique. Quatre cas dacceptabilit sont discernable, cause de la possibilit dune largeur 0 pour la fentre et dune longueur nulle de segment: Longueur du segment ------0 0 >0 >0 Fentre de rception ------0 >0 0 >0 Test -------------------------------------SEG.SEQ = RCV.NXT RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND non acceptable RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND ou RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Notez que lorsque la largeur de fentre est nulle, aucun segment except un acquittement (sans donnes) ne peut tre reu. Il est donc possible un TCP de maintenir une largeur de fentre zro, tout en transmettant des donnes et recevant des accuss de rception. Cependant, mme lorsque la fentre une largeur nulle, TCP doit examiner les champs RST et URG pour tous les segments entrants. Le mcanisme de numrotation nous permet en outre de protger quelques informations de contrle. Ceci est ralis en introduisant implicitement des flags de contrle dans la squence (ou plus explicitement, attribuer un numro de squence un contrle).Ces contrles pourront alors tre retransmis et acquitts sans confusion (ex., une instance unique du contrle sera traite). Mais les informations de contrle ne sont pas physiquement transmises dans le champ de donnes, le seul tre numrot. Il faudra donc mettre en place une technique pour assigner ce numro de squence au contrle. Les bits SYN et FIN sont les seuls contrles pouvant ncessiter cette protection. Ceux-ci ne sont mis que pendant une phase dtablissement ou de rupture dune connexion. Pour des raisons de numrotation, SYN est toujours considr arriver avant le premier octet de donnes du segment dans lequel il est marqu. A linverse FIN est toujours considr arriver aprs le dernier octet du segment. La longueur du segment (SEG.LEN) prend en compte lespace de donnes ainsi que celui des contrle. Lorsque SYN est marqu SEG.SEQ est alors le numro de squence du associ au contrle SYN. Slection du premier numro de squence Le protocole nimpose pas de restrictions ltablissement simultan de plusieurs connexions identiques. Un connexion est dfinie par une paire de sockets. De nouvelles instances dune connexion peuvent tre ouvertes. Le problme qui en dcoule est -- "comment TCP identifie les segments dupliqus lorsquils arrivent dinstances diffrentes dune connexion?" Ce problme devient apparent lorsquune connexion souvre et se ferme une cadence rapide, ou si une connexion se coupe par manque de mmoire et se rtablit par la suite. Pour viter toute confusion, il faut viter que les numros de squence utiliss par une instance de connexion ne soient utiliss lorsque les mmes numros de squence sont mis sur le rseau par une autre instance. Ceci doit tre assur y

compris si TCP se bloque et perd toute connaissance des numros de squence quil utilisait. Lorsquune connexion est tablie, un gnrateur de numro de squence initial (ISN) est utilis, qui gnre un nouvel ISN sur 32 bits. Ce gnrateur est bas sur une horloge (qui peut tre virtuelle) 32 bit dont le bit de poids faible est incrment environ toutes les 4 microsecondes. De ce fait, le cycle des ISN dure environ 4,55 heures. Comme nous supposons quun segment ne peut tre prsent dans le rseau plus longtemps que sa dure de vie maximale (Maximum Segment Lifetime = MSL) et que MSL est infrieur 4,55 heures, il est raisonnable de penser que lISN sera unique. Pour chaque connexion, on met en place un numro de squence dmission et un numro de squence de rception. Le numro initial dmission (ISS) est choisi par le TCP metteur, le numro de squence initial de rception (IRS) est "appris" par le rcepteur durant la phase dtablissement. Pour quune connexion puisse tre considre comme tablie, les deux TCPs doivent auparavant avoir pu synchroniser leurs numros de squence respectifs. Ceci est ralis grce lmission de segments particuliers de synchronisation avec le bit SYN marqu et les numros de squence initiaux. Par extension, les segments marqus du bit SYN seront nomms aussi SYN. La solution demande donc un mcanisme pour "prendre" un numro de squence initial, ainsi quun dialogue pour se communiquer les ISNs. La solution consiste faire envoyer par chaque extrmit son propre numro de squence initiale, charge de lautre bout dacquitter cette information. 1) A --> B SYN "mon numro de squence est X" 2) A <-- B ACK "ton numro de squence est X" 3) A <-- B SYN "mon numro de squence est Y" 4) A --> B ACK "ton numro de squence est Y" Comme les tapes 2 et 3 peuvent tre rassembles dans le mme segment, ce dialogue sappelle "ternaire". Cet change en trois tapes est ncessaire dans la mesure o le choix des numros de squence initiaux ne dpend pas dune horloge commune lensemble du rseau, et les diverses implmentations de TCP peuvent recourir des mthodes diverses pour choisir un ISN. Le rcepteur dun premier segment SYN na aucun moyen de dterminer quil ne sagit pas dun ancien segment "perdu" sur le rseau, sauf sil se "souvient" du dernier numro de squence utilis par la dernire connexion (ce qui nest pas toujours possible). Il doit donc demander lmetteur de vrifier ce segment SYN. Savoir ne rien mettre Pour tre certain que TCP nutilise pas un numro de squence dj contenu dans un segment "perdu" en cours de transmission sur le rseau, TCP doit attendre au moins la dure dun MSL (dure de vie maximale des segments) avant toute assignation dun nouvel ISN pour une nouvelle connexion ou sur rcupration dune connexion dont lhistorique de la numrotation de squence a t perdue. Dans le cadre de cette spcification, MSL vaut 2 minutes. Cette valeur rsulte de lexprimentation, et est susceptible de changer si le besoin sen fait sentir. Notez que si un TCP est rinitialis en ayant pu conserver lhistorique de squence, alors cette attente ne sera pas ncessaire; il lui suffira de produire des numros de squence suprieurs aux dernier mis. Le concept de "silence" TCP Cette spcification prvoit que des ordinateurs en faute ayant perdu toute trace des numros de squence sur les connexions non fermes ne puisse mettre sur le rseau Internet des segments TCP pendant au minimum la dure MSL. Dan ce qui suit, une explication dtaille de cette spcification est fournie. Les dveloppeurs implmentant TCP pourront toujours ne pas tenir compte de ce principe, mais au risque de voir des anciens segments accepts comme nouveaux, ou des nouveaux rejets car apparaissant comme des doubles danciens segments. TCP consomme lespace de numrotation des squences chaque fois quun nouveau segment est constitu et plac dans la pile dmission du pilote de rseau. La dtection de doublons, et lalgorithme de squence du protocole TCP sappuie sur le champ de numrotation fini en supposant que la squence est suffisamment longue pour que tous les segments, y compris toutes ses rmissions ou doublons aient t retirs du rseau avant que la squence ne reboucle. Sans ce principe, deux segments TCP pourraient se voir attribuer des plages de squence superposes, provoquant une extrme

difficult au rcepteur pour savoir quelle donne est ancienne et quelle donne est rcente. Souvenez vous ici que dans une transmission normale, les segments successifs dune transmission utilisent des plages de squence disjointes et contigus. En temps normal, TCP garde la trace du numro de squence mettre, et du plus ancien acquittement attendu. Ceci lui permet de ne pas utiliser un numro de squence attribu un segment en attente dacquittement. Ceci ne garantit pas que danciens doublons de paquets aient t totalement retirs du rseau. Le champ de numrotation a donc t choisi trs grand pour viter quun paquet "fantme" ne vienne perturber une rception. A 2 megabits/seconde, lutilisation des 2**32 valeurs de lespace de numrotation prend environ 4,5 heures. Comme la dure de vie dun paquet dans le rseau ne peut excder quelques dizaines de secondes, on considre que cette protection est largement suffisante mme lorsque la vitesse de transmission atteint 10 megabits/seconde. A 100 megabits/seconde, le cycle dure 5,4 minutes, ce qui peut paratre assez court, mais laisse encore une marge raisonnable. Lalgorithme de dtection de doublons et de squencement de TCP peut cependant tre mis en dfaut, dans le cas o TCP perd la mmoire du numro de squence quil utilisait pour les dernires transmissions. Un exemple de ceci serait un TCP initiant toutes ses connexion au numro de squence 0, puis sur faute et rinitialisation, rtablit une connexion (ex. en excutant lanalyse dune demi connexion reste ouverte) et met des paquets avec des plages de squences recoupant celles de paquets toujours en transit dans le rseau, et provenant de la connexion avant la rupture. Lorsque cette synchronisation de squence est perdue, la spcification TCP recommande de respecter un dlai de MSL secondes avant de remettre des segments sur la connexion, afin de permettre tous les anciens segments encore en transit dtre limins du rseau. Mme les ordinateurs avec horloge interne absolue, et utilisant cette horloge pour le choix dun ISN ne sont pas immuniss contre ce problme. Supposons, pat exemple, quune connexion soit ouverte, disons, en partant du numro de squence S. Supposons de plus que cette connexion est trs peu charge et quen plus, la fonction de gnration des numros de squence initiaux (ISN(t)) prenne comme base la valeur du numro de squence, disons S1, du dernier segment mis par ce TCP sur une connexion particulire, qui se trouve tre cette celle-ci. Supposons enfin que lordinateur redmarre et quune connexion soit restaure. Le numro de squence initial repris sera S1 = ISN(t) -- le mme numro que celui du dernier paquet envoy par linstance prcdente de la connexion ! Pour peu que la rcupration soit suffisamment rapide, tous les paquets sur le rseau portant un numro de squence proche de S1 risquent dtre compris comme des nouveau paquets, mme sils proviennent de lancienne instance de la connexion. Le problme est que lordinateur ayant eu la dfaillance ne sait absolument pas combine de temps celle-ci a dur, et par consquent si des paquets de lancienne connexion ne se trouvent pas encore en transit dans le rseau. Lune des faons de se sortir de ce problme est dimposer un silence dau moins un MSL aprs rcupration sur faute Cest la spcification dite de "silence TCP". Les implmentation qui ne tiennent pas compte de ce temps de silence et lignorent risquent de provoquer des confusions entre nouveaux et anciens segments dans les TCP rcepteurs. Au minimum, il est conseill que les dveloppeurs prvoient de laisser lutilisateur la possibilit dignorer le temps de silence connexion par connexion, ou, encore mieux, de systmatiser de manire informelle ce fonctionnement. Bien videmment, mme lorsque lattente TCP est implmente, elle nest pas indispensable lorsque la dfaillance intervient quelques MSL aprs que la connexion ait cess dmettre. Pour rsumer: chaque segment occupe une plage de squence lintrieur de lespace de numrotation, tous les numros lintrieur de ces plages sont "occups" pendant MSL secondes. Aprs une dfaillance, un bloc temporel est pris par la plage de squence du dernier segment mis. Si une connexion reprend trop tt, rmettant un segment utilisant un numro de squence compris dans la plage de squence prcdente, il y aura risque pour le rcepteur de mal interprter la squence de segments et produire une erreur de rassemblage de donnes.

3.4. Etablissement dune connexion

Lchange "ternaire" est la technique de ngociation utilise pour la connexion. Cette procdure est habituellement initie par un TCP vers un autre TCP. La procdure fonctionne mme si les deux TCP essaient de se connecter simultanment lun lautre. Lorsquune telle tentative simultane survient, chaque TCP reoit un segment "SYN" ne transportant aucun accus de rception aprs lmission de son propre "SYN". Bien sr, il restera toujours le cas dun segment "SYN" dune ancienne connexion qui peut faire croire TCP quun tablissement est en cours. Une bonne utilisation du segment de rinitialisation peut rsoudre cette ambigut.

Plusieurs exemples dinitialisation dune connexion suivent. Aucun de ces exemples ne montrent des segments dinitialisation transportant des donnes, ce qui est parfaitement lgitime, dans la mesure o TCP nenvoie pas de donne tant quil nest pas sr de la stabilit du canal (cest--dire que TCP est sens tamponner les donnes qui lui sont transmises par lapplication tant que ltat ESTABLISHED na pas t atteint). La ngociation "ternaire" rduit le risque de fausses connexions. Limplmentation des changes entre la mmoire et les messages apportera les informations ncessaires cette vrification. La transaction ternaire la plus simple est dcrite en figure 7. Ces figures doivent tre interprtes de la faon suivante. Chaque ligne est numrote pour rfrence. La flche vers la droite (-->) indique le dpart dun paquet TCP du TCP A vers le TCP B, ou larrive en B dun segment issu de A. La flche inverse (<--), la transmission dans le sens oppos. Lellipse (...) indique un segment toujours sur le rseau (retard). Un "XXX" indique un segment perdu, ou rejet. Les commentaires apparaissent entre parenthse. Ltat TCP reprsente ltat obtenu APRES le dpart ou larrive du segment (dont le contenu est mentionn au centre de la ligne). Le contenu des segments est montr sous forme abrge, avec son numro de squence, les flags marqus, et le champ ACK. Les autres champs tels quadresses, fentres, offset, etc. ne sont pas montrs par souci de clart.

1. 2. 3. 4. 5.

TCP A CLOSED SYN-SENT ESTABLISHED ESTABLISHED ESTABLISHED

--> <---> -->

<SEQ=100><CTL=SYN> <SEQ=300><ACK=101><CTL=SYN,ACK> <SEQ=101><ACK=301><CTL=ACK> <SEQ=101><ACK=301><CTL=ACK><DATA> Dialogue "ternaire" basique de connexion Figure 7.

--> <---> -->

TCP B LISTEN SYN-RECEIVED SYN-RECEIVED ESTABLISHED ESTABLISHED

En ligne 2 de la figure 7, TCP A met une requte envoyant un segment SYN indiquant quil utilisera des numros de squence partir de 100. En ligne 3, TCP B renvoie sa requte SYN tout en acquittant le SYN reu de TCP A. Notez que le champ daccus de rception indique que TCP B attend maintenant un numro de squence gal 101, le SYN de la premire requte ayant consomm la valeur 100 suivant le principe du numrotage implicite des contrles. En ligne 4, TCP A rpond par un segment vide contenant laccus de rception au SYN de TCP B; En ligne 5 enfin, TCP A envoie des donnes. Notez alors que le numro de squence de la ligne 5 est identique celui de la ligne 4, car ACK noccupe pas despace dans la squence (si ctait le cas, il nous faudrait acquitter les acquittements et on nen sortirait plus!). Ltablissement dune double requte simultane est lgrement plus complexe, comme cela apparat en figure 8. Chaque TCP bascule de ltat CLOSED vers SYN-SENT puis vers SYN-RECEIVED et enfin vers ESTABLISHED.

1. 2. 3. 4. 5. 6. 7.

TCP A CLOSED SYN-SENT --> <SEQ=100><CTL=SYN> SYN-RECEIVED <-- <SEQ=300><CTL=SYN> ... <SEQ=100><CTL=SYN> SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> ... <SEQ=101><ACK=301><CTL=ACK>

TCP B CLOSED ... <-- SYN-SENT --> SYN-RECEIVED ... <-- SYN-RECEIVED --> ESTABLISHED

Synchronisation dune requte de connexion simultane Figure 8. La principale raison du dialogue "ternaire" est dviter que danciens paquets issus dune prcdente tentative de connexion ne vienne perturber la nouvelle. Pour matriser ce cas de figure, un message de contrle spcial pour la rinitialisation, "reset", a t institu. Si le TCP rcepteur est dans un tat non synchronis (cest dire, SYN-SENT ou SYN-RECEIVED), il peut retourner ltat dattente LISTEN sur rception dune commande de rinitialisation valable. Si TCP est dans lun des tats synchroniss (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), la commande de rinitialisation casse la connexion et lapplication en est alors informe. Nous verrons ce cas plus en dtail lorsque nous analyserons les connexion semi-ouvertes ou

"demi-connexions". TCP A CLOSED SYN-SENT (duplicate) SYN-SENT SYN-SENT TCP B LISTEN <SEQ=100><CTL=SYN> <SEQ=90><CTL=SYN> <SEQ=300><ACK=91><CTL=SYN,ACK> <SEQ=91><CTL=RST> <SEQ=100><CTL=SYN> <SEQ=400><ACK=101><CTL=SYN,ACK> <SEQ=101><ACK=401><CTL=ACK> ... --> <---> --> <---> SYN-RECEIVED SYN-RECEIVED LISTEN SYN-RECEIVED SYN-RECEIVED ESTABLISHED

1. 2. 3. 4. 5. 6. 7. 8.

--> ... <---> ... SYN-SENT <-ESTABLISHED -->

Rcupration sur doublon dun ancien SYN Figure 9. La figure 9 prsente un cas simple de rcupration sur rception dun SYN chapp dune ancienne tentative. A la ligne 3, le doublon du SYN arrive au TCP B. TCP B na aucun moyen de savoir sil sagit dun doublon ou dun segment valide, Il rpond donc normalement (ligne4). TCP A dtecte que le champ daccus de rception est incorrect et renvoie une commande "reset" en marquant le bit RST en renseignant le champ SEQ pour maintenir la conformit du processus. TCP B, en recevant RST, revient ltat LISTEN. Lorsque le SYN valide arrive enfin la ligne 6, la synchronisation se droulez normalement. Si le segment SYN de la ligne 6 tait arriv avant RST, un change plus complexe aurait eu lieu, impliquant des RST envoys dans les deux directions. Connexions semi-ouvertes et autres anomalies On parle de connexion "demi-ouverte" lorsque lun des TCP a ferm ou coup brutalement la connexion sans que lautre extrmit nen ait eu connaissance, ou si les deux extrmits se retrouvent dsynchronises suite une dfaillance avec perte de mmoire. De telles connexions vont dclencher lopration de rinitialisation la moindre tentative denvoi de donnes dans lun ou lautre sens. Cependant, une telle situation est considr comme inhabituelle ou du moins anormale, et la procdure de rcupration ne sera pas toujours invoque. Si la connexion nexiste plus au site A, alors une tentative dmission de donnes du site B va rsulter en la rception dun message de rinitialisation par le TCP du site B. Un tel message indique au site B que quelque chose ne fonctionne pas, et quil serait plus sr darrter la communication. Supposez maintenant que deux applications A et B communiquent ensemble, et quune dfaillance quelconque provoque une perte de mmoire au niveau du TCP A. Suivant le systme dexploitation qui supporte A, il se peut quil existe un mcanisme de rcupration derreur. Dans ce cas, et lorsque le TCP est rtabli, A va certainement vouloir renvoyer les donnes partir du dbut, ou partir du point de rcupration si cela lui est possible. En consquence de quoi A va certainement essayer de rouvrir (OPEN) la connexion de nouveau ou essayer denvoyer (SEND) des donnes sur la connexion quil croit encore ouverte. Dans ce dernier cas, il recevra un message du type "connexion inexistante" du TCP local (A) TCP. Dans lintention de rouvrir la connexion, le TCP A va mettre un segment SYN. Ce scnario conduit lexemple de la figure 10. Aprs le crash du TCP A, lapplication tente de rouvrir la connexion. TCP B, dans le mme temps, pense toujours que la connexion est ouverte. TCP A (CRASH) CLOSED SYN-SENT (!!) SYN-SENT SYN-SENT SYN-SENT TCP B (send 300,receive 100) ESTABLISHED --> (??) <-- ESTABLISHED --> (Abort!!) CLOSED -->

1. 2. 3. 4. 5. 6. 7.

--> <SEQ=400><CTL=SYN> <-- <SEQ=300><ACK=100><CTL=ACK> --> <SEQ=100><CTL=RST> --> <SEQ=400><CTL=SYN>

Dcouverte dune connexion semi-ouverte Figure 10. Lorsque le segment SYN arrive en ligne 3, TCP B, toujours synchronis, et le segment reu se trouvant en dehors de la fentre de rception, rpond par un acquittement indiquant quelle squence il sattend recevoir (ACK 100). TCP A saperoit que cet accus de rception naccuse rien du tout (puisquil est totalement dsynchronis). Il envoie donc un

reset (RST), ayant dtect une situation de connexion semi-ouverte. TCP B abandonne en ligne 5. TCP A va continuer tenter dtablir la connexion; le problme est alors rsolu dans la mesure o lon revient la procdure de base "ternaire" de la figure 7. Une alternative intressante apparat dans le cas dun crash de TCP A alors que TCP B essaie denvoyer des donnes sur ce quil pense tre une connexion synchronise. Ceci est illustr en figure 11. Dans ce cas, les donnes arrivant au TCP A partir de TCP B (ligne 2) ne peuvent tre accept puisquaucune connexion nexiste, TCP A envoie donc un RST. RST est acceptable par TCP B qui abandonne la connexion. TCP A TCP B (CRASH) (send 300,receive 100) (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED --> <SEQ=100><CTL=RST> --> (ABORT!!) Dcouverte de connexion semi-ouverte par le ct actif Figure 11. En figure 12, nous trouvons les deux TCPs A et B en tat de connexion passive attendant un SYN. Un doublon ancien arrivant au TCP B (ligne 2) rveille celui-ci. Un SYN-ACK est renvoy (ligne 3) et force TCP A gnrer un RST (lacquittement de la ligne 3 nest pas recevable). TCP B accepte la rinitialisation et retourne sagement dans ltat dattente LISTEN. TCP A LISTEN ... <SEQ=Z><CTL=SYN> (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> --> <SEQ=Z+1><CTL=RST> LISTEN TCP B LISTEN SYN-RECEIVED SYN-RECEIVED (return to LISTEN!) LISTEN

1. 2. 3.

1. 2. 3. 4. 5.

--> <--->

Rinitialisation suite rception dun doublon sur deux connexions passives Figure 12. Une grande varit de cas est possible, chacune rsultant dans une procdure de rinitialisation selon les rgles qui suivent. Gnration dun signal de rinitialisation En rgle gnrale, un signal de rinitialisation (RST) doit tre mis sur toute rception dun segment qui ne rpond visiblement pas aux exigences de la connexion ouverte. Ce message ne doit pas tre mis si il nest pas certain que cest le cas. . On dnotera trois types de situations: 1. Si la connexion nexiste pas (CLOSED) alors un "reset" est envoy sur toute rception dun segment sur cette connexion, except sil sagit lui-mme dun "reset". En particulier, des segments SYN adresss une connexion inexistante sont rejets par ce moyen. Si le segment entrant prsente un accus de rception, le segment RST mis rcupre le numro de squence du champ ACK de ce segment. Autrement le numro de squence du "reset" est zro et laccus de rception est fix la somme du numro de squence et de la longueur de segment du segment entrant. La connexion demeure ferme. 2. Si la connexion est dans un tat non synchronis (LISTEN, SYN-SENT, SYN-RECEIVED), et le segment entrant acquitte quelque chose qui na pas t encore envoy (ACK non recevable), ou le segment entrant est sur un niveau de scurit ou un compartiment de scurit ne correspondant pas exactement celui attendu pour la connexion, un segment RST est mis. Si notre propre segment SYN na pas t acquitt et le niveau de priorit du segment entrant est suprieur celui attendu, on pourra relever le niveau de priorit de la connexion (si lapplication et le systme dexploitation

lautorisent) ou mettre un "reset"; ou si le niveau de priorit du segment entrant est infrieur celui requis, on continuera le traiter sans changer sa propre priorit (si le TCP distant ne peut augmenter le niveau de priorit pour rpondre nos exigences locales, cela sera signifi dans les prochains segments reus, et la connexion se fermera). Dans le cas ou notre segment SYN a t acquitt (peut tre dans ce segment entrant) le niveau de priorit doit correspondre exactement. Dans le cas contraire un "reset" doit tre mis. Si le segment entrant prsente un accus de rception, le segment RST mis rcupre le numro de squence du champ ACK de ce segment. Autrement le numro de squence du "reset" est zro et laccus de rception est fix la somme du numro de squence et de la longueur de segment du segment entrant. La connexion demeure dans le mme tat. 3. Si la connexion est dans un tat synchronis (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), tout segment non recevable (hors fentre de rception, ou accus de rception invalide) provoque lmission dun segment vide contenant le numro de squence courant en mission et laccus de rception indiquant le prochain numro de squence attendu en rception, et la connexion reste dans le mme tat. Si un segment entrant a un niveau de scurit, ou compartiment, ou une priorit qui ne correspond pas exactement la scurit, et compartiment, et priorit requise pour la connexion, une rinitialisation est envoye et la connexion se referme. Laccus de rception du segment RST est renseign avec la valeur de laccus de rception du segment entrant. Traitement sur rinitialisation Dans tous les cas, except SYN-SENT, tous les segments de rinitialisation (RST) sont valids en inspectant le champ SEQ. Une rinitialisation nest reconnue que si elle intervient dans la fentre de rception. Dans ltat SYN-SENT (correspondant un RST reu en rponse un segment SYN initial), le segment RST est considr comme valide si son champ ACK acquitte le message SYN auquel il rpond. Le rcepteur dun segment RST commence par le valider, puis change dtat. Si le rcepteur tait dans ltat LISTEN, il lignore. Si le rcepteur tait dans ltat SYN-RECEIVED aprs tre sorti de ltat LISTEN, alors il revient dans ltat LISTEN. Dans tous les autres cas, la connexion est abandonne. Lapplication est informe de la rupture de la connexion.

3.5. Fermeture dune connexion

CLOSE est une opration signifiant "Je nai plus dautre donnes envoyer". La notion de fermeture dune communication bidirectionnelle peut tre sujette une interprtation ambigu. Lanalyse faire du ct rception nest pas de la plus grande simplicit. Nous avons choisi de lexpliquer de la faon la plus simple. Lapplication demandant la fermeture peut continuer recevoir jusqu tre averti que lautre extrmit ferm son tour la connexion. Ainsi, un programme pourrait mettre plusieurs SEND suivi dun CLOSE, et ensuite continuer recevoir des donnes jusqu ce que TCP lui signale que le distant a ferm sa connexion. Du moins supposons nous que TCP le fera, mme si aucune commande RECEIVE ne reste pendante, et ce ds que lautre extrmit ferme la connexion, et permette lextrmit locale de terminer ses oprations proprement. TCP devra mettre toutes les donnes qui lui auront t passes par lapplication avant lactivation de la commande CLOSE. Ainsi, une application peut sans problme fermer une connexion qui continuera mettre des donnes et lancer une autre tche. Par contre il faudra toujours lire les tampons de rception, jusqu ce que le TCP distant indique quil na plus de donnes envoyer. On distingue trois cas de figure principaux:

1. 1) Lapplication demande la fermeture au TCP en activant la commande CLOSE. 2. 2) La connexion est rompue par le distant qui marque son flag FIN 3. 3) Les deux applications coupent simultanment la connexion
Cas 1: Lapplication locale dclenche la dconnexion Dans ce cas, un segment FIN est constitu et inscrit au bas de la pile dmission. Aucune commande SEND ne sera plus accepte par TCP, celui-ci passant ltat FIN-WAIT-1. Les commandes RECEIVE restent acceptes dans cet tat, la demi-connexion inverse fonctionnant toujours. Tous les segments prsents 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 quun TCP recevant un segment FIN peut lacquitter, mais nenverra son propre segment FIN que lorsque son application aura excut la commande CLOSE. Cas 2: TCP reoit un segment FIN du distant Si un segment FIN arrive inopinment par le rseau, TCP peut lacquitter et avertit lapplication de la notification de fermeture. Lapplication mettra une commande CLOSE aprs avoir pris ses dispositions, suite laquelle TCP peut alors envoyer son propre FIN au TCP distant, une fois toutes les donnes restantes mises. TCP attend alors lacquittement de ce FIN pour effacer le TCB de cette connexion. Si aucun acquittement ne survient aprs un certain laps de temps, la connexion est coupe et lapplication en est avise. Cas 3: les deux applications ferment simultanment Une commande CLOSE simultane aux deux extrmits provoque un change de segments FIN. Tous les segments de donnes restants, y compris le dernier FIN seront mis et acquitts, chaque TCP pourra acquitter le segment FIN reu. Les deux cts, sur acquittement, effaceront chacun le TCB de cette connexion. TCP A ESTABLISHED (Close) FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> TIME-WAIT TIME-WAIT (2 MSL) <-- <SEQ=300><ACK=101><CTL=FIN,ACK> --> <SEQ=101><ACK=301><CTL=ACK> CLOSED Squence de fermeture normale Figure 13. TCP A ESTABLISHED (Close) FIN-WAIT-1 --> <-... CLOSING --> <-... TIME-WAIT (2 MSL) CLOSED TCP B ESTABLISHED (Close) ... FIN-WAIT-1 <---> ... CLOSING <---> TIME-WAIT (2 MSL) CLOSED TCP B ESTABLISHED --> CLOSE-WAIT <-- CLOSE-WAIT (Close) <-- LAST-ACK --> CLOSED

1. 2. 3. 4. 5. 6.

1. 2.

3. 4.

<SEQ=100><ACK=300><CTL=FIN,ACK> <SEQ=300><ACK=100><CTL=FIN,ACK> <SEQ=100><ACK=300><CTL=FIN,ACK> <SEQ=101><ACK=301><CTL=ACK> <SEQ=301><ACK=101><CTL=ACK> <SEQ=101><ACK=301><CTL=ACK>

Squence de fermeture bilatrale Figure 14.

3.6. Priorit et Scurit

Le propos de ce chapitre est de ne permettre ltablissement dune connexion quentre deux ports fonctionnant exclusivement avec les mmes valeurs de scurit et compartiment, et la priorit la plus leve des deux cts. Les paramtres de priorit et de scurit utiliss dans TCP sont exactement ceux dfinis par le protocole Internet (IP). Dans la prsente spcification, le couple "scurit/compartiment" dsigne lensemble des paramtres de scurit dIP dont le niveau de scurit, le compartiment, le groupe dutilisateur, et les restrictions dusage. Une tentative de connexion avec des valeurs de scurit/compartiment non concordantes, ou un niveau de priorit plus faible devra tre rejete via un segment de rinitialisation "reset". Le rejet dune connexion uniquement du une priorit plus faible ne pourra tre excut quaprs acquittement en bonne et due forme du segment SYN..

Notez quun module TCP travaillant la priorit par dfaut devra nanmoins surveiller la priorit des segments entrants, et augmenter son niveau de priorit si requis. Les paramtres de scurit peuvent tre exploits y compris en dehors dun environnement scuris (les valeurs indiquent des donnes non classifies), Ainsi, les ordinateurs doivent toujours tre en mesure, dans un environnement scuris, de lire les informations de scurit, mme sils nont pas lobligation de les transmettre.

3.7. Transfert de donnes

Une fois la connexion tablie, les donnes peuvent commencer tre changes dans des segments. Ceux-ci pouvant tre rejets (erreur de Checksum), ou perdus dans le rseau (congestion du rseau), TCP utilise un principe de retransmission (au bout dune temporisation) pour garantir lacheminement de tous les segments de donnes. Ce principe de retransmission peut conduire la rception de "doublons". Comme il a t prcis dans les paragraphes consacrs aux numros de squence, TCP effectue un certain nombre de tests sur les squences et les acquittements afin de dduire lacceptabilit des donnes reues. Lmetteur des donnes garde toujours en mmoire le prochain numro de squence utiliser dans la variable SND.NXT. Le rcepteur garde en mmoire le prochain num&eacute;ro de squence recevoir dans la variable RCV.NXT. Lmetteur garde en mmoire la valeur du plus ancien numro de squence non acquitt dans la variable SND.UNA. Si le flux de donnes sinterrompt pendant un temps suffisant pour que tous les segments sur le rseau soient parvenus destination, ces trois valeurs doivent tre gales. Lorsque lmetteur constitue un segment et le transmet, il incrmente la valeur de SND.NXT (souvenez-vous: modulo 2**32 !). Lorsque le rcepteur reoit un segment, il incrmente la valeur de RCV.NXT et envoie un acquittement. Lorsque lmetteur reoit cet acquittement, il incrmente SND.UNA. Lcart moyen entre ces variables est une mesure du "temps de propagation" lintrieur du rseau. A chaque fois, cest la longueur du paquet qui est ajout ces variables. Notez que dans un tat ESTABLISHED tous les segments transporteront linformation dacquittement courant. Le dclenchement dune commande CLOSE impose lutilisation de la fonction push, et lajout final dun segment FIN la pile de transmission. Temporisation de retransmission Du fait de la grande varit de rseaux formant Internet, et lemploi massif de connexions TCP travers ce rseau la valeur de temporisation de retransmission doit tre dtermine dynamiquement. Nous donnons ici un exemple de procdure permettant de dfinir cette temporisation. Exemple de procdure de calcul de temporisation de retransmission Mesurer tout dabord le temps entre lenvoi dun octet de numro de squence particulier (appelons le "marqueur") et la rception dun acquittement englobant ce numro de squence (les plages de squence dans les deux segments nont 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 infrieure (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 dinformations urgentes

Lobjectif du mcanisme durgence de TCP est de fournir un moyen lapplication mettrice dinciter le rcepteur prendre en compte des donnes urgentes, et un moyen pour signaler en retour que ces donnes urgentes ont bien t prise en compte par le rcepteur. Ce mcanisme permet de marquer un numro de squence particulier comme tant la fin dun bloc de donnes urgentes. Lorsque ce marqueur pointe sur un numro de squence non encore reu (RCV.NXT) par le TCP rcepteur, ce dernier doit prvenir lapplication de passer en "mode durgence"; et lorsque le numro de squence reu rattrape ce marqueur, le TCP doit signifier lapplication de repasser en "mode normal". Si le pointeur durgence est ractualis en "mode durgence", lapplication utilisatrice ne pourra en avoir connaissance. Ce mcanisme utilise un champ ddi dans chaque segment mis, appel "pointeur urgent". Le bit de contrle URG indique que ce champ contient une information valide. Le TCP rcepteur ajoutera la valeur de ce champ au numro de squence du segment concern pour obtenir le "marqueur". Lorsque le bit URG nest pas marqu, ce champs nest pas marqu, aucune mention durgence nest contenue dans le segment. Pour signifier ltat durgence, le segment mis doit au moins contenir un octet de donnes. Si lmetteur utilise de plus la fonction push, le temps de transmission des donnes urgentes sera optimis. Gestion de la fentre de transmission La fentre transmise dans chaque segment indique la plage de numros de squence que lmetteur de la fentre (celui qui reoit les donnes) est prte accepter. La taille de cette fentre est en relation avec la taille disponible des tampons de donnes associs cette connexion. Une grande taille de fentre encourage lmission. Si le nombre de donnes reues est suprieur ce que la fentre indique, les donnes hors fentre seront rejetes. Cette dperdition entrane un grand nombre de retransmissions et surcharge inutilement le rseau et les TCP. Lusage dune petite taille de fentre morcelle le dbit en ajoutant un certain retard supplmentaire au "temps de boucle", mais en limitant la surcharge du rseau due aux retransmissions. Le mcanisme instaur ninterdit pas un TCP de signifier une largeur de fentre importante, puis beaucoup plus mince dans le segment suivant sans avoir reu pour autant la quantit de donnes qui le justifie. Cette technique dit "dtranglement de fentre," est fortement dconseille. Le principe de robustesse nous dicte quun TCP ne doit pas de lui mme trangler une fentre, mais devra tre prpar accepter un tel comportement de la part dautres TCP. Le TCP metteur doit tre prt accepter de lapplication et envoyer au moins un octet de nouvelles donnes mme lorsque la fentre de transmission est de largeur nulle. Lmetteur devra retransmettre rgulirement le segment au TCP rcepteur. Lintervalle recommand entre deux retransmissions, lorsque la largeur de fentre est nulle est denviron 2 minutes. Cette retransmission est essentielle pour sassurer que la rouverture de la fentre par le rcepteur sera bien signifie au TCP metteur. A lautre bout, lorsque le TCP rcepteur affiche une largeur de fentre nulle et quun segment arrive, il doit ncessairement rpondre an acquittant le segment, un bon moyen de confirmer rgulirement le nouveau numro de squence attendu et la largeur de fentre courante (zro). Le TCP metteur met en forme les donnes afin de constituer des segments mette tenant dans lespace de squence autoris par la fentre, et rpte la mme opration pour inscrire les copies de segments dans la pile de retransmission. Cette dernire opration nest pas obligatoire, mais cependant trs utile. Pour une connexion nutilisant quun seul flux de donnes unidirectionnel (mais ncessairement "ouverte" en bidirectionnel), la largeur de fentre est envoye dans les acquittements sous un numro de squence unique (un segment ACK ne "consomme" pas despace de squence). Il nest donc pas possible de remettre dans lordre lhistorique de la largeur de fentre. Cela ne reprsente pas un problme critique, bien quil signifie que le TCP metteur puisse se baser sur danciennes valeurs de largeur de fentre lors dune mission. Une technique pour saffranchir de ce problme est de toujours rcuprer linformation de fentre dans laccus de rception contenant le plus grand numro de squence (une mthode indirecte de numrotation des segments ACK !).

La gestion de la largeur de fentre a une influence importante sur les performances de la communication. Les commentaires qui suivent sont destination des dveloppeurs. Suggestion pour gestion de la largeur de fentre Louverture dune toute petite fentre rduit les performances en augmentant le poids des en-ttes par rapport aux donnes. Ct rcepteur: Une suggestion pour viter des fentres trop petites est de ne diffrer louverture de la fentre jusqu ce quun certain pourcentage minimum X de lespace total des tampons allous la communication nait t libr (X peut tre pris entre 20 et 40%). Ct metteur: Lmetteur peut attendre que la fentre atteigne une certaine largeur avant de commencer envoyer des donnes. La fonction push permettra denvoyer un reliquat de donnes mme si la largeur de fentre est infrieure la limite choisie. Notez quil nest pas une bonne stratgie de retarder lmission des acquittements, au risque de provoquer des retransmissions inutiles et coteuses en termes de performances. Une stratgie est dmettre des acquittements ds quun segment court arrive (sans modifier la largeur de fentre), la largeur de fentre tant transmise dans les acquittements donns pour des segments de taille suprieure. Le segment envoy pour tester une largeur de fentre nulle peut conduire une "atomisation" de la transmission. Lorsque le segment testant cette information et contenant un seul octet de donnes est accept ( la rouverture de la fentre), il consomme un octet du nouvel espace ouvert. Si lmetteur envoie systmatiquement autant de donnes quil peut lorsque la fentre est ouverte, la transmission va se stabiliser en une succession de petits et longs segments. Au fur et mesure du temps, les variations de dbit interne entre les tampons et la connexion conduit une squence de segments courts et "pas si longs que a". Aprs un certain temps, la connexion est principalement constitue de segments courts. La suggestion faite ici est que les implmentations de TCP doivent grer attentivement la variation de largeur de fentre, les versions les plus simplistes conduisant toujours une fragmentation excessive de la transmission.

3.8. Interfaces
Deux interfaces sont concernes dans ce chapitre: linterface application/TCP et lapplication TCP/rseau (la dernire via le protocole de niveau infrieur). Nous dfinirons assez prcisment le protocole entre lapplication et linterface, et passerons sous silence linterface entre TCP et la couche infrieure, dans la mesure o celle-ci est parfaitement dfinie dans la spcification de ce protocole. Dans le cas o ce protocole est IP, on remarquera quelques paramtres communs ces deux protocoles. Interface application/TCP La description suivre des commandes envoyer TCP sera tout au plus une spcification dintention, dans la mesure o les ressources systme et leur forme diffrent considrablement dun systme lautre. Par consquent, nous devons prvenir le lecteur que diffrentes implmentations de TCP peuvent prsenter des interfaces distinctes. Cependant, il existera toujours un noyau de fonctions que TCP devra fournir toute application, afin dassurer la compatibilit globale du systme multicouches. Ce chapitre dcrit les commandes essentielles quun TCP se doit daccepter. Commandes applicatives vers TCP Les paragraphes suivants dcrivent les aspects fonctionnels de linterface Application/TCP. La notation utilise est trs proche de la syntaxe habituellement accepte pour les appels de fonctions par les langages de haut niveau, mais cet usage ninterdit pas lutilisation dappels sous forme condense (ex., SVC, UUO, EMT). Les commandes de base dcrites ici sont essentielles pour quun TCP puisse supporter une communication inter-processus. Chaque implmentation concrte 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 quune premier appel la fonction SEND puisse automatiquement ouvrir la connexion (OPEN). Dans son rle dintermdiaire de communication, TCP doit non seulement accepter des commandes, mais doit retourner un certain nombre dinformations lapplication, soit en rponse une commande, soit de faon unilatrale. Ces dernires consistent en: (a) une information gnrale sur la connexion (ex., interruptions, fermeture distante, connexion sur tel socket passif en attente).

(b) des rponses des commandes applicatives, indiquant le succs ou lchec pour telle ou telle raison.
Convention : Dans la formulation des commandes qui suivent, nous adoptons la convention de notation suivante pour les paramtres : Les paramtres de type bit (smaphores) sont nots en MAJUSCULE. Les paramtres dun autre type (adresse, entier, long, etc. sont nots en minuscule. OPEN Format: OPEN (port_local, socket_distant, ACTIF/PASSIF [, tempo] [, priorit] [, scurit/compartiment] [, options]) -> nom_local Nous supposons ici que le TCP local connat lidentit du processus quil sert, et vrifiera que ce processus est bien autoris ouvrir une connexion sur le socket spcifi. Suivant limplmentation de TCP, les identificateurs TCP et rseau dadresse source seront soit fournis par TCP soit par le protocole de routage (ex. IP). Ces considrations dcoulent dune rflexion sur la scurit, dont le but est dinterdire un TCP de se faire passer pour un autre. De mme, aucun processus ne peut se faire passer pour un autre sans la complicit des couches infrieures. Si le paramtre ACTIF/PASSIF est marqu "passif", TCP se mettra dans ltat LISTEN et "coutera" le rseau. Dans ce cas, le socket distant pourra soit tre spcifi soit laiss "indfini". Si le socket est spcifi, seule une demande de connexion provenant de ce socket pourra rveiller la connexion. Si le socket est laiss "indfini", toute tentative de connexion distante sur cette connexion sera prise en compte. Une connexion passive peut tre rendue active par lenvoi dune commande SEND ultrieure. Un bloc de contrle de transmission (TCB) est cr, partiellement renseign avec les paramtres passs par la commande OPEN. Sur commande OPEN active, TCP dmarrera immdiatement la procdure de synchronisation (cest--dire, ltablissement). Le paramtre de temporisation tempo, si prcis, permet de rgler la limite maximale admise pour la transmission de donnes par TCP. Si les donnes nont pu tre transmises au destinataire avant ce temps, TCP aura la charge de couper la communication. La valeur par dfaut actuelle pour cette temporisation est de 5 minutes. TCP ou un autre composant du systme dexploitation aura la charge de vrifier les droits de lapplication ouvrir une communication sur la priorit, la scurit et le compartiment demands. Labsence de paramtres ce niveau implique lutilisation des valeurs "par dfaut". TCP ne pourra accepter de requte entrante que dans la mesure o les informations de scurit/compartiment correspondent exactement celles prcises dans la commande OPEN, et la priorit y est au moins gale ou suprieure.

La priorit choisie pour la connexion sera la valeur maximum entre celle pr&eacut 1000 e;cise dans la commande OPEN et celle arrive par le rseau. Elle sera fixe pour toute la dure de vie de la connexion. Certains dveloppeurs voudront pouvoir donner lapplication le pouvoir de ngocier cette priorit. Par exemple, lapplication pourra souhaiter de naccepter la connexion que sur le mme 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 dfinie par la paire <socket local, socket distant>. SEND Format: SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo]) Cet appel permet lenvoi des donnes contenues dans le tampon de taille compte dbutant ladresse_tampon sur la connexion dfinie par nom_local. Dans le cas gnral, si la connexion na pas t ouverte auparavant, cette commande gnre une erreur. Certaines implmentations permettront lusage direct de la commande SEND; celles-ci demanderont les paramtres supplmentaires utiles ltablissement pralable de la connexion. Si lapplication demanderesse nest pas autorise ouvrir la connexion demande, une erreur sera retourne. Si lindicateur PUSH est marqu, les donnes 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 donnes pourront tre momentanment stockes par TCP pour tre assembles celles provenant des SEND suivants, si lefficacit de la transmission le demande. Si lindicateur URGENT est marqu, les segments envoys au TCP distant auront le flag URG marqu, indiquant la validit du "pointeur urgent". Le TCP rcepteur signalera lapplication distante ltat durgence tant que toutes les donnes urgentes nont pas t rcupres par lapplication destinataire. Le but de ce mcanisme et dinciter lapplication traiter ces donnes en priorit, et daviser le rcepteur que toutes les donnes de ce type ont t prises en compte. Le nombre de fois que le TCP metteur signale le caractre durgence nest pas ncessairement le mme que celui que lapplication reoit du TCP distant. Si aucun socket distant na t spcifi dans la commande OPEN, et la connexion tablie malgr tout (ex. la suite dune requte de connexion quelconque arrive sur ce socket), alors le tampon dsign est envoy vers ce socket "implicite". Les applications utilisant la commande SEND sur une telle connexion nont pas le besoin de connatre la valeur du socket distant. Par contre, si une commande SEND est excute avant que le socket distant ait t explicit, une erreur est retourne. Lapplication peut excuter la commande STATUS pour dterminer ltat de la connexion. Dans certaines implmentations TCP indiquera lapplication lorsquune connexion passive "indfinie" est explicite. Lorsquune tempo est prsente, la valeur courante de la temporisation dfinie la commande OPEN est remplace par la nouvelle valeur. Dans les implmentations les plus simples, la commande SEND ne rendra pas la main au processus appelant tant que la transmission nest pas acheve ou, dfaut, la temporisation nest pas coule. Cependant, cette technique simpliste provoque de nombreux temps morts, voire blocages (par exemple, si les deux cts dune transmission essaient denvoyer des donnes avant de demander la premire rception). Elle est donc dconseille. Une technique plus sophistique rendra la main immdiatement lapplication, de sorte quelle continue son traitement concurrentiellement avec les routines dentres/sorties rseau, et, de plus permettre le lancement de plusieurs missions successives (une sorte de "batch"). Des envois successifs seront traits dans ce cas sur le mode FIFO (premier arriv premier servi), et TCP devra amnager une pile pour ceux quil ne pourra traiter immdiatement. Nous venons implicitement de dfinir une interface de type "asynchrone" dans laquelle une commande SEND induit un SIGNAL ultrieur ou une pseudo interruption provenant du TCP. Une autre alternative est de rpondre

immdiatement lapplication. Par exemple, TCP peut donner un acquittement local immdiat en rponse la commande SEND de lapplication, mme si lui-mme na pas encore reu lacquittement de rception par le distant, ni mme envoy les donnes. Nous pouvons avec optimisme penser que le succs 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 implmentation de ce type (synchrone) ne pourra saffranchir de quelques signaux asynchrones, mais ceci concernent ltat global de la connexion, plutt que des informations particulires sur les tampons. Afin que lapplication puisse distinguer les retours derreur ou de succs de multiples SENDs, il parat appropri dajouter la rponse ladresse du tampon concern (celui qui aura t transmis par la commande SEND correspondante). La signalisation TCP vers application est dcrite ci-aprs, indiquant le type dinformation qui doit tre retourn lapplication appelante. RECEIVE Format: RECEIVE (nom_local, adresse_tampon, compte) -> compte, URGENCE, PUSH Cette commande alloue un tampon de rception la connexion spcifie. Si la connexion na pas t ouverte au pralable par une commande OPEN, ou lapplication na pas lautorisation dutiliser une telle connexion, une erreur sera renvoye. Dans une implmentation simpliste, la main ne sera pas redonne lapplication tant que le tampon naura pas t rempli, ou une erreur survenue. Ce schma est malheureusement souvent bloquant. Une implmentation plus sophistique consisterait pouvoir mettre en attente plusieurs commandes de rception. Les tampons associs se remplissent alors ds que les segments concerns arrivent par le rseau. Cette stratgie permet un dbit dinformation plus rapide, au prix dun mcanisme plus labor (ventuellement asynchrone) destin avertir lapplication quune fonction push a t active, ou que le tampon est plein. Si une quantit de donnes suffisante est reue avant quun flag PUSH napparaisse, lindicateur PUSH ne sera pas marqu dans la rponse la commande RECEIVE. Le tampon contiendra autant de donnes quil peut en contenir. Si un flag PUSH arrive du rseau, le tampon sera retourn partiellement rempli, et lindicateur PUSH marqu dans la rponse. Si des donnes urgentes sont prsentes par le rseau, lapplication en sera avertie immdiatement par un signal asynchrone de linterface TCP vers application. Cette dernire doit passer en "mode urgent". Tant que lindicateur URGENCE est marqu dans la rponse une commande RECEIVE, des donnes urgentes restent latentes dans les tampons de TCP. Lorsque lindicateur URGENCE nest plus marqu, les dernires donnes urgentes ont t transfres dans le tampon associ et lapplication peut repasser en "mode normal". Notez que les donnes "normales" suivantes ne peuvent tre transmises dans le mme tampon (mais seront disponibles via la commande RECEIVE suivante), moins que la limite ne soit clairement marque. Pour discriminer la rponse plusieurs commandes RECEIVE en instance et pour sassurer que les tampons rcuprer ont t compltement remplis, la rponse mise sous forme de signal, aprs rception, est accompagne dun pointeur sur le tampon et de la taille occupe dans celui-ci. Dautres implmentations de la commande RECEIVE peuvent directement adresser lespace mmoire allou en interne par TCP au tampon de rception, ou encore mettre en place le partage dun tampon tournant par les deux partenaires. CLOSE Format: CLOSE (nom_local)

Cette commande demande la fermeture de la connexion spcifie. Si la connexion nexiste pas, ou lapplication na pas lautorisation ncessaire pour utiliser cette connexion, une erreur est renvoye. La fermeture de connexions est prvue pour se drouler de faon "propre" dans la mesure ou toutes les missions en instance seront menes leur terme (et retransmises si ncessaire),selon les impratifs du contrle de flux. Ainsi, il est lgitime de lancer plusieurs commandes SEND successives suivies dune commande CLOSE, et de considrer que le message a t correctement et compltement transmis. Il est aussi clair que la communication doit tre toujours "coute", afin de rcuprer tout ce que le distant a transmettre. De ce fait, la commande CLOSE signifie "je nai plus rien transmettre", et non pas "je ne veux plus rien recevoir". Il peut arriver (notamment si le protocole au niveau application nest pas suffisamment complet) que le ct fermant la connexion ne puisse se dbarrasser de toutes ses donnes avant intervention de la temporisation. Dans ce cas, la commande CLOSE revient une commande ABORT, et TCP finit le travail de fermeture. Lapplication doit pouvoir fermer la connexion tout moment de sa propre initiative, ou en rponse des signaux venant de TCP (ex. signal de dconnexion distante, temporisation de transmission coule, destination inaccessible). Comme la fermeture dune connexion demande un change avec le TCP distant, celle-ci peut rester dans ltat "encours de fermeture" (CLOSING) pendant un petit laps de temps. Toute tentative de rouverture de cette connexion avant que TCP nait pu rpondre la commande CLOSE gnrera une erreur. Lexcution dune commande CLOSE dclenche implicitement une fonction push. STATUS Format: STATUS (nom_local) -> tat Cette commande dpend de limplmentation et peut tre "oublie" sans consquence majeure. Linformation renvoye est essentiellement issue des donnes du TCB associ la connexion. Cette commande renvoie habituellement une structure de donnes comprenant les information suivantes: socket local, socket distant, nom local de la connexion, fentre en rception, fentre en mission, tat de la connexion, nombre de tampons attendant un acquittement, nombre de tampons en attente de rception, tat durgence, priorit, scurit/compartiment, temporisation de transmission courante. Suivant ltat courant de la connexion ou limplmentation, certaines de ces donnes ne peuvent tre obtenues, ou significatives. Si lapplication na pas lautorisation pour adresse cette connexion, une erreur est renvoye. Ceci permet dviter de diffuser des informations sur une connexion une application non autorise. ABORT Format: ABORT (nom_local) Cette commande abandonne toutes les commandes SEND et RECEIVE en cours. Le TCB est effac, et un message dabandon est envoy au TCP distant. Suivant limplmentation, lapplication recevra des indications en retour sur chacune des missions et rceptions abandonnes, ou simplement un acquittement global de labandon.

Messages TCP vers utilisateur Il est prvu que le systme dexploitation fournisse un moyen pour que TCP puisse signaler des vnements de faon asynchrone lapplication qui lutilise. Lorsque TCP envoie un tel signal, des informations y prennent place. Il arrivera souvent quon y trouve un statut derreur. Dans les autres cas, on y trouvera un rapport concernant le succs de telle ou telle commande SEND, RECEIVE, ou autre. Les information suivantes y apparaissent: nom local de connexion Libell de la rponse Adresse du tampon compteur (taille reue) Indicateur PUSH Indicateur URGENCE Interface TCP vers couche infrieure TCP effectue des appels vers une couche infrieure du protocole de communication, charge de "router" les segments. Les rseaux ARPAnet et Internet sappuient sur le protocole Internet (IP). Lorsque le protocole de niveau infrieur est I, TCP ajoute aux segments deux informations: le type de service et la dure de vie. TCP donne pour ces informations les valeurs suivantes: Type de service = Priorit: routine, Delay: normal, Dbit: normal, Fiabilit: normal; soit 00000000. Dure de vie = une minute, soit 00111100. Notez que la dure de vie maximale encodable pour un segment est de deux minutes. Par cette information, nous indiquons de manire explicite que tout segment doit tre dtruit sil na pas t achemin au bout dune minute. Si le protocole infrieur est IP (ou tout autre protocole disposant de cette fonction) et le "routage retour" (vers la source) est exploit, Linterface doit permettre de communiquer le chemin pris. Ceci est fondamental pour que les adresses source et destinataire utilises pour le dcodage du Checksum TCP soient bien les adresses originales de lmetteur et celle de lexpditeur (et non ladresse du dernier routeur par lequel a transit le message). Il est aussi important de garder la trace du chemin pour permettre dtablir la connexion inverse. Tout protocole sur lequel sappuiera TCP doit pouvoir fournir ladresse source, destinataire, les champs de protocole, et une faon de dterminer la longueur "TCP length", lesquels garantissent ainsi une compatibilit avec les services offerts par IP, et ncessaires au calcul du Checksum. Toujours Toujours SEND & RECEIVE RECEIVE RECEIVE RECEIVE

3.9. Traitement des vnements

Les procdures dcrites dans ce chapitre ne sont quun exemple dimplmentation possible. Dautres implmentations pourront sappuyer sur des squences diffrentes, mais seulement en dtail, et non dans lintention. Le principal de lactivit de TCP peut tre assimil comme la rponse des vnements. Les vnements pouvant survenir peuvent tre rpartis en trois catgories: commandes de lapplication, arrive de segments, et coulement de temporisations. Ce chapitre dcrit dans le dtail tout ce que TCP excute sur rception de chacun de ces vnements. Dans la plupart des cas, la raction de TCP dpendra de ltat de la connexion. Evnements susceptibles de survenir: Appels applicatifs Arrive dun segment Temporisations OPEN SEND SEGMENT ARRIVES USER TIMEOUT RETRANSMISSION TIMEOUT

RECEIVE STATUS CLOSE ABORT

TIME-WAIT TIMEOUT

Le modle choisi pour linterface TCP/application est celui o TCP rpond immdiatement la commande, quitte fournir un complment de rponse diffr par le biais dun vnement ou dune pseudo-interruption. Dans tout ce qui suit, on nommera "rponse" la rponse immdiate, et "signal" la rponse diffre. Les messages derreur sont indiqus sous leur forme explicite. Par exemple, une application mettant une commande pour une connexion inexistante recevra le message derreur "erreur: connexion inexistante". Notez que dans tout ce qui suit, larithmtique utilise pour les calculs sur les numros de squence, numros dacquittement, fentres, etc., est modulo 2**32 (la taille de lespace de numrotation). Notez que le symbole "=<" signifie infrieur ou gal modulo 2**32. Le traitement des segments entrants suppose quils ont t au pralable valids en termes de squence (cest--dire que leur plage de squence est effectivement incluse dans la fentre de transmission courante) et quils sont de ce fait empils, puis traits par ordre de squence. Lorsquun segment reu affiche une plage de squence qui recoupe celle dun segment prcdemment reu, nous reconstituons ce segment en ne gardant que les "nouvelles" donnes, et rajustons les paramtres de son en-tte en consquence. Notez enfin quen labsence dune mention explicite de changement dtat, TCP reste dans ltat o il tait avant lvnement. Commande OPEN Etat prcdent : CLOSED STATE (TCB inexistant) Crer un nouveau bloc de contrle de transmission (TCB) pour mmoriser les informations sur la connexion. Remplit lidentificateur du socket local, du socket distant, la priorit, la scurit/compartiment, et la temporisation "application". Certaines sous adresses du socket distant peuvent ne pas tre remplies lorsque la commande OPEN est excute en mode "passif". Celles-ci seront explicites lors de larrive dune requte de connexion via le rseau. Vrifie les autorisations systme pour la priorit et la scurit m si non autorise Rpondre "erreur: priorit non attribue" ou "erreur: scurit/compartiment non autoris". Retour Si passive, entre dans le mode LISTEN. Retour Si active, si le socket distant est non spcifi, ou "indfini", Rpondre "erreur: socket distant non spcifi". Retour si le socket distant est valide, Composer un segment SYN. Choisir un numro initial de squence (ISS). Emettre un segment SYN de forme <SEQ=ISS><CTL=SYN>. Renseigner SND.UNA par lISS, SND.NXT par ISS+1, Entrer en mode SYN-SENT. Retour

si lapplication na pas le droit daccs au socket spcifi, Rpondre "erreur: connexion illgale pour cette application". Retour si manque de mmoire pour crer la connexion, Rpondre "erreur: ressources insuffisantes ". Retour Etat prcdent : LISTEN Si active Si le socket distant est spcifi, Changer la connexion de passive active. Choisir un ISS. Envoyer un segment SYN. Renseigner SND.UNA par lISS, SND.NXT par ISS+1. Entrer dans ltat SYN-SEN. Des donnes arrives par une premire commande SEND peuvent tre envoyes dans le segment SYN ou empiles pour transmission aprs passage ltat ESTABLISHED. Le bit URG doit tre marqu si spcifi dans le premire commande SEND. Retour Si manque de mmoire pour empiler cette commande, Rpondre "erreur: ressources insuffisantes". Retour Si le socket distant non spcifi ou "indfini", Rpondre "erreur: socket distant non spcifi". Retour Etats prcdents : 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 Rpondre "erreur: la connexion existe dj". Retour Commande SEND Etat prcdent : CLOSED STATE (TCB inexistant) Si lapplication na pas lautorisation daccs cette connexion, Rpondre "erreur: connexion illgale pour cette application". Retour Autrement Rpondre "erreur: connexion inexistante". Retour Etat prcdent : LISTEN Si manque de mmoire pour empiler les donnes, Rpondre "erreur: ressources insuffisantes". Retour Si le socket distant non spcifi ou "indfini" Rpondre "erreur: socket distant non spcifi". Retour

Si le socket distant est spcifi, Passer la connexion de ltat passif actif. Choisir un ISS. Emettre un segment SYN. Renseigner SND.UNA par lISS, SND.NXT par ISS+1. Entrer dans ltat SYN-SENT. Les donnes jointes peuvent tre envoyes dans le segment SYN ou empiles pour transmission aprs passage ltat ESTABLISHED. Le bit URG doit tre marqu si spcifi dans le premire commande SEND. Retour Etats prcdents : SYN-SENT STATE, SYN-RECEIVED STATE Si manque de mmoire pour empiler les donnes, Rpondre "erreur: ressources insuffisantes". Retour Sinon Empiler les donnes pour transmission une fois ltat ESTABLISHED tabli. Retour Etats prcdents : ESTABLISHED STATE, CLOSE-WAIT STATE Si manque de mmoire pour conserver les donnes, Rpondre "erreur: ressources insuffisantes". Retour Segmenter le tampon et lenvoie avec un acquittement (valeur = RCV.NXT). Si lindicateur URGENT est marqu, alors SND.UP <- SND.NXT-1 et le pointeur durgence est activ dans les segments sortants. Retour Etats prcdents : FIN-WAIT-1 STATE, FIN-WAIT-2 STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE Rpondre "erreur: connexion en fermeture" et ignorer les requtes ultrieures. Commande RECEIVE Etat prcdent : CLOSED STATE (TCB inexistant) Si lapplication na pas lautorisation daccs cette connexion, Rpondre "erreur: connexion illgale pour cette application". Retour Autrement Rpondre "erreur: connexion inexistante". Retour Etats prcdents : LISTEN STATE, SYN-SENT STATE, SYN-RECEIVED STATE Si manque de mmoire pour empiler cette requte, Rpondre "erreur: ressources insuffisantes". Retour Empiler la requte pour traitement une fois ltat ESTABLISHED tabli. Etats prcdents : ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE

Si un nombre insuffisant de segments sont arrivs, Empiler la requte. Retour Si manque de mmoire pour empiler cette requte, Rpondre "erreur: ressources insuffisantes". Retour Rassembler les segments empils dans le tampon de rception et donner la rponse lapplication. Marquer "push seen" (PUSH) le cas chant. Si RCV.UP pointe sur des donnes non encore reues, notifier lapplication de la prsence de donnes urgentes. Lorsque TCP prend la responsabilit de passer des donnes lapplication, il doit envoyer un acquittement lmetteur. La construction de cet acquittement est traite ci-aprs aux paragraphes concernant larrive dun segment. Etat prcdent : CLOSE-WAIT STATE Comme le distant a dj envoy son segment FIN, la commande passe lapplication les donnes encore stockes par TCP. Si plus aucune donne nest dlivrer, Rpondre "erreur: dconnexion en cours". Retour Autrement toute les donnes restantes sont utilisables pour satisfaire la requte. Etats prcdents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE Rpondre "erreur: dconnexion en cours". Retour Commande CLOSE Etat prcdent : CLOSED STATE (TCB inexistant) Si lapplication na pas lautorisation daccs cette connexion, Rpondre "erreur: connexion illgale pour cette application". Retour Autrement Rpondre "erreur: connexion inexistante". Retour Etat prcdent : LISTEN Toute requte RECEIVE empile provoque une sortie derreur Rpondre "erreur: dconnexion". Effacer le TCB. Passer la connexion ltat CLOSED. Retour Etat prcdent : SYN-SENT STATE Efface le TCB et retourne "erreur: dconnexion" pour chaque requte SEND ou RECEIVE latente. Etat prcdent : SYN-RECEIVED STATE

Si aucune commande SEND na t lance et quil ne reste plus de donnes transmettre Constituer un segment FIN et lmettre Passer dans ltat FIN-WAIT-1 Retour. Autrement Empiler la requte en attente de passage dans ltat ESTABLISHED. Retour. Etat prcdent : ESTABLISHED STATE Place la requte en attente, le temps de segmenter toutes les requtes SEND en attente Forme un segment FIN et lenvoie. Passe la connexion ltat FIN-WAIT-1 dans tous les cas. Etats prcdents : FIN-WAIT-1 STATE, FIN-WAIT-2 STATE Strictement parlant, il sagit dune erreur et devrait provoquer une sortie "erreur: dconnexion en cours". Une rponse "OK" serait aussi bien acceptable, jusqu ce que le deuxime FIN soit mis (le premier segment Fin peut encore tre retransmis). Etat prcdent : CLOSE-WAIT STATE Placer la requte en attente, le temps de segmenter toutes les requtes SEND en attente, Former un segment FIN et lenvoie. Passer la connexion ltat CLOSING. Retour. Etats prcdents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE Retourner "erreur: dconnexion en cours". Retour. Commande : ABORT Etat prcdent : CLOSED STATE (TCB inexistant) Si lapplication na pas dautorisation daccs cette connexion, Rpondre "erreur: connexion illgale pour cette application". Retour. Autrement Rpondre "erreur: connexion inexistante". Retour. Etat prcdent : LISTEN Toute requte RECEIVE en attente recevra un signal "erreur: abandon" en rponse. Effacer le TCB. Passer la connexion ltat CLOSED. Retour. Etat prcdent : SYN-SENT STATE

Toute requte SEND ou RECEIVE en attente recevra un signal "erreur: abandon" en rponse. Effacer le TCB. Passer la connexion ltat CLOSED. Retour. Etats prcdents : SYN-RECEIVED STATE, ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE, CLOSE-WAIT STATE Envoyer un segment de rinitialisation: <SEQ=SND.NXT><CTL=RST> Toute requte SEND ou RECEIVE en attente recevra un signal "erreur: abandon" en rponse. Librer tous les tampons lis aux commandes RECEIVE et SEND en attente, Supprimer les segments constitus except le segment RST ci-dessus. Effacer le TCB. Passer la connexion dans ltat CLOSED. Retour Etat prcdent : CLOSING STATE, LAST-ACK STATE, TIME-WAIT STATE Rpondre "OK" Effacer le TCB, Passer la connexion en mode CLOSED. Retour. Commande STATUS Etat prcdent : CLOSED STATE (TCB inexistant) Si lapplication na pas dautorisation daccs cette connexion, Rpondre "erreur: connexion illgale pour cette application". Retour. Autrement Rpondre "erreur: connexion inexistante". Retour. Etat prcdent : LISTEN Renvoie "tat = LISTEN", et un pointeur sur le TCB. Retour Etat prcdent : SYN-SENT STATE Renvoie "tat = SYN-SENT", et un pointeur sur le TCB. Retour Etat prcdent : SYN-RECEIVED STATE Renvoie "tat = SYN-RECEIVED", et un pointeur sur le TCB. Retour Etat prcdent : ESTABLISHED STATE Renvoie "tat = ESTABLISHED", et un pointeur sur le TCB. Retour Etat prcdent : FIN-WAIT-1 STATE Renvoie "tat = FIN-WAIT-1", et un pointeur sur le TCB. Retour

Etat prcdent : FIN-WAIT-2 STATE Renvoie "tat = FIN-WAIT-2", et un pointeur sur le TCB. Retour Etat prcdent : CLOSE-WAIT STATE Renvoie "tat = CLOSE-WAIT", et un pointeur sur le TCB. Retour Etat prcdent : CLOSING STATE Renvoie "tat = CLOSING", et un pointeur sur le TCB. Retour Etat prcdent : LAST-ACK STATE Renvoie "tat = LAST-ACK", et un pointeur sur le TCB. Retour Etat prcdent : TIME-WAIT STATE Renvoie "tat = TIME-WAIT", et un pointeur sur le TCB. Retour Arrive rseau : SEGMENT ARRIVES Etat prcdent : CLOSED (cest--dire, TCB nexiste pas) Toutes les donnes du segment sont ignores. Un segment RST est ignor.. Un segment autre que RST entrane lmission dun segment RST en rponse. Le numro de squence et laccus de rception sont renseigns de faon ce que le segment soit acceptable par le TCP qui a envoy le segment erron. Si le bit ACK nest 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 prcdent : LISTEN

1. Vrifier le marquage du bit RST

Un segment RST entrant sera ignor. Retour.

2. Vrifier le marquage du bit ACK

Un accus de rception reu par une connexion ltat LISTEN reprsente 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. Vrifier le marquage de SYN Si le bit SYN est marqu, vrifier la scurit: Si la donne de scurit/compartiment sur le segment entrant ne correspond pas exactement celle marque dans le TCB, Envoi dun segment RST au distant. : [SEQ=SEG.ACK][CTL=RST] Retour. Si SEG.PRC est suprieur TCB.PRC (test de priorit) si non autoris, envoi dun segment RST: [SEQ=SEG.ACK][CTL=RST]. Retour. si autoris par le systme et lapplication TCB.PRC<-SEG.PRC.

3.

4.

Continuer Si SEG.PRC est infrieur TCB.PRC Continuer. Renseigner RCV.NXT par SEG.SEQ+1, IRS par SEG.SEQ tous les autres contrles et donnes doivent tre empils pour traitement ultrieur. 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 ltat SYN-RECEIVED. Tous les autres contrle ou donnes seront examins et traits dans ltat SYN-RECEIVED, sauf SYN et ACK qui auront dj t traits. Si la connexion tait totalement ou partiellement indfinie, la connexion est alors explicite ce moment. Autres donnes et contrles Tout autre contrle ou segments portant des donnes (sans SYN) sont ncessairement marqus en tant que ACK et seront donc carts 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 prcdent : SYN-SENT

1. vrifier 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 mme un RST auquel cas il doit tre ignor et Retour) [SEQ=SEG.ACK][CTL=RST] dtruire le segment. Retour. Si SND.UNA =< SEG.ACK =< SND.NXT lacquittement est acceptable.

2. Vrifier le marquage du bit RST

Si RST est marqu Si lacquittement est conforme, avertir lapplication par "erreur: abandon distant", dtruire le segment, passer la connexion en tat CLOSED, effacer le TCB Retour. Sinon (non ACK) Ignorer le segment. Retour.

Vrifier la scurit et la priorit Si la valeur de scurit compartiment ne correspond pas celle inscrite dans le TCB, Si ACK est marqu Envoi dun RST : [SEQ=SEG.ACK][CTL=RST] Sinon Envoi dun 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 dun segment RST: [SEQ=SEG.ACK][CTL=RST] sinon Si la priorit du segment est suprieure celle inscrite dans le TCB et

si le systme et lapplication le permettent, remonter la priorit de la connexion inscrite dans le TCB au niveau de celle trouve dans le segment Si il nest 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 infrieure celle inscrite dans le TCB continuer. Si un RST a t envoy, dtruire le segment Retour.

3. Vrifier le marquage du bit SYN

Cette tape ne peut tre atteinte que si lACK est valide, ou il ne sagit pas dun ACK ni dun segment RST. Si le bit SYN est marqu et les conditions de scurit/compartiment et priorit sont vrifies RCV.NXT prend la valeur SEG.SEQ+1, IRS prend la valeur SEG.SEQ. Si ACK est marqu : SND.UNA est incrment jusqu la valeur SEG.ACK tous les segments de la pile de retransmission qui ont de ce fait t acquitts sont supprims. Si SND.UNA > ISS (notre propre SYN a t acquitt), passer la connexion ltat ESTABLISHED, Emettre laccus de rception [SEQ=SND.NXT][ACK=RCV.NXT][CTL=ACK] Les donnes et contrles en attente dans la pile dmission peuvent tre transmis dans ce segment. Si des donnes sont contenues dans le segment Aller au pas 6 ci-aprs, o le bit URG est vrifi, Sinon Retour. Autrement (notre SYN nest 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 lenvoyer. Si dautres contrles ou donnes sont prsentes dans le segment, les empiler en attendant le passage ltat ESTABLISHED. Retour. Si aucun des bits SYN ou RST nest marqu rejeter le segment Retour. Autrement, Etats prcdents : 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 numro de squence

Les segments sont traits dans lordre de la squence. Les premiers tests servent liminer les anciennes donnes dupliques, les traitements suivants sont faits selon lordre des SEG.SEQ. Si segment transporte des donnes dont une partie est ancienne et lautre nouvelle, seule la partie nouvelle sera prise en compte. Il y a quatre cas dacceptabilit des segments: Longueur du Segment ------0 0 >0 >0 Fentre de Rception ------0 >0 0 >0 Test ---------------------------------------SEG.SEQ = RCV.NXT RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND non acceptable RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

Si RCV.WND vaut zro, aucun segment ne peut tre accept, mais des drogations doivent tre prvues pour des segments ACK, URG et RST valides. Si le segment nest pas acceptable, sil sagit dun 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 dun segment "idal" de premier numro de squence RCV.NXT et dont la longueur nexcde pas la largeur de la fentre. Il serait possible, si cette longueur tait suprieure, de dcouper ce segment en deux parties, lune de longueur gale la largeur fentre (y compris pour les segments SYN et FIN), et traiter le segment commenant RCV.NXT. Lautre partie "hors fentre" serait alors empile pour traitement ultrieur.

2. Vrifier le bit RST, Etat prcdent : SYN-RECEIVED STATE

Si le bit RST est marqu Si louverture de connexion tait passive (cest--dire, tait passe par un tat LISTEN) Retourne la connexion ltat passif LISTEN. Lapplication nen est pas ncessairement avise. Si louverture de la connexion tait active (cest--dire, tant passe par ltat SYN-SENT) alors la requte de connexion a t refuse par le distant. TCP signale lapplication "Connexion rejete". Passer la connexion ltat CLOSED Supprimer le TCB. Dans les deux cas, Supprimer tous les segments de la pile de retransmission. Retour. Etats prcdents : 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. Lapplication peut de plus recevoir un signal "abandon" global. Passer la connexion ltat CLOSED, Supprimer le TCB. Retour. Etats prcdents : CLOSING STATE, LAST-ACK STATE, TIME-WAIT Si le bit RST est marqu Passer la connexion ltat CLOSED Supprimer le TCB Retour.

3. Vrifier la scurit et la priorit

Etat prcdent : SYN-RECEIVED Si la valeur de scurit/compartiment ne correspond pas exactement celle inscrite dans le TCB, mettre un segment RST Retour. Etat prcdent : ESTABLISHED STATE Si la valeur de scurit/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. Lapplication peut de plus recevoir un signal "abandon" global. Passer la connexion ltat CLOSED, Supprimer le TCB. Retour. Notez que ce test est plac aprs le test de squence, afin dviter quun segment dune ancienne connexion entre ces deux ports, avec un niveau de priorit et de scurit distinct ne vienne provoquer labandon intempestif de la connexion courante.

4. Vrifier le bit SYN

Etats prcdents : 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 fentre, ce ne peut tre quune erreur, Emettre un RST, Signaler "erreur : abandon" pour toute commande SEND ou RECEIVE en instance. Vider toutes les piles internes. Lapplication peut de plus recevoir un signal "abandon" global. Passer la connexion ltat CLOSED Supprimer le TCB Retour. Le cas o le segment SYN nest pas dans la fentre correspond celui o un ACK a t renvoy dans le premier pas (vrification des numros de squence).

5. Vrifier le marquage du bit ACK

Si le bit ACK nest pas marqu Jeter le segment Retour. Si le bit ACK est marqu Etat prcdent : SYN-RECEIVED STATE Si SND.UNA =< SEG.ACK =< SND.NXT Passer la connexion ltat ESTABLISHED continuer Si laccus de rception nest pas acceptable, Emettre un RST : [SEQ=SEG.ACK][CTL=RST] Etat prcdent : ESTABLISHED STATE Si SND.UNA < SEG.ACK =< SND.NXT SND.UNA = SEG.ACK. Retirer de la pile de retransmission tous les segments acquitts. Renvoyer un signal daquittement lapplication pour chaque commande SEND compltement envoye et acquitte (en renvoyant le tampon SEND avec la mention "OK"). Si le segment ACK est un doublon (SEG.ACK < SND.UNA) Ignorer le segment Si laccus de rception acquitte des donnes non encore mises (SEG.ACK > SND.NXT) Emettre un ACK Jeter le segment Retour. Si SND.UNA < SEG.ACK =< SND.NXT, Remettre jour la fentre dmission 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 reprsente un dcalage relatif par rapport SND.UNA, que SND.WL1 enregistre le numro de squence du dernier segment ayant servi remettre SND.WND jour, et que SND.WL2 enregistre le numro dacquittement du dernier segment ayant permis de remettre SND.WND jour. Ce test permet dviter de considrer des segments "anciens" pour remettre jour la fentre. Etat prcdent : FIN-WAIT-1 STATE En plus du traitement effectu pour ltat ESTABLISHED, Si le segment FIN mis (local) a t acquitt Passer la connexion ltat FIN-WAIT-2 Continuer dans cet tat. Etat prcdent : FIN-WAIT-2 STATE En plus du traitement effectu pour ltat ESTABLISHED, Si la pile de retransmission est vide La commande CLOSE de lapplication peut tre acquitte ("OK"), mais le TCB doit rester en place.

Etat prcdent : CLOSE-WAIT STATE Id. ESTABLISHED. Etat prcdent : CLOSING STATE En plus du traitement effectu pour ltat ESTABLISHED, Si le segment ACK acquitte le segment FIN mis (local) Passer la connexion ltat TIME-WAIT Sinon Ignorer le segment. Etat prcdent : LAST-ACK STATE Le seul vnement attendu dans cet tat est lacquittement de notre segment FIN. Ds que cet vnement se produit, Supprimer le TCB, Passer la connexion ltat CLOSED Retour. Etat prcdent : TIME-WAIT STATE Le seul segment attendu dans cet tat est la retransmission du segment FIN distant. Ds que cet vnement se produit, Lacquitter Relancer la temporisation de 2 MSL. Retour.

6. Vrifier le bit URG

Etats prcdents : 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 donnes non consommes Si lapplication nest pas dj dans le mode "urgent" Signaler lapplication la prsence de donnes urgentes. Etats prcdents : CLOSE-WAIT STATE, CLOSING STATE, LAST-ACK STATE, TIME-WAIT Ce cas ne devrait pas se produire, car un segment FIN a t reu du distant. Ignorer lURG.

7. Rcuprer les donnes,

Etats prcdents : ESTABLISHED STATE, FIN-WAIT-1 STATE, FIN-WAIT-2 STATE Une fois la connexion entre dans ltat ESTABLISHED, il est possible de livrer des donnes dans les tampons RECEIVE de lutilisateur. Les donnes peuvent tre extraites du segment et ranges dans le tampon jusqu ce que celui-ci soit plein, ou le segment soit vide. Si le segment est vide (moins de donnes arrives que despace libre dans le tampon) et que le flag PUSH est marqu, alors lapplication en est informe lorsque le tampon lui

est renvoy. Lorsque TCP prend la responsabilit de transmettre des donnes vers lutilisateur, il est suppos acquitter la rception de ces donnes. Une fois que TCP a pris cette responsabilit, il doit avancer RCV.NXT du nombre doctets accepts, et ajuste RCV.WND de faon tenir compte de lespace de tampon restant. La somme de RCV.NXT et RCV.WND ne peut tre rduit. Reportez vous aux suggestions sur la gestion de fentre au paragraphe 3.7. Envoyer un accus de rception sous la forme: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> Cet accus de rception pourra profiter de la transmission dun segment dmission, dans la mesure o cela nengendre pas un retard trop important. Etats prcdents : 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 reu du ct distant. Ignorer les donnes du segment dans ce cas.

8. vrifier le bit FIN,

Ne traitez pas le bit FIN si ltat 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 lapplication "dconnexion 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 dlivr lapplication. Etats prcdents : SYN-RECEIVED STATE, ESTABLISHED STATE Passer dans ltat CLOSE-WAIT. Retour. Etat prcdent : FIN-WAIT-1 STATE Si notre propre FIN a t acquitt (peut tre dans ce segment), alors Passer dans ltat TIME-WAIT, Amorcer la temporisation dattente Arrter toutes les autres temporisations; Retour. Sinon Passer dans ltat CLOSING. Etat prcdent : FIN-WAIT-2 STATE Passer dans ltat TIME-WAIT. Amorcer la temporisation dattente

Arrter toutes les autres temporisations; Retour. Etat prcdent : CLOSE-WAIT STATE Reste dans ltat CLOSE-WAIT. Etat prcdent : CLOSING STATE Reste dans ltat CLOSING. Etat prcdent : LAST-ACK STATE Reste dans ltat LAST-ACK. Etat prcdent : TIME-WAIT STATE Reste dans ltat TIME-WAIT. Relance de 2 MSL la temporisation. Retour. Temporisation : USER TIMEOUT Dans tous les tats, si la temporisation utilisateur scoule compltement, Vider toutes les piles Renvoyer "erreur: abandon sur non rponse" lapplication, en gnral, et pour chacune des commandes en instance. Supprimer le TCB Passer ltat 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 tte de pile. Rinitialiser la temporisation Retour. Temporisation : TIME-WAIT TIMEOUT Lorsque la temporisation dattente de dconnexion expire, Supprimer le TCB Passer dans ltat CLOSED Retour.

GLOSSAIRE
1822 BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". La spcification de linterface entre un ordinateur et ARPAnet. Accus de rception

Le numro de squence indiqu dans le champ daccus de rception du segment entrant. ACK

Un bit de contrle (acquittement) ne consommant pas despace squence, indiquant que le champ daccus de rception de ce segment indique le prochain numro de squence attendu par lmetteur de ce segment, acquittant implicitement tous lespace de squence infrieur ce nombre.
Adresse de destination Ladresse de destination spcifie le numro de la "branche" de rseau et le numro de lordinateur cible sur cette branche. Adresse source Ladresse Internet de la source, constitue dune adresse rseau et de ladresse de lordinateur sur ce rseau. ARPAnet, message Lunit de transmission entre un ordinateur et un IMP dARPAnet. La taille maximale du message est denviron 1012 octets (8096 bits). ARPAnet, paquet Unit de transmission utilise sur ARPAnet entre IMP. La taille maximale du paquet est de 126 octets (1008 bits). Connexion Une communication logique dfinie par une paire de sockets. Datagramme Un message envoy sur un rseau de transmission de donnes commutation de paquets. Fentre dmission Reprsente la plage de squence que le TCP distant est prt recevoir. Elle correspond la valeur de fentre reue dans les segments transmis par le TCP distant. La plage de numro de squence quil est possible dmettre est ncessairement incluse dans lintervalle [SND.NXT, SND.UNA + SND.WND - 1] et, en gnral commence sur SND.NXT. (Les retransmissions de segments dans une plage de SND.UNA SND.NXT sont bien entendu accepts). Fentre de rception Reprsente la plage de numros de squence (en rception) que TCP sattend recevoir. Ainsi, tout segment dont la plage est incluse dans lintervalle [RCV.NXT, RCV.NXT + RCV.WND - 1] est recevable. Tout segment dont la plage est intgralement en dehors de cet intervalle est suppos tre un doublon et est rejet. FIN Un bit de contrle (finis) occupant consommant un numro de squence, indiquant que lmetteur nenverra plus de donnes ni de contrles occupant de lespace de squence. Fragment

Une portion dune unit de transmission de donnes, en particulier, un fragment Internet est une portion dun datagramme Internet. FTP Protocole de transfert de fichiers. Header (en-tte) Ensemble dinformations de contrle plac en tte dun datagramme, segment, fragment, paquet ou bloc de donnes. Host Un ordinateur. Peut tre source ou destination du point de vue dun rseau de donnes. On distingue les Hosts des stations de travail ou terminaux, lesquels ne sont pas autonomes et ncessitent justement les ressources dun Host. Identification Un champ du protocole IP. Cette valeur didentification aide recomposer les fragments dun mme datagramme. IMP Interface Message Processor, le "routeur" du rseau ARPAnet. Internet, adresse Une adresse de 32 bits spcifiant ladresse unique dun host sur un rseau. Internet, datagramme Lunit dchange de donnes entre la couche Internet et les couches suprieures comprenant len-tte Internet. Internet, fragment Une portion dun datagramme Internet complt dune en-tte Internet. IP Protocole Internet IRS Initial Receive Sequence. Le tout premier numro de squence attendu par un rcepteur. ISN Initial Sequence Number. Le premier numro de squence utilis lors dune connexion, (ISS ou IRS). Choisi en fonction dune horloge. ISS Initial Send Sequence. Le tout premier numro de squence mis par un metteur. Leader (en-tte)

Information de contrle plac en tte dun bloc de donnes. En particulier, dans ARPAnet, linformation de contrle de message ARPAnet la hauteur de linterface host/IMP. Longueur de segment La plage de numro de squence transmise par le segment, y compris les numros consomms par certains bits de contrle. Module Limplmentation, gnralement logicielle, dune fonction particulire. MSL Maximum Segment Lifetime, Le temps pendant lequel un segment TCP peut exister lintrieur du rseau de transmission. Arbitrairement : 2 minutes. Numro de squence Un index numrique servant identifier un octet de donnes dans le flux de transmission. Cet index est calcul sur 32 bits, et reboucle modulo 2**32. Octet Huit bits. Options Un champ doption peut en contenir plusieurs, chacune des options pouvant avoir une longueur de plusieurs octets. Les options sont lorigine utilises pour des fonctions de test; par exemple, pour vhiculer des tiquettes temporelles. Les deux protocoles Internet Protocol et TCP disposent de champs doption. Paquet Un paquet est un terme trs gnral dsignant trs exactement une section dun flux de donnes encapsul dans divers protocoles. En gnral, on parlera de paquet une entit physique, plutt que logique. Mais lusage fait utiliser ce terme dans le cas le plus gnral. Paquet local Lunit de transmission dans un rseau local. Pointeur de donnes urgentes Un champ de contrle qui na de signification que lorsque le bit URG est marqu. Ce champ communique le numro de squence du dernier octet urgent sur rception duquel lapplication pourra repasser en mode "normal". Port La portion dun socket qui dfinit lentre ou la sortie "logique" quutilise un processus pour vhiculer ses donnes. Processus Un programme en cours dexcution. Une source ou destination, du point de vue du rseau ou de toute autre protocole

de communication "host-to-host". PUSH Un bit de contrle ne consommant pas despace squence, indiquant que ce segment contient des donnes transfrer immdiatement lutilisateur. RCV.NXT Prochain numro de squence recevoir. RCV.UP Pointeur de donnes urgentes. RCV.WND Fentre de rception RST Un bit de contrle (reset) ne consommant pas despace squence, indiquant au rcepteur que celui-ci doit abandonner la connexion sans autre interaction ultrieure. Le rcepteur doit dterminer, selon le numro de squence et la valeur de laccus de rception, sil doit prendre en compte cette demande ou lignorer. En aucun cas la rception dun segment RST nentrane une rponse du type RST. RTP Real Time Protocol: un protocole de communication inter-processus pour la transmission de donnes contraintes temporelles fortes. SEG.ACK Accus de rception du segment. SEG.LEN Longueur du segment. SEG.PRC Valeur de priorit du segment. SEG.SEQ Squence du segment. SEG.UP Pointeur de donnes urgentes du segment. SEG.WND Fentre dans le segment.

Segment Une unit logique de base, un segment TCP est lunit de transmission entre deux agents TCP. Squence dmission Prochain numro de squence mis par lmetteur. Il est initialis par une fonction gnratrice renvoyant un numro de squence initial (ISN) et est incrment pour chaque octet ou bit de contrle (certains seulement) mis. Squence gauche Le prochain numro de squence tre acquitt par le TCP rcepteur (ou le numro dacquittement courant le plus bas) parfois rfrenc comme le bord gauche de la fentre de transmission. SND.NXT Squence lmission. SND.UNA Numro de squence du premier octet non acquitt. SND.UP Pointeur de donnes urgentes lmission. SND.WL1 Numro de squence du dernier segment ayant servi remettre jour linformation de fentre. SND.WL2 Numro dacquittement du dernier segment ayant servi remettre jour linformation de fentre. SND.WND Fentre dmission. Socket Une adresse rseau constitue par la concatnation dune adresse Internet avec un numro de port TCP. SYN Un bit de contrle consommant un numro de squence, utilis pendant la phase dinitialisation de la connexion pour indiquer quel numro de squence la transmission de donnes dbute. TCB Transmission Control Block. La structure de donnes enregistrant les paramtres dune connexion. TCB.PRC

Le niveau de priorit dune connexion. TCP Transmission Control Protocol: Un protocole de communication inter-processus fiabilis dans un environnement multirseaux. TOS Type Of Service. Un champ IP indiquant le type de service du fragment IP. URG Un bit de contrle ne consommant pas despace squence, utilis pour indiquer que des donnes urgentes sont transportes par le segment. Lapplication rceptrice doit en tre informe, basculer en mode "durgence", et y rester tant que le numro de squence des donnes reste infrieur la valeur du pointeur de donnes 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.