Services et protocoles de la couche Transport

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

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

3. 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 Pourquoi UDP?
? Service “au mieux”, les ? sans délai de connexion
segments UDP peuvent être:
? simple: sans nécessité d’
un
? Perdus état dans l’
émetteur et le
? Delivré dans le désordre récepteur
? Sans connexion: ? Petit entête
? Sans handshaking entre ? Sans contrôle de congestion:
l’
émetteur et le UDP peut émettre aussi
récepteur rapidement qu’ le souhaite
il
? Chaque segment UDP est
traité indépendamment
des autres
2: Application Layer 6
3

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

5. 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 ‘ , en
C’
prochain octet =43,
data
=‘ ’
C
envoyant
attendu Seq =79
, ACK
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

6. 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’ segment dans
un 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’ segment dans
un Envoyer immédiatement un ACK cumulé
l’
ordre, sans trou,
Un ACK en attente
Arrivée d’ segment dans
un Envoyer un ACK dupliqué, indiquant le seq. #
le désordre avec un seq. # Du prochain octet attendu
supérieur à l’
attente
Arrivée d’ segment qui
un Envoyer immédiatement un ACK si le segment
remplit partiellement ou rempli un trou
complètement le trou
2: Application Layer 12
6

7. 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 Recepteur: informe
L’
émetteur ne submerge explicitement l’émetteur
pas le récepteur en
de l’
espace vide (qui
émettant trop
rapidement change dynamiquement)
? champs RcvWindow
RcvBuffer = Taille du tampon de réception TCP dans l’éntête TCP
RcvWindow = espace vide dans le tampon
émetteur: borne la taille des
données transmise et non
acquittées à RcvWindow
Tampon de reception
2: Application Layer 14
7

8. 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’ échantillon est réduit
un
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

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

10. 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’ reçoit
il 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

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

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

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

14. Contrôle de Congestion TCP
? “probing” pour la bande ? Deux “phases”
passante disponible: ? slow start
? idealement: émettre le plus ? congestion avoidance
rapidement possible ? Variables importante:
(Congwin aussi grand que
?
possible) sans pertes Congwin
? augmenter Congwin jusqu’ à ? threshold: defini le
une perte (congestion) seuil entre les deux
phases
? perte: réduire Congwin, et
recommencer
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

15. 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’ facteur 2 en cas
un
de pertes
bottleneck
TCP
router
connection 2
capacity R
2: Application Layer 30
15

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