2 La couche transport est une couche part

2. La couche transport est une couche à part dans le modèle l Elle peut être vue comme la plaque tournante de tous les protocoles l Son rôle : l l réaliser un transfert (connexion) fiable entre deux machines (distante) l indépendamment de la nature du ou des sous-réseaux mis en place

Le service transport l Rappel : l la vocation de la couche transport est de fournir, en principe un processus de la couche applications, un service de transport : l efficace l fiable l économique l pour réaliser cette tâche, cette couche utilise les services mis à sa disposition par la couche réseau l entité de transport = logiciel et/ou matériel qui assure cette fonction

Le service transport Hôte 1 Couche application (ou session) Entité de transport Hôte 2 Adresse transport Couche application (ou session) Interface application/transport Entité de transport TPDU Protocole de transport Couche réseau Interface transport/réseau Adresse réseau Couche réseau

Le service transport l A l’instar de la couche réseau, la couche transport fournit deux types de services : l l l avec connexion sans connexion Ces services sont très proches de ceux de la couche réseau. Pourquoi les avoirs dans deux couches ? l l le code de la couche transport est exécuté sur les clients le code de la couche réseau est exécuté sur des routeurs : l l le client n’y a donc pas d’influence Améliorer le service de la couche 3 ne peut donc se faire qu’en ajoutant une couche l’encapsulant

Les primitives du service transport l La couche transport fournit une interface afin d’accéder à ses services. Les primitives de cette interface sont fonction : l du type de service demandé l ont été définies de manière à être pratiques et faciles à utiliser. En effet, un grand nombre d’informaticiens (développeurs, …) sont amenés à les utiliser

Les primitives du service transport Bloque jusqu’à ce qu’un processus tente de se connecter listen (aucun) connect CONNECTION REQUEST Tente activement d’établir une connexion send DATA Envoie des informations receive (aucun) Bloque jusqu’à ce que le paquet DATA arrive disconnect DISCONNECTION REQUEST Cette extrémité souhaite libérer la connexion

L’encapsulation l Pour rappel : l les TPDU (cfr. N-PDU de 1080) sont les messages envoyés par une entité transport à une autre entité transport. l les TPDU (échangées par la couche transport) sont contenues dans des paquets (échangés par la couche réseau). Les paquets sont, eux, contenus dans des trames (échangées par la couche liaison de données)

L’encapsulation En-tête de la trame En-tête du paquet En-tête de la TPDU Charge utile du paquet Charge utile de la trame

Sockets de Berkeley Ces sockets (interface de connexion) offrent une autre ensemble de primitives. l Elles sont très similaires au modèle de notre premier exemple tout en offrant plus de souplesse et davantage de fonctions. Leur TPDU seront vues plus tard avec TCP. l

Sockets de Berkeley socket Crée le nouveau point terminal d’une communication bind Attache une adresse locale au socket listen Annonce la volonté d’accepter des connexions. Donne la taille de la file d’attente accept Bloque l’appelant jusqu’à ce qu’une tentative de connexion se présente connect Tente activement d’établir une connexion send Envoie des données via la connexion receive Reçoit des données de la connexion close Libère la connexion

Sockets de Berkeley l Fonctionnement : l le serveur exécute les primitives : l socket, bind, listen et accept l socket crée un nouveau point terminal et lui alloue un espace de tables dans l’entité de transport l bind attribue une adresse réseau à un socket. Dès cet instant, des clients distants peuvent s’y connecter l listen alloue de l’espace pour gérer les files d’attentes des appels entrants. Grande différence p/r au modèle précédent : ce listen n’est pas bloquant

Sockets de Berkeley l accept : l lors de l’arrivée d’une TPDU demandant une connexion, l’entité de transport crée un nouveau socket ayant les mêmes caractéristiques que l’original (descripteur de fichier). l le serveur peut alors dupliquer le processus (le thread) pour gérer la connexion sur un nouveau socket l le serveur revient alors sur le socket original pour attendre une nouvelle connexion

Eléments de protocoles de transport l Le service transport est assuré par un protocole de transport établi entre deux entités de transport. Il ressemble par de nombreux aspects au protocole de la couche liaison de données. Comme lui, il gère : l le contrôle d’erreurs l le séquencement l le débit l…

Eléments de protocoles de transport l Il existe cependant des différences fondamentales entre les deux. Alors qu’au niveau de la couche 2, la communication s’opère directement via le support physique, au niveau de la couche 4, ce support est « remplacé » par un sous-réseau. Routeur Hôte Canal de communication Sous-réseau Hôte

