Les protocoles de transport

Le service fourni par IP n’étant pas fiable, il faut implanter par-dessus un protocole supplémentaire, en fonction de la qualité de service dont les applications ont besoin. Pour les échanges de données exigeant une grande fiabilité, le protocole de transport TCP (Transmission Control Protocol ) est utilisé. Pour ceux qui ne nécessitent pas une telle fiabilité, un protocole de transport plus simple, appelé UDP (User Datagram Protocol) fournit un service de bout en bout en mode sans connexion. Avant de décrire les protocoles TCP et UDP, nous allons voir les notions qui leur sont communes. Le protocole de transport, greffé au-dessus d’IP, est choisi en fonction de la qualité de service souhaitée par l’application. Celle-ci choisira l’un des deux protocoles disponibles : TCP, si elle souhaite une grande fiabilité de l’échange des données, ou UDP si elle ne souhaite pas être ralentie par la gestion des services assurant l’intégrité des données. Les deux diffèrent par bien des aspects mais utilisent des concepts communs, notamment les notions de ports, de sockets et de total de contrôle. .

Architecture des réseaux

Notions utilisées dans les protocoles de transport Un protocole de transport offre aux applications situées sur la machine de l’utilisateur une interface leur permettant d’utiliser les services offerts par le ou les réseaux physiques sousjacents. Comme plusieurs applications sont susceptibles d’accéder au réseau, il faut les identifier sans ambiguïté ; on utilise pour cela la notion de port. Par ailleurs, les extrémités qui échangent des données sont repérées grâce à la notion de socket. Un protocole de transport souhaite en outre s’assurer que l’en-tête contenant les informations nécessaires à la gestion du protocole n’a pas été altéré au cours de la transmission. Il emploie à cette fin des techniques de redondance appelées total de contrôle (ou checksum). 1.1 NOTION DE PORT Les identifiants d’application sont indispensables, car plusieurs applications différentes peuvent s’exécuter simultanément sur la même machine. Un protocole de transport doit donc savoir pour qui il travaille ! L’identifiant d’application est appelé numéro de port – ou port – (ce qui n’a rien à voir avec les ports d’un commutateur). Selon les systèmes d’exploitation, le numéro de port peut correspondre au PID (Process Identifier), l’identifiant du processus qui s’exécute sur la machine. Il existe des milliers de ports utilisables, puisque le numéro de port tient sur 16 bits. Une affectation officielle des ports a été définie par l’IANA (Internet Assigned Numbers Authority), afin d’aider à la configuration des réseaux. Parmi ceux-ci, les ports 0 à 1023 sont les ports bien connus ou réservés (well known ports), affectés aux processus système ou aux programmes exécutés par les serveurs. Les systèmes d’exploitation diffèrent dans leur affectation pour les identificateurs des autres processus. Ils choisissent a priori les grands numéros. Le tableau 7.1 cite quelques numéros de port bien connus

INTERFACE ENTRE LE PROTOCOLE DE TRANSPORT ET L’APPLICATION

Les applications ayant le choix du protocole de transport (TCP ou UDP), le système d’exploitation doit utiliser un système de nommage qui affecte un identifiant unique, appelé socket1 , à tout processus local utilisant les services d’un protocole de transport. Le socket est constitué de la paire : < adresse IP locale, numéro de port local >. Pour identifier de manière unique l’échange de données avec le processus applicatif distant, le protocole de transport utilise un ensemble de cinq paramètres formé par le nom du protocole utilisé, le socket local et le socket distant : < protocole, adresse IP locale, numéro de port local ; adresse IP distante, numéro de port distant >. 

TOTAL DE CONTRÔLE OU CHECKSUM

