Vous êtes sur la page 1sur 50

Chapitre 3

Protocoles de transport de
l’Internet

1
Chapter 3: Couche Transport

Nos objectifs:

Comprendre les services

Etudier les protocoles de
implémentés par la couche couche transport :
transport:
 UDP: transport sans
connexion
 multiplexage/
demultiplexage
 TCP: transport orienté
connexion
 fiabilité du transfert de
données
 le contrôle de congestion
TCP
 contrôle de flux
 contrôle de congestion

2
Couche transport vs. Couche
réseau


La couche réseau : 
La couche transport:
communication logique entre communication logique entre
les hôtes les processus
 apporter des améliorations
de fiabilité par rapport à celle
de la couche réseau

3
Multiplexage/demultiplexae
Demultiplexage au hôte récep: Multiplexage au hôte émett:
Colleter les données de
Délivrer les segments à la
plusieurs sockets et enveloppe
bonne socket
les données avec l’en-tête
(utile pour le démultiplexage)
= socket = process

P3 P1
P1 P2 P4 application
application application

transport transport transport

network network network

link link link

physical physical physical

hôte 2 hôte 3
hôte 1
4
Comment s’effectue le démultiplexage

Hôte recevant les datagramme
IP 32 bits
 Chaque datagramme a une
port source port dest
adresse IP source et une
adresse IP destination
 chaque datagramme
Les autres champs de
l’en-tête
encapsule un segment de
couche transport
 Chaque segment a un Les données de
numéro de port source et l’application
un num de port destination
(message)
spécifiques à l’application

hôte utilise les adresses IP et
Format d’un segment TCP/UDP
les numéros de port pour
diriger le segment à la bonne
socket 5
Démultiplexage sans connexion

DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

PS: 6428 PS: 6428


PD: 9157 PD: 5775

PS: 9157 PS: 5775


client PD: 6428 PD: 6428 Client
serveur
IP: A IP:B
IP: C

6
Démultiplexage orienté connexion

socket TCP identifiée par 
L’hôte serveur peut
4-tuple: supporter simultanément
 Adresse IP source plusieurs sockets :
 num de port source  chaque socket est
 Adresse IP dest identifiée par ses 4-tuple
 num de port dest 
Les serveurs Web ont des

l’hôte récepteur utilise sockets différents pour
toutes les 4 valeurs pour chaque connexion d’un
diriger le segment à la client
socket appropriée  HTTP non-persistant aura
une socket différente pour
chaque requête

7
Démultiplexage orienté connexion

P1 P4 P5 P6 P2 P1P3

PS: 5775
PD: 80
IP-S: B
IP-D:C

PS: 9157 PS: 9157


client PD: 80 PD: 80 Client
serveur
IP: A IP-S: A IP-S: B IP:B
IP: C
IP-D:C IP-D:C

8
Le protocole UDP

Souvent utilisé pour des app
multimédias
 tolère la perte 32 bits
 mais c’est un service port source port dest
La longueur totale
rapide (en octet)du checksum
longueur

autres utilisations de UDPsegment UDP
 DNS y compris
 SNMP l’en-tête

fiabilité de transfert à
travers UDP: ajouter des Données de la couche
fonctions de contrôle au Application
niveau de la couche (message)
application pour améliorer
la fiabilité
 recouvrement spécifique
Format d’un segment UDP
d’erreurs au niveau
applicatif
9
checksum UDP
But: detecter des “erreurs” (e.g., bits altérés) dans la transmission
du segment

Emetteur: Récepteur:

traite le contenu du segment 
Calcule le cheksum du
comme étant une séquence
segment reçu
d’entiers de 16 bits

checksum: le complément à un

et vérifie si la valeur calculée
de la somme de tous les mots du checksum est égale à la
de 16 bits du segment en valeur mise dans le champ
éliminant tout dépassement de checksum:
capacité  NON - détection d’erreur

met la valeur du checksum
 OUI - pas d’erreur