Eléments de protocoles de transport l Quelques différences influant sur le protocole : l un routeur n’a pas besoin de spécifier à quel routeur il veut s’adresser, alors qu’en couche 4 il faut explicitement désigner l’adresse du destinataire l l’établissement d’une connexion est également plus complexe. En couche 2, l’entité située à l’autre extrémité du support physique est toujours là (sauf panne). La couche transport doit faire face à un niveau de difficulté bien plus grand

Eléments de protocoles de transport l Suite : l la couche 4 est confrontée au risque d’errance des données à l’intérieur du réseau. Lorsqu’une trame est envoyée elle arrive ou non mais elle ne tourne pas en rond. Dans un réseau, ce type de problème est plus que probable. Pire, dans un sous-réseau, un paquet peut non seulement tourner en rond mais aussi disparaître puis … réapparaître (mémorisation dans les routeurs, …). Ces éléments engendrent une complexification des protocoles

Eléments de protocoles de transport l Suite : l last but not least les couches 2 et 4 gèrent un contrôle du flux et donc une mémorisation. Cependant, la couche transport gère un nombre important et fluctuant de connexions et nécessite de ce fait une approche radicalement différente de celle retenue pour la couche 2. l Détaillons quelque peu ces points

Adressage l Etablissement d’une connexion : l dès qu’un processus applicatif souhaite ouvrir une connexion, il faut spécifier à qui ont veux s’adresser l nb : également vrai pour le mode sans … connexion car la question est : a qui envoyer le message ? l Utilisation des ports : l la méthode courante est la définition d’adresses de transport pour lesquelles processus peuvent être à l’écoute d’éventuelles demandes de connexion : les ports

Adressage l TSAP : l au niveau de la couche 4, nous les appelerons des TSAP. l l’équivalent au niveau de la couche 3 sont les NSAP dont les adresses IP sont un exemple l La figure suivante illustre la relation entre TSAP et NSAP

Adressage TSAP 1208 Hôte 1 Hôte 2 Couche application Processus applicatif Couche transport TSAP 1836 Connexion de transport TSAP 1522 Couche réseau NSAP Couche liaison de données NSAP Couche physique

Adressage l Scénario : l l’hôte 2 héberge, entre autre, un serveur de date sur le point d’accès TSAP 1522. Il est en attente d’un appel entrant (usage d’un listen) l un processus sur l’hôte 1 veut connaître la date. Il émet un connect en spécifiant la source (TSAP 1208) et la destination (TSAP 1522). Il en découle l’établissement d’une connexion de transport entre les deux processus sur les deux machines

Adressage l Localisation des services ? l une question cruciale est de connaître la localisation des services l comment l’hôte 1 sait-il que le serveur de date est connecté au TSAP 1522 de l’hôte 2 ? l soit les TSAP sont fixes (historique) et leur adresse est immuable : l ceci est vrai pour un certain nombre d’entre eux : l Web, ftp, telnet

Adressage l mais il en existe de nombreux autres qui ne sont pas dans ce cas : l service peu connu ou « privé » l à la durée de vie courte l dont l’adresse n’est pas connue par avance l il est donc nécessaire de trouver un modèle d’adressage plus efficace. On l’appelle protocole de préconnexion.

Adressage l Fonctionnement : l au lieu d’attribuer une adresse définie à chaque serveur potentiel écoutant un TSAP connu, chaque ordinateur, souhaitant offrir des services, possède un serveur de processus. l ce dernier ce comporte comme un proxy. Il écoute simultanément sur un ensemble de ports, en attente d’une demande de connexion. Les utilisateurs potentiels d’un service doivent donc commencer par générer un connect en spécifiant le TSAP du service souhaité.

Adressage l si aucun serveur ne les attend, ils se connectent alors au serveur de processus qui, après avoir pris la requête entrante, active le serveur demandé et lui transmet la connexion. l Malheureusement, ce protocole ne résout pas tout. l il y a de nombreuses situations pour lesquelles le service doit exister indépendamment du processus serveur : l serveur de fichier. Nécessite du matériel spécifique qui ne peut être construit à la volée