Un total de contrôle est une information de redondance permettant de contrôler l’intégrité d’un bloc d’informations défini. Le calcul effectué est en général plus simple que celui décrit au chapitre 2 ; il s’agit, le plus souvent, d’une simple addition sans report des bits du bloc (un OU exclusif), suivie éventuellement d’une complémentation bit à bit du résultat précédent. Dans TCP ou dans UDP, le total de contrôle est un champ de 16 bits incorporé dans l’en-tête. Sa position dépend du protocole de transport utilisé. 2 Protocole TCP (Transmission Control Protocol) TCP comble les carences d’IP lorsque les applications requièrent une grande fiabilité. Ce protocole de transport, lourd et complexe, met en œuvre la détection et la correction d’erreurs, gère le contrôle de flux et négocie les conditions du transfert des données entre les deux extrémités de la connexion. L’entité gérée par le protocole TCP s’appelle le segment. Une fois le segment fabriqué, le module TCP sollicite le module IP pour le service de transmission, par l’intermédiaire de la primitive que nous avons vue au chapitre précédent : Requête_émission (segment, adresse IP distante), dans laquelle les deux paramètres fournis sont le segment à émettre et l’adresse IP de destination. (Dans la pratique, plusieurs autres paramètres sont également fournis, mais nous nous intéressons ici au principe de fonctionnement.) À l’inverse, lorsque le module IP reçoit un datagramme destiné à la machine concernée et que celui-ci transporte un segment TCP, le module IP extrait le segment du datagramme et en signale l’arrivée au module TCP par la primitive : Indication_réception (segment reçu, adresse IP source). L’interface entre la couche TCP et la couche IP est très simple, celle entre la couche TCP et l’application utilisatrice est beaucoup plus complexe. Nous la détaillerons plus loin, après avoir vu le format du segment TCP et la vie d’une connexion. 1. Nous avons conservé ce terme anglais car aucun équivalent français n’est utilisé. 178 Architecture des réseaux 2.1 DIALOGUE DE BOUT EN BOUT À la demande des applications qui ont besoin d’échanger des données de manière fiable, TCP ouvre une connexion et gère un dialogue. TCP n’est implanté que sur les machines des utilisateurs, c’est-à-dire qu’il n’est pas géré par les systèmes intermédiaires (ponts, commutateurs et autres routeurs du réseau). Il est défini dans la RFC 793 et s’occupe de gérer et de fiabiliser les échanges, alors qu’IP est responsable de la traversée des différents réseaux. TCP permet à deux utilisateurs d’avoir une vision de bout en bout de leurs échanges, quels que soient l’interconnexion de réseaux sous-jacente et le chemin par lequel IP a fait passer les données. Pour apporter la fiabilité dont les utilisateurs ont besoin, TCP gère un contexte de l’échange (l’ensemble des paramètres choisis et négociés par les deux utilisateurs pour leur dialogue, ainsi que l’ensemble des paramètres temporels liés à l’état du dialogue). Le contexte est mémorisé dans le module TCP des deux interlocuteurs. Ce protocole fonctionnant en mode connecté, les deux modules TCP doivent être opérationnels simultanément. En outre, il faut que l’une des extrémités ait sollicité l’autre et que cette dernière ait répondu positivement. On parle de la vie de la connexion pour décrire tous les événements qui s’y produisent. 2.2 FONCTIONNALITÉS DE TCP TCP est capable de détecter les datagrammes perdus ou dupliqués et de les remettre dans l’ordre où ils ont été émis. Ce service repose sur la numérotation et l’acquittement des données et utilise une fenêtre d’anticipation. Remarquons dès à présent que la numérotation des données dans TCP s’effectue octet par octet, alors que les protocoles définis dans le modèle OSI numérotent les unités de données du niveau concerné. TCP considère les données transportées comme un flot non structuré d’octets. Une connexion étant a priori bidirectionnelle, les deux flots de données sont traités indépendamment l’un de l’autre. Le flot géré par chaque module concerne les octets de données compris dans une zone délimitée nommée fenêtre, dont la taille est définie par un entier de 16 bits, ce qui la limite a priori à 65 535 octets. Chaque module TCP annonce la taille de son tampon de réception à l’ouverture de la connexion. Il est convenu que l’émetteur n’envoie pas plus de données que le récepteur ne peut en accepter. La taille de la fenêtre varie en fonction de la nature du réseau et surtout de la bande passante estimée à partir des mesures de performances qui sont effectuées régulièrement (voir section 2.4). Grâce aux mesures effectuées, différents temporisateurs d’attente maximale d’acquittement de bout en bout sont dimensionnés de manière dynamique, à partir de la connaissance acquise sur le fonctionnement du réseau. En effet, le délai de traversée du réseau change d’une connexion à l’autre ; il peut même changer pendant la vie d’une connexion puisque IP ne garantit rien, pas même l’ordre dans lequel arrivent les données. Par ailleurs, TCP gère un flot de données urgentes, non soumises au contrôle de flux.