Vous êtes sur la page 1sur 16
Services et protocoles de la couche Transport logical end -end transport ? Crée un circuit
Services et protocoles de la couche Transport
logical end -end transport
? Crée un circuit de communication
logique entre des applis
s’exécutant sur des hôtes
distants
application
transport
network
data link
network
physical
data link
network
physical
? Les protocoles de la couche
transport ne s’exécutent qu’au
extrémités
data link
physical
network
data link
physical
network
data link
? Services transport vs réseau :
physical
network
? Couche réseau : Transfert de
données entre machines
data link
physical
? Couche transport : Transfert de
données entre applis
application
transport
network
data link
Se fonde sur les services de la
couche réseau et les améliore
physical
2: Application Layer
1
logical end -end transport
Protocoles de couche de transport
Services de transport dans
Internet :
application
transport
network
data link
network
? Fiable, réception dans
l’ordre des paquets (TCP)
physical
data link
network
physical
data link
physical
? Contrôle de congestion
network
data link
? Contrôle de flot
physical
network
data link
? Mise en place de connection
physical
network
? Non fiable (“Au mieux ”),
sans garantie d’ordre (UDP)
data link
physical
application
?
Peut s’étendre au multicast
transport
network
? Services non disponibles:
data link
physical
? Temps-réel, garantie de
délai
? Garantie de bande passante
? Multicast fiable
2: Application Layer
2

Multiplexage/demultiplexage

segment – unité de données échangée entre deux couches transport ? TPDU: transport protocol data unit

Demultiplexage: Distribution de chaque segment à l’application à laquelle il est destiné

Récepteur

P3 P4 Données M M applicative application Entête de P1 transport M P2 segment M
P3
P4
Données
M M
applicative
application
Entête de
P1
transport
M P2
segment
M
network
application
application
segment
transport
H t
M
transport
network
segment
H n
network

2: Application Layer

3

Multiplexage/demultiplexage

Multiplexage:

Encapsuler les données de plusieurs applis dans un segment avec une entête qui permettra le Démultiplexage

multiplexage/demultiplexage:

? Fondé sur le port de réception, le port d’émission et les adresses IP

? Les ports source et destination sont répetés dans chaque segment

? Certaines applications utilisent des ports spécifiques

? Certaines applications utilisent des ports spécifiques 32 bits # port source # port dest Autres

32 bits

applications utilisent des ports spécifiques 32 bits # port source # port dest Autres champs d’entête

# port source

# port dest

Autres champs d’entête

Données

applicative

(message)

format de segment TCP/UDP

2: Application Layer

4

Multiplexage/demultiplexage: exemples

source port: x dest. port: 23
source port: x
dest. port: 23

host A

source port: x dest. port: 23 host A

server B

 
   
 
   
source port:23 dest. port: x    

source port:23 dest. port: x

 
source port:23 dest. port: x    
 
 
App telnet simple Web client host A
App telnet simple
Web client
host A

Web client

host C

Source IP: C Source IP: C Dest IP: B Dest IP: B source port: y
Source IP: C
Source IP: C
Dest IP: B
Dest IP: B
source port: y
dest. port: 80
source port: x
dest. port: 80
port: y dest. port: 80 source port: x dest. port: 80 Web server B Source IP:
port: y dest. port: 80 source port: x dest. port: 80 Web server B Source IP:

Web

server B

Source IP: A

Dest IP: B

source port: x dest. port: 80

Serveur Web

2: Application Layer

5

UDP: User Datagram Protocol [RFC 768]

? Protocole de transport le plus simple

? Service “au mieux”, les segments UDP peuvent être:

? Perdus

? Delivré dans le désordre

? Sans connexion:

? Sans handshaking entre l’émetteur et le récepteur

? Chaque segment UDP est traité indépendamment des autres

Pourquoi UDP?

? sans délai de connexion

? simple: sans nécessité d’un état dans l’émetteur et le récepteur

? Petit entête

? Sans contrôle de congestion:

UDP peut émettre aussi rapidement qu’il le souhaite

2: Application Layer

6

