Les Réseaux Informatiques DEUST AMMILoR Les Réseaux Informatiques Couche Transport Protocoles TCP et UDP Questions sur les cours précédents ? Laurent JEANPIERRE 2002 - 2003

Rôle de la couches OSI.4 Couche transport Communication de bout en bout Abstraction de la structure du réseau Donnée  Message Multiplexage 1 machine n services 1 service n machines Transport Réseau Couche 4 Indépendant de la structure des réseaux Multiplexage ( donner des exemples ) Plusieurs services par machine Plusieurs machines par service LLC MAC Couche Physique

Rôle des couches OSI (4b) Couche transport TCP Connecté Messages remis dans le bon ordre Aucun message perdu Aucun message abîmé UDP Non connecté Rapide Aucune garantie Transport Réseau TCP => Connecté => Service Garanti Messages délivrés dans le bon ordre Messages ni perdus ni abimés Contrôle de flux UDP => spécial LLC MAC Couche Physique

Fondations et Besoins La couche Réseau permet MAIS Envoi de données de taille quelconque Adressage unique des machines Contact d’une machine arbitraire (routage) MAIS Aucune garantie d’arrivée Aucun respect de l’ordre Une seule connexion par machine

Le protocole UDP User Datagram Protocol Gère le multiplexage Protocole léger Usage général Gère le multiplexage Plusieurs connexions par machine Multiplexage temporel Besoin d’adresse plus fine que IP  Notion de « port »

Notion de port UDP 1 « port »  1 point d’accès « adresse » de service Numéro sur 16 bits (0  65535) Deux classes de ports 0  1000 : Ports réservés « well known ports» 1001  65535 : Ports libres Pas d’utilisation précise Souvent alloués par le système

Connexion UDP Un transfert UDP est caractérisé par : @ IP source @ IP destination Port source Port destination Connexion à usage unique Le port client est rendu après utilisation Le port serveur attend un autre client

Exemple Le protocole HTTP Requête HTTP : Surcouche de UDP Le Client demande un port UDP  1843 Le Client envoie datagramme IPclient:1843  IPserveur:80 Le Serveur envoie une réponse (page Web) IPserveur:80  IPClient:1843 Le port 1843 est rendu à la machine Client

Trame UDP 8 octets Port source (16 bits) Port destination (16 bits) Longueur totale (16 bits) Entête : 8 octets Données : 0  65527 octets Somme de contrôle (16 bits)

Trame UDP (2) Entête Ethernet Entête IP Entête UDP Données 8 octets 20 octets 8 octets 1472 octets Entête Ethernet Entête IP Données Voici par exemple un bloc de données à envoyer par UDP. On va donc lui ajouter une entête UDP, de 8 octets. Ce datagramme va être encapsulé dans une trame IP; 20 octets d’entête Ce paquet IP va être transporté dans une trame Ethernet; 8 octets d’entête Le CRC de 4 octets n’a pas été représenté Dans ces conditions, combien peut-on transporter de données ? 1472, bien sûr. Si plus que cela à transporter ? Nouvelle trame Ethernet, toujours 8 octets. Et ensuite ? Nouvelle entête IP, toujours 20 octets; l’offset du fragment est réglée sur 1472 octets (=184*8) Et ensuite ? La suite des données… pour 1480 octets. (185*8) Le prochain fragment sera donc à 184+185=369 ( 2952) 8 octets 20 octets 1480 octets

Bilan Protocole léger Ports clients à usage unique 8 octets pour 64Ko Ports clients à usage unique 1 Port serveur sert plusieurs clients Multiplexage temporel Aucune garantie D’ordre D’arrivée

Le protocole TCP Transport Control Protocol Communication en mode connecté Ouverture d’un canal Communication Full-Duplex Fermeture du canal La connexion sécurise la communication Ordre garanti Arrivée garantie

Arrivée garantie Comment savoir si un paquet arrive ?  Accusé de réception Machine 1 Machine 2 Envoi de message Réception Accuse réception Reçoit accusé Envoi suite du message Trop long ! Ré-envoi du message Réception Accuse réception

Utilisation du réseau Gaspillage de bande passante ! Envoi de données Attente Envoi d’acknowledge … On peut faire mieux !  fenêtrage

Fenêtres TCP Idée : prendre de l’avance sur les réponses  fenêtre glissante D 0 D 1 D 2 D 3 D 4 D 5

Notion de segments UDP gère des messages TCP gère une communication Echange soutenu entre deux machines Durée importante Messages  Flux de données Taille inconnue à l’avance  segmentation TCP gère des segments de 64K (ou moins)

Réception Chaque segment est un morceau Ressemble à la fragmentation IP Ordre nécessaire pour recomposer le message initial IP ne garantit pas l’ordre Chaque paquet est routé séparément Certains routeurs équilibrent la charge des réseaux  routes différentes pour paquets successifs Problème des pertes de trames  trou dans la séquence ( retransmission) Fenêtre glissante  retard d’un segment  les segments sont reçus en désordre