dans le champs checksum du
segment UDP à envoyer
10
Exemple de checksum Internet

Note
 En additionnant les mots de 16 bits, les retenues
sortantes du bit du poids fort doivent être ajoutées
au résultat final

Exemple: addition de deux entiers 16-bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
Retenue
sortante 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

somme 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
11
TCP: vue générale
RFCs: 793, 1122, 1323, 2018, 2581

application application
Écrit données Lit données
Interface Interface
socket socket
Tampon Tampon de
d ’envoi de réception
TCP de TCP
segment

12
structure d’un segment TCP
32 bits
URG: données urgentes Compte le
port source port dest
nombre
sequence number d’octets
ACK: séq de l’ACK
pris en considération Ack number de données
head not (non pas du
SH: passer les donnée à UAP R S F Receive window
len used segment !)
la couche application checksum URG data Pointer
Nombre d’octets
RST, SYN, FIN: Options (variable variable) pouvant être
pour établissement acceptés
et fermeture
de connexion

Checksum Application
Internet data
(comme pour UDP) (variable length)

13
sequence number et
acknowledgement number
Numéro de séquence: Hôte A Hôte B
 Le numéro dans le Utilisateur Seq=
42, AC
flux de données du tappe K=79,
data =
‘C’ ‘ C’
premier octets de Aquitte
‘C’,
chaque segment t a = ‘C’ envoie ‘C’
3, d a
, ACK=4
Numéro ACKs: Seq=
79

 le num de seq du
Aquitte
prochain octet qu’il ‘C’,
Seq=4
envoie ‘C’ 3, ACK=
attend de l’autre 80

côté
 ACK cumulatif temps
Exemple de scénario Telnet

14
Scénarios de retransmission

15
RTT et Timeout TCP

Q: Comment choisir la Q: Comment estimer le RTT?


valeur de timeout?

SampleRTT: : mesure le temps
entre la transmission du segment

Supérieur à RTT
et la réception de son ACK
 mais RTT varie
 ignore les retransmissions

plus petit

SampleRTT va varier selon le
 des retransmissions
niveau de congestion
inutiles  Ne peut pas être une valeur

beaucoup plus grand: fiable de RTT
ralentit la reaction face  On considère une moyenne
à la perte des segments des mesures et non le
SampleRTT courant

16
RTT et Timeout TCP

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT


Une moyenne pondérée des différentes valeurs de
SampleRTT

plus de poids aux échantillons récents qu’aux
échantillons plus anciens

valeur typique:  = 0.125


Timeout= 2 * EstimatedRTT

17
Exemple d’estimation RTT :
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

18
RTT et Timeout TCP
Configurtion du timeout (Jacobson & Karels )

Première estimation de combien SampleRTT dévie de
EstimatedRTT:

DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|SampleRTT-EstimatedRTT|SampleRTT-EstimatedRTT|

(typiquement,  = 0.25))

TimeoutInterval = EstimatedRTT + 4*DevRTT

19
Transfert de données fiable
avecTCP

TCP crée un service de transfert fiable au dessus du
service IP non fiable

Piplinage des segments (plusieurs envoi sans ack)

acks cumulatifs

TCP utlise un seul timer de retransmission

Initialement considérons la version simplifié de TCP
 ignorer la dupplication des acks
 ignorer, le contrôle de flux et le contrôle de congestion

20
Evenements de l’expéditeur
TCP:
Données reçues de l’app: timeout:

créer un segment avec 
retransmettre le segment
un numéro de séquence qui a causé le
 le num de séq est le
déclenchement du timeout
numéro dans le flux de
données du premier octet 
redémarrer le timer
de chaque segment
réception d’un Ack:

actionner le timer s’il
n’est pas encore

s’il accuse réception des
déclenché (pensez que le segments non acquittés
timer est pour le plus  mettre à jour ce qu’il n’est
ancien segment non pas encore acquitté
acquitté)  démarrer le timer s’il y a

interval d’expiration: des segments envoyés non
TimeOutInterval encores acquittés