UDP: suite ? Souvent utilisé pour les applications multimédias (streaming multimedia) Taille en octet du
UDP: suite
?
Souvent utilisé pour les
applications multimédias
(streaming multimedia)
Taille en octet
du segment
32 bits
# port source
# dest source
? Tolérance aux pertes
UDP incluant
l’entête
taille
checksum
? Sensible au débit
? Autre utilisation d’UDP:
? DNS
? SNMP
?
Transfert fiable sur UDP:
ajouter des mécanismes de
compensation de pertes à
niveau applicatif
Données Applicative
(message)
?
Compensation de pertes
adaptée à chaque
appplication
format
de segment
UDP
2: Application Layer
7
TCP: Survol
RFCs: 793, 1122, 1323, 2018, 2581
? point-à-point:
? Transfert bidirectionnel
des données:
?
Un émetteur, un récepteur
? Fiable, réception dans
l’ordre du flot d’octet:
? Transfert bi-directionel de
données sur une connexion
? MSS: maximum segment
size
?
Pas de « frontières de
message »
? Orienté connexion:
? Fenêtre d’émission:
?
handshaking (échange de
msgs de control) initialise
?
Les mécanismes de
contrôle de flot et de
congestion règlent la taille
de la fenêtre
l’état de l ’émetteur et du
récepteur avant l’émission
de données
? Contrôle de flot :
? Tampons de réception et
d’émission
?
L’émetteur ne submerge
pas le récepteur
application
application
writes data
reads data
socket
socket
door
door
TCP
TCP
send buffer
receive buffer
segment
2: Application Layer
8
Structure du segment TCP 32 bits URG: données source port # dest port # urgentes
Structure du segment TCP
32 bits
URG: données
source port #
dest port #
urgentes
Countage en octet
des données
Numéro sequence
ACK: ACK #
valide
Numéro d’ack
head
not
U
A P
PSH: push data now
R S
F Taille de fenêtre rcvr
len
used
checksum
ptr urgent
# d’octets
que le rcvr
Peut accepter
RST, SYN, FIN:
Options (variable)
Pour la connexion
application
data
Internet
checksum
(variable length)
(comme UDP)
2: Application Layer
9
= ‘C’ # de seqTCP et ACKs Seq=42, ACK=79, data #’Seq.: Hote A Hote B
= ‘C’
# de seqTCP et ACKs
Seq=42, ACK=79, data
#’Seq.:
Hote A
Hote B
? « Numéro » du
premier octet dans
le segment
L’utilisateur
tape
‘C’
ACKs:
ACK la
réception
? # de seq du
prochain octet
attendu
Seq=43, ACK=80
du
‘C’,
en
envoyant
un echo
? ACK cumulé
Q: Comment traiter les
segments arrivé en
désordre
ACKs la
reception de
l’écho
? R: La spec TCP ne
le dit pas- laissé au
concepteur
time
Seq=79, ACK=43, data = ‘C’
scenario
simple telnet
2: Application Layer
10

TCP: Transfert fiable de données

evenement: réception de données de l’application Créer un segment

wait wait for for event event
wait
wait
for
for
event
event

Émetteur simplifié

•Transmission dans un sens •Pas de contrôle de flot et de congestion

evenement: temp de garde fini pour le segment avec seq # y

Retransmet le segment

evenementt: ACK reçu, avec ACK # y

Traitement du ACK

2: Application Layer

11

Generation des ACKTCP [RFC 1122,2581]

Evenement

Action du récepteur

Arrivée d’un segment dans l’ordre, sans trou, Tout le reste a été ACKé

 

Arrivée d’un segment dans l’ordre, sans trou, Un ACK en attente

 

Arrivée d’un segment dans le désordre avec un seq. # supérieur à l’attente

 

Arrivée d’un segment qui remplit partiellement ou complètement le trou

Envoyer immédiatement un ACK cumulé

ACK mis en attente. Attendre jusqu’à 500ms pour le segment suivant. Sinon envoyer l’ACK

Envoyer un ACK dupliqué, indiquant le seq. # Du prochain octet attendu

Envoyer immédiatement un ACK si le segment rempli un trou

2: Application Layer

12

timeout

Seq=92, 8 bytes data

TCP: Scénario de retransmission

timeout Seq=92, 8 bytes data TCP: Scénario de retransmission t i m e Host A Host

time

8 bytes data TCP: Scénario de retransmission t i m e Host A Host B Seq=92,

Host A

Host B

TCP: Scénario de retransmission t i m e Host A Host B Seq=92, 8 bytes data
TCP: Scénario de retransmission t i m e Host A Host B Seq=92, 8 bytes data
Seq=92, 8 bytes data
Seq=92, 8 bytes data
ACK=100
ACK=100

X

loss