Adressage l Solution : l faire appel à un processus spécial : l serveur de noms ou serveur d’annuaire l pour connaître l’adresse d’un TSAP correspondant à un nom de service donné (ex. « date et heure » ), l’utilisateur établit une connexion vers le serveur de noms (son TSAP est connu !!!) l dans cette requête, le nom du service recherché est mentionné l le serveur d’annuaire communique l’adresse en retour

Etablissement d’une connexion l Problème très délicat à cause : l des pertes l des stockages l de la duplication l des disparitions/réapparitions l… l Il existe peu de méthodes capables de s’accommoder de l’existence de doublons.

Etablissement d’une connexion l La plus efficace : l consiste en une discrimination fondée sur la durée de vie des paquets l on peut restreindre la durée de vie à un maximum en utilisant une ou plusieurs des méthodes suivantes : l limiter la taille du sous-réseau l affecter un compteur de nombre de nœuds traversés pour chaque paquet l timestamp pour chaque paquet

Etablissement d’une connexion l Evaluation : l la première méthode limite les risques que les paquets tournent en rond et diminue les risques de congestion l la seconde (cfr. TTL) initialise un compteur. Ce dernier est décrémenté à chaque passage dans un nœud. Le paquet ayant son compteur à zéro est éliminé du réseau

Etablissement d’une connexion l la troisième utilise un timestamp. Les routeurs vérifient la valeur pour chaque paquet avec leur horloge interne et éliminent les plus vieux l inconvénient : il faut que les horloges des routeurs soient synchronisées. Tâche très complexe (nécessite une source externe) l En pratique : l il ne suffit pas de s’assurer qu’un paquet est détruit. Il faut aussi que tous les accusés de réception le concernant le soient aussi.

Etablissement d’une connexion l Pour se faire : l notion de T : l multiple (faible) de la durée maximale de vie d’un paquet (le multiple est fonction du protocole) l idée : l si on attend un temps T après qu’un paquet a été envoyé, on peut supposer que toutes traces de ce dernier a disparu l une fois la durée de vie des paquets limitée, une connexion fiable est possible

Etablissement d’une connexion l Tomlinson : l a défini une méthode dont certains aspects ont été revus par Sunshine et Dalal. C’est une de ces variantes, dont TCP, qu’on utilise aujourd’hui l Perte de mémoire des machines : l Tomlinson a proposé d’équiper chaque hôte d’une horloge temps réel : l les horloges des hôtes étant synchronisées l chaque horloge est un compteur binaire qui s’incrémente à intervalles réguliers

Etablissement d’une connexion l de plus, le nombre de bits du compteur doit être supérieur (ou égal) au nombre de bits des numéros de séquence l enfin, et fondamental, l’horloge doit continuer de fonctionner même si l’hôte est en panne l Idée de base : l deux unités en transit ne peuvent avoir la même référence. Comment ? l lorsqu’une connexion est établie, les k bits de poids faible de l’horloge compose la référence initiale

Etablissement d’une connexion l par opposition à la couche 2 : l cfr. numérotation et fenêtre coulissante l chaque connexion numérote ses TPDU avec des références différentes l la capacité du compteur est telle que lorsqu’il repasse par zéro, toutes les données qui pourraient avoir reçu une de ces références ont disparu depuis longtemps

Etablissement d’une connexion l Relation entre le temps et la référence : Message interdit Vrais numéros de séquence utilisés T Numéro de séquence 2 K-1 60 90 Zone interdite 30 Reprise après incident à 70 0 Numéro de séquence 120 T 0 30 60 90 Temps 120 150 180 Temps

Etablissement d’une connexion l Déroulement : l une fois que les deux entités se sont misent d’accord sur les références initiales : l utilisation de n’importe quel protocole de fenêtre dynamique : anticipation l … l l reste un problème : l quid en cas de panne d’un hôte : l à son « réveil » , il a oublié la référence courante

Etablissement d’une connexion l Solution : l on laisse passer un temps T : l pour laisser mourir toutes les TPDU l mais dans un interréseau, T peut-être très grand : l inadéquat l on adapte les exigences sur les références : l ex : soit T = 60 s. et l’horloge incrémentée chaque seconde l selon notre graphe, une connexion au temps x aura la référence x l supposons qu’à t=30, une TPDU ait été envoyée à la connexion 5 avec la référence 80. Soit X cette TPDU l