21
Vérsion simplifiée de l’expéditeur
TCP:
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
event: données reçues de la couche application
créer un segment TCP avec le num de séq= NextSeqNum

if (timer n’est pas encore déclenché) Commentaire:


start timer • SendBase-1: num
pass segment to IP de séq du dernier
NextSeqNum = NextSeqNum + length(data) octet reçu intact
event: timer timeout et dans l’ordre
retransmettre le segment non encore acquitté avec le plus • Example:
petit numéro de séquence • SendBase-1 = 71;
start timer
event: ACK reçu, avec séq ACK= y
y= 73, récepteur
if (y > SendBase) { demande 73+ ;
SendBase = y y > SendBase, don
if (S’il reste des segments non encore acquittés) de nouvelle données
start timer sont acquittées
}
} /* end of loop forever */
22
TCP: scénarios de retransmission
Hôte A Hôte B Hôte A Hôte B

Seq=9 Seq=9
2, 8 o 2, 8 o
c t e ts d ctets
e don Seq= de do

Seq=92 timeout
nées 100, nnée
20 oc s
t et s
de d
timeout

onné
CK=100 es
A 0
10
X C
A AC
K =
K = 120
lost
Seq=9 Seq=9
2, 2, 8 o
8 oct ctets
ets d
e do n Sendbase de do
nné e

Seq=92 timeout
nées = 100 s
SendBase
= 120 0
K=12
C K =100 AC
A

SendBase
= 100 SendBase
= 120 mauvaisTimeout
temps temps
Perte d’un accusé
23
TCP: scénarios de retransmission
Hôte A Hôte B
Seq=9
2, 8 o
ctets
de do
nnée
s
Seq=1 100
timeout
00, 20 ACK=
octet
s de d
on né
X es
lost

SendBase =120
ACK
= 120

temps
Accusé de réception cumulatif

24
Génération des ACK TCP [RFC 1122, RFC
2581]

Evénement Réponse du destinataire TCP

Arrivée d’un segment intact et dans Génération de l’accusé de réception


l’ordre, porteur du num de séq attendu. retardé d’une durée de 500 ms, en
Toutes les données jusqu’à ce num de attente d’un autre segment
séq sont déjà acquitté

Arrivée d’un segment intact et dans Envoi immédiat d’un ACK cumulatif
l’ordre, doté d’un num de séq attendu. simple, accusant réception des deux
Un segment précédent est en attente segments (dans l’ordre)
de l’émission de son ACK

Arrivée d’un segment hors séq doté Envoi immédiat d’un ACK dupliqué
d’un num de Seq supérieur au num indiquant le num de séq du prochain
attendu. (Lacune détectée) octet attendu (limite inf lacune)

Arrivée d’un segment remplissant Envoi immédiat d’un ACK, sous réserve
complétement ou partiellement la que le segment coïncide avec la limite
lacune dans les données reçues inf de la lacune

25
Retransmission rapide

Souvent, la periode du Time-
out est relativement longue : 
Si l’émetteur reçoit 3 ACKs
 Délai long avant la du même segment, il
retransmission d’un paquet
suppose que ce segment
perdu

Détection de perte de est perdu:
segment avec les ACKs  Retransmission rapide:
dupliqués. retransmet le segment
 Emétteur envoie souvent un avant l’expiration du
grand nombre de segment Time-out
l’un derrière l’autre
 La perte d’un segment est
susceptible de générer un
grand nombre d’accusé de
réception en chaîne.

26
Algorithme de retransmission
rapide

event: ACK received, with ACK field value of y


