Couche Transport Protocoles TCP et UDP

Présentation au sujet: "Couche Transport Protocoles TCP et UDP"— Transcription de la présentation:

1 Couche Transport Protocoles TCP et UDP
Les Réseaux Informatiques Couche Transport Protocoles TCP et UDP Questions sur les cours précédents ? Boukli HACENE Sofiane

2 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

3 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

4 Fondations et Besoins La couche Réseau permet MAIS
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

5 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 »

6 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  1024 : Ports réservés (FTP=22, HTTP=80, …) « well known ports» 1025  : Ports libres Pas d’utilisation précise Souvent alloués par le système

7 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

8 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

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

10 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 à =369 ( 2952) 8 octets 20 octets 1480 octets

11 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

12 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

13 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

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

15 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

16 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)

17 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

18 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)

19 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 = , secondes = 4, heures = 4H46 minutes 20 secondes 32 bits  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 ????????

20 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.

21 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 565 ACK 1565

22 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

23 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

24 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

25 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

26 Et après ? Couche 4  Accroche de base des applications
Tous les services principaux sont offerts Suite du cours ?