éseaux - Cours 2 UDP et : Protocoles de Transport de /IP Cyril Pain-Barre IUT Informatique Aix-en-Provence Semestre 2 - version du 22/3/2011 1/67 Cyril Pain-Barre Transport UDP et 1/90
Services et Limitations d IP Services d IP : interconnexion de réseaux remise de datagrammes à des hôtes (adresses IP) adaptation aux MTU des réseaux durée de vie limitée des datagrammes détection des erreurs sur l en-tête signalisation de certaines erreurs via ICMP Limitations d IP : pas d adressage des applications (client/serveur Web, client/serveur FTP, etc.) livraison des datagrammes non garantie duplication possible des datagrammes! déséquencement possible des datagrammes erreurs possibles sur les données pas de contrôle de flux 2/67 Cyril Pain-Barre Transport UDP et 2/90
ôle du Transport Aller au-delà des limites d IP Assurer, si possible, la correction d erreurs : signalées par ICMP non signalées 2 protocoles de transport disponibles dans /IP : UDP : transport rapide, non connecté, permettant la multi-diffusion : transport fiable en mode connecté point-à-point distinguent les applications au sein d un même hôte garantissent l indépendance des communications 3/67 Cyril Pain-Barre Transport UDP et 3/90
Adressage des applications Plusieurs applications réseaux peuvent s exécuter en parallèle sur un ordinateur Problème : comment un émetteur peut-il préciser à quelle application est adressé un message? La solution retenue sur Internet est l utilisation de destinations abstraites : les ports (ne pas confondre avec les ports physiques des hubs/switchs) entiers positifs sur 16 bits UDP et fournissent chacun un ensemble de ports indépendants : le port n de UDP est indépendant du port n de le système permet aux applications de se voir affecter un port UDP et/ou (choisi ou de manière arbitraire) certains numéros de port sont réservés et correspondent à des services particuliers L adresse d une application Internet est le triplet : (adresse IP, protocole de transport, numéro de port) 4/67 Cyril Pain-Barre Transport UDP et 4/90
Démultiplexage des ports DHCP (serveur) applications UDP applications UDP/ applications......... TFTP DNS FTP SMTP HTTP 67 69 53 selon Port 53 21 25 80 UDP 17 selon champ Protocole 6 IP 5/67 Cyril Pain-Barre Transport UDP et 5/90
Le protocole UDP : User Datagram Protocol (FC 768) 6/67 Cyril Pain-Barre Transport UDP et 6/90
Services d UDP Utilise IP pour acheminer les messages d un ordinateur à un autre. Service rendu : adressage des applications par numéro de port multiplexage/démultiplexage par numéros de port contrôle facultatif de l intégrité des données Même type de service non fiable, non connecté que IP : possibilité de perte, duplication, déséquencement de messages pas de régulation de flux Un programme utilisant UDP doit gérer lui-même ces problèmes! 7/67 Cyril Pain-Barre Transport UDP et 7/90
Format des datagrammes UDP En-tête : pas d option possible, nombre fixe d octets = 8 Données : nombre variable d octets ( 65 535) en tête 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Port UDP Source Longueur Totale bits : 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Port UDP Destination Checksum 3 0 3 1 taille variable Données 8/67 Cyril Pain-Barre Transport UDP et 8/90
Champs UDP : ports source et destination Port UDP Source : indique le numéro de port de l émetteur. Peut être à 0 si aucune réponse n est attendue. Port UDP Destination : numéro de port du destinataire. Si ce port n a été alloué à aucun processus, UDP renverra un message ICMP de destination inaccessible car port non alloué (type 3, code 3) et détruit le datagramme Démultiplexage UDP selon le port destination : Appli 1 Appli 2 Appli 3 port x port y port z UDP selon champ Protocole (17) IP 9/67 Cyril Pain-Barre Transport UDP et 9/90
Serveurs et ports réservés UDP Voir http://www.iana.org/assignments/port-numbers Well known Port Assignment : certaines applications bien connues ont des ports UDP réservés [0, 1023] Exemples : Num (décimal) Application 7 Serveur echo 13 Serveur daytime 19 Serveur chargen 53 Serveur DNS 67 Serveur BOOTP/DHCP 68 Client BOOTP/DHCP 69 Serveur TFTP 123 Serveur NTP les ports [1024, 49151] sont enregistrés (mais peuvent être utilisés) les ports [49152, 65535] sont dits dynamiques et/ou à usage privé 10/67 Cyril Pain-Barre Transport UDP et 10/90
Champs UDP : Checksum Facultatif : tout à 0 si non calculé Vérifie la totalité du datagramme + Pseudo en-tête UDP. Permet de s assurer : que les données sont correctes que les ports sont corrects que les adresses IP sont correctes Même calcul que IP sur tout le datagramme UDP (bourrage éventuel 1 octet à 0) + pseudo en-tête UDP Pseudo en-tête UDP (interaction avec IP) : (12 octets) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 bits : Adresse IP Source Adresse IP Destination 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 3 0 3 1 Zone à Zéro Protocole Longueur Datagramme UDP 17 (en décimal) pour IP 11/67 Cyril Pain-Barre Transport UDP et 11/90
Interface BSD (Unix) pour UDP int (int domain, int type, int protocol) : retourne un Service Access Point (SAP) auprès d UDP, utilisé en premier paramètre des primitives ci-après int bind(int sock, const struct sockaddr *addr, socklen t addrlen) associe au SAP l adresse d application addr ssize t sendto(int sock, const void *buf, size t len, int flags, const struct sockaddr *to, socklen t tolen) demande l envoi de len octets contenus dans buf, à l adresse to ssize t recvfrom(int sock, void *buf, size t len, int flags, struct sockaddr *from, socklen t *fromlen) reçoit dans buf un message d au plus len octets ; l adresse de l émetteur est placée dans from int close(int sock) : libère le SAP 12/67 Cyril Pain-Barre Transport UDP et 12/90
Modèle Client/Serveur utilisant UDP Le serveur est démarré sur un ordinateur en écoute sur un port. Son adresse est le triplet : (adresse IP, UDP, port) L écoute consiste à attendre qu un message parvienne à ce port ; les clients devront connaître le port du serveur (intérêt des ports réservés) Le client envoie une requête au serveur (à son adresse) : pour recevoir une réponse du serveur, il doit avoir acquis un numéro de port UDP. Le plus souvent, ce port est quelconque. ares sont les clients (comme BOOTP/DHCP) qui nécessitent un port précis. la requête est un message applicatif : suite d octets constituant un PDU (Protocol Data Unit) du protocole qu implémentent le client et le serveur. UDP fabrique un datagramme UDP avec pour champ Données ce message, et pour champ Port Destination celui du serveur. Le Port Source est celui du client. Le datagramme UDP est ensuite envoyé via un datagramme IP avec les adresses IP du serveur (destination) et du client (source). Le serveur reçoît le message du client, ainsi que son adresse. Il peut alors traiter le message et répondre au client. Selon le protocole, la discussion peut se poursuivre, ou s arrêter là. Cyril Pain-Barre Transport UDP et 13/90 13/67
Files d attente et réception Attribution de port allocation file d attente éception d un datagramme : port destination non attribué : destruction + message ICMP port alloué : si file non pleine, ajouté dans la file, sinon détruit (pas de message ICMP!) Appli consomme les éléments de la file, par accès synchrone : si aucun datagramme, processus placé en attente sinon, consommation du premier datagramme (FIFO) Une application peut demander plusieurs ports 14/67 Cyril Pain-Barre Transport UDP et 14/90
Utilisation UDP : modèle requête/réponse Soit AppliB qui utilise 2 ports : si reçoit datagramme sur port x, renvoie les données en majuscules si reçoit datagramme sur port y, renvoie les données à l envers pour ce genre de service, AppliB peut traiter les datagrammes au fûr et à mesure A1 A2 AppliB C1 x y UDP Hôte A UDP Hôte B UDP Hôte C 15/67 Cyril Pain-Barre Transport UDP et 15/90
Utilisation UDP : suivi de la discussion Si la discussion est longue et complexe, il est plus simple de déléguer Exemple : serveur TFTP reçoit un premier datagramme d un client sur le port 69 demande un nouveau port crée un fils pour traiter ce client sur ce nouveau port renvoie un datagramme au client indiquant sur quel port poursuivre la discussion (transfert de fichier) retourne à l écoute de l arrivée de nouveaux clients la discussion se poursuit entre le client et le fils TFTP dédié Client TFTP Fils TFTP Serveur TFTP Fils TFTP Client TFTP x 69 y UDP UDP UDP Hôte A Hôte B Hôte C 16/67 Cyril Pain-Barre Transport UDP et 16/90
Utilisation UDP : multidiffusion Exemple UDP offre un service en mode non connecté Une application peut ainsi exploiter la multidiffusion IP et émettre un seul datagramme qui sera reçu par un ensemble de stations, en utilisant comme destination, une adresse : broadcast : diffusion à toutes les stations d un réseau, ou du réseau local pour l adresse de diffusion limitée (255.255.255.255) multicast : adresses de classe D pour diffuser à un ensemble de stations se trouvant éventuellement sur des réseaux différents (les routeurs qui les séparent doivent être configurés pour cela). Utilisées notamment pour la diffusion de médias audio/vidéo. Envoi par un client DHCP d un message à tous les serveurs DHCP du réseau local. L adresse destination du message DHCP est (255.255.255.255, UDP, 67) 17/67 Cyril Pain-Barre Transport UDP et 17/90
Mise en œuvre du transfert fiable 18/67 Cyril Pain-Barre Transport UDP et 18/90
Transfert fiable en mode connecté Bien souvent les applications ont besoin d échanger de gros volumes de données de manière fiable Exemples : FTP, SMTP, HTTP,... Il est toujours possible d offrir ce service en s appuyant sur un service non fiable non connecté comme IP ou UDP Pour cela, on a besoin de quelques éléments essentiels : les accusés de réception (ACK) des temporisateurs : alarmes qui expirent (timeout) la numérotation des paquets (ou données) 19/67 Cyril Pain-Barre Transport UDP et 19/90
Accusés de réception (ACK) L émetteur d un paquet attend une confirmation de réception de la part du récepteur avant d envoyer un autre paquet Le récepteur accuse réception d un paquet en envoyant un ACK Émetteur éseau écepteur émission paquet 1 réception paquet 1 envoi d un ACK réception ACK émission paquet 2 Protocole de type envoyer et attendre 20/67 Cyril Pain-Barre Transport UDP et 20/90
Temporisateurs Des paquets peuvent être perdus dans le réseau Si paquet perdu, pas d ACK donc blocage Utilisation d un timer armé lors de l émission du paquet : si expire, renvoie le paquet si réception ACK avant expiration, désactivation du timer Émetteur éseau écepteur émission paquet 1 + armement timer timeout émission paquet 1 envoi de l ACK 21/67 Cyril Pain-Barre Transport UDP et 21/90
Temporisateurs : problème de réglage Scénario du timer trop court et mise en cause fiabilité : Émetteur éseau écepteur émission paquet 1 + armement timer timeout émission paquet 1 envoi de l ACK émission paquet 2 envoi de l ACK émission paquet 3 Le paquet 1 est accepté deux fois par le récepteur! Le deuxième ACK est pris pour celui du paquet 2! Mais si timer trop long, on perd en efficacité... 22/67 Cyril Pain-Barre Transport UDP et 22/90
ACK : problème de l ACK perdu Scénario de l ACK perdu et mise en cause fiabilité : Émetteur éseau écepteur émission paquet 1 + armement timer envoi de l ACK timeout émission paquet 1 envoi de l ACK émission paquet 2 Le paquet 1 est accepté 2 fois par le récepteur! 23/67 Cyril Pain-Barre Transport UDP et 23/90
Numérotation des paquets et des ACK Les paquets et les ACK portent des numéros : résoud les problèmes d ACK perdu et d alarme trop courte. Émetteur éseau écepteur émission paquet 1 + armement timer envoi de l ACK n 1 (paquet 2 attendu) timeout émission paquet 1 ignore paquet 1 envoi de l ACK n 1 émission paquet 2 24/67 Cyril Pain-Barre Transport UDP et 24/90
Numérotation des paquets et des ACK Les paquets et les ACK portent des numéros : résoud les problèmes d ACK perdu et d alarme trop courte. Émetteur éseau écepteur émission paquet 1 + armement timer timeout émission paquet 1 envoi de l ACK n 1 (paquet 2 attendu) émission paquet 2 ACK n 1 ignoré timeout émission paquet 2 ignore paquet 1 envoi de l ACK n 1 accepte paquet 2 envoi de l ACK n 2 24/67 Cyril Pain-Barre Transport UDP et 25/90
Fenêtre glissante (ou à anticipation) Principe : émettre n paquets sans attendre d ACK (n est la taille de la fenêtre) fenêtre initiale (taille 8) 1 2 3 4 5 6 7 8 9 10 11... envoyés envoi autorisé envoi interdit un temporisateur par paquet émis la réception du ACK du premier paquet de la fenêtre la fait glisser : la fenêtre a glissé 1 2 3 4 5 6 7 8 9 10 11... acquittés envoyés envoi autorisé envoi interdit 25/67 Cyril Pain-Barre Transport UDP et 26/90
Efficacité de la fenêtre glissante La fenêtre glissante permet d exploiter au mieux le réseau : Émetteur éseau écepteur émission paquet 1 émission paquet 2 émission paquet 3 émission paquet 4 émission paquet 5 émission paquet 6 émission paquet 7 émission paquet 8 émission paquet 9 envoi de l ACK n 1 envoi de l ACK n 2 envoi de l ACK n 3 envoi de l ACK n 4 envoi de l ACK n 5 envoi de l ACK n 6 envoi de l ACK n 7 26/67 Cyril Pain-Barre Transport UDP et 27/90
Fenêtre glissante et gestion des acquittements Si un paquet de données est perdu, deux possibilités : rejet total (ou global) rejet sélectif 27/67 Cyril Pain-Barre Transport UDP et 28/90
Fenêtre glissante et gestion des acquittements ejet total : aucun paquet suivant celui perdu n est acquitté Émetteur éseau écepteur émission paquet 1 émission paquet 2 émission paquet 3 accepté : envoi de l ACK n 1 émission paquet 4 émission paquet 5 accepté : envoi de l ACK n 2 accepté : envoi de l ACK n 3 émission paquet 6 émission paquet 7 émission paquet 8 émission paquet 9 rejeté : envoi de l ACK n 3 rejeté : envoi de l ACK n 3 rejeté : envoi de l ACK n 3 timeout, réémission paquet 4 rejeté : envoi de l ACK n 3 réémission paquet 5 la fenêtre en réception a une taille de 1 28/67 Cyril Pain-Barre Transport UDP et 29/90
Fenêtre glissante et gestion des acquittements ejet sélectif : paquet de données i perdu la fenêtre en réception a une certaine taille m (de préférence m = n) ceux qui entrent dans la fenêtre sont gardés, les autres sont ignorés mais les ACK pour ces paquets ont pour numéro i 1 si timeout, l émetteur n envoie que le premier paquet non acquitté lorsque paquet i réémis et reçu, l ACK renvoyé est celui du dernier paquet reçu (ou celui avant un autre paquet éventuellement perdu) Fenêtre d émission (taille 15) : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16... Fenêtre de réception (taille 10) : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16... 29/67 Cyril Pain-Barre Transport UDP et 30/90
ejet sélectif : exemple Émetteur émission paquet 1 émission paquet 2 émission paquet 3 émission paquet 4 émission paquet 5 émission paquet 6 émission paquet 7 émission paquet 8 émission paquet 9 émission paquet 10 émission paquet 11 émission paquet 12 réémission paquet 2 émission paquet 13 émission paquet 14 émission paquet 15 émission paquet 16 émission paquet 17 éseau écepteur accepté : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 rejeté : envoi de l ACK n 1 accepté : envoi de l ACK n 11 gardé : envoi de l ACK n 11 gardé : envoi de l ACK n 11 gardé : envoi de l ACK n 11 30/67 Cyril Pain-Barre Transport UDP et 31/90
ejet sélectif : amélioration par NACK Envoi d un (seul) NACK si récepteur se rend compte d une erreur : Émetteur éseau écepteur émission paquet 1 émission paquet 2 émission paquet 3 émission paquet 4 émission paquet 5 émission paquet 6 émission paquet 7 émission paquet 8 émission paquet 9 réémission paquet 2 émission paquet 10 émission paquet 11 émission paquet 12 émission paquet 13 émission paquet 14 émission paquet 15 émission paquet 16 émission paquet 17 accepté : envoi de l ACK n 1 gardé : envoi de NACK n 2 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 1 gardé : envoi de l ACK n 9 gardé : envoi de l ACK n 10 gardé : envoi de l ACK n 11 gardé : envoi de l ACK n 12 gardé : envoi de l ACK n 13 gardé : envoi de l ACK n 14 31/67 Cyril Pain-Barre Transport UDP et 32/90
Transmission bidirectionnelle et superposition Pour une transmission bidirectionnelle : équiper les deux côtés de fenêtres d émission et de réception pas forcément de même taille de chaque côté! amélioration par superposition ou piggybacking : les paquets de données contiennent un indicateur ACK (oui ou non le paquet contient aussi un ACK) et un champ n o ACK :... ACK Num ACK Num Paquet Données 32/67 Cyril Pain-Barre Transport UDP et 33/90
Le protocole : Transmission Control Protocol (FC 793 corrigée par FC 1122 et 1323) 33/67 Cyril Pain-Barre Transport UDP et 34/90
Propriétés du service de Orienté connexion : transfert de flots d octets. La suite d octets remise au destinataire est la même que celle émise Circuits virtuels : une fois une connexion demandée et acceptée, les applications la voient comme un circuit dédié Transferts tamponnés : quelle que soit la taille des blocs de données émis par les applications, est libre de les découper ou de les regrouper Connexions non structurées : pas de frontière placée par entre les messages émis par les applications Connexions full-duplex : les données s échangent dans les deux sens mais un sens de transmission peut être libéré par l émetteur 34/67 Cyril Pain-Barre Transport UDP et 35/90
Adresse d application, port et connexion Comme pour UDP, l adresse d une application est un triplet (adresse IP,, port) : le serveur et le client doivent en posséder une. Le port du client est généralement quelconque. Mais à la différence d UDP, on ne peut envoyer un message directement à une adresse : il faut que le client établisse une connexion avec le serveur. Ils ne peuvent échanger des messages que via une connexion Établissement d une connexion : Serveur : effectue une ouverture passive en écoutant sur un port, c est à dire en demandant un port et en attendant qu un client s y connecte Client : effectue une ouverture active en demandant l établissement d une connexion entre son adresse et celle du serveur. Le serveur doit être en écoute. Les modules du client et du serveur intéragissent pour établir cette connexion. Une fois la connexion établie, le serveur et le client doivent l utiliser pour envoyer/recevoir des messages. est chargé d assurer la fiabilité de la connexion (notamment s occupe des acquittements/ retransmissions) Cyril Pain-Barre Transport UDP et 36/90 35/67
Serveurs et ports réservés Voir http://www.iana.org/assignments/port-numbers Well known Port Assignment : certaines applications bien connues ont des ports UDP réservés [0, 1023]. Exemples : Num (décimal) Application 7 Serveur echo 13 Serveur daytime 20 Serveur FTP (données) 21 Serveur FTP (commandes) 22 Serveur SSH 23 Serveur TELNET 25 Serveur SMTP (transfert de mail) 53 Serveur DNS 80 Serveur HTTP (www) 119 Serveur NNTP (news) les ports [1024, 49151] sont enregistrés (mais peuvent être utilisés) les ports [49152, 65535] sont dits dynamiques et/ou à usage privé 36/67 Cyril Pain-Barre Transport UDP et 37/90
Interface BSD (Unix) pour () et bind() ont la même fonction que pour UDP int listen(int sock, int backlog) (serveur) prépare le SAP pour une ouverture passive int accept(int sock, struct sockaddr *addr, socklen t *addrlen) (serveur) attend une demande de connexion (ouverture passive). envoie un SAP pour la connexion établie et addr contient l adresse du client int connect(int sock, const struct sockaddr *addr, socklen t addrlen) (client) demande l établissement d une connexion (ouverture active) au serveur d adresse addr ssize t send(int sock, const void *buf, size t len, int flags) envoie len octets contenus dans buf à travers la connexion sock ssize t recv(int sock, void *buf, size t len, int flags) reçoit dans buf au plus len octets de la connexion sock int close(int sock) : libère un SAP ( d écoute ou connexion) Cyril Pain-Barre Transport UDP et 38/90 37/67
Ports et connexions Plus complexe qu UDP car un port peut être utilisé pour plusieurs connexions simultanément : un serveur peut accepter plusieurs clients à la fois : chaque appel d accept() retourne une nouvelle connexion utilisant le port du serveur plus rare, un client peut aussi utiliser son port pour établir plusieurs connexions (mais pas vers la même adresse serveur) En dehors des SAP d ouverture passive, gère surtout des objets connexion Une connexion est identifiée par le quadruplet formé avec l adresse de ses deux extrémités : (adresse IP locale, port local, adresse IP distante, port distant) Les connexions sont gérées indépendamment les unes des autres Chaque connexion dispose de ses propres tampons en émission/ réception et de chaque côté 38/67 Cyril Pain-Barre Transport UDP et 39/90
Ports et connexions : exemple AppliB (serveur) Interface Hôte B (139.124.187.4) 39/67 Cyril Pain-Barre Transport UDP et 40/90
Ports et connexions : exemple AppliB (serveur) Ouverture passive () bind() listen() accept() port 80 Hôte B (139.124.187.4) 39/67 Cyril Pain-Barre Transport UDP et 41/90
Ports et connexions : exemple A1 (client) AppliB (serveur) Interface port 80 Hôte A (32.128.54.97) Hôte B (139.124.187.4) 39/67 Cyril Pain-Barre Transport UDP et 42/90
Ports et connexions : exemple Ouverture active () connect() A1 (client) AppliB (serveur) Interface port 80 Hôte A (32.128.54.97) Hôte B (139.124.187.4) 39/67 Cyril Pain-Barre Transport UDP et 43/90
Ports et connexions : exemple Ouverture active A1 (client) AppliB (serveur) () connect() E E Interface connexion #1 port 4321 Hôte A (32.128.54.97) port 80 Hôte B (139.124.187.4) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321) 39/67 Cyril Pain-Barre Transport UDP et 44/90
Ports et connexions : exemple A1 (client) AppliB (serveur) Interface E E connexion #1 port 4321 Hôte A (32.128.54.97) port 80 Hôte B (139.124.187.4) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321) 39/67 Cyril Pain-Barre Transport UDP et 45/90
Ports et connexions : exemple A1 (client) AppliB (serveur) C1 (client) E E connexion #1 port 4321 Hôte A (32.128.54.97) port 80 Hôte B (139.124.187.4) Hôte C (195.10.134.12) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321) 39/67 Cyril Pain-Barre Transport UDP et 46/90
Ports et connexions : exemple A1 (client) AppliB (serveur) C1 (client) E E E E connexion #1 connexion #2 port 4321 Hôte A (32.128.54.97) port 80 Hôte B (139.124.187.4) port 5678 Hôte C (195.10.134.12) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321) Connexion #2 : (139.124.187.4, 80) et (195.10.134.12, 5678) 39/67 Cyril Pain-Barre Transport UDP et 47/90
Flots d octets et segments pour une connexion sert à transmettre des flots d octets dans les deux sens les flots sont transmis par des segments (PDU de ) un segment est transmis par un seul datagramme IP (sauf fragmentation pendant l acheminement) l émetteur transmet à des blocs de données de taille quelconque le récepteur récupère des blocs de données de taille quelconque mais le nombre d octets transportés par un segment est décidé par : pour des raisons d efficacité pour la régulation de flux 40/67 Cyril Pain-Barre Transport UDP et 48/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 49/90
Flots d octets et segments : exemple AppliA données à transmettre send() AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 50/90
Flots d octets et segments : exemple AppliA AppliB placement dans le tampon d émission E connexion établie E port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 51/90
Flots d octets et segments : exemple AppliA autres données à transmettre send() AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 52/90
Flots d octets et segments : exemple AppliA AppliB E E placement dans le tampon d émission connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 53/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 décide de transmettre un segment port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 54/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 en tête IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 55/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 IP IP en tête IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 56/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 IP traversée du réseau (fragmentation possible) IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 57/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 IP traversée du réseau (fragmentation possible) IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 58/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 59/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie placement dans le tampon de réception port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 60/90
Flots d octets et segments : exemple AppliA AppliB E E connexion établie port 4321 peut envoyer un ACK maintenant ou plus tard port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 61/90
Flots d octets et segments : exemple AppliA lecture des données recv() AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 62/90
Flots d octets et segments : exemple AppliA mise à jour des tampons AppliB E E connexion établie port 4321 port 80 IP IP Hôte A (32.128.54.97) Hôte B (139.124.187.4) 41/67 Cyril Pain-Barre Transport UDP et 63/90
Numéro de séquence et fenêtre glissante Pour une transmission efficace, utilise une fenêtre glissante n acquitte pas les segments mais les octets reçus Tous les octets de données transmis portent un numéro : le numéro de séquence Les acquittements indiquent le numéro du prochain octet attendu La fenêtre glissante (émission) comporte alors 3 pointeurs : Fenêtre d émission... 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33... octets transmis et acquités octets transmis mais non encore acquittés octets non encore transmis mais qui peuvent l être octets qu on n est pas encore autorisé à transmettre Chaque côté de la connexion possède une fenêtre d émission et une fenêtre de réception Les acquittements peuvent transiter avec les données (superposition) 42/67 Cyril Pain-Barre Transport UDP et 64/90
Taille de fenêtre variable et contrôle de flux La fenêtre glissante n a pas une taille fixe Les segments (en particulier ACK) contiennent une information taille de fenêtre : A segment avec taille = x B..................... fenêtre actuelle A indique à B la place disponible dans son tampon de réception La réaction de B dépend de la taille annoncée : augmentation : B augmente sa fenêtre et envoie les octets supplémentaires qu elle comprend B..................... fenêtre augmentée diminution : lors du glissement, B diminue sa fenêtre (sans exclure les octets qui y étaient déjà) B..................... fenêtre diminuée 43/67 Cyril Pain-Barre Transport UDP et 65/90
Format des segments Unité de données de protocole (PDU) échangée pour établir/libérer une connexion et transférer/acquitter des données en tête partie fixe (20 octets) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Port Source LET éservé Flags Checksum bits : Numéro de Séquence 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Numéro d Accusé de éception Port Destination Fenêtre Pointeur Urgent 3 0 3 1 taille variable Options (éventuelles) Bourrage taille variable Données 44/67 Cyril Pain-Barre Transport UDP et 66/90
Format des segments Unité de données de protocole (PDU) échangée pour établir/libérer une connexion et transférer/acquitter des données en tête partie fixe (20 octets) taille variable taille variable 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Port Source LET éservé Flags Checksum bits : Numéro de Séquence 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Numéro d Accusé de éception U G A P S F C S S Y I Options (éventuelles) K H T N N 6 bits Données Port Destination Fenêtre Pointeur Urgent Bourrage 3 0 3 1 44/67 Cyril Pain-Barre Transport UDP et 67/90
Segment : champ Numéro de séquence en tête partie fixe (20 octets) taille variable taille variable 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 LET premier octet Port Source éservé bits : Numéro de Séquence 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Numéro d Accusé de éception Flags Port Destination Fenêtre Checksum Indique le numéro que porte Pointeur le premier Urgent octet de données Options (éventuelles) Données Bourrage 3 0 3 1 45/67 Cyril Pain-Barre Transport UDP et 68/90
Segment : champ LET en tête partie fixe (20 octets) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 LET bits : 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Port Source à multiplier Port par 4 pour Destination Numéro longueur de Séquence de l en tête Numéro d Accusé (à cause de éception des options) éservé Checksum Flags Fenêtre Pointeur Urgent 3 0 3 1 taille variable taille variable Options (éventuelles) Données Bourrage 46/67 Cyril Pain-Barre Transport UDP et 69/90
Segment : champ Fenêtre en tête partie fixe (20 octets) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 LET Port Source éservé Checksum bits : Numéro de Séquence 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Numéro d Accusé de éception Flags Port Destination Fenêtre Pointeur Urgent 3 0 3 1 taille variable taille variable Options (éventuelles) indique la place disponible dans le tampon de réception Données Bourrage 47/67 Cyril Pain-Barre Transport UDP et 70/90
Segment : Checksum Obligatoire Vérifie la totalité du segment + Pseudo en-tête. Comme pour UDP, permet de s assurer : que les données sont correctes que les ports sont corrects que les adresses IP sont correctes Même calcul que IP/UDP (bourrage éventuel 1 octet à 0) + pseudo en-tête Pseudo en-tête (interaction avec IP) : (12 octets) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 bits : Adresse IP Source Adresse IP Destination 1 2 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 3 0 3 1 Zone à Zéro Protocole Longueur Segment 6 (en décimal) pour IP 48/67 Cyril Pain-Barre Transport UDP et 71/90
Segment : option MSS Utilisée éventuellement pendant la phase de connexion (uniquement) Format (4 octets) : 8 bits 8 bits Type (2) Longueur Option (4) Valeur MSS Chaque côté indique la taille max des données des segments qu il veut recevoir, appelée MSS (Maximum Segment Size) : souvent MTU - 40 (en-têtes IP et sans option) dépendant de la taille des buffers de reception par défaut 536 (576 octets pour le datagramme IP) Difficile à choisir pour l Internet : si trop petit, perte d efficacité si trop grand, risque de fragmentation L idéal est le plus grand tel qu aucun datagramme n est fragmenté 49/67 Cyril Pain-Barre Transport UDP et 72/90
Données Urgentes (Hors Bande) Émetteur veut envoyer des données en urgence, sans attendre que le récepteur ait lu les données précédentes Exemple : envoi de Ctrl-C pour arrêter le traitement de l application destinataire Le émetteur place les données urgentes et envoie immédiatement le segment Le récepteur interrompt l application destinataire (sous Unix, signal SIGUG) Mise en œuvre par bit UG et Pointeur Urgent : si bit UG = 1 : données urgentes présentes et Pointeur Urgent indique leur fin dans le segment (mais pas leur début) si bit UG = 0 : pas de données urgentes, Pointeur Urgent ignoré U G A C K flags (6 bits) P S H S T S Y N F I N 16 bits Pointeur Urgent 50/67 Cyril Pain-Barre Transport UDP et 73/90
emise forcée Application émettrice demande de ne pas retarder l émission des données, plutôt que de tamponner Particulièrement utile dans le cas d un terminal virtuel : après le retour à la ligne, il faut envoyer, voire même pour chaque caractère tapé ou déplacement de souris (X-Window) émetteur place le bit PSH à 1 : flags (6 bits) U G A C K P S H S T S Y N F I N Le récepteur doit remettre les données au plus vite (ne pas tamponner dans sa mémoire) 51/67 Cyril Pain-Barre Transport UDP et 74/90
Acquittements et etransmissions Le bit ACK à 1 indique que le champ Numéro d Accusé de éception doit être utilisé U G A C K flags (6 bits) P S H S T S Y N F I N 32 bits Numéro d Accusé de éception Un segment non acquitté est retransmis après timeout Un segment retransmis peut contenir plus de données que le précédent Numéro ACK n acquitte pas le segment : indique le numéro du prochain octet attendu L ACK est cumulatif : a des avantages et des inconvénients ejet global ou sélectif (le plus courant) En pratique l émetteur ne renvoie que le premier segment non acquitté 52/67 Cyril Pain-Barre Transport UDP et 75/90
Établissement d une connexion En 3 temps, avec bits SYN et ACK U G A C K P S H S T S Y N F I N Émetteur éseau écepteur Émission SYN, séq=x éception SYN Émission SYN séq=y, ACK x+1 éception SYN, ACK Émission ACK y+1 (connexion établie) éception ACK (connexion établie) Permet d ignorer des demandes retardées ésoud aussi les connexions simultanées des deux côtés Numéro de Séquence choisi (presque) aléatoirement dans chaque sens 53/67 Cyril Pain-Barre Transport UDP et 76/90
Libération d une connexion Processus en trois temps modifié, avec bits FIN et ACK Connexion libérée lorsque chaque côté a indiqué qu il n avait plus de données à émettre : Émetteur éseau écepteur Émission FIN séq=x U G A C K P S H S T S Y N F I N éception FIN Émission ACK x+1 éception ACK plus de données vers récepteur des données peuvent être transmises Émission FIN séq=y, ACK x+1 éception FIN Émission ACK y+1 Armement timer éception ACK Armement timer À la fin, un temporisateur est utilisé pour laisser le temps aux segments retardés d arriver ou d être détruits Puis les données relatives à la connexion sont détruites 54/67 Cyril Pain-Barre Transport UDP et 77/90
Fermeture brutale d une connexion Bit ST à 1 : Signifie qu il a y eu un problème grave U G Connexion libérée immédiatement Données non traitées/segments retardés sont perdus Applications sont informées Utilisé aussi pour refuser une demande de connexion A C K P S H S T S Y N F I N 55/67 Cyril Pain-Barre Transport UDP et 78/90
Temporisation et retransmission Un segment (données) non acquitté doit être retransmis Problèmes importants sur Internet : comment calculer/estimer le TT (ound Trip Time)? quelle durée du temporisateur? source : /IP Architecture, protocoles, applications. D. Comer, Edts Dunod 56/67 Cyril Pain-Barre Transport UDP et 79/90
Ajustement dynamique du TT estimé Pour chaque connexion, gère une variable TT Soit M = temps mis pour retour de l ACK d un segment TT est mis à jour selon la formule : TT = αtt + (1 α)m où 0 α 1 (généralement 7/8) est le poids attribué à l anciennce valeur de TT Valeur du timer T = βtt (à l origine du standard β = 2) Jacobson (1988) a proposé une amélioration du calcul de TT et de T, pour tenir compte de la variance. Devenu la règle depuis 1989 : Diff = M TT TT = TT δ Diff, où généralement δ vaut 1/2 3 Dev = Dev + ρ ( Diff Dev), où généralement ρ vaut 1/2 2 T = TT + η Dev, où généralement η vaut 4 57/67 Cyril Pain-Barre Transport UDP et 80/90
Ajustement dynamique du timer : exemple En pointillés, des valeurs aléatoires de TT. En trait plein, le timer calculé : source : /IP Architecture, protocoles, applications. D. Comer, Edts Dunod 58/67 Cyril Pain-Barre Transport UDP et 81/90
TT et Algorithme de Karn Problème : si un segment est retransmis et un ACK reçu, doit-il être pris pour le premier ou le dernier segment? Selon le choix, le calcul de TT et de T peut être grandement faussé! Algorithme de Karn (radio amateur) : Ne pas mesurer M pour un segment retransmis Mais augmenter T, selon la formule : où généralement γ vaut 2. T = γ T 59/67 Cyril Pain-Barre Transport UDP et 82/90
Timer et grandes variations TT source : /IP Architecture, protocoles, applications. D. Comer, Edts Dunod Il reste des situations impossibles à prévoir mais la réaction est généralement très bonne. 60/67 Cyril Pain-Barre Transport UDP et 83/90
Syndrome de la fenêtre stupide Soit une application qui ne lit les données qu octet par octet L émetteur envoie suffisamment d octets pour remplir le tampon de réception Le récepteur envoie une taille de fenêtre nulle Lorsque l application lit un octet, enverra une taille de fenêtre de 1 L émetteur peut alors envoyer 1 octet! Puis taille de fenêtre 0 etc. C est pas mieux si c est l émetteur qui envoie de lui-même des petits segments! 61/67 Cyril Pain-Barre Transport UDP et 84/90
Éviter la fenêtre stupide Côté récepteur : (Algorithme de Clark) n annoncer une réouverture de la fenêtre que lorsque sa taille est : soit égale à la moitié du tampon de réception soit égale au MSS Côté émetteur : (Algorithme de Nagle) retarder le plus possible l envoi : si des données n ont pas été acquittées, placer les nouvelles données en tampon ne les envoyer que si atteint taille maximale du segment ou la moitié de la fenêtre d émission lorsqu un ACK arrive, envoyer ce qu il y a (même si le segment n est pas plein) ceci même en cas de PUSH! Il est parfois nécessaire de désactiver l algo de Nagle, notamment pour X-Window (il faut envoyer les mouvements de la souris de suite et non les tamponner... ). 62/67 Cyril Pain-Barre Transport UDP et 85/90
et la congestion La congestion produit des retards importants et des pertes de datagrammes etransmettre des segments retardés/détruits aggrave la congestion jusqu à l effondrement congestif en tient compte et cherche à éviter la congestion et réagit en cas de congestion : démarrage lent diminution dichotomique Nécessite la gestion d une fenêtre de congestion Fenêtre utilisée = min(fenêtre récepteur, Fenêtre congestion) 63/67 Cyril Pain-Barre Transport UDP et 86/90
et la congestion : démarrage lent Au début de la connexion ou suite à une congestion, effectuer un démarrage lent avec fenêtre congestion = 1 segment Démarrage lent : pour chaque segment acquitté, augmenter de 1 segment la fenêtre de congestion lent mais croissance exponentielle! 64/67 Cyril Pain-Barre Transport UDP et 87/90
et la congestion : diminution dichotomique estime que la perte d un segment est due à la congestion Si segment perdu, fixer un seuil à la moitié de la fenêtre de congestion (taille mini = 1 segment) Augmenter la temporisation (algo de Karn) ecommencer un démarrage lent jusqu à atteindre le seuil phase d évitement de congestion : à partir du seuil, n augmenter que de 1 segment pour l ensemble des segments acquittés (croissance linéaire) 65/67 Cyril Pain-Barre Transport UDP et 88/90
et la congestion : illustration taille fenêtre (nombre de segments) 17 16 15 14 non acquitté : nouvelle fenêtre (évitement à partir de 8) + doublement temporisateur 13 12 11 non acquitté : nouvelle fenêtre (évitement à partir de 6) + doublement temporisateur 10 9 8 7 6 5 4 3 mise à jour TT et timer mise à jour TT et timer mise à jour TT et timer 2 1 temps démarrage lent évitement congestion démarrage lent évitement congestion 66/67 Cyril Pain-Barre Transport UDP et 89/90
Automate d états fini de transitions d états : événement / action, où : événement : italiques : primitive appelée par le programme ACK, SYN, etc. : réception d un segment avec ce bit positionné action : ACK, SYN, etc. : envoi segment - : rien tempo : temporisation de 2 fois la durée de vie d un segment en pointillés, les événements exceptionnels SYN reçu Fermer / FIN ACK / Fin Attente 1 Fin Attente 2 Début SYN / SYN + ACK Ouverture passive ST/ Fermer / FIN FIN / ACK ACK / FIN + ACK / ACK FIN / ACK Fermé Fermer Écoute Connexion établie Fermer en cours Tempori sation Émission / SYN SYN / SYN + ACK ACK / Ouverture active / SYN SYN émis SYN + ACK / ACK FIN / ACK Attente Fermer Dernier ACK Fermer / tempo Fermer / FIN ACK / tempo 67/67 Cyril Pain-Barre Transport UDP et 90/90