Notion de séquence Introduction d’un « numéro de segment »  introduit un ordre sur les segments  permet d’accuser réception d’un segment particulier Un même numéro ne doit pas être réutilisé Risque de confusion  durée de vie limitée (2 minutes)

Choix du numéro de séquence Rappel : Donne un numéro d’octet Spécifique à une connexion donnée Mêmes IPs Mêmes ports Unique par période de 2 minutes Choix basé sur l’horloge de la machine +1 toutes les 4 ms +1 toutes les 4 micro-secondes 32 bits = 4 milliards 4E9 * 4us = 17 179,869184 secondes = 4,7721858844 heures = 4H46 minutes 20 secondes 32 bits  8 589 934 592 bits À 10Mbps, 859 secondes Mais, MTU=1500 octets, -20 IP => 1480, -20 TCP => 1460 Sur 10 Mbps, 4,4% passent dans les entêtes.  897 secondes 14 minutes, 58 secondes A 100 Mbps, 1 minute 30 secondes… si 100% bande passante allouée ! + ajouter acknowledges Encore bon. Passer en 10Gbps ?  risque non nul. Autre solution ????????

Numéros de séquence (2) Numéro initial variable Comment identifier le premier segment ?  Synchronisation nécessaire Elément essentiel de l’ouverture de connexion « three-way handshaking » Synchro, Séq = xxx Synchro, Séq = yyy; Ack xxx+1 Ack yyy+1 Les messages de synchronisation ne contiennent aucune donnée. Ils comptent quand même pour 1 octet.

Entête TCP Port Source Port Destination Numéro de séquence Numéro d’acknowledge Réservé Long Drapeaux Longueur de l’entête En mots de 32 bits Urgent Acknowledge Push Reset Synchro Fin

Somme de contrôle d’erreurs Entête TCP Port Source Port Destination Numéro de séquence Numéro d’acknowledge Long Réservé Drapeaux Taille de fenêtre Somme de contrôle d’erreurs Pointeur Urgent Options

Bilan Une connexion TCP : Ouverture de connexion Sychronisation Acknowledge Synchronisation Envoi de trames selon fenêtre disponible Si accusé réception, décaler la fenêtre Si TimeOut, ré-envoyer le segment fautif Envoi trame de fin Accuse réception de la trame de fin

Exemple D1 : Séq=1565 ACK 124 D3 : Séq=3565 ACK 124 TimeOut D1 SYN Séq=564 Voici un exemple de communication TCP. Je prendrai à nouveau une fenêtre de 2 segments pour des raisons de place sur la diapo…  La machine 1 ouvre la communication. Elle initie donc le Three Ways Handshake en choisissant un numéro de séquence basé sur son horloge. (564) La machine 2 reçoit le message, initialise son Séq (123) et mémorise celui de la machine 1. Comme chaque datagramme contient un numéro de Séq & Ack, elle peut transmettre son propre n° en même temps que l’ack. D’où gain de bande passante. La M1 reçoit Séq&Ack de M2. La 1° trame est validée, et la connexion est ouverte. On envoie donc un premier segment de données, +Ack du SYN de M2. M2 reçoit Ack SYN2 et marque la connexion comme ouverte. Pendant ce temps, M1 envoie un second segment. N’ayant pas de données à transmettre, M2 se borne à envoyer un Ack Ici, on supposera que l’une des trames de D1 s’est perdue. Quand M1 reçoit l’Ack de D0, elle retire D0 de sa fenêtre. On peut alors envoyer le segment D2 puisque seule D1 est en attente. Comme M2 n’a pas reçu D1, elle n’Ack pas la trame D2. Au bout d’un temps d’attente, M1 réémet le segment D1 pour lequel elle n’a pas eu de confirmation. M2 reçoit D1, et Ack D2. Ainsi, elle indique qu’elle a bien reçu tous les octets depuis SYN, et qu’elle attend le suivant (3565) M1 reçoit l’Ack de D2, nettoie sa fenêtre et relance l’émission avec le segment D3. ................ SYN Séq=123 ACK 565 ACK 1565 ACK 3565

Conclusion La couche 4 améliore les services de couche 3 UDP TCP Multiplexage de services Protocole très léger TCP Full-Duplex Service garanti Acknowledges  arrivée garantie des segments Séquencement  ordre garanti des segments Acknowledges cumulés  pas trop de gaspillage

Et après ? Couche 4  Accroche de base des applications Tous les services principaux sont offerts Suite du cours ? Couche logicielle FTP DHCP/DNS Serveurs fichiers et d’utilisateurs Serveur Web / Serveur de courrier