La couche transport.

La couche transport

La couche Transport Notions de base
Création d'une couche de transport fiable transmission fiable des données établissement de la connexion libération de la connexion UDP : un protocole de transport sans connexion TCP : un protocole de transport orienté connexion fiable

La couche Transport objectifs Les services de la couche Transport
Segments Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical objectifs Améliore le service fourni par la couche réseau pour lui permettre d'être utilisable par les applications fiabilité multiplexge Les services de la couche Transport service sans connexion non fiable service orienté connexion Fiable

La couche Transport Network Packets Network Packets Network Datalink Datalink Datalink Physical Physical Physical Service de couche réseau (Internet) service sans connexion non fiable Les paquets peuvent être perdus Erreurs de transmission paquets n'arrivent pas en ordre Paquet peut être dupliqué La taille des paquets est limitée (environ 64 Ko)

La couche Transport La couche Transport doit résoudre plusieurs problèmes. La couche application doit permettre aux applications d’échanger les informations. Une méthode pour identifier les applications est nécessaire. Un service de la couche transport doit être utilisable par les applications. Détection des erreurs de transmission correction des erreurs de transmission Résoudre les problèmes des pertes de paquets et les paquets dupliqués.

La couche Transport(2) Organisation interne
La couche transport utilise les services fournis par la couche réseau. Deux entités de la couche transport échangent les segments Application Application ADU Segment Transport entity Transport layer Transport entity Packet Network Network

Les protocoles de la couche transport
Comment peut-on assurer un service fiable dans la couche transport Hypothèses Les applications envoient des petits SDUs La couche réseau fournit un service parfait Il n’y a pas des erreurs de transmission dans les paquets Il n’y a pas de perte de paquets Les paquets arrivent pas en ordre Il n’y a pas de paquets dupliqués La transmission de données est unidirectionnel

Les protocoles de la couche transport (2)
L’environment Notations data.req et data.ind primitives pour les interactions application/transport recv() et send() pour les interactions couche transport/réseau Application Application ADU Segment Entité Transport La couche Transport Entité Transport Packet Network Network

Protocol 1 : Notions de base
A B Data.request(a) Segment(a) Data.ind(a)

Protocole 1 :(MEF) émetteur Récepteur Data.req(SDU) send(SDU)
Wait for SDU recvd(SDU) Data.ind(SDU) Wait for segment

Protocole 1 : Exemple Problème: A B Data.request(a) Segment(a)
Data.ind(a) Data.request(b) Segment(b) Data.ind(b) Data.request(c) Segment(c) Data.ind(c) Problème: Le récepteur est plus lent que l’émetteur!!->???.

Protocol 2 Principe Conséquences
Utiliser un segment de contrôle (OK) qui est envoyé par le récepteur après le traitement d’un segment reçu Conséquences Deux type de segments: Un segment de données qui contient un SDU Notation : D(SDU) Un segment de contrôle Notation : C(OK) Format de segment Au moins un bit dans le segment pour indiquer le type de segment Type

Protocole 2 (cont.) Emetteur Récepteur Data.req(SDU) send(D(SDU))
Wait for SDU Wait for OK Recvd(C(OK)) - Recvd(D(SDU)) Data.ind(SDU) Wait for segment Process SDU - Send(C(OK))

Protocole 2 : Exemple A B Data.req(a) D(a) C(OK) Data.req(b)
Data.ind(a) D(a) Data.req(a) C(OK) Data.req(b) D(b) C(OK) Data.ind(b)

Les protocoles de la couche transport
Comment peut-on assurer un service fiable dans la couche transport Hypothèses Les applications envoient des petits SDUs La couche réseau fournit un service parfait Il y des erreurs de transmission Il n’y a pas de perte de paquets Les paquets arrivent pas en ordre Il n’y a pas de paquets dupliqués La transmission de données est unidirectionnel

Protocole 3a : émetteur Emetteur Recvd(C(NAK)) Data.req(SDU)
send(D(SDU,CRC)) Data.req(SDU) send(D(SDU,CRC)) Wait for SDU Wait for OK/NAK Recvd(C(OK)) -