if (y > SendBase) {
SendBase = y
if (des segments ne sont pas encore acquittés)
start timer
}
else {
incrémenter le compteur des ACKs reçus pour y
if (compteur des ACKs reçus pour y = 3) {
retransmettre le segment avec le num de séq = y
}

Un ACK duppliqué Retransmission rapide


pour un segment
Déjà acquitté
27
Contrôle de flux TCP

Le côte récepteur a un buffer Contrôle de flux
de réception: L’emetteur ne doit
pas saturer le buffer
du récepteur en
transmettant avec
un rythme trop
soutenu

Eviter la saturation par
un système d’équilibrage
qui ajuste le rytme
d’envoi à la vitesse de

Le processus applicatif lecture de l’application
peut prendre du temps destinataire
(occupée par d’autres
activités) pour lire le
contenu du buffer

28
Contrôle de flux TCP :
comment ça marche

RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

(On suppose que le récepteur TCP supprime les segments hors


séquence)

RcvWindow : Espace mémoire disponible (spare room) en buffer

RcvBuffer : la taille du buffer de récéption allouée pour la
connexion

LastByteRead : numéro du dernier octet dans le flux de données
retiré du buffer par le processus applicatif

LastByteRcvd : numéro du dernier octet dans le flux de données
29
reçus et placé dans le buffer
Contrôle de flux TCP :
comment ça marche


Récepteur informe l’émetteur de l’espace disponible dans
son buffer en insérant RcvWindow dans tous les segments
TCP.

L’emetteur limite les segments non acquittés à l’espace
RcvWindow

Si RcvWindow passe à 0, l’émetteur continue à
émettre des segments TCP contenant un seul octet de
données obligeant le récepteur à envoyer des ACKs
porteurs des nouvelles réactualisation de RcvWindow
(éviter un deadlock)
30
Gestion de la connexion TCP

Initialisation: Echange de
Trois états d’échange:
segments TCP de connexion
entre un client et un serveur Etape 1: l’hôte client envoie un
segment TCP SYN au

Initialisation de variables TCP:
serveur
 Num de séq  Spécifie un num de séq
 buffers, info contrôle de flux initial
(e.g. RcvWindow)  Pas de données

client: intitiateur de connexion Etape 2: l’hôte serveur reçoit
Socket clientSocket = new SYN et répond par un
Socket("hostname","port number"); segment SYN+ACK

serveur: contacté par le client
 Serveur alloue les buffers
 Spécifie un num de séq
Socket connectionSocket =
welcomeSocket.accept(); initial serveur
Etape 3: le client reçoit SYN+ACK
et répond par un segment ACK
qui peut contenir des données31
Gestion de la connexion TCP
Fermeture de connexion:
client ferme socket:
clientSocket.close(); client serveur

Etape 1: Le système terminal close


client envoie un segmet de FIN
contrôle TCP FIN au serveur
Etape 2: Le serveur reçoit un FIN,
répond avec un segment ACK. ACK
Ferme la connexion et envoie un close
segment FIN FIN

Temps d’attente
Etape 3: client reçoit FIN, répond
avec un ACK. ACK
 Met un “temps d’attente” –
pour recevoir les segments
de données en cours de
transfert
Etape 4: serveur, reçoit ACK et
ferme la connexion Fermeture

32
Gestion de la connexion TCP

Représentation d’une connexion TCP par un automate à états fini :
« schéma complet» C0NNECT/SYN
FERMÉE
CLOSE/-
LISTEN/- CLOSE/-
SYN/SYN+ACK
ÉCOUTE
SYN
SYN émis
reçu

Transfert de données
ACK/- SYN+ACK/ACK
ÉTABLIE
CLOSE/FIN FIN/ACK

FIN/ACK ATTENTE
FIN FERMETURE
ATTENTE 1 EN COURS FERMETURE

CLOSE/FIN
ACK/- ACK/-
FIN+ACK/ACK
Dernier
FIN ATTENTE ACK
ATTENTE 2 TEMPORISÉE
FIN/ACK
ACK/-
FERMÉE

33
Principe du contrôle de congestion

Congestion:

Informellement :”plusieurs sources envoient un grand volume
de données sur un court intervalle de temps au réseau.

Différent du contrôle de flux !

Les conséquences:
 Perte de paquets (saturation des buffers des routeurs “buffer
overflow”)
 Délai de mise en file d’attente très long

34
Causes et effets de congestion: sénario 1

Hôte A lout

Deux émetteurs, lin : données
originales
deux récepteurs

Un routeur, buffer Hôte B Tampons de liaison de
de taille infinie sortie de nombre illimité


Pas de
retransmission


Un long délai
quand c’est
congestionné

Exploitation de la
liaison au
maximum de sa
capacité eq.
Longues files
d’attentes au
35
niveau du
Causes et effets de congestion : scenario 2


Un seul routeur, buffers limités

L’émetteur retransmet les paquets perdus

Hôte A lin : données originales lout

l'in : données originales,


plus données retransmises

Hôte B Tampons de liaison de


sortie partagés de nombre
limité

36
Causes et effets de congestion :
scenario 2
 Dans le cas idéal: lin = lout (a)
 retransmission uniquement dans le cas de perte : l’in > lout (b)
 retransmission des paquets retardé (non perdus) met l’in encore
plus grand que lout (c)
R/2 R/2 R/2

R/3
lout

lout

lout
R/4

R/2 R/2 R/2


lin lin lin

a. b. c.
“coût” de congestion:

Plus de travail (retrasmission) au niveau de l’expéditeur et
exploitation inutile du débit de liaison des routeur

Retramsmission inutile: la liaison supporte de multiples copies des
paquets 37
Causes et effets de congestion : scenario 3


Quatre émetteurs Q: Que ce passe –t-il si

Plusieurs chemins possibles lin et l’in augmentent?

timeout/retransmission

Hôte A lout
lin : données originales Serveur D

l'in : données originale, plus


données retransmisses
Tampons de liaison de
sortie partagés de nombre
limité

Hôte B
R4 R1
R2 Serveur C

R3

38
Causes et effets de congestion : scenario 3

Hôte A lout

Hôte B

Autre “coût” de congestion:



Lorsqu’un paquet est perdu sur son parcours, la
capacité de transmission dépensée par chacun des
routeurs en amont pour le faire progresser (jusqu’au
routeur saturé) s’en trouve perdue
39
contrôle de congestionTCP
Comment l’émetteur
détecte la congestion?

Événement de perte =

Contrôle de bout en bout (pas expiration du timeout ou
d’assistance du réseau) l’arrivé de 3 acks

L’émetteur limite sa transmission: duppliqués
LastByteSent-LastByteAcked = 
L’émetteur réduit la
Min{CongWin,RcvWindows}  CongWin fenêtre de congestion

Rééllement, (CongWin) après
l’événement de perte
CongWin Trois mécanismes:
Vitesse d’envoi = Bytes/sec  Accroissement additif et
RTT
décroissance

CongWin est dynamique et fonction multiplicative (AIMD)
du niveau de congestion du réseau  Départ lent
 Réactions aux
temporisations

40
AIMD TCP
décroissance multiplicative: Accroissement additif:
réduire CongWin à sa moitié si augmenter la valeur de
l’événement de perte CongWin de 1 MSS après
apparaît chaque RTT en absence
Fenêtre de de phénomène de perte
congestion

24 Kbytes

16 Kbytes

8 Kbytes

temps

41
Départ lent TCP

Quand la connexion démarre,

Quand la connexion
le taux d’envoi croît de façon
démarre, CongWin = 1 MSS
expoentielle jusqu’à
 Exemple: MSS = 500 bytes
l’apparition d’un événement
& RTT = 200 msec
de perte
 taux d’envoi initiale = 20
kbps
 doubler CongWin chaque RTT

La bande passante

conclusion: le taux d’envoi
disponible peut être >> initial est lent mais augmente
MSS/RTT rapidement en exponentiel
 C’est souhaitable de
remettre rapidement le
taux d’envoi aux taux de
la bande passante
disponible

42
Départ lent TCP

Hôte A Hôte B

un segme
n t

RTT
deux segm
ents

Quatre se
gments

time

43
Réaction aux temporisations

Après 3 ACKs duppliqués: Philosophie:
 CongWin est divisée à sa
moitiée
• 3 ACKs dup indiquent
 La fenêtre croît linéairement que le réseau est

Mais après un timeout : capable de de
 CongWin est mise à 1 MSS;
délivrer quelques
 Puis la fenêtre de congestion
segments
croît de façon exponentielle
• timeout avant 3
jusqu’à un seuil puis elle ACKs dup est “plus
progresse linéairement critique”
 La valeur seuil de la fenêtre :
 Initilialiée à valeur élevée (65 Ko)
 S’il y a un timeout elle passe à la
moitié de CongWin

44
Réaction aux temporisations
Q: Quand est ce que
l’accroissement
exponentiel passe
au linéaire?
A: Qaund CongWin
prend le 1/2 de sa
valeur avant le
timeout.

Implementation:

Variable seuil (Threshold)

À l’événement de perte, le seuil
est mis à 1/2 du CongWin juste
avant l’apparition de
l’événement de perte

45
contrôle de congestionTCP :
synthèse

Tant que CongWin est inférieure à la valeur du seuil,
l’expéditeur est en phase de départ lent et la fenêtre connaît
une croissance exponentielle.

Une fois la valeur de seuil dépassée, l’expéditeur entre dans la
phase d’évitement de la congestion durant laquelle la fenêtre
s’accroît de manière linéaire.

Lorsqu’il y a trois ACKs identiques, la valeur du seuil est réglée
à la moitié de la taille de CongWin en cours et cette dernière
est portée à la valeur du seuil

Lors de l’expiration du timeout, la valeur du seuil est reglée à
la moitié de la taille de CongWin en cours et cette dernière est
portée à 1 MSS

46
Contrôle de congestion TCP
de l’expéditeur
Evénement Etat Action TCP de l’expéditeur Commentaires

Réception d’un Départ Lent CongWin = CongWin + MSS, Doubler la valeur de CongWin à
ACK pour un (DL) If (CongWin > Threshold) chaque RTT
segment non set state to “Evitement de
acquitté Congestion ”

Réception d’un Evitement de CongWin = CongWin+MSS * Accroissement Additif de


ACK pour un Congestion (MSS/CongWin) CongWin par 1 MSS à chaque
segment non (EC) RTT
acquitté

Détection de DL ou EC Threshold = CongWin/2, Recouvrement rapide, par


perte après 3 CongWin = Threshold, implementation de la
ACK duplliqués Set state to “Evitement de décroissance multiplicative.
Congestion ” CongWin ne se met pas à 1
MSS.

Timeout DL ou EC Threshold = CongWin/2, Passe au Départ Lent


CongWin = 1 MSS,
Set state to “Départ Lent ”

ACK duppliqué DL ou EC Incrémentation du compteur des CongWin et le seuil ne changent


ACK dup du segment déja acquitté pas

47
DébitTCP

Quel est le débit moyen TCP en fonction de la taille de
fenêtre et RTT?
 On Ignore le départ lent

Soit W la taille de la fenêtre quand il y a perte.

Quand la fenêtre a la taille W, le débit est W/RTT

Juste après la perte, la fenêtre passe à W/2 et le débit
passe à W/2RTT.

Débit moyen0.75W
RTT

48
Equité TCP

Objectif de l’équité: Si K sessions TCP partage la même


liaison ( responsable d’un goulet d’étranglement) de
débit R, alors chaqu’une doit avoir un débit moyen de
R/K

Connexion TCP 1

Routeur encombré
de capacité R
Connexion TCP 2

49
Comment est implémenté l’equité
TCP?
Deux sessions compétitives:

Acroissement additif ajoute 1 MSS à la fenêtre et le débit croît avec

Décroissance multiplicatif décroit le débit proportionellement

R Partage équitable du débit


Débit Connection 2

perte: fenêtre CongWin/2


Evitement de congestion: Accroissement
additif
perte: fenêtre CongWin/2
Evitement de congestion: Accroissement
additif

Débit Connection 1 R
50

Vous aimerez peut-être aussi