t i m e Host A Host B Seq=92, 8 bytes data ACK=100 X loss ACK=100
ACK=100
ACK=100

ACK perdu

Seq=92, 8 bytes data Seq=100, 20 bytes data Host A Host B Seq=92, 8 bytes
Seq=92,
8 bytes data
Seq=100,
20 bytes data
Host A
Host B
Seq=92, 8 bytes data
time
Timeout prematuré,
ACK cumulé
2: Application Layer
13
ACK=120
ACK=120
ACK=100
Seq=100 timeout
Seq=92 timeout

Contrôle de Flot TCP

Contrôle de flot

L’émetteur ne submerge pas le récepteur en émettant trop rapidement

RcvBuffer = Taille du tampon de réception TCP RcvWindow = espace vide dans le tampon

Recepteur: informe explicitement l’émetteur de l’espace vide (qui change dynamiquement) ? champs RcvWindow dans l’éntête TCP émetteur: borne la taille des données transmise et non acquittées à RcvWindow

borne la taille des données transmise et non acquittées à RcvWindow Tampon de reception 2: Application

Tampon de reception

2: Application Layer

14

TCP: Temps aller-retour (RTT) et temps de garde

 

Q: Comment définir la valeur du temps de garde dans TCP?

Q: Comment estimer le RTT?

? SampleRTT: temps mesuré depuis l’émission du segment

? Supérieur au RTT

jusqu’à la réception de son ACK

Ignorer les retransmissions

?

?

note: RTT varie

? Trop petit : timeout prematuré

?

multiple, et les ACKs cumulés

? SampleRTT varie: un RTT plus régulier est nécessaire

 

?

Moyenner sur plusieurs mesure récente du SampleRTT

Retransmissions redondante

? Trop long: lenteur de la réaction à la perte d’un segment

 

2: Application Layer

15

TCP: Temps aller-retour (RTT) et temps de garde

 

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

 

? Calcul de moyenne par pondération exponentielle

? L’influence d’un échantillon est réduit exponentiellement

? Valeur typique de x: 0.1

Le timeout

 

? EstimtedRTT plus une “marge de sécurité”

 

? Grande variation de EstimatedRTT -> plus grande marge de sécurité

 

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

 

2: Application Layer

16

TCP: Gestion de la Connexion ? L’émetteur et le réception doivent initier une « connexion
TCP: Gestion de la Connexion
? L’émetteur et le réception
doivent initier une
« connexion TCP » avant
d’échanger des données
Poignée de main
tripartite:
? 1: le client envoit un segment
? Initialiser les variables TCP:
de contrôle TCP SYN
? seq. #s
? Tanpons, information de
contrôle de flot (e.g.
RcvWindow)
?
Défini le seq # initial
? client: initiateur de la
connexion
? 2: le serveur reçoit le SYN, et
répond par un segment de
contrôle SYNACK
Socket clientSocket = new
Socket("hostname","port
? ACKs le SYN reçu
number");
? alloue des tampons
? server: contacté par le client
Socket connectionSocket =
welcomeSocket.accept();
? specifie le seq.# initial du
serveur-> récepteur
2: Application Layer
17
FIN
TCP: Gestion de Connexion (cont.)
Fermer une connexion:
client
server
close
Le client ferme la socket:
ACK
clientSocket.close();
1: le client envoit un segment
TCP FIN au serveur
close
2: le serveur reçoit le FIN,
repond par un ACK. Ferme la
connexion et envoi un FIN.
closed
ACK
2: Application Layer
18
FIN
timed wait

timed wait

TCP: Gestion de Connexion (cont.)

3: le client reçoit un FIN, et répond par un ACK.

? Passe en attente et acquitte to les FINs qu’il reçoit

4: le serveur, reçoit l’ACK. La connexion est fermé.

4: le serveur , reçoit l’ACK. La connexion est fermé. client server closing closed FIN ACK

client

server

, reçoit l’ACK. La connexion est fermé. client server closing closed FIN ACK FIN ACK closing

closing

closed

FIN
FIN
ACK FIN
ACK
FIN
ACK
ACK

closing

closed

2: Application Layer

19

TCP: Gestion de Connexion (cont.)

Cycle de vie du serveur TCP Cycle de vie du client TCP
Cycle de vie du serveur TCP
Cycle de vie du client TCP

2: Application Layer

20

Principes du contrôle de Congestion

Congestion:

? “trop de sources envoient trop de données trop rapidement dans le réseau

? Différent du contrôle de flot!

? manifestations:

? Pertes de paquets (débordement des routeurs)

? delais important (file d’attente dans les routeurs )

2: Application Layer

21

Causes/coûts de la congestion: scenario 1

? Deux émetteurs, deux récepteurs

? un routeur, mémoire infinie

? Pas de retransmission

1 ? Deux émetteurs, deux récepteurs ? un routeur, mémoire infinie ? Pas de retransmission 2:
1 ? Deux émetteurs, deux récepteurs ? un routeur, mémoire infinie ? Pas de retransmission 2:

2: Application Layer

22

Causes/coûts de la congestion: scenario 2

 

? Un routeur, mémoire finie

 

? L’émetteur retransmet les paquets perdus

 
 
 
 

2: Application Layer

23

Causes/coûts de la congestion: scenario 2

 

?

? in

=

? out

(goodput)

 
  ? ? in = ? out (goodput)   ? Si la retransmission est parfaite :

?

Si la retransmission est parfaite :

? in

>

? out

? in > ? out
 

?

La retransmission de paquet non perdu rend

? in

que dans le cas

parfait

 
“coûts” de la congestion:
“coûts” de la congestion:
 

? Plus de travail (retrans) pour un même débit utile (“goodput”)

? Retransmissions redondantes

 
 

2: Application Layer

24

Approches du contrôle de congestion

 

Deux approches principales :

 

Contrôle de congestion de Bout-en-bout :

Contrôle de congestion assisté par le réseau:

 

? Pas de feedback explicite du réseau

?

Les routeurs fournissent un feedback aux émetteurs

? La congestion est estimé grace à l’observation des pertes et des délais de bout en bout.

? Un bit d’annonce de congestion (SNA, DECbit, TCP/IP ECN, ATM)

? approche suivi par TCP

 

? Débit d’émission explicite

 

2: Application Layer

25

Contrôle de Congestion TCP

 

? Contrôle de bout-en-bout

 

? Le débit est limité par la taille de la fenêtre de contrôle de congestion Congwin

 
Congwin
Congwin

? w segments, chacun avec MSS octets transmis durant un RTT:

 

throughput =

w * MSS RTT

Bytes/sec

 
 

2: Application Layer

26

Contrôle de Congestion TCP ? “probing” pour la bande passante disponible: ? Deux “phases” ?
Contrôle de Congestion TCP
? “probing” pour la bande
passante disponible:
? Deux “phases”
? slow start
? idealement: émettre le plus
rapidement possible
(Congwin aussi grand que
possible) sans pertes
? congestion avoidance
? Variables importante:
? Congwin
? augmenter Congwin jusqu’à
une perte (congestion)
? threshold: defini le
seuil entre les deux
phases
? perte: réduire Congwin, et
recommencer
2: Application Layer
27
TCP Slowstart
one segment
Host A
Host B
two segments
algorithme Slowstart
initialiser: Congwin = 1
for (each segment ACKed)
Congwin++
until (loss event OR
CongWin > threshold)
four segments
? Augmentation exponentielle
(par RTT) de la taille de la
fenêtre
time
? perte? : timeout (Tahoe
TCP) ou or trois ACKs
dupliqués (Reno TCP)
2: Application Layer
28
RTT

TCP Congestion Avoidance

Congestion avoidance

/* slowstart est fini

/* Congwin > threshold */ Until (loss event) { every w segments ACKed:

*/

Congwin++

}

threshold = Congwin/2 Congwin = 1 perform slowstart

1

w segments ACKed: */ Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 2:

2: Application Layer

29

AIMD

TCP congestion avoidance:

? AIMD: additive increase, multiplicative decrease

? Augmente la fenêtre de 1 par RTT

? Réduit la fenêtre d’un facteur 2 en cas de pertes

TCP et justice

Justice: Si N sessions TCP partage un même lien chacune doit obtenir 1/N de la capacité du lien

TCP connection 1 bottleneck TCP router connection 2 capacity R 2: Application Layer 30
TCP connection 1
bottleneck
TCP
router
connection 2
capacity R
2: Application Layer
30

TCP est il juste?

Deux sessions en parallele

? Incrément additif génére une pente de 1,

? La réduction multiplicative réduit le débit proportionnellement

R Partage égal Connection 2 throughput
R
Partage égal
Connection 2 throughput

Connection 1 throughput

R

2: Application Layer

31