Etablissement d’une connexion juste après l’envoi de X, l’hôte tombe en panne. Toutefois, il redémarre immédiatement l à t=70, il ouvre à nouveau la connexion 5 avec la référence initiale … 70 (logique). l pendant 15 s. il envoie les unités de données 70 à 80 : l nb : une TPDU peut prendre plus qu’une seconde l à t=85, une nouvelle TPDU ayant la référence 80 est affectée à la connexion 5 l Catastrophe : l la TPDU X existe toujours l si elle est reçue avant la TPDU 80, elle sera considérée comme la bonne et le système est en échec l de plus, l’unité correcte sera rejetée comme … doublon l

Etablissement d’une connexion l pour éviter cela : l il faut interdire que des références déjà utilisées (affectées à des TPDU) soient à nouveau utilisées pendant un temps T : l ceci matérialise la zone interdite l avant d’envoyer une TPDU, l’entité de transport vérifie son horloge afin de constater qu’elle n’est pas dans la zone interdite : l si c’est le cas, il faut : l attendre l resynchroniser les références

Etablissement d’une connexion l Mauvaise nouvelle : l cette méthode résout le problème des duplicatas retardés pour les TPDU de données (connexion existante à priori) l Mais quid des TPDU de contrôle ? l en fait, il peut être extrêmement complexe d’établir la négociation initiale

Etablissement d’une connexion l ex : l l’hôte 1 envoi une TPDU Connection Request contenant une proposition de référence initiale et un port destinataire à l’hôte 2 l ce dernier doit répondre au moyen d’une TPDU Connection Accepted. Si la TPDU request se perd mais qu’un doublon égaré apparaît en 1, la connexion est réellement établie MAIS sur des bases incorrectes l Tomlinson propose une procédure en trois étapes : l three ways handshake

Etablissement d’une connexion l Dans cette procédure : l les deux entités démarrent avec la référence qu’elles souhaitent (indépendamment). L’utilisation de l’horloge globale n’est pas nécessaire l fonctionnement : l l’hôte 1 choisit une référence (x) et l’envoie à l’hôte 2 via une Connection Request l l’hôte 2 accuse réception de x et propose sa propre référence initiale y l enfin, 1 confirme le choix de 2 en lui signifiant y au cours de l’envoi de la première TPDU de données