AND Not(IsOK(CRC,SDU))
Protocol 3a : Receiver Récepteur Recvd(D(SDU,CRC)) AND IsOK(CRC,SDU) Data.ind(SDU) Process segment OK Wait for segment Send(C(OK)) - Send(C(NAK)) - Process segment KO Recvd(D(SDU,CRC)) AND Not(IsOK(CRC,SDU)) -

Protocole 3a : Example A B Data.req(a) D(a) C(OK) Data.ind(a)
Data.req(b) D(b') Transmission error C(NAK) Invalid checksum Retransmission D(b) C(OK) Data.ind(b)

A Protocol 3b Comment peut-on assurer un service fiable dans la couche transport Hypothèses Les applications envoient des petits SDUs La couche réseau fournit un service parfait Il y des erreurs de transmission Les paquets peuvent être perdus Les paquets arrivent pas en ordre Il n’y a pas de paquets dupliqués La transmission de données est unidirectionnel

Protocole 3a et perte de paquets
Comment les pertes des segments affectent le protocole 3a ? A B Data.ind(a) D(a) Data.req(a) C(OK) Data.req(b) D(b) Segment perdu B attend un segment A attend segment de contrôle INTERBLOCAGE

Protocole 3b Modification au niveau de l’émetteur
Non modification au niveau du récepteur Data.req(SDU) send(D(SDU,CRC)) start_timer() Recvd(C(NAK)) send(D(SDU,CRC)) restart_timer() Wait for SDU Wait for OK/NAK Recvd(C(OK)) cancel_timer() Timer expires send(D(SDU,CRC)) restart_timer()

Protocole 3b : Exemple Est-ce que ce protocole fonctionne très bien?
A B Data.ind(a) D(a) Data.req(a) start timer C(OK) cancel timer Data.req(b) D(b) Segment perdu start timer Data.ind(b) D(b) timer expires C(OK) Est-ce que ce protocole fonctionne très bien?

Data.ind(b) Protocol 3b : Example Comment résoudre ce problème? A B
Data.ind(a) D(a) Data.req(a) start timer C(OK) cancel timer Data.req(b) D(b) start timer Lost segment C(OK) Data.ind(b) D(b) timer expires C(OK) Data.ind(b) Comment résoudre ce problème?

Protocole du bit alterné Exemple
A B Data.ind(a) D(0,a) Data.req(a) C(OK0) Data.req(b) Retransmission timer D(1,b) Data.ind(b) D(1,b) C(OK1) D(1,b) recvd Duplicate detected C(OK1) D(1,b) recvd Data.req(c) Segment perdu D(0,c) Retransmission timer Data.ind(c) D(0,c)

Performance du protcole du bit alterné
Quelle est la performance de ce protocole? Data Ack 520 msec 1000/50000 = 20 msec 250 msec

Comment améliorer la performance du protocole PBA?
Utilisation de Pipeline A B Data.ind(a) Data.req(a) ... D(0,a) D(4,e) Data.req(b) Data.req(e) Data.ind(e)

Comment améliorer la performance du protocole PBA? (2)
Modifications pour PBA Numéro de séquence (NS) dans chaque segment Chaque segment de données contient son propre NS Chaque segment de contrôle indique le NS (OK/NAK) On doit avoir des buffers pour stocker les segments de données non acquittés Problème: buffers overflow

Sliding window Principe ... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ....
seq. num. non autorisés Segments acquittés seq. nums disponibles segments non acquittés

Sliding windows : exemple
A B Sending window Data.req(a) Data.ind(a) D(0,a) Data.req(b) Data.ind(b) D(1,b) Data.req(c) Data.ind(c) D(2,c) C(OK0) C(OK1) Data.req(d) Data.ind(d) D(3,d) C(OK2) Data.req(e) D(4,e)

Codage des numéros de séquence
Utiliser N bits signifie 2N NS placer dans chaque segment transmit son NS modulo 2N Le même NS est utilisé pour plusieurs segments.

Sliding window : exemple2
2 bits pour les NS A B Sending window Data.req(a) Data.ind(a) D(0,a) Data.req(b) Data.ind(b) D(1,b) Data.req(c) Data.ind(c) D(2,c) C(OK0) C(OK1) Data.req(d) Data.ind(d) D(3,d) C(OK2) Data.req(e) D(0,e)

Go-Back-N : Example A B Sending window 0 1 2 3 Data.req(a) 0 1 2 3
Data.ind(a) D(0,a) Data.req(b) D(1,b) Transmission error Data.req(c) D(2,c) C(OK,0) Invalid CRC, discarded C(NAK,1) Retransmission Not expected seq num, discarded C(OK,0) Data.req(d) D(3,d) Data.ind(d) D(1,b) Data.ind(b) D(2,c) Data.ind(c) Data.req(e)

Go-Back-N : Exemple (2) A B Sending window 0 1 2 3 Data.req(a) 0 1 2 3
Data.ind(a) D(0,a) Data.req(b) D(1,b) Segment lost Data.req(c) D(2,c) C(OK,0) Retransmission timer expires Not expected seq num, discarded C(OK,0) Data.req(d) D(3,d) Data.ind(d) D(1,b) Data.ind(b) D(2,c) Data.ind(c) Data.req(e)

Selective Repeat : Exemple
A B Sending window Rec. window Data.req(a) Data.ind(a) D(0,a) Data.req(b) D(1,b) Transmission error Data.req(c) D(2,c) C(OK,0) Discard segment C(NAK,1) Retransmission Segment stored C(OK,0) D(1,b) Data.req(d) D(3,d) Data.ind(d) Data.ind(b) C(OK,2) Data.ind(c) C(OK,3)

Selective Repeat : Exemple (2)
A B Sending window Rec. window Data.req(a) Data.ind(a) D(0,a) Data.req(b) D(1,b) Lost segment Data.req(c) D(2,c) C(OK,0) Retransmission timer expires Segment stored C(OK,0) D(1,b) Data.req(d) D(3,d) Data.ind(d) Data.ind(b) C(OK,2) Data.ind(c) C(OK,3)

Etablissement de la connexion
Comment établir une connexion de transport entre deux entités de transport? La couche de transport utilise le service de la couche réseau non fiable Les erreurs de transmission sont possibles Les segments peuvent être perdus Les segments peuvent être réordonnés Les segments peuvent être dupliqués

Solution simple principe 2 segments de contrôle
Connect.req CR Connect.ind Connect.resp Connect.conf CA Connection établie Connection établie principe 2 segments de contrôle CR est utilisé pour demander un établissement de la connexion CA est utilisée pour aquiter un établissement de la connexion? Est-ce que cette solution est suffisante?

Solution simple (2) Comment faire face aux pertes et aux erreurs de transmission? CRC ou checksum. Retransmission timer. CR Connect.req() Retransmission timer expires CR Connect.ind() Connect.resp Connect.conf() CA Connection établie Connection établie

Etablissement de la connexion
Connect.ind() CR Connect.req() Connect.resp Connect.conf() CA Connexion 1 établie Connexion 1 établie Connexion 1 arrétée CR Old previous CR CR dupliquée CA D

Etablissement de la connexion (2)
Comment détecter les segments dupliqués? Principe La durée de vie de paquet ne peut pas dépasser une durée déterminée. Les entités de transport utilisent une horloge locale

Three way handshake A B CR (seq=x) CA (seq=y, ack=x) Connexion établie
Numéro de séquence x, (La valeur de l’horloge locale) CR (seq=x) Numéro de séquence y, (La valeur de l’horloge locale) CA (seq=y, ack=x) Connexion établie CA (seq=x, ack=y) Connexion établie D(x) D(y)

Three way handshake (2) CR dupliquée A B CR (seq=z) CA (seq=y, ack=z)
REJECT (ack=y) Connection annulée aucune connexion n'est établie

Three way handshake (3) A B CR (seq=z) CA (seq=y, ack=x)
Expiration de timer CA (seq=y, ack=x) REJECT (ack=y) ignoré CR (seq=z) CA (seq=w, ack=z) CA (seq=z, ack=w)

Three way handshake (4) Un autre scenario A B CR (seq=z)
CA (seq=w, ack=z) REJECT (ack=w) CA (seq=z, ack=y) REJECT (ack=z) aucune connexion n'est établie

Libération de la Connexion
Une connexion transport peut être utilisée dans les deux sens. Types de libération de connextion Abrupt connection release Une des deux entités transport ferme la connexion dans les deux sens. Possibilité de perte de données Graceful release Chaque entité ferme la connexion (un seul sens) Connexion libérée après le transfert de données.

Abrupt release Data.req() Data.req() Data.ind() Disc.req() Disc.req()
CR (seq=z) CA (seq=w, ack=z) CA (seq=z, ack=w) D Data.req() Data.ind() D Data.req() Disc.req() DR Disc.req() Connexion fermée Segment perdu Connexion fermée

Abrupt release (2) La couche transport peut libérer la connexion Si:
le même segment de données a été transmis plusieurs fois sans recevoir un ack. la couche réseau indique que l'hôte destinataire n'est plus accessible l'entité de la couche de transport n'a pas suffisamment de ressources disponibles.

Graceful shutdown DISCONNECT.req (A-B) DR(A-B) DISCONNECT.ind(A-B)
ACK DISCONNECT.conf(A-B) (A->B) fermée (A->B) fermée DISCONNECT.req(B-A) DISCONNECT.ind(B-A) DR(B-A) (B->A) fermée ACK DISCONNECT.conf(A-B) (B->A) fermée

Un protocole de transport simple
User Datagram Protocol (UDP) Le protocole transport le plus simple But Permet aux applications d’échanger des petits SDUs en utilisant le service IP L’implémentation de UDP doit être simple.

Checksum :(UDP segment | partie de l’entete IP)
Le protocole UDP 2 entités UDP échange des segments UDP UDP segment format Identifie l’application destinatire Identifie l’application qui a envoyé le segment 32 bits Source Port Destination port Contrainte: aucune segmentation 8 octes UDP length UDP Checksum Checksum :(UDP segment | partie de l’entete IP) Payload

Le protocole UDP (2) Utilisation of the UDP ports Requête Client
Port Source : 1234 Port Destination : 5678 Serveur Réponse Port Source : 5678 Port Destination : 1234

Limitations de service UDP
La taille Max des SDUs UDP dépend de la taille max des paquets IP. Les SDUs peuvent être perdus Ne garantit pas l’ordre des SDUs UDP ne détecte pas les SDUs dupliqués

Utilisation de UDP Applications requête-réponse DNS
Remote Procedure Call NFS Games Voice over IP Video over IP

TCP Transmission Control Protocol Fournit un service fiable
Caractéristiques du service TCP Connexion TCP Le transfert de données est fiable Pas de pertes Pas des erreurs Pas de duplication Le transfert de données est bidirectionnel TCP Utilise le service IP TCP fonctionne seulement en mode unicast

Connexion TCP Comment identifier une connexion TCP
@ de l’application source (IP+Port) @de l’application destinataire Chaque segment TCP contient l’id de la connexion.

Protocole TCP

Le segment TCP Les 6 indicateurs
URG : valide le champ « Ptr données urgentes » ACK : valide le champ NR PSH : PUSH indique au récepteur de délivrer immédiatement les données en attente sur le récepteur RST : demande au destinataire de réinitialiser la connexion ou rejet d'une demande de connexion SYN : demande de connexion (échange des ISN) FIN : demande de déconnexion

Le segment TCP Numéro de séquence NS (émission)
comptabilise les octets depuis le début de la connexion ISN : numéro de séquence initial, valeur "aléatoire« acquittée lors de l'établissement de la connexion le numéro de séquence du premier octet transmis est ISN+1 puis NS=ISN+nb_octets_transmis+1 Numéro de séquence NR (réception) le récepteur renvoie le numéro du prochain octet attendu soit NS_reçu+taille_données_reçues

Le numéro de séquence initial (ISN)
Chaque entité communique son ISN à l'autre à l'ouverture de la connexion Il permet de distinguer les octets de deux connexions successives utilisant les mêmes adresses de transport ouverture de la connexion échanges de segments fermeture de la connexion … Un même ISN est tiré toutes les 4h30 environ

Numéro de séquence et ACK
Principe du piggybacking : un segment peut contenir des données et acquitter un segment précédent SEQ=numéro du premier octet dans le segment depuis l'ouverture de la connexion SEQa=numéro du prochain octet attendu L'acquittement d'un octet acquitte tous les octets précédents

Fermeture d'une connexion TCP
Fermeture négociée demande de fin de connexion (FIN) par une des extrémités acquittement du FIN (ACK) mais mise en attente de la demande (B a encore des données non transmises) B envoie ses données en attente A acquitte les données (ACK) acceptation de la fin de connexion par B (FIN) acquittement de la fin de connexion (ACK)

Taille des segments TCP
Souplesse de TCP : l'application lit/écrit dans un tampon TCP décide quand envoyer/restituer un segment (si PSH n'est pas positionné) Idée : TCP a intérêt d'envoyer des segments de taille maximale (limitation de l'overhead lié à la taille de l'en-tête) fragmentation IP coûteuse --> éviter la fragmentation la taille max. d'un segment TCP est de 64Ko (à cause d'IP) MSS : Maximum Segment Size (sans en-tête) à l'ouverture de la connexion, chaque entité peut annoncer (option TCP) son MSS à l'autre, en fonction de la MTU de son réseau (MSS=MTU-40)

Politique de retransmissions
Les pertes de segment sont détectées par absence d'ack positif à expiration d'un temporisateur sur l'émetteur 1 tempo. par seg. Toutes les données reçues hors séquence sont mémorisées par le destinataire SEQ=X,700 octets

Retransmissions rapides (Fast Retransmit)
Idée : il est de toute façon pénalisant d'attendre l'expiration du RTO pour retransmettre quand le récepteur reçoit des données hors-séquence, il renvoie immédiatement un ACK indiquant les données qu'il attend si l'émetteur a reçu 3 ACK dupliqués (4 ACK avec le même numéro de séquence attendu), il retransmet sans attendre l'expiration du RTO Suppositions de cas de perte : expiration du RTO --> pas d'ACK dupliqués, congestion dans le réseau (plusieurs segments sont perdus) ACK dupliqués --> peu de segments sont perdus (un ACK dupliqué signifie la réception d'un segment)

Algorithme de Nagle Idée : il est pénalisant d'envoyer des segments contenant 1 seul octet de données (par ex. terminal virtuel) principe de Nagle : si l'application écrit octet par octet envoi du premier octet dans un segment accumulation dans le tampon des octets suivants tant que le premier octet n'est pas acquitté envoi des octets accumulés dans un seul segment attente de l'acquittement pour envoyer le segment suivant…

Gestion de la fenêtre Contrôle de flux TCP :
l'émetteur ne doit pas en envoyer de données si le tampon de réception n'a pas l'espace libre correspondant Quand l'émetteur est bloqué, il peut : envoyer des données urgentes (interruption de l'application réceptrice) envoyer des segments de 1 octet pour obliger le récepteur à envoyer SEQa et WIN et maintenir l'état actif de la connexion

Contrôle de flux TCP

Cas de blocage Après un remplissage du tampon de réception si le paquet de “déblocage” se perd, on arrive à une situation de blocage Solution: l’émetteur continue à envoyer le dernier octet de donnée afin de forcer le récepteur à émettre un acquittement

Valeur du temporisateur RTO
RTO : Retransmission Time Out Impact de cette valeur sur les performances valeur trop petite : des retransmissions inutiles ont lieu valeur trop grande : attente trop importante entre deux retransmissions TCP fait une estimation du RTT (temps aller/retour) et ajuste dynamiquement la valeur du temporisateur en fonction de cette estimation utilisation d'une option TCP : l'émetteur met la valeur de son horloge dans l'option le récepteur fait écho de cette valeur dans l'ACK l'émetteur fait la différence entre son horloge et cette valeur à la réception de l'ACK

TCP: Round Trip Time et Timeout
Méthode de Jacobson (1988) RTT = *RTT + (1-) *RTT_mesuré l'influence des échantillons passés décroît exponentiellement valeur typique pour  : 7/8 en cas de retransmission d’un segment, l’émetteur ne peut savoir si l’acquittement s’adresse au segment initial ou retransmis (ambiguïté des acquittements) => RTT ne peut donc être calculé correctement

TCP: Round Trip Time et Timeout
Jacobson propose: L'intervalle de timeout RTO = RTT + 4*D D est l’écart type entre RTT mesuré et RTT calculé Grande variation de RTT  grande marge de sécurité Estimer d'abord de combien dévie RTT_mesuré par rapport au RTT_calculé: D = *D + (1-)*|RTT-RTT_mesuré|

Contrôle de congestion dans TCP
Pour une bande passante idealement: émettre le plus rapidement possible (Congwin aussi grand que possible) sans pertes augmenter Congwin jusqu’à une perte (congestion) perte: réduire Congwin, et recommencer

Les causes de congestion (scénario 1: Taille de buffer infinie)

Les causes de congestion (scénario 2: Taille de buffer finie+ retransmission)

Contrôle de congestion dans TCP
Dans la suite, nous introduisons deux mécanismes de contrôle de congestion basés sur l’utilisation d’un mécanisme de fenêtres, à savoir : TCP Tahoe TCP Reno Il existe d’autres versions de TCP, certaines toujours à l’étude pour d’éventuelles améliorations.

TCP Tahoe Cet algorithme de contrôle de congestion utilise deux mécanismes particuliers, à savoir: Le mécanisme de démarrage lent (slow start) Le mécanisme de évitement de la congestion (congestion avoidance) Ceux-ci définissent la quantité de données transmissibles sur le réseau à chaque instant

Mécanisme de Slow start
Principe: Pour chaque accusé de réception d’un segment précédemment transmis, on permet l’émission de 2 nouveaux segments. A chaque transmission, la taille de la fenêtre de congestion est doublée. Cette rapidité d’évolution se fait dans une certaine limite, désignée par la taille de la fenêtre de réception mais également par une valeur particulière « seuil », notée le SSthres (pour slow start threshold). La valeur SSthres recommandée est fixée initialement à bytes.

Présence de congestion Congestion : Signifie qu’un accusé de réception n’est pas reçu dans les délais acceptés Conséquence pour la source: Reprise du mécanisme slow start avec Cwnd =1 MSS Et ssthres_nouveau =cwnd_atteint/2

Mécanisme de Congestion avoidance
Principe: Cwnd = cwnd +1 lorsque l’accusé de réception du dernier segment de la fenêtre est reçu. Tout se passe comme si, à chaque accusé de réception, la fenêtre cwnd = cwnd + 1/fenêtre

Mécanisme de Congestion avoidance

Présence de congestion

TCP extension Options Type Valeur Longeur 20 octcts ≤40 octets
Kind (1 octet) Length (1 octet) Value (1 octet) Type Valeur Longeur

TCP extension Kind=0 (1 octet) : No more options
Kind=1 (1 octet): Padding Kind=2, length=4: Mss Kind=3, length=3: Window scaling Kind=4, length=2: Sack support Kind=5, Length=Variable: Sack block Kind = 8, length=10 : Timestamp

La couche transport.

Présentations similaires

Présentation au sujet: "La couche transport."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

La couche transport.

Présentations similaires

Présentation au sujet: "La couche transport."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back