Services et protocoles de la couche Transport

? Crée un circuit de communication

logique entre des applis application
transport
s’exécutant sur des hôtes network
data link
distants physical
network
data link
network physical

log
? Les protocoles de la couche data link

ica
physical
transport ne s’exécutent qu’au

l
network

en
data link

d
extrémités

-e
physical network

nd
data link
? Services transport vs réseau : physical

tr
an
network
Couche réseau : Transfert de

sp
? data link

or
données entre machines physical

t
? Couche transport : Transfert de application
transport
données entre applis network
data link
• Se fonde sur les services de la physical
couche réseau et les améliore

2: Application Layer 1

Protocoles de couche de transport

Services de transport dans application

Internet :
transport
network
data link network
? Fiable, réception dans physical data link
network physical
l’ordre des paquets (TCP)
log

data link
ica

physical
Contrôle de congestion
l

network
en

?
data link
d

Contrôle de flot
-e

? physical network
nd

data link
Mise en place de connection physical
tr

?
an

network
? Non fiable (“Au mieux ”),
sp

data link
or

physical
t

sans garantie d’ordre (UDP)

? Peut s’étendre au multicast application
transport

? Services non disponibles:

network
data link
physical
? Temps-réel, garantie de
délai
? Garantie de bande passante
? Multicast fiable
2: Application Layer 2

1
 Multiplexage/demultiplexage
segment – unité de données
Demultiplexage: Distribution
échangée entre deux
de chaque segment à
couches transport
l’application à laquelle il est
? TPDU: transport destiné
protocol data unit
Récepteur
P3 P4
Données M M
applicative
application
Entête de P1 transport P2
segment M
M network
application application
segment Ht M transport transport
network
Hn segment network

2: Application Layer 3

Multiplexage/demultiplexage
Multiplexage:
Encapsuler les données de 32 bits
plusieurs applis dans un segment
avec une entête qui permettra le # port source # port dest
Démultiplexage
Autres champs d’entête
multiplexage/demultiplexage:
? Fondé sur le port de
réception, le port d’émission
et les adresses IP Données
? Les ports source et applicative
destination sont répetés (message)
dans chaque segment
? Certaines applications
utilisent des ports
spécifiques format de segment TCP/UDP

2: Application Layer 4

2
Multiplexage/demultiplexage: exemples
source port: x Web client
host A dest. port: 23 server B host C

source port:23
dest. port: x
Source IP: C Source IP: C
Dest IP: B Dest IP: B
source port: y source port: x
App telnet simple dest. port: 80 dest. port: 80

Source IP: A
Dest IP: B Web
Web client source port: x server B
host A 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

3
 UDP: suite
? Souvent utilisé pour les
applications multimédias Taille en octet 32 bits
(streaming multimedia) du segment
# port source # dest source
? Tolérance aux pertes UDP incluant
? Sensible au débit
l’entête taille checksum

? Autre utilisation d’UDP:

DNS?
SNMP
?
? Transfert fiable sur UDP: Données Applicative
ajouter des mécanismes de (message)
compensation de pertes à
niveau applicatif
? Compensation de pertes
adaptée à chaque format
appplication
de segment
UDP
2: Application Layer 7

TCP: Survol RFCs: 793, 1122, 1323, 2018, 2581

? point-à-point: ? Transfert bidirectionnel
? Un émetteur, un récepteur
des données:
? Transfert bi-directionel de
? Fiable, réception dans données sur une connexion
l’ordre du flot d’octet: ? MSS: maximum segment
? Pas de « frontières de size
message » ? Orienté connexion:
? Fenêtre d’émission: ? handshaking (échange de
msgs de control) initialise
? Les mécanismes de l’état de l ’émetteur et du
contrôle de flot et de récepteur avant l’émission
congestion règlent la taille de données
de la fenêtre ? Contrôle de flot :
? Tampons de réception et ? L’émetteur ne submerge
d’émission 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

4
 Structure du segment TCP
32 bits
URG: données Countage en octet
urgentes source port # dest port #
des données
Numéro sequence
ACK: ACK #
valide Numéro d’ack
head not
PSH: push data now len used
U A P R S F Taille de fenêtre rcvr
# d’octets
checksum ptr urgent
que le rcvr
RST, SYN, FIN: Peut accepter
Options (variable)
Pour la connexion

application
Internet data
checksum (variable length)
(comme UDP)

2: Application Layer 9

# de seqTCP et ACKs
#’Seq.:
Hote A Hote B
? « Numéro » du
premier octet dans L’utilisateur Seq
=42, A
le segment tape CK=7
9, data
‘C’ = ‘C’
ACKs: ACK la
réception
? # de seq du
du ‘C’, en
prochain octet , data
= ‘C’
envoyant
K=43
attendu Seq =79, AC
un echo
? ACK cumulé
Q: Comment traiter les ACKs la
segments arrivé en reception de Seq =4
l’écho 3,
désordre
ACK=
80

? R: La spec TCP ne
le dit pas- laissé au
concepteur time
scenario
simple telnet
2: Application Layer 10

5
TCP: Transfert fiable de données

Émetteur simplifié
evenement: réception de
données de l’application
Créer un segment •Transmission dans un sens
•Pas de contrôle de flot et
de congestion

wait evenement: temp de garde fini

wait
for pour le segment avec seq # y
for
event
event 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 ACK mis en attente. Attendre jusqu’à 500ms
l’ordre, sans trou, pour le segment suivant. Sinon envoyer l’ACK
Tout le reste a été ACKé

Arrivée d’un segment dans Envoyer immédiatement un ACK cumulé

l’ordre, sans trou,
Un ACK en attente

Arrivée d’un segment dans Envoyer un ACK dupliqué, indiquant le seq. #

le désordre avec un seq. # Du prochain octet attendu
supérieur à l’attente

Arrivée d’un segment qui Envoyer immédiatement un ACK si le segment

remplit partiellement ou rempli un trou
complètement le trou
2: Application Layer 12

6
 TCP: Scénario de retransmission
Host A Host B Host A Host B

Seq=9 Seq=9
2, 2, 8 b
8 byte ytes d
s data ata

Seq=92 timeout
Seq =
100,
20 by
tes da
timeout

Seq=100 timeout
ta
=100
ACK 0
10
X K=
AC ACK=
120
loss
Seq=9 Seq=9
2, 2, 8 byte
8 byte s data
s data

20
K=1
=100 AC
ACK

time time Timeout prematuré,

ACK perdu
ACK cumulé

2: Application Layer 13

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

Tampon de reception
2: Application Layer 14

7
TCP: Temps aller-retour (RTT) et
temps de garde
Q: Comment définir la Q: Comment estimer le RTT?
valeur du temps de ? SampleRTT: temps mesuré
garde dans TCP? depuis l’émission du segment
jusqu’à la réception de son ACK
? Supérieur au RTT
? Ignorer les retransmissions
? note: RTT varie
multiple, et les ACKs cumulés
? Trop petit : timeout
? SampleRTT varie: un RTT plus
prematuré
régulier est nécessaire
? Retransmissions
? Moyenner sur plusieurs
redondante
mesure récente du
? Trop long: lenteur de la SampleRTT
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

8
TCP: Gestion de la Connexion
? L’émetteur et le réception Poignée de main
doivent initier une
« connexion TCP » avant tripartite:
d’échanger des données
? Initialiser les variables TCP: ? 1: le client envoit un segment
? seq. #s de contrôle TCP SYN
? Tanpons, information de ? Défini le seq # initial
contrôle de flot (e.g.
RcvWindow) ? 2: le serveur reçoit le SYN, et
? client: initiateur de la répond par un segment de
connexion 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 = ? specifie le seq.# initial du
welcomeSocket.accept(); serveur-> récepteur
2: Application Layer 17

TCP: Gestion de Connexion (cont.)

Fermer une connexion: client server

close
Le client ferme la socket: FIN
clientSocket.close();

1: le client envoit un segment ACK

close
TCP FIN au serveur FIN

2: le serveur reçoit le FIN,

timed wait

repond par un ACK. Ferme la ACK

connexion et envoi un FIN.

closed

2: Application Layer 18

9
TCP: Gestion de Connexion (cont.)

3: le client reçoit un FIN, et client server

répond par un ACK. closing
FIN
? Passe en attente et
acquitte to les FINs
qu’il reçoit ACK
closing
4: le serveur, reçoit l’ACK. FIN

La connexion est fermé.

timed wait
ACK

closed

closed

2: Application Layer 19

TCP: Gestion de Connexion (cont.)

Cycle de vie du serveur TCP

Cycle de vie du client TCP

2: Application Layer 20

10
 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

2: Application Layer 22

11
 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

? ? = ? (goodput)
in out
? Si la retransmission est parfaite : ? > ? out
in
? La retransmission de paquet non perdu rend ? que dans le cas
in
parfait

“coûts” de la congestion:
? Plus de travail (retrans) pour un même débit utile (“goodput”)
? Retransmissions redondantes
2: Application Layer 24

12
Approches du contrôle de congestion
Deux approches principales :

Contrôle de congestion Contrôle de congestion

de Bout-en-bout : assisté par le réseau:
? Pas de feedback explicite ? Les routeurs fournissent un
du réseau feedback aux émetteurs
? La congestion est estimé ? Un bit d’annonce de
grace à l’observation des congestion (SNA,
pertes et des délais de DECbit, TCP/IP ECN,
bout en bout. 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

? w segments, chacun avec MSS octets transmis

durant un RTT:
w * MSS
throughput = Bytes/sec
RTT
2: Application Layer 26

13
 Contrôle de Congestion TCP
? “probing” pour la bande
passante disponible:
? 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
? Deux “phases”
? slow start
? congestion avoidance
? Variables importante:
?
Congwin
? threshold: defini le
seuil entre les deux
phases

2: Application Layer 27

TCP Slowstart
Host A Host B
algorithme Slowstart one segm
ent
RTT

initialiser: Congwin = 1
for (each segment ACKed) two segm
ents
Congwin++
until (loss event OR
four segm
CongWin > threshold) ents

? 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

14
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

2: Application Layer 29

AIMD
TCP et justice
TCP congestion
avoidance: Justice: Si N sessions
? AIMD: additive TCP partage un même
increase, lien chacune doit
multiplicative obtenir 1/N de la
decrease capacité du lien
? Augmente la fenêtre TCP connection 1
de 1 par RTT
? Réduit la fenêtre
d’un facteur 2 en cas
de pertes
bottleneck
TCP
router
connection 2
capacity R

2: Application Layer 30

15
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
Connection 2 throughput Partage égal

Connection 1 throughput R

2: Application Layer 31

16