Etablissement d’une connexion Ancien doublon hôte 1 hôte 2 CR Ancien doublon hôte 2 hôte 1 hôte 2 CR ( s (s é q = CR ( x) éq = x) séq = x ) x) = AC K = AC y, = séq ( K AC Temps , = y séq K ( y, x) Temps x) K = AC K AC q = é s K ( AC DO DA TA RE NN E ES (sé q = x JEC , A CK = y T ( AC ) (s éq = x , A CK K = y) RE JEC (a) (b) T ( (c) AC = z) K = y) Ancien doublon

Etablissement d’une connexion l tenue au problème : l la figure (b) illustre le fait que la présence d’un doublon retardé d’une Connexion Request provenant d’une ancienne connexion est détectée : l l 2 la reçoit correctement, en avise 1 avec un numéro de référence. 1 détecte l’erreur et en averti 2 la figure (c) illustre le pire des cas. Une CR et un accusé de réception d’une CA errent dans le sous-réseau : l l l 2 reçoit une CR retardée et y répond. Notons que 2 propose une valeur y comme numéro initial lorsque la seconde TPDU arrive en 2, le fait qu’elle contienne la confirmation pour z au lieu de y indique à 2 qu’il s’agit d’un doublon heureusement, il n’y a pas de combinaison d’anciennes TPDU qui peuvent faire faillir le protocole et initialiser par erreur une connexion

Libération d’une connexion l Libérer une connexion : l plus facile que de l’établir l quoique …deux méthodes : l libération asymétrique : l brutale risque de perte de données (cfr. illustration) l libération symétrique : considère qu’il y a non pas une mais deux connexions l problème des deux armées l

Libération d’une connexion hôte 1 hôte 2 l après établissement de la connexion, l’hôte 1 envoie une TPDU qui arrive correctement à l’hôte 2 l l’hôte 1 envoie une autre TPDU l malheureusement, l’hôte 2 envoi un DISCONNECT avant l’arrivée de cette seconde TPDU l la connexion est alors brutalement rompue et les données sont perdues CR Temps ACK DA T A DR Aucune donnée n’est livrée après la requête de déconnexion

Libération d’une connexion l Il faut clairement : l un protocole plus élaborer pour éviter ce genre de pertes libération symétrique : l dans ce cas, un hôte peut continuer à recevoir des données même après avoir envoyé un Disconnect l ce protocole fonctionne parfaitement quand les deux processus ont une quantité de données fixée à transmettre et savent quand libérer la connexion l l’ennui est que cela ne fonctionne pas toujours

Libération d’une connexion Armée des blancs n° 1 Armée des blancs n° 2 Armée des verts

Libération d’une connexion l Les deux armées : l l’armée des verts campe dans la vallée l les deux armées des blancs ont pris position sur les collines l l’armée des verts est plus forte que chaque armée des blancs prisent individuellement, mais est plus faible que les deux réunies l Le problème est donc la coordination

Libération d’une connexion l Comment faire pour attaquer ensemble ? l l supposons que l’armé 1 des blancs souhaite attaquer. Elle envoi un éclaireur vers la 2ème armée (il doit passer par la vallée). Le commandant de l’armée 2 reçoit le message et envoie un éclaireur pour confirmer. Est-ce concluant ? NON : l l car le commandant de l’armée 2 ne saura pas si le commandant de l’armée 1 à reçu son message. Donc, dans le doute, il ne lancera pas l’attaque solution : l le commandant 1 envoie une confirmation. OK, mais cette fois, c’est le commandant 1 qui est dans le doute que le commandant 2, ayant bien reçu la confirmation, va attaquer comme prévu … et ainsi de suite en fait, il n’y a pas de limites. Aucun protocole ne peut résoudre le problème. Retenons qu’il n’est pas simple de libérer une connexion

Contrôle de flux l Un parallèle avec la gestion de flux de la couche 2 peut être fait : l la couche 4 va également utiliser un système de fenêtres à anticipation afin de conserver une communication rapide mais respectueuse des possibilités du destinataire l Toutefois, des différences notables existent : l alors qu’un routeur n’a, en général, que peu de connexions, un hôte en a un grand nombre : l l’implémentation doit donc utiliser une toute autre stratégie

Contrôle de flux l Mémorisation : l les entités de transports (ET) ont également un important travail au niveau de la mémorisation des TPDU : l si la couche réseau n’est pas fiable, il est évident que les ET devront mémoriser toutes les TPDU expédiées l mais même si la couche 3 offre un service fiable, il faut encore s’assurer que l’ET de réception acceptera toujours toute TPDU entrante (place mémoire disponible) : l sinon, le problème est encore plus aigu, car l’expéditeur ne pourra même pas se fier sur les acquits de la couche réseau et la mémorisation sera quand même obligatoire

Contrôle de flux l Mémorisation : l de grandes difficultés sont également au programme de l’ET destinataire : l comment gérer les tampons ? l la difficulté réside dans le fait que la taille des TPDU n’est pas forcément constante. une allocation statique de la taille n’est pas toujours possible l par contre, une allocation dynamique de la taille est beaucoup plus complexe à gérer l

Multiplexage l Nécessaire ? l il se peut qu’un hôte ne propose qu’une seule adresse : l toutes les connexions de transports devront l’utiliser. Il faut alors que lorsqu’une TPDU se présente, disposer d’un moyen permettant d’indiquer quel est le processus concerné : multiplexage de connexions (ou en amont) l dans l’exemple suivant nous illustrons 4 connexions de transport distinctes (processus ≠) utilisant la même connexion réseau

Contrôle de flux Adresse de transport Adresse de réseau Lignes de routage Vers le routeur

Protocole de transport l La couche de transport de l’Internet dispose de deux protocoles principaux : l UDP : protocole sans connexion l TCP : protocole orienté connexion l Les deux protocoles sont fort proches dans leur définition (en-tête), mais n’offrent en rien les mêmes services

UDP l User Datagram Protocol : l avec ce protocole, les applicatifs peuvent encapsuler des datagrammes IP bruts et les envoyer sans établir, au préalable, une connexion RFC 768 l Structure : l l un segment UDP comprend un en-tête de 8 bytes suivi de la charge utile

UDP l L’entête : Port source Port de destination Longueur UDP Total de contrôle UDP 32 Bits l les 2 ports servent à identifier les points d’extrémité au niveau des ordinateurs : l l lorsqu’un paquet UDP se présente, sa charge utile est passée au processus lié au port de destination Comparé à IP, ces ports permettent de livrer correctement les paquets que la couche réseau n’aurait pas pu traiter

UDP l port source : l permet essentiellement de retourner une réponse à l’expéditeur (cfr. MAC adresse source). Niveau applicatif et non plus hôte l longueur UDP : l contient un en-tête (8 bytes) et les données l total de contrôle : l optionnel, mais aucun intérêt à le désactiver (valeur 0)

UDP l Attention : l UDP ne fait pas : l de contrôle de flux, l de contrôle d’erreur, l de retransmission si segment erroné l toutes ces opérations sont laissées à la discrétion des processus utilisateurs l UDP est particulièrement bien adapté aux applications clients-serveurs : l RPC, RMI, …, DNS, …

UDP - RPC l Nature : l très semblable à un appel de fonction au sein d’une même machine : l envoi de paramètres, réception de valeur l RPC vise donc à rendre « locaux » des appels distants : l définition de deux morceaux de codes (1 côté client et 1 côté serveur) : les stub (ou skeleton selon les langages) l ainsi, le stub client (sur le … client), matérialise la procédure localisée sur le serveur dans l’espace d’adressage du client. Ceci dissimule le fait que l’appel n’est pas local

UDP - RPC l l l tant du côté serveur que client, les applications travaillent comme-ci leurs appels/réponses étaient locaux. ce sont les stub (// proxy) qui vont réaliser les communications réseaux sans obliger les développeurs à utiliser des E/S sur sockets Remarques : l les RPC comportent malheureusement certains problèmes plus ou moins aigus selon les langages : plus de notion de variable globale l le typage des paramètres ne peut pas toujours être déduit des entêtes l passage de pointeurs mémoires problématiques, … l

TCP Transmission Control Protocol l La plupart des applications Internet réclament : l l une remise séquentielle l fiable l TCP a été spécialement conçu pour fiabiliser une communication empruntant un grand nombre de réseaux hétérogènes et potentiellement non fiables

TCP Défini par la RFC 793 l Corrigé par les RFC 1122 et 1323 l Toute machine supportant TCP possède : l l une Entité Transport (ET) TCP l une procédure de bibliothèque l un processus gérant l’interface avec IP

TCP l Cette machine accepte : l des flux de données utilisateurs venant de processus locaux l elle les fragmente en unités de taille < à 64 KBits : l en pratique 1. 460 bytes pour entrer dans une trame Ethernet (avec en-tête IP et TCP) l envoie chaque unité sous forme de datagramme IP l En cas de réception par la couche IP, la couche 4 effectue le travail de reconstruction

TCP – modèle de service l Pour disposer d’un service TCP, il faut deux points de connexion : l les sockets : l chacun possède un numéro, ou adresse, constitué de l’IP de l’ordinateur hôte et d’un nombre de 16 bits local à ce dernier l le port n’est autre que le TSAP de TCP l Les connexions sont identifiées par les ID des sockets (socket 1, socket 2)

TCP – modèle de service Les ports dont les numéros sont < à 1024 sont appelés ports réservés (well-know port) l Exemple : l l 21 FTP l 23 Telnet l 25 SMTP l 80 HTTP l 110 POP 3

TCP – modèle de service l Tous les ports ne sont pas actifs au démarrage. Les démons à leur écoute encombreraient inutilement la mémoire : l sous UNIX, la technique est celle d’un démon générique qui écoute tous les ports : l lorsqu’un processus souhaite se connecter à un port spécifique, sa demande est reçue par le démon générique (inetd), qui active le démon adéquat et lui passe la requête pour traitement

TCP – modèle de service l Mode : l toutes les connexions TCP sont bidirectionnelles l flux de bytes et non de messages : l la délimitation des messages n’est donc pas garantie de bout-en-bout : l l’émetteur peut envoyer 4 * 512 bytes et le récepteur se voir livrer 1 * 2. 048 bytes l quand une application fournit des données à TCP, celui peut, à sa guise, les stocker ou les envoyer (optimisation) : l l’application peut forcer l’envoi immédiat via le drapeau PUSH. Attention toutefois, pas toujours implémenté

TCP – Protocole l Les ET TCP échangent les données : l sous forme de segments : l un segment est formé : en-tête de longueur fixe de 20 bytes l d’une partie optionnelle l suite de zéro ou plusieurs bytes de données l l le logiciel détermine la taille des segments : l soit il accumule les données provenant de plusieurs écritures dans un seul segment l soit il fragmente les données d’une seule écriture en plusieurs segments

TCP – Protocole l Limitations : l un segment, en-tête TCP comprise, doit pouvoir tenir dans la charge utile d’un paquet IP (65. 535 bits) l chaque réseau possède sa propre MTU : l (Maximum Transfert Unit) l dans laquelle le segment doit s’insérer l en pratique, la taille est de 1. 500 bytes car il s’agit de la charge utile d’une trame Ethernet l Le protocole utilise les fenêtres à anticipation l cfr. 1080

TCP – En-tête 32 Bits Port source Port de destination numéro de séquence Numéro d’accusé de réception Longueur de l’en-tête TCP A C K P S H R S T S Y N F I N Total de contrôle 6 Bits 1 Bit U R G Taille de la fenêtre Pointeur urgent Options (0 ou plusieurs mots de 32 bits) Données (optionnel)

TCP – En-tête l Port source / destination : l identifient les extrémités locales de la connexion l un port et l’adresse IP de l’hôte forment un point final unique de 48 bits l le doublet (point final source / destination) identifie la connexion l Numéro de séquence / Numéro d’accusé : l rôle habituel d’ordonnancement l rem : le second indique le prochain octet attendu et non le dernier correctement reçu

TCP – En-tête l Longueur : l indique le nombre de mots de 32 bits de l’en-tête. Comme la longueur du champ Options est variable, Longueur indique donc le point de départ des données au sein du segment : l point de départ mesuré en mots de 32 bits l 6 bits non utilisés

TCP – En-tête l 6 drapeaux : l URG : pointeur d’urgence. Donne un décalage en octet à partir du numéro de séquence courant. Il indique où trouver les données urgentes l ACK : mis à 1 pour indiquer la validité du Numéro d’accusé de réception. Si 0, alors il n’y a pas d’acquittement et le champ Numéro d’accusé de réception est ignoré l PSH : pousse TCP à envoyer les données immédiatement, sans les accumuler

TCP – En-tête l RST : réinitialise une connexion devenue incohérente. Permet également de rejeter un segment erroné. Utilisé enfin pour refuser l’ouverture d’une connexion l SYN : utile pour établir une connexion. La demande de connexion met SYN à 1 et ACK à 0. La réponse à cette demande contient un SYN à 1 et un ACK à 1. Comme le SYN est utilisé à la fois pour une demande et une communication acceptée, c’est le bit ACK qui différencie la nature

TCP – En-tête l FIN : libère une connexion. Il indique l’émetteur n’a plus rien à transmettre. Ce qui ne l’empêche pas de pourvoir continuer à recevoir (cfr. 3 ways handshake) l Taille de fenêtre : l puisque TCP utilise des fenêtres dynamiques, ce champ indique combien on peut transmettre d’octets après l’octet acquitté. La valeur 0 dans ce champ indique tous les octets jusqu’au Numéro d’accusé – 1 ont été reçus

TCP – En-tête l Total de contrôle : l le calcul du CRC porte sur : l l’en-tête l les données et la pseudo en-tête (IP) 32 Bits Adresse source Adresse destination Pseudo entête 0000 Protocole = 6 Longueur du segment TCP

TCP – pseudo en-tête l la prise en compte de la pseudo en-tête dans le calcul du total de contrôle permet de détecter les paquets non délivrés : l mais violation du principe de la hiérarchie des protocoles : l en effet, les paquets IP appartiennent à la couche IP et non TCP

Etablissement d’une connexion l Méthode en 3 étapes : l le ‘serveur’ est en attente : listen, accept : l l désignation d’une source précise, acceptation d’un appel d’où qu’il vienne le ‘client’ exécute un connect : en indiquant l’IP et le port souhaité, … l la primitive connect envoie un segment TCP avec : l l l SYN à 1 et ACK à 0 quand ce dernier segment arrive, l’entité TCP cherche une application à l’écoute du port indiqué : si elle trouve : le processus à l’écoute reçoit le segment TCP l sinon, l’entité TCP envoie une réponse avec RST à 1 l

Libération de la connexion TCP l Toutes les connexions étant bidirectionnelles : l la libération revient en fait à agir comme s’il existait deux connexions unidirectionnelles : l pour libérer, une des deux parties envoie un segment avec le bit FIN sur 1 : cela signifie qu’elle n’a plus de données à transmettre l lorsque ce segment est acquitté, cette direction est fermée l l toutefois, le flux de données peut continuer sans problème dans l’autre sens : l pas de perte l lorsque les deux sens ont été fermés, la connexion est libérée

Libération de la connexion TCP l Problème des deux armées : l pour éviter un aller-retour à l’infini des confirmations : l utilisation de timers : si une réponse à un FIN n’est pas parvenue dans la limite de 2 fois la durée de vie maximale d’un paquet, alors l’émetteur du FIN libère la connexion l l’autre extrémité a son attention attirée par le fait que plus personne n’est à l’écoute et elle s’arrête d’elle-même. l l En pratique, cette méthode est rarement défaillante

Gestion de la connexion l Machine à états finis : l filets continus épais : l l filets discontinus épais : l l chemin normal d’un serveur filets maigres : l l chemin normal d’un client événements inhabituels chaque transition : l prend le nom de l’événement qui la provoque et celui de l’action qui en résulte : l l FIN/ACK entre parenthèses : l commentaires

Politique de transmission de TCP l Gestion des fenêtres : l dans TCP, non directement liée aux accusés de réception l exemple : l si un récepteur possède une mémoire tampon de 4. 096 octets et qu’un émetteur transmet un segment de 2. 048 octets. Le récepteur, s’il le reçoit correctement, acquittera ce segment sans pour autant être obligé de le transmettre à l’application concernée. Il adaptera (et le fera savoir) la taille de sa fenêtre et reste à l’écoute

Politique de transmission de TCP Récepteur Emetteur L’application écrit 2 Kb Tampon du récepteur vide 2 K | SEQ =0 2 K = 2048 48 WIN L’application écrit à nouveau 2 Kb ACK = 20 2 K | SEQ = 20 48 Plein L’émetteur est bloqué =0 96 WIN L’application lit 2 Kb ACK = 40 = 2048 96 WIN ACK = 40 2 K L’émetteur peut envoyer jusqu’à 2 Kb 1 K | SEQ = 40 96 1 K 2 K

Politique de transmission de TCP l Pourquoi : l optimisation : l il est plus rationnel d’envoyer un segment de 4. 096 que deux de 2. 048 (moins de gaspillage de largeur de bande) l Toutefois : l le regroupement en gros segments n’est pas toujours souhaitable : l ainsi l’algorithme de Nagle (qui vise à accumuler dans le tampon) génère des problèmes dans le cas ou il faut envoyer les petits segments : l cas du X Windows avec segment portant coordonnées souris

Contrôle de congestion l Quid si la charge est plus importante que ce que l’on peut gérer ? l une congestion apparaît l nous avons déjà dit que la couche réseau s’occupait de gérer cette problématique l c’est toutefois TCP qui fait la grosse partie du travail l principe : l on n’injecte pas un nouveau paquet tant qu’un ancien subsiste : l recours à la gestion dynamique de la taille des fenêtres

Contrôle de congestion l Principe de base : l l pour éviter la congestion, il faut faire de la détection dans le passé c’était difficile. En effet, l’expiration des timers pouvait être aussi bien due à une réelle congestion qu’à une distorsion du signal due à la piètre qualité des lignes actuellement, les principales artères étant en fibres optiques, les timers expirent la majeur partie du temps à cause des seules congestions Tous les algorithmes de TCP se base sur cette constatation

Contrôle de congestion l Il existe deux problèmes potentiels : l congestion du récepteur : l car il a des capacités de traitement plus faibles de l’émetteur l ce cas est ‘facile’ à traiter : lors de l’établissement de la connexion, les deux ET se mettent d’accord sur la vitesse, le débit l utilisation de la fenêtre de congestion qui reflète le nombre de byte que l’émetteur peut envoyer : l initialisation à la taille maximale d’un segment, puis, tant que tout va bien, cette taille est systématiquement doublée. l c’est l’algorithme dit à démarrage lent l

Contrôle de congestion l congestion du réseau : utilisation des fenêtres récepteur et de congestion l définition d’un nouveau paramètre : l l le seuil de congestion (threshold) : l valeur initial 64 Kb l quand un timer expire (signe de congestion réseau), on redimensionne le seuil à la moitié de la taille de la fenêtre de congestion courante et on réinitialise la fenêtre de congestion à la taille maximale de segment l on utilise alors le démarrage lent pour déterminer la capacité d’absorption du réseau à ceci près que la croissance exponentielle est stoppée dès que le seuil est atteint l à partir de là, les transmissions réussies font croître linéairement (un seul segment pour l’ensemble des segments de la fenêtre au lieu d’un par segment acquitté) la fenêtre de congestion

Contrôle de congestion