La couche Transport

Master Spé MIAGE
M1
UE Réseaux
La couche Transport
Emmanuel Hyon
E. Hyon
2
2007-2008
Services et protocoles de transport

nd
-e
network
data link
physical
sp
an
tr
network
data link
physical
t
or

nd

network
data link
physical
network
data link
physical
e
al

application
transport
network
data link
physical
ic
log

Fournit une communication
logique entre processus
tournant sur des hosts ≠
Les protocoles de
transport tournent dans
les hôtes
Services de couche
transport vs réseau :
Couche réseau : transfert
de données entre hôtes
Couche transport :
transfert de données
entre processus fondé sur
les services (de couche)
réseau
network
data link
physical
application
transport
network
data link
physical
E. Hyon
2007-2008
Rôle et défis du Transport
3
 Transformer
les pptés pas tjs désirables du réseau
en un service de haut niveau souhaité par les appli

Prendre en compte le
service fourni par la couche
réseau






Pertes de paquets
Déséquencements
Duplications
Erreurs
MTU
Temps de traversée
imprévisibles

Prendre en compte les
besoins des applications








Garantie de remise des msg
Séquencement
Absence de duplications
Absence de messages erronés
Messages de lg quelconque
Synchronisation entre
l'émetteur et le récepteur
Contrôle de flux par le
récepteur sur l'émetteur
Support de +ieurs appli
sur le même hôte
E. Hyon
4
2007-2008
Protocoles de transport Internet
network
data link
physical
t

or

Temps réel
Garantie de bande passante
Multicast fiable
sp

an

Livraison non fiable (“besteffort”), non séquencée,
point à point ou multicast
(UDP)
Services non disponibles :
network
data link
physical
tr

nd
-e

nd

Contrôle de congestion
Contrôle de flux
Mode connecté
network
data link
physical
e
al

network
data link
physical
ic
log
Services de transport :
 Livraison fiable, séquencée
et point à point (TCP)
application
transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
E. Hyon
5
2007-2008
Multiplexage/démultiplexage
un exemple introductif
 Courrier
interne dans une entreprise.

Employé d'un service: remise du courrier dans une
case courrier

Une personne prend courrier amène au service
courrier général

Le service courrier trie les courriers par service

L'employé chargé de la remise prend les courriers
destiné à son service

Les remets à leur destinataire.
E. Hyon
2007-2008
Multiplexage démultiplexage
Le but
6
 Collecte
des données envoyées par les différents
processus et encapsulation dans des segments
envoyés au medium.



+sieurs applis tournent et emettent des données
Il faut pouvoir les envoyer par le même canal
service de multiplexage
 Livraison
des segments reçus aux bons processus
+sieurs applis tournent simultanément sur un même host
 Il faut pouvoir les identifier de façon non ambiguë
⇒ service de demultiplexage

E. Hyon
7
2007-2008
Multiplexage/démultiplexage
Rappel : segment - unité de données échangées entre
entités de couche transport
= TPDU: Transport Protocol Data Unit
P3
APDU
(message)
Entête du
segment
segment
M
P1
M
Ht
M
H n segment
récepteur
application
transport
network
M
application
transport
network
P4
M
P2
application
transport
network
E. Hyon
8
2007-2008
Implémentation des ports
 Port

 En
= référence abstraite
L'implémentation diffère d'un OS à l'autre !
général, un port = une file de messages
processus
d'appli
processus
d'appli
processus
d'appli
ports
files
UDP
démuX
arrivée de segments

Insertion en queue (par UDP)


Si file pleine, rejet msg
Retrait en tête (par le
processus)

Si file vide, le processus se
bloque jusqu'à ce qu'un msg
soit disponible
E. Hyon
9
2007-2008
Numéros de port
3

catégories
Ports well-known : de 0 à 1023
 Alloués
par l'IANA
 Sur la plupart des systèmes, ne peuvent être utilisés que par des
processus système (ou root) ou des programmes exécutés par des
utilisateurs privilégiés

Ports registered : de 1024 à 49 151
 Listés
par l'IANA
 Sur la plupart des systèmes, peuvent être utilisés par des
processus utilisateur ordinaires ou des programmes exécutés par
des utilisateurs ordinaires

Ports dynamic/private : de 49 152 à 65 535
 Alloués
dynamiquement
E. Hyon
2007-2008
Les ports quelques remarques
segment donne l'information sur le port
local, port distant (ainsi que les adresses IP).
 Fermeture des ports
10
 Chaque


Au niveau transport : on ne donne pas le droit à des
sockets de se connecter (pas de socket d'accueil en TCP
par exemple). Mais les paquets IP peuvent très bien
arriver au terminal
Fermeture selon le port distant
 Toutes
les sockets dont le port distant est x ne peuvent être
connectées

Fermeture selon port local
 Aucune
socket dont le port local est y ne sera acceptée
E. Hyon
2007-2008
 Un

Serveur TCP et UDP
serveur TCP est GÉNÉRALEMENT concurrent
Arrivée d’une requête => le serveur l'accepte et crée un
nouveau processus pour gérer le nouveau client (par ex, il
fait un fork), cf le cours CAR sur le client/serveur ou le
cours système.
Identité du nouveau processus ?

Son n° de port reste le même que celui du processus
d'accueil (i.e. le père)
@IP client, n° port client, n° port serveur
 Un

11
serveur UDP est généralement itératif
les segments sont traités les uns à la suite des autres
E. Hyon
Multiplexage/démultiplexage
UDP
2007-2008
multiplexage/démultiplexage :
 Basé sur les n° de ports
source / destination pour
une @IP



N° de ports source & dest
dans chaque segment
N° de ports “well-known” pour
des applications spécifiques
Clé de démultiplexage de UDP
= (#port) une fois sur le host
12
32 bits
# port source
# port dest
Autres champs d’entête
APDU
(message)
Format de segment TCP/UDP
E. Hyon
13
2007-2008
Le démultiplexage TCP
 TCP
utilise le triplet (n° de port local, @IP
distante, n° de port distant) pour démultiplexer
(identifier le processus destinataire du segment)
 Rappel
: UDP utilise le n° de port local
(destinataire) pour identifier un processus
POURQUOI ?
E. Hyon

14
Exercice démultiplexage
2007-2008
Pour UDP et TCP un envoi sur un même serveur B de :
 Plusieurs

sockets provenant du même terminal A:
• ports locaux (sur A) x et y et distant 80 et 110
Plusieurs sockets provenant de C:
Client Web
• port distant 80 et locaux x et y
host C
Source IP: C
Dest IP: B
source port: y
dest. port: 80
Source IP: A
Dest IP: B
source port: x
dest. port: 110
Client Web
host A
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
Serveur Web
B
Application Web
E. Hyon
15
2007-2008
Le multiplexage TCP
 Comment



identifier chaque processus destinataire ?
Le port local sur le serveur distingue ?
 Regarder
les sockets provenants de A
 Regarder
les deux sockets provenants de B
 Regarder
les sockets de même port provenant de A et B
Le port distant sur le serveur distingue ?
Les adresses IP sources suffisent-elles ?
 Sur
votre terminal tapez la commande
netstat ­tau
E. Hyon
16
2007-2008
UDP : User Datagram Protocol
[RFC 768]
 Service
“best effort” : les segments UDP peuvent
être perdus ou déséquencés

Pas de contrôle de congestion
 Service
en mode non connecté

Pas d’établissement de connexion entre host émetteur et
host récepteur => simplicité

Chaque segment UDP est acheminé indépendamment des
autres (pour la même communication) => déséquencement
E. Hyon
17
2007-2008

Souvent utilisé pour les appli
multimédia (flux)
Lg en octets,



Tolérantes aux pannes
Sensibles au débit
Autres usages d’UDP



Compléments sur UDP
du segment
UDP entête
incluse
# port source
# port dest
length
checksum
DNS
SNMP
Transfert fiable avec UDP :
ajouter la fiabilité dans la
couche application

32 bits
APDU
(message)
Recouvrement d’erreurs
spécifique pour l’application
Format du segment UDP
E. Hyon
18
2007-2008
Le checksum UDP (facultatif en IPv4)
But : détecter des “erreurs” (bits erronés) dans le
segment émis
 Portée

Le segment UDP
 L'en-tête
UDP
 Le champ de données UDP

Un pseudo-header (qui inclut des champs du datagramme)
 Champ
IP protocol (8 bits cadrés à droite sur 16 bits)
 Champ IP @source (32 bits)
 Champ IP @dest. (32 bits)
 Champ UDP length (16 bits)
 UDP
est indissociable de IP !
!
E. Hyon
19
2007-2008
Calcul du checksum UDP
Émetteur :
 Le champ checksum est
initialement mis à 0
 La suite à protéger est
considérée comme une
suite de mots de 16 bits
 Calcul du Checksum



Addition des mots de 16 bits
(modulo 65 535) puis
Complément à 1 (inverse bit
à bit) du résultat de
l’addition
Insertion du checksum
dans l’entête
Récepteur :
 Calcule le checksum du
segment reçu
 Vérifie si le checksum
calculé est 11 11...


NON - erreur détectée. Le
segment est abandonné
OUI - pas d’erreur
détectée
Cas particulier :
Le checksum dans le segment
reçu est à 0 = il n’a pas été
calculé
E. Hyon
20
2007-2008
Exercice : Calcul de checksum

On suppose que les données à envoyer représentent x mots de 16
bits quel est le checksum ?
Le checksum est le complément à 1 de la somme des x mots.

Exemple :

Les données sont décomposées en 3 mots de 16 bits




0110011001100110

0101010101010101

0000111100001111
Le checksum donné sur le segment UDP est
1.
0010010100110101
2.
0011010100110101
Dans quel(s) cas le segment est corrompu ?
E. Hyon
21
2007-2008
Segmentation
 En

 En
théorie
Les segments UDP peuvent être segmentés par IP
pratique
La plupart des applications utilisant UDP limitent leurs
segments à 512 octets
 Pas de segmentation
 Pas de risque de message incomplet

E. Hyon
2007-2008
22
TCP: Transmission Control Protocol
RFCs: 793, 1122, 1323, 2018, 2581

Point à point



Un émetteur, un récepteur
Fiable, flux d’octets
ordonné

Full duplex

Pas de “délimiteurs de
message”

Les contrôles de congestion
et de flux TCP fixent des
tailles de fenêtres

Mode pipeline


Flux de données bidirectional sur la même
connexion
Mode connecté

Établissement de
connexion (handshaking)
Contrôle de flux

L’émetteur n’inonde pas le
récepteur avec ses envois
E. Hyon
23
2007-2008
TCP: orienté flux (Byte-oriented)
 TCP


Le processus émetteur "écrit" des octets sur la connexion
TCP
Le processus récepteur "lit" des octets sur la connexion
TCP
 TCP

est orienté flux d'octets
ne transmet pas d'octets individuels
En émission
 TCP
bufferise les octets jusqu'à en avoir un nombre raisonnable
 TCP fabrique un segment et l'envoie

En réception
 TCP
vide le contenu du segment reçu sans un buffer de réception
 Le processus destinataire vient y lire les octets à sa guise
E. Hyon
24
2007-2008
TCP: orienté flux (Byte-oriented)
processus
émetteur
processus
récepteur
écrit des octets
TCP
buffer d'émission
lit des octets
TCP
buffer de réception
transmet des segments
E. Hyon
25
2007-2008
Construction d'un segment
(envoi concret: des segments)
Quand est-ce que TCP décide d'envoyer un segment ?

Taille du champ de données d’un segment = MSS
(MaximumSize Segment) octets



Le processus lui demande explicitement


Dépend de l’implantation de TCP (1500, 536, 512 oct)
Autre contrainte liée à la taille du champ de données
d’une trame (MTU)
Fonction push
Le temporisateur expire

Pour éviter d'attendre trop longtemps MSS octets
E. Hyon
26
2007-2008
Entête Champ de données
(message)
TCP
Entête
IP
Champ de données
(segment TCP)
Entête Champ de données (datagramme IP)
Segment TCP
(couche 4)
Datagramme IP
(couche 3)
Trame (couche 2)
MTU
MTU – en-tête IP – en-tête TCP
E. Hyon
27
2007-2008
Le segment TCP
header
data
0
4
8
16
19
24
31
destination port
source port
sequence number
acknowledgment number
data
offset
unused
UA P RS F
RCSSY I
G K H TNN
window
urgent pointer
checksum
options
padding
data
E. Hyon
28
2007-2008
Les champs de l'en-tête TCP
source port : identifie le
processus source sur la machine
source
 destination port : identifie le
processus destinataire sur la
machine destinataire
 checksum : obligatoire, calculé
sur la totalité du segment et sur
le pseudo en-tête
 data offset : lg de l'en-tête en
mots de 32 bits


unsused : 6 bits à 0

Fiabilité



Contrôle de flux


options : MSS, …
 padding : alignement de l'entête sur 32 bits
rcvWindow : # d'octets de données que le
destinataire du segment est prêt à recevoir
Flags




sequence n° : N° du 1er octet de données
du segment (sauf si SYN=1 : ISN)
acknowledgment n° : acquitte tous les
octets de données de N° strictement
inférieur

RST, SYN et FIN : pour l’établissement et
la fermeture de connexion
ACK : 1 si le champ acknowledment number
est significatif
PSH : 1 si fin d'un msg logique (push)
URG : 1 si données urgentes

urgent pointer : pointe sur la fin (comprise)
des données urgentes
E. Hyon
29
2007-2008
TCP : fiabilité du transfert de données
 Fiabiliser
le transfert de données sur un « canal »
avec erreur et perte
processus
processus
données
TCP : protocole de
transfert fiable
de données
segment
données
TCP : protocole de
transfert fiable
de données
segment
Canal non fiable
TCP : Contrôle d'erreur et Contrôle de flux
E. Hyon
Fiabilité
2007-2008
Mécanismes
 Principe


de base:
Dire quels sont les paquets reçus et quels sont les
paquets non reçus.
On identifie ceux qui ne sont pas reçus et on les
réemet.
 Exercice
Donner un exemple de protocole qui
permette de mettre en place un contrôle des
paquets reçu afin de n'en perdre aucun.


On supposera tout d'abord qu'il n'y a pas de pertes
des paquets de contrôle.
Application dans un cadre plus général du
contrôle d’erreurs
30
E. Hyon
31
2007-2008
Contrôle d'erreur
 Repose



sur
Le champ Checksum : idem à UDP
 Permet
de savoir si un bit est erroné
 Permet
de détecter la perte de segment (si déséquencement)
Le champ SequenceNumber
Des acquittements
 Permet
de prévenir l’autre extrémité des pertes (sur
déséquencement)

Des retransmissions
 Permet
de remédier aux pertes de segments et aux réceptions de
segments erronés

Un temporisateur de retransmission
E. Hyon
2007-2008
Sequence number
32
(identifications des octets envoyés)


TCP : transport de flux d’octets
Numérotation des octets : Sequence number


Représente le numéro du 1er octet dans le segment
Exercice : donner les n° de séq des deux premiers segments,
du 5ème et du dernier pour



Un fichier de 500 000 octets émis par A
MSS = 1000 octets
La numérotation des octets commence à 0
Nb segments = 500, dans 1 segment : 1000 octets
1er segment : de 0 à 999 - 2ème segment : de 1000 à 1999
Le 5ème segment : de 4000 à 4999
Le dernier segment : de 499 000 à 499 999
E. Hyon
2007-2008
Sequence number (suite)
33
Et si le segment a un champ de données vide ?
 1er

échange : segment d’établissement de connexion
SYN = 1 et sequence # = ISN
 Fin
d’échange : segment de fin de connexion
 Segment d’accusé de réception
Sequence # = sequence # +1
E. Hyon
34
2007-2008
ACK number
 Numéro
du prochain octet attendu
A
B
Seq # = 19
99, Ack # =
10
000
2
=
#
k
c
A
Seq # = 10,
 Acquitte
A a reçu de B les
octets de 0 à 9. Le
prochain octet
attendu par A est 10
B a reçu de A les
octets de 0 à 1999.
Le prochain octet
attendu par B est
2000
(accuse réception) de tous les octets reçus
jusqu’à ACK # - 1 (strictement inférieur au
ACK #)
E. Hyon
35
2007-2008
Exercice
 Exemple
simple d’une application : echo
A
 A initie le dialogue : il saisit
 B lui renvoie la lettre saisie
 Représenter

B
la lettre « C »
Le séquence #, le ACK # et le champ data de chaque
segment échangé entre A et B avec les hypothèses
suivantes :
 La
connexion est déjà établie
 La numérotation de A commence à 42, celle de B à 79
 La lettre « c » = 1 octet
E. Hyon
36
2007-2008
Corrigé
A
B
Seq # = 42
, Ack # = 7
9, data=‘c’
‘c’
=
a
t
a
d
,
3
4
# =
k
c
A
,
9
7
=
Seq #
Seq # = 43,
Ack # = 80
e
m
ê
m
e
l
iser
l
i
t
U
:
es
k
d
c
r
a
e
b
y
y
o
g
Pig
env
r
u
o
p
es
t
segmen et acquitter d
données ées reçues
donn
E. Hyon
37
2007-2008
La génération des ACK
[RFC 1122, RFC 2581]
Event
Action
Arrivée séquencée d’un segment
Pas de perte,
Tous les octets précédents sont
déjà acquittés
ACK retardé. Attente jusqu’à 500ms
d’un prochain segment à émettre. S’il n’y en
a pas, envoi du ACK
Arrivée séquencée d’un segment
Pas de perte,
un ACK en attente d’envoi
Émission immédiate d’un ACK cumulatif (un
seul ACK accuse réception de +sieurs
segments)
Arrivée déséquencée d’un segment
seq. # > à seq # attendu
Perte détectée
Envoyer un ACK dupliqué, indiquant le seq.
# du prochain octet attendu
E. Hyon
2007-2008
38
TCP: scénarios de retransmission
Host A
Host A
Host B
=100
K
C
A
X
perte
Seq=9
2, 8 b
ytes d
ata
=100
K
C
A
time
Perte d’acquittement
=> réemission de A
B jette le segment retransmis (il l’a déjà)
Seq=100 timeout
Seq=92 timeout
timeout
Seq=9
2, 8 b
ytes d
ata
Host B
Seq=9
2, 8 b
ytes d
ata
Seq=
100, 2
0 byte
s data
0
10
=
K
AC
0
=12
K
AC
Seq=9
2, 8 b
ytes d
ata
0
=12
K
AC
time
Expiration de temporisateur avant
arrivée du ACK => réémission
(seul le segment concerné est
réémis. Le 2ème segment n’a pas
besoin d’être réémis)
E. Hyon
39
2007-2008
TCP: scénarios de retransmission
Host A
Host B
Seq=92 timeout
Seq=9
2, 8 b
ytes d
ata
0
10
Seq=
=
K
100, 2
0 byte AC
s data
X
perte
0
=12
K
AC
time
Perte d’acquittement mais
l’ACK cumulatif évite la
retransmission du 1er segment
E. Hyon
40
2007-2008
Dimensionnement du temporisateur
Q: Quelle doit être la valeur
du temporisateur ?
 Suffisament grand pour
qu’un aller-retour se
produise (émission segment retour ACK) => > RTT


Si T trop court : expiration
prématurée


Attention : le RTT varie
Q: Comment estimer le RTT?
 SampleRTT: temps écoulé
entre transmission segment
jusqu’à réception ACK

Pb : SampleRTT varie, il
diffère d’un segment à
l’autre

Retransmissions inutiles
Si T trop long: manque de
réactivité à la perte de
segment

Temps de traversée du réseau
dépend du trafic
Travailler avec un échantillon
de valeurs
E. Hyon
2007-2008
Valeur du temporisateur
41
 La
valeur du temporisateur est une estimation du
RTT à laquelle on ajoute une marge de sécurité

Plus la variation de EstimatedRTT est grande, plus la
marge de sécurité doit l’être également

La valeur vaut donc
Timeout = EstimatedRTT + 4*Deviation
 Où Deviation estime la variation de SampleRTT par
rapport à EstimatedRTT
 Et EstimatedRTT : moyenne pondérée entre
l'estimation précédente et le dernier échantillon
mesuré du RTT

L’influence d’un échantillon donné décroit exponentiellement vite
EstimatedRTT = α*EstimatedRTT + (1–α)*SampleRTT
E. Hyon
42
2007-2008

Dimensionnement du temporisateur
Problème

un ACK n'acquitte pas une
transmission, mais une
réception
tran
tran
sm.
sm.
retr
retr
ansm
ansm
.
.
ACK
ACK
SampleRTT SampleRTT
trop grand trop petit

Algorithme de Karn-Partridge


ne mesurer SampleRTT que pour les
segments envoyés une seule fois
calcul de TimeOut
à chaque retransmission, doubler la
valeur de TimeOut, jusqu'à ce que
la transmission réussisse
 pour les segments suivants,
conserver la valeur du TimeOut,
jusqu'à ce qu'un segment soit
acquitté du 1er coup
 recalculer TimeOut à partir de
EstimatedRTT

E. Hyon
2007-2008

43
Contrôle d’erreur : le pipelining
Mécanisme d’anticipation des émissions sans acquittement :
protocole Go-Back-N (GBN)
base
nextseqnum
Taille de fenêtre
N (=14)
Déjà acquittés
Émis, non acquittés
Taille de N ?
cf. le contrôle de flux
N° utilisables, encore
non émis
[nextseqnum, base+N-1]
N° non utilisables
≥ base+N
E. Hyon
44
2007-2008
Contrôle de flux
Contrôle de flux
L’émetteur n’inonde pas le
récepteur en émettant
trop, et trop vite
RcvBuffer = taille des buffers de réception
RcvWindow = espace libre dans les buffers
Buffers de réception
récepteur: informe
explicitement l’émetteur de
l’espace disponible dans les
buffers (=> nb d’octets qu’il
est prêt à recevoir)
 champ rcvWindow dans
le segment TCP
émetteur: conserve un volume
de données transmises non
acquittées inférieur au
RcvWindow le plus
récemment reçu
le
b
a
i
r
a
: v E !
w
o
d
Win AMIQU la même
RcvD
YN ours de P
c ion TC
u
a
e
Vari connex
E. Hyon
45
2007-2008
Questions
 Un
host B alloue une taille RcvBuffer de buffer en
réception pour une connexion TCP avec un host A
 LastByteRead = n° du dernier octet lu par
l’application B dans le buffer
 LastByteRcvd = n° du dernier octet arrivé par le
réseau et placé dans le buffer
 Quelle est la relation entre ces trois variables ?
 Soit RcvWindow la taille de la fenêtre (espace
disponible dans le buffer de taille RcvBuffer).
Exprimer RcvWindow en fonction des trois autres
variables
E. Hyon
46
2007-2008
Réponses
 Relation
entre RcvBuffer, LastByteRead et
LastByteRcvd
RcvBuffer
LastByteRead
…
 Valeur
de RcvWindow
LastByteRcvd
RcvBuffer
LastByteRcvd
LastByteRead
RcvWindow
(Rq : à l’initialisation, RcvWindow = RcvBuffer)
E. Hyon
47
2007-2008
Réponses
 Relation
entre RcvBuffer, LastByteRead et
LastByteRcvd
LastByteRcvd - LastByteRead ≤ RcvBuffer
LastByteRead
Ex : RcvBuffer = 1000
LastByteRead = 1000
LastByteRcvd = 2000
RcvBuffer
…
 Valeur
de RcvWindow
LastByteRcvd
RcvWindow = RcvBuffer - (LastByteRcvd - LastByteRead)
RcvBuffer
LastByteRcvd RcvWindow
LastByteRead
(Rq : à l’initialisation, RcvWindow = RcvBuffer)
E. Hyon
48
2007-2008
Côté émetteur
 L’host


émetteur stocke
Les données envoyées et en attente d'acquittement
Les données passées par le processus émetteur mais non
encore émises
processus
émetteur
TCP
LastByteWritten
LastByteAcked LastByteSent
E. Hyon
49
2007-2008
Questions
 Caractériser
le volume de données envoyées non
acquittées
 Caractériser le volume de données passées par le
processus et non envoyées
 Quelle est la relation que A doit vérifier avant
d’émettre pour assurer le contrôle de flux ?
 Soit SentBuffer : taille du buffer émission. Quelle
est la relation que A doit vérifier avant d’accepter
une écriture de y octets par un processus ?
LastByteSent - LastByteAcked
LastByteWritten - LastByteSent
LastByteSent - LastByteAcked ≤ RcvWindow
(LastByteWritten – LastByteAcked) + y ≤ SentBuffer
E. Hyon
50
2007-2008
Réouverture de fenêtre
Et si la fenêtre est fermée ?
RcvWindow=0 => plus de place dispo chez le récepteur
 L’émetteur
fenêtre


 Et

Quand le processus récepteur aura lu des données
Déblocage sur réception d’un seg avec RcvWindow > 0
si le récepteur n’a rien à émettre ?
Dans TCP, un ACK ne peut être envoyé que sur réception
de données (approche smart sender/dumb receiver)
 Solution

est bloqué en attente d’ouverture de
Lorsque l'émetteur reçoit une RcvWindow à 0, il envoie
périodiquement un segment d’1 octet de données pour
provoquer l'envoi d'un ACK
E. Hyon
51
2007-2008
Le contrôle de congestion
Congestion
 Informellement : “trop de sources envoient trop de
données, trop rapidement, plus que ce que le réseau
peut absorber”
 Différent du contrôle de flux !
 Manifestations


 Un
Perte de segments (overflow des buffers aux routeurs)
Long retards (temps d’attente élevés dans les buffers des
routeurs)
des 10 problèmes majeurs en réseau !
E. Hyon
52
2007-2008
Approches pour le contrôle de congestion
Deux grandes approches :
Contrôle de congestion de
bout en bout :
Contrôle de congestion
assisté réseau :




Pas d’informations explicites de la
part du réseau
La congestion est supposée par le
système terminal à partir de
l’observation de pertes et de
retards
Approche mise en œuvre dans TCP
Les routeurs fournissent des
informations aux systèmes
 Un bit indicateur de
congestion (SNA, DECbit,
ATM, une extension
deTCP/IP)
E. Hyon
2007-2008
TCP : Contrôle de Congestion
 Contrôle

 Le
53
de bout en bout
IP ne fournit aucune information sur l’état du réseau
taux de transmission des segments est limité par
la taille de la fenêtre de contrôle de flux

w segments, chacun de MSS octets, envoyés chaque RTT
sec
throughput =
 Nouvelle
w * MSS
Bytes/sec
RTT
donnée : la fenêtre de congestion Congwin
Congwin
E. Hyon
54
2007-2008
RcvWindow vs CongWin
 AvecTCP

gestion de deux fenêtres
Une fenêtre pour le contrôle de flux
 La
taille de la fenêtre a un impact sur le nombre de segments
envoyés par anticipation (sans ACK)
LastByteSent - LastByteAcked ≤ RcvWindow

Une fenêtre pour le contrôle de congestion
 Pour
prendre en compte ces deux fenêtres :
LastByteSent - LastByteAcked ≤
min(RcvWindow,CongWin)
E. Hyon
2007-2008
TCP : Contrôle de Congestion
55
Calcul de la fenêtre de congestion “idéale »

“recherche” de la bande
passante utilisable




Idéalement : transmettre aussi
vite que possible sans perte
(Congwin aussi grand que
possible)
Initialiser Congwin à 1 MSS
Augmenter Congwin jusqu’à
avoir une perte (congestion)
Perte : réinitialiser Congwin,
puis recommencer à augmenter

Deux “phases”



Le slow start
L’évitement de congestion
Variables importantes


Congwin
threshold: définit le seuil
entre les deux phases (quand
finit le slow start et
commence l’évitement de
congestion)
E. Hyon
56
2007-2008
Phase 1 : Le Slowstart
Algorithme Slowstart


Augmentation exponentielle (par
RTT) (1, puis 2, puis 4, puis 8, …)
Détection de perte : expiration du
temporisateur (algo TCP Tahoe)
et/ou trois ACKs dupliqués (algo TCP
Reno)
RTT
Init.: Congwin = 1
for (each segment ACKed)
augmenter Congwin
until (perte OR
CongWin > threshold)
Host A
Host B
un segme
nt
deux segm
ents
quatre se
gments
time
E. Hyon
2007-2008
Phase 2 : L’évitement de Congestion
Évitement de Congestion
/* slowstart terminé
*/
/* Congwin > threshold */
Until (perte) {
chaque w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
1
Recommencer le slowstart
Variante si l’algo Reno TCP est mis en œuvre : il lance le
slowstart (fast recovery) après trois ACKs dupliqués
57
E. Hyon
58
2007-2008
TCP : protocole en mode connecté
Rappel: émetteur et récepteur TCP établissent une connexion


avant d’échanger des segments de données
Initialisation de buffers et de variables TCP
 Buffers
 Numéros de séquence
 Variables de contrôle de flux (ex RcvWindow), de contrôle
de congestion
client : initiateur de connexion
Socket clientSocket = new

Socket("hostname","port number");
serveur : contacté par le client
Socket connectionSocket = welcomeSocket.accept();
E. Hyon
59
2007-2008
Établissement : three way handshake
Étape 1: le système client envoie le segment de contrôle SYN
au serveur (bit SYN = 1)
 Spécifie l’ISN
Étape 2: le système serveur répond avec un segment de
contrôle SYNACK
 Bit SYN = 1 et bit ACK = 1
 Champ ACK# = client_isn +1
 Champ SEQ# = son ISN
 Initialise buffers et variables
 Étape 3: le système client initialise ses buffers/variables
et acquitte le segment du serveur

SYN = 0 et champ ACK# = server_isn +1
E. Hyon
60
2007-2008
Établissement : les 3 segments échangés
Le client
SYN=1,
Le serveur
SeqNum
=client_
1
+
n
s
i
_
t
n
i
snum=clie
1
=
K
C
A
N
k
c
A
,
n
SYN=1,
s
i
r_
e
v
r
e
s
=
SeqNum
SYN=0,
s
ACK=1, A eqNum=client_i
sn+1,
ckNum=
server_
isn+1
Rq : bit ACK = 1 quand le champ ACK# est significatif
E. Hyon
61
2007-2008
Libération de connexion
Fermer une connexion :
Les 2 sens de transmission
sont fermés séparément.
Chacune des 2 extrémités
peut avoir l’initiative de
fermer.
client
close
Étape 2: le système serveur reçoit
le FIN, répond par ACK. Il ferme
la connexion, et envoie FIN.
FIN
timed wait
segment FIN au serveur (FIN=1)
FIN
ACK
Ex : Le client ferme la socket:
clientSocket.close();
Étape 1: le système client envoie le
server
closed
ACK
close
E. Hyon
62
2007-2008
Libération de connexion (suite)
Étape 3: le client reçoit FIN et
client
répond par ACK.

Il entre en “timed wait” :
femera la connexion 30 sec
après réception du FIN
closing
Étape 4: le serveur reçoit ACK.
FIN
ACK
La connexion est fermée.
closing
FIN
timed wait
Note: possibilité de gérer des
FINs simultanés.
server
closed
ACK
closed
E. Hyon
2007-2008
Le transport sécurisé
63
(Secure Socket Layer)
 SSH

Cryptage des données par
 SSL

Aucun cryptage des
données par l'appli. Mais
par contre les protocoles
doivent prendre en compte
que les données vont être
transportées cryptées.
Ex: https, pops, imaps.

Cryptage par la couche
couche application.

Transport en utilisant TCP
non sécurisé.
Cryptage des données par l'appli
Transport non crypté
transport (ou une couche
intermédiaire).
E. Hyon
2007-2008
Le transport sécurisé II
(Secure Socket Layer)
 Fonctions

assurées
Authentification de serveur (contrairement à ssh ou
pgp).

Authentification de clients (optionnelles)

Codage (cryptage) des sessions.
 Au
moyen d'un centre de certification (CA)

accréditent signent numériquement des certificats

hébergent les clefs publiques associées aux certificats

présentation « similaire » ssh clef ass puis clef sym
64
E. Hyon
2007-2008
 Soit
Auto-évaluation (vrai-faux)
65
un serveur Web HTTP à connexions
persistentes. Le serveur gère un processus par
client connecté au serveur. Alors chacun de ces
processus aura un numéro de port serveur distinct
 L’host A envoie à l’host B un grand fichier sur une
connexion TCP. B n’a pas de données à envoyer à A.
B ne pourra pas envoyer d’acquittement à A car il ne
peut pas faire de piggyback
 La taille de RcvWindow ne change jamais pendant
une connexion
 Le segment TCP a un champ dans son entête pour
RcvWindow
 L’host A envoie à B des données et B envoie à A des
données (les 2 sur TCP). Deux connexions TCP
séparées sont nécessaires.
E. Hyon
66
2007-2008
Auto-évaluation (vrai-faux)
 L’host
A envoie à l’host B un grand fichier sur une
connexion TCP. Si le numéro de séquence pour un
segment de cette connexion est m, alors le numéro
de séquence du segment suivant sera m+1
 Soit une connexion TCP avec le dernier SampleRTT
égal à 1 sec. Alors Timeout pour la connexion sera
nécessairement initialisé à une valeur >= 1 sec
 L’host A envoie à l’host B un segment avec un
numéro de séquence égal à 38 et 4 octets de
données. Alors dans ce segment, le numéro d’ACK
sera forcément 42
 Le MSS est la taille maximum d’un segment TCP,
entête incluse