Chapitre3 Transport Ver2

Cours Réseaux
Chapitre 3
Couche Transport
Université de Perpignan
Ouvrage de référence: Analyse Structurée des Réseaux, J. Kurose & K. Ross, Pearson Education, 2002
Chapitre 3: Couche Transport
Nos objectifs: 
Apprendre les protocoles de

Comprendre les principes la couche transport d'internet:
derrière les services de la ●
UDP: transport sans connexion
couche transport: ●
TCP: transport orienté
●
multiplexage/démultiplexage connexion
●
transfert de donnée fiable ●
contrôle de congestion de TCP
●
Contrôle de flux
●
Contrôle de congestion
2
Chapitre 3: Plan

3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage et
●
Structure des segments
démultiplexage
●
Transfert de données fiable
●
Controle de flux

3.3 Transport sans ●
Gestion de la connexion
connexion: UDP

3.6 contrôle de congestion

3.4 Principe du transfert ●
Principe
de données fiable
●
Controle de congestion
de TCP

3.7 Performance de TCP
3
Services et protocoles de la
couche Transport

La couche transport fournit une
communication logique entre
applicatio
processus tournant sur différents
Tr
n
an
transport
terminaux
sp
réseau réseau
or
liaison

Les protocoles de transport s'exécutent liaison
t
physique réseau physique
de
liaison
sur les terminaux :
bo
physique
ut
réseau
●
Coté expéditeur: il découpe les liaison
en
physique réseau
messages des processus en
bo
liaison
ut
physique
segments, et les passe à la couche
de
réseau
réseau liaison
ty
physique
pe
●
Cote destinataire: il réassemble les
lo
gi
applicatio
messages à partir des segments et
qu
n
les fait passer à la couche transport
e
réseau
application liaison
physique

Plus d'un protocole de transport
disponible :
●
Internet: TCP et UDP 4
Transport vs. Couche réseau

Couche réseau: Analogie foyer:
communication logique 12 enfants envoient des
entre terminaux lettres a 12 autres enfants

Couche transport: 
processus = enfant
communication logique 
messages des app =
entre processus lettres dans des
●
Est liée à la couche réseau enveloppes
et étend les services de
cette couche réseau

terminaux = maisons

protocole = Ann et Bill

Protocole de la couche
réseau = service postal
5
La couche transport : Introduction
Deux grands protocoles de

transport :
 UDP (User Datagram Protocol) : applicatio
Tr
n
non fiable
an
 transport
sp
réseau
 sans connexion réseau
or
liaison liaison
t
physique réseau
TCP (Transmission Control physique
de
 liaison
bo
physique
Protocol) :
ut
réseau
liaison
fiable (contrôle de flux, de
en
 physique réseau
bo
liaison
congestion, numéro de
ut
physique
séquence, accusés de
de
réseau
liaison
ty
réception) physique
pe
Convertit le service du protocole
lo

gi
applicatio
qu
IP (service non fiable de la n
transport
e
couche réseau) en un service réseau
liaison
fiable physique
Chapitre 3: Plan


3.2 Multiplexage et ●
démultiplexage ●

3.3 transport sans
●
Controle de flux
connexion: UDP
●

3.4 Principe du transfert

de donnee fiable
●
Principe
●
de TCP

7
Multiplexage/démultiplexage
Démultiplexage sur le terminal dest.: Multiplexage sur le terminal exp.:

Délivre le segment à la socket Rassemble les données provenant
correspondant au processus de multiple sockets, enveloppant
destinataire les données dans une entête
(utilisées plus tard pour le
= socket = processus
demultiplexage)
P3 P1
P1 P2 P4 application
application application
transport transport transport
reseau reseau reseau
liaison liaison liaison
physique physique physique
term 3
term 1 term 2
8
Comment ca marche le démultiplexage

Le terminal reçoit des datagrammes IP 32 bits
●
Chaque datagramme a une adresse
Numéro
IP source et une adresse IP de de port source
Numéro de port destination
destination
●
Chaque datagramme contient 1 Autres champs d'en-tête
segment de la couche transport
●
Chaque segment a un numéro de
port source et un numéro de port de
destination Données d'application
(message)

Le terminal utilise l'adresse IP et le
numéro de port pour diriger le segment
vers la socket appropriée
Format d'un segment TCP/UDP
9
Démultiplexage UDP (sans connexion)

Crée des sockets avec un 
Quand un terminal reçoit un
numéro de port: segment UDP, Il
DatagramSocket mySocket1 = new ●
vérifie le port de destination
DatagramSocket(12534); port dans les segments
DatagramSocket mySocket2 = new ●
dirige les segments UDP
DatagramSocket(12535);
vers la socket avec ce

Une socket UDP est identifiée numéro de port
par: 
Des datagrammes IP avec
(adresse IP de dest., numéro de port des adresses IP sources et
de dest.) des numéros de port sources
identiques sont redirigés vers
la même socket
10
Démultiplexage UDP (cont.)
DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P1
P1
P3
SP: 6428 SP: 6428

DP: 9157 DP: 5775
SP: 9157 SP: 5775

client DP: 6428 DP: 6428 Client
serveur
IP: A IP:B
IP: C
SP fournit “adresse de retour”

11
Démultiplexage TCP (orienté
connexion)

Socket TCP identifiée par 
Un processus du terminal peut
un quadruplet: supporter de nombreuse
●
Adresse IP source socket TCP simultanément:
●
Numéro de port source ●
chaque socket est identifiée par
●
Adresse IP de dest. son propre 4-tuple
●
Numéro de port de dest. 
Les serveurs web ont des

Le terminal destinataire sockets différentes pour
utilise les quatre valeurs chaque connexion client
pour diriger le segment à la ●
Une connexion HTTP non
socket appropriée persistante aura différentes
sockets pour chaque requête
12
Démultiplexage orienté
connexion (cont.)
P1 P4 P5 P6 P2 P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157 SP: 9157

client DP: 80 DP: 80 client
serveur
IP: A S-IP: A S-IP: B IP:B
IP: C
D-IP:C D-IP:C
13
Démultiplexage orienté
connexion: Web serveur threadé
P1 P4 P2 P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
serveur
IP: A S-IP: A S-IP: B IP:B
IP: C
D-IP:C D-IP:C
14
Chapitre 3: Plan


démultiplexage ●

3.3 Transport sans
●
Controle de flux
connexion: UDP
●


de données fiable
●
Principe
●
de TCP

15
UDP: User Datagram Protocol [RFC 768]

Protocole de transport Internet
“sans fioritures” Pourquoi utiliser UDP?

Service “au meilleur effort”, les 
Pas d'établissement de
segments UDP peuvent être: connexion (qui peut ajouter du
●
perdu délai)
●
Délivrés en désordre à 
simple: pas de données à
l'application destinataire maintenir concernant la

Sans connexion: connexion (côte expéditeur et
destinataire)
●
pas de “poignée de mains” ou
“présentation” entre expéditeur

Léger: petite entête
et destinataire UDP 
Pas de contrôle de congestion:
●
Chaque segment UDP est géré UDP peut envoyer des données
indépendement des autres. aussi rapidement qu'on le
souhaite
16
UDP: cont.

UDP est souvent utilisé par les
applications multimédias utilisant 32 bits
du streaming
Longueur en Port source # Port de dest#
●
Tolérant aux pertes
octets length checksum
●
Sensible au taux de d'un segment
transmission UDP

D'autres utilisations d'UDP incluant
l'entête
dans Donnée de
●
DNS l'application
●
SNMP (message)

Transfert basé sur UDP: gestion
de la fiabilité au niveau de la
couche application
●
Recouvrement d'erreur Format de segment UDP
spécifique à l'application !
17
La somme de contrôle
(checksum) d'UDP
Objectif: détecter des “erreurs” (e.g., bits erronés)
dans la transmission d'un segment
Expéditeur: Destinataire:

Traite le contenu des

Calcule la somme de contrôle du
segment reçu
segments comme une suite
d'entiers codés sur 16-bit

Vérifie si la somme de contrôle
calculée est égale à la valeur stockée

checksum: addition avec dans le champs “checksum”:
complément à 1 du contenu ●
NON - erreur détectée
du segment ●
OUI – pas d'erreur détectée. Mais

L'expéditeur met la somme de peut contenir des erreurs tout de
contrôle (checksum) dans le même? On verra ça plus tard ….
champs “checksum” de
l'entête UDP
18
La somme de contrôle d'UDP
Expéditeur Destinataire
0110011001100110
0110011001100110
+ 0101010101010101
+ 0101010101010101
+ 0000111100001111
+ 0000111100001111
= 1100101011001010
= 1100101011001010
+ 0011010100110101
0011010100110101
(complément à 1) = 1111111111111111
(<=Ok)
= 1111111101111111
(<=Erreur)
 Remarque: les additions sont faites modulo 2^16

Chapitre 3: Plan


démultiplexing ●
●
Controle de flux

3.3 Transport sans
●
connexion: UDP


de données fiable
●
Principe
●
de TCP

20
Principes du transfert de données fiable

Aspect important des couches application, transport et liaison.

top-10 des sujets important concernant les réseaux!

Caractéristique d'un canal non fiable déterminera la
complexité du transfert de données fiable. 21
(rdt= reliable data transfert)



top-10 des sujets important concernant les reseaux!




top-10 des sujets important concernant les réseaux!


Reliable data transfer: premier pas
rdt_send(): appel par le haut, (e.g., deliver_data(): appelé par

par l'appli.). Récupère les données rdt pour délivrer les données
provenant de la couche supérieure à la couche supérieure
pour les envoyer au destinataire
pôle pôle
expéditeur destinataire
udt_send(): appellé par rdt, rdt_rcv(): appelle lorsqu'un

pour transférer un paquet sur paquet est reçu du
un canal non sûr au côté destinataire
destinataire 24
Transfert de données fiable: premier pas
Nous allons:

Nous allons développer pas a pas les pôles expéditeur et
destinataire d'un transfert de données fiable (rdt)

Considérons seulement un transfert de données unidirectionnel
●
Mais les informations de contrôle navigueront dans les deux
directions!

On modélisera le rdt via machine à état fini (FSM=Finite State
Machine) pour l'expéditeur et le destinateur
événement provoquant un changement d'état

État: lorsque l'on est Actions réalisées lors du changement d'état
dans cet “état” le
prochain état est état état
déterminé 1 événement
2
uniquement par le actions
prochain événement
25
Rdt1.0: transfert fiable à travers un canal fiable

Le canal de transmission est parfaitement fiable
●
Pas d'erreurs sur les bits lors de la transmission
●
Pas de perte de paquet

Séparer FSMs pour l'expéditeur et destinataire:
●
L'expéditeur envoie des données dans le canal
●
Le destinataire lit les données sortant du canal
Attend un Attend un
rdt_send(data) appel de la rdt_rcv(packet)
appel de la
couche couche extract (packet,data)
packet = make_pkt(data) inférieure deliver_data(data)
supérieure
udt_send(packet)
Expéditeur Destinataire
26
Rdt2.0: canal avec des erreurs

Le canal de transmission peut modifier certains bits dans les
paquets
●
checksum pour détecter des erreurs eventuelles

LA question: comment recupérer des paquets erronés:
●
Accusé de réception/validité (Note ACKs=acknowledgements (): le
destinataire dit explicitement à l'expéditeur que le paquet reçu était correct
●
Accusé de réception négatif, d'invalidité (NAKs): le destinataire dit
explicitement à l'expéditeur que le paquet contenait des erreurs
●
L'expéditeur retransmet pkt (=paquet) lors d'une réception d'un NAK

Nouveau mécanisme dans rdt2.0 (au delà de rdt1.0):
●
détection d'erreur
●
Le destinataire répond par des messages de contrôle (ACK,NAK)
expéditeur->destinaire
27
Rdt2.0: canal avec des erreurs

Le canal de transmission peut modifier certains bits dans les
paquets
●
checksum pour détecter des erreurs éventuelles

LA question: comment récupérer des paquets erronés:
●
Accusé de réception/validité (Note ACKs=acknowledgements (): le
destinataire dit explicitement à l'expéditeur que le paquet reçu était correct
●
Accusé de réception négatif, d'invalidité (NAKs): le destinataire dit
explicitement à l'expéditeur que le paquet contenait des erreurs
●
L'expéditeur retransmet pkt (=paquet) lors d'une réception d'un NAK

Nouveau mécanisme dans rdt2.0 (au delà de rdt1.0):
●
détection d'erreur
●
Le destinataire répond par des messages de contrôle (ACK,NAK)
expéditeur->destinaire
28
rdt2.0: spécification du FSM
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
destinataire
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Attend un Attend un rdt_rcv(rcvpkt) &&
appel du ACK ou corrupt(rcvpkt)
udt_send(sndpkt)
haut NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Attend un
Λ appel du
dessous
expéditeur
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
29
rdt2.0: exemple de déroulement (1/10)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Attend un Attend un isNAK(rcvpkt)
Exp. appel du ACK ou
NAK udt_send(sndpkt)
haut

Λ
Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 30
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
haut

Λ
Dest.
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut

Λ
Dest.
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
Λ
Dest.
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut correctes
envoie
ACK
Λ
Dest.
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut correctes
envoie
ACK
Λ Attend un appel du
haut
Dest.
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut correctes
envoie
ACK
Λ Attend un appel du haut
Dest. corrompu
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut correctes
envoie
ACK
Dest. corrompu
rdt_rcv(rcvpkt) &&
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
haut correctes
envoie
ACK
Dest. corrompu
Attend ACK ou NAK données
incorrect
rdt_rcv(rcvpkt) && envoie
Attend un NAK
corrupt(rcvpkt)
appel du
udt_send(ACK)
rdt_send(data)
Exp. Dest.
udt_send(sndpkt)
Données
NAK udt_send(sndpk) données
haut correctes
envoie
ACK
Dest. corrompu
Attend ACK ou NAK données
incorrecte
rdt_rcv(rcvpkt) && envoie
Attend un NAK
corrupt(rcvpkt)
appel du
udt_send(ACK) Attend ACK ou NAK
rdt2.0 a une faille fatale!
Que se passe-t-il si Gérer les duplicatas:

ACK/NAK est corrompu? 
L'expéditeur retransmet le paquet

L'expéditeur ne sait pas ce qu'il courant si ACK/NAK abîmer
s'est passé au pôle 
L'expéditeur ajoute un numéro de
destinataire! séquence pour chaque paquet

Ne peut pas retransmettre: car 
Le destinataire rejette (ne délivre pas
ce la produirait un possible au dessus) des paquets dupliqués
duplicata
« stop and wait »

L'expéditeur envoie un paquet,
puis attend une réponse
du destinataire
40
rdt2.1: expéditeur, gestion des ACK/NAKs
abîmés
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Attend un isNAK(rcvpkt) )
Attend un
ACK ou un
appel 0 du
haut NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
Attend un Attend un
ACK ou un appel 1 du
rdt_rcv(rcvpkt) && NAK 1 haut
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
41
rdt2.1: destinataire, gestion des ACK/NAKs
corrompus
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Attend un Attend un
rdt_rcv(rcvpkt) && pkt 0 de pkt 1 de rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && dessous dessous not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)

udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
42
rdt2.1: discussion
Expéditeur: Destinataire:

Seq. # ajouter au pkt 
Doit vérifier si le paquet est

Deux numéros de séquence dupliqué
(0,1) suffisent. Pourquoi? ●
Etat indique si un pkt 0 ou 1
est attendu

Doit vérifier si le ACK/NAK
est corrompu

note: destinataire ne peut pas
savoir si sont dernière

Deux fois plus d'état
ACK/NAK a été reçu
●
Etat doit “se souvenir” si le
correctement par l'expéditeur
pkt courant a un seq #
valant 0 ou 1
43
rdt2.2: un protocole sans NAK

Même fonctionnalité que rdt2.1, mais n'utilise que des ACKs

A la place d'un NAK, le destinataire envoie un ACK pour le
dernier pkt reçu sans erreur
●
Le destinataire doit explicitement inclure un numéro de seq # du pkt
qui a été ACKé

Des ACK dupliqués arrivant à l'expéditeur provoque une même
action qu'un NAK: retransmission du paquet courant
44
rdt2.2: Expéditeur, Destinataire (partiel)
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Attend pour Attent un
isACK(rcvpkt,1) )
un appel 0 ACK
du haut 0 udt_send(sndpkt)
Partie du FSM
expéditeur rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) || Λ
has_seq1(rcvpkt)) Attend un Partie du FSM
●
pkt 0 du
udt_send(sndpkt) dessous destinataire

&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum) 45
udt_send(sndpkt)
rdt3.0: Cannaux avec erreur et pertes
Nouvelle hypothèse : Le canal Approche adoptée: l'expéditeur

de transmission peut aussi attend durant un temps
perdre des paquets (données “raisonnable” l'ACK attendu
ou ACKs)

Il le retransmet si aucun ACK n'est
reçu durant cette période
●
checksum, seq. #, ACKs,
retransmissions sera

Si le pkt (ou ACK) est juste retardé
nécessaire, mais pas suffisante (mais pas perdu):
●
La retransmission sera
dupliquée, mais l'utilisation de
numéro de sequence déjà permet
de remédier à ca
●
Le destinataire doit spécifier le
numéro de séquence d'un paquet
ayant été ACKé

Nécessite un chronomètre
46
rdt3.0 expéditeur
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
start_timer
rdt_rcv(rcvpkt) Λ
Λ Attend un Attend
un timeout
appel 0 du
haut ACK0 udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
Attend Attend un
timeout un appel 1 du
udt_send(sndpkt) ACK1 haut
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ
47
rdt3.0 en action
48
rdt3.0 en action
49
Performance de rdt3.0

rdt3.0 fonctionne, mais sa performance est minable

exemple: une liaison a 1 Gbps , 15 ms de délai de propagation,
paquet de 1KB:
T L (long en bits du pkt) 8kb/pkt

transm
= = = 8 microsec
R (taux de transmission, bps) 10**9 b/sec
 Uexp: utilisation – fraction du temps ou l'expéditeur est occupé à

envoyer
L/ R .008
U = = = 0.00027
sender 30.008
RTT +L / R microsec
onds
 1KB pkt chaque 30 msec -> 33kB/sec
de débit sur un lien a 1 Gbps
 Protocole réseau réduit l'utilisation des
ressources physiques! 50
Fonctionnement de rdt3.0
les 1er bit du paquet envoyé, t = 0

les derniers bit du paquet envoyé, t = L / R
les 1er bits du paquet arrivent

RTT
ACK arrive, envoie du prochain

paquet, t = RTT + L / R
L/ R .008
U = = = 0.00027
sender 30.008
RTT +L / R microsec
onds
Protocole pipeliné
Pipeline: l'expéditeur permet l'envoie multiple de paquets en
instance d'accusé de réception :
●
L'espace des numéro de séquence doit être augmenté
●
La mise en tampon au niveau expéditeur et du receveur

Deux formes génériques des protocoles pipelinés: go-Back-N,
répétition sélective
52
Pipeline: utilisation amélioré
premier bit du paquet

transmis, t = 0
dernier bit transmis, t = L / R
Premier bit du paquet arrive

RTT Dernier bit du paquet arrive, envoie de l' ACK
Dernier bit du 2nd paquet arrive, ACK envoyé
dernier bit du 3e paquet arrive, ACK envoyé
ACK arrive, envoie du
prochain paquet,
t = RTT + L / R
Améliore l'utilisation
par un facteur 3!
3*L/ R .024
U = = = 0.0008
sender 30.008
RTT +L / R microsecon
ds 53
Go-Back-N
Sender:

numéro de séquence sur K-bit dans l'entête du paquet

“fenêtre” jusqu'a N, paquets non acquités simultanés
 ACK(n): accuse reception de tous les paquets jusqu'au numéro n

(On parle alors d'“ACK cumulatif”)
 Peut recevoir des ACKs dupliqués (cf. destinataire)
 Minuterie (ou timer) pour chaque paquet envoyé
 timeout(n): retransmet le paquet n et ceux de plus grand numéro de
54
séquence # pkts dans la fenêtre
GBN: FSM étendu de l'expéditeur
rdt_send(data)
if (nextseqnum < base+N) {

sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
else
Λ refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Attente udt_send(sndpkt[base])
udt_send(sndpkt[base+1])
rdt_rcv(rcvpkt)
…
&& corrupt(rcvpkt)
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer 55
GBN: FSM étendu du destinataire
default
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Attente extract(rcvpkt,data)

sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
ACK-seulement: envoie toujours ACK pour des paquets

correctement reçu avec le plus haut # seq dans-ordre
●
peut génère des ACKs dupliqués
●
Ont besoin seulement de mémorise expectedseqnum

Paquet hors-séquence:
●
rejeter (ne pas mettre en tampon) -> pas de tampon utilisateur!
●
Re-ACK paquet avec le plus haut seq # en séquence
56
GBN en action
57
Répétition Sélective

Le destinataire accuse réception individuellement tous les
paquets recus correctement
●
Paquets dans le tampon, au besoin, au final pourra être délivré
en-séquence à la couche supérieure

L'expéditeur ré-envoie seulement les paquets avec un
ACK non reçu
●
expéditeur lance un timer pour chaque paquet non acquité

Fenêtre de l'expéditeur
●
N numéro de seq. consécutifs
●
Limite encore les numéro de seq. des paquets envoyés mais non
acquités
58
Répétition sélective: fenêtre de l'expéditeur et
du destinataire
59
Répetition sélective
data from above : pkt n dans [rcvbase, rcvbase+N-1]

Si il y a un numéro de seq.  envoyer ACK(n)
disponible dans la fenêtre send  Hors séquence: mise en
pkt tampon
timeout(n):  en-séquence: délivrer (aussi

renvoyer pkt n, relancer le délivrer les paquet du tampon
minuteur en-séquence), avancer la
fenêtre jusqu'au prochain
ACK(n) dans [sendbase,sendbase+N]: paquet non acquité

marquer pkt n comme reçu

si n est le paquet de plus petit
pkt n dans [rcvbase-N,rcvbase-1]
numéro, avancer la base de la  ACK(n)

fenêtre jusqu'au prochain otherwise:
numéro de paquet non-acquité  ignorer
60
Répétition sélective en action
61
Répétition sélective:
dilemme
Exemple:

seq #’s: 0, 1, 2, 3

Taille de la fenêtre=3

Le destinataire voit
aucune différence dans
deux scénarios!

Des données dupliquées
passent pour nouvelles
dans (a)
Q: Quel relation y a-t-il entre

seq # size et la taille de la
fenêtre?
62
Chapitre 3: Plan


3.2 Multiplexge and
●
démultiplexage
●
●
Controle de flux

connexion: UDP


Principe
de données fiable
●
de TCP

63
TCP: Vue générale RFCs: 793, 1122, 1323, 2018, 2581

point-à-point: 
Donnée en mode duplex:
●
Un expéditeur, un destinataire ●
Flux de données
bi-directionel dans la même

fiable, en séquence flux connexion
d'octet (byte stream): ●
MSS: maximum segment size
●
Pas de “message boundaries” 
orienté-connexion:

pipeliné: ●
Poignée de main (échange
●
Le contrôle de congestion et de msgs de contrôle) initalise
du flux fixe une taille de les données d'état
fenêtre expéditeur, destinataire
avant l'échange de données

Tampon d'envoi & réception
a p p lic a t io n a p p lic a t io n

Contrôle de flux:
w r it e s d a t a re a d s d a ta
socket socket
●
L'expéditeur ne va pas
door
TCP TCP
door inonder le destinataire
s e n d b u ffe r r e c e iv e b u f f e r
segm ent 64
Structure du segment TCP
32 bits
URG: donnée urgente compteur
(generalement inutilisé) source port # dest port #
par octet
Numéro de séq. de données
ACK: ACK #
(pas de segments!)
valide Numéro acquité
head not
PSH: pousser les len used U A P R S F Fenêtre de récept.
données maintenant # octets
Som. ctrl Urg data pnter accepeté par
(generallement inutilisé)
le
RST, SYN, FIN: Options (de longueur variable)
destinataire
gestion de la connexion
(etablissement, terminaison
commandes)
Donnée
application
somme de (longueur variable)
contrôle
Internet
(comme dans UDP)
65
Chapitre 3: Plan


3.2 Multiplexage and ●
demultiplexage ●

3.3 Transport sans
●
Controle de flux
connexion: UDP
●


de donnée fiable
●
Principe
●
de TCP

66
Transfert de données fiable de TCP

TCP crée un service transfert 
Les retransmissions sont
de données fiables (rdt) au déclanchés par:
dessus du service non fiable ●
timeout
d'IP ●
ACKs dupliqués

Les segments sont pipelinés 
On considère un expéditeur TCP

ACKs cumulatif simplifié:

TCP utilise une minuterie
●
ignore ACKs dupliqués
(timer) pour détecter les ●
ignore contrôle de flux et contrôle
pertes de congestion
67
Num. de seq. et ACKs TCP
Numéro de séquence:
Hote A Hote B
●
Fil de “numéro” d'octets
du premier octet dans les Appli envoit
Seq=4
données du segment ‘C’ 2, AC
K=79 , data
= ‘A’
ACKs: ACKs
●
Num. de seq. du prochain du
‘ B’ ‘B’ reçu
octet attendu 3, d ata =
K=4 renvoyé
●
ACK cumulatif (quitte tous q =79, AC
Se
octets de numéros de seq
inférieurs)
ACKs
Qu.: Comment le destinataire du ‘B’ reçu
envoyé
gère les segments
hors-séquence
●
Rep: TCP ne le spécifie
pas – c'est à la discrétion temps
du développeur Scénario simple
68
Evènement du côté expéditeur TCP:
Données reçues par l'app: timeout:

Créer un segment avec un N° 
Retransmettre le segment qui a
de seq causé le timeout

Le N° de seq est le numéro de 
Redémarrer la minuterie
séquence d'un fil d'octets du ACK reçus:
premier octet de donnée du
segment

S'il acquite des segments

Lancement de la minuterie précédement non acquité
(timer) si elle n'est pas déjà en
●
Mettre à jour ce que l'on sait
train de tourner (penser à la être acquité
minuterie pour le plus ancien ●
Démarrer le minuteur s'il reste
segment non acquité) des segments en suspens

intervalle d'expiration:
TimeOutInterval
69
TCP expéditeur(simplifié)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
●
switch(event)
event: data reçu de l'application de la couche supérieure
cree un segment TCP avec un numéro de séquence NextSeqNum Commentaire:
if (minuterie arretée) SendBase-1: dernier
demarer la minuterie
octet acquité
passer le segment à la couche IP
NextSeqNum = NextSeqNum + length(data) cumulativement
Exemple:
event: timeout de la minuterie SendBase-1 = 71;
retransmettre segment pas-encore-acquité avec y= 73, donc le dest.
le plus petit numéro de séquence veut 73+ ;
demarrer la minuterie y > SendBase, donc
cette nouvelle donnée
event: ACK reçu, avec le valeur du champs ACK de s'y satisfaisant
if (y > SendBase) {
est acquitée.
SendBase = y
if (il y a actuellement des segments pas-encore-acquités)
●
Demarrer la minuterie}
} /* fin de boucle forever */ 70
TCP: scénarios de retransmission
Hôte A Hôte B Hôte A Hôte B
Seq=9 Seq=9
2, 8 b 2, 8 b y te
y t es da s data
ta
Seq=92 timeout
Seq=
100,
20 by
tes d
timeout
at a
0
X =10
K 120
AC ACK=
perte
Seq=9 Seq=9
2, 8 b 2, 8 b
y te s d a Sendbase y te s d a
ta
ta = 100
Seq=92 timeout
SendBase
= 120 =12
0
K
=100 AC
AC K
SendBase
= 100 SendBase
= 120
Timeout prémature
temps
temps 71
scénario ACK perdu
TCP scénarios de retransmission (suite)
Hote A Hote B
timeout
Seq=1
00, 20
bytes
d ata
X
perte
SendBase
= 120
temps
scénario ACK accumulatif
72
TCP : émission d'un ACK [RFC 1122, RFC 2581]
Evènement chez destin.

Action TCP du dest.
Génération retardée de l'ACK:
Arrive d'un segment dans l'ordre avec attendre jusqu'a 500ms pour envoyer l'ACK.
un seq # attendu. Toutes les données Si aucun segment n'arrive durant ces 500ms
jusqu'à ce seq # ont été ACKée. alors envoyer l' ACK.
Envoyer immédiatemment d'un ACK cumulatif.
Arrivé d'un seqment dans l'ordre Accuse réception des deux segments arrivés
avec le N° de seq attendu. Un autre dans l'ordre (celui dont l'envoie de l'ACK est
segment a un ACK non encore envoyé. retardé + celui qui vient d'arriver).
Arrivé d'un segment dans Envoyer immédiatemment un

le désordre. D'un plus haut N° de seq ACK dupliqué indiquant le numéro de seq.
que celui attendu. Un écart est détecté. du prochain octet attendu
Arrivé d'un segment qui comble Envoyer immédiatemment

partiellement l'écart. un ACK, si le segment
augmente la valeur de base window
de l'expéditeur 73
Retransmission rapide

Hors-délai période souvent 
Si l'expéditeur reçoit 3 ACKs
relativement longue: pour la même donnée, cela
●
Un délai long avant le suppose que le segment
renvoie d'un paquet perdu après une donnée aquittée a

Segments perdu détectés par été perdue:
réception d'ACKs dupliqués. ●
retransmettre: réenvoyer un
●
L'expéditeur envoie souvent segment avant que le timeout
ne se produise.
beaucoup de segment
successivement.
●
Si un segment est perdu, il y
aura probablement
beaucoup d'ACKs dupliqués.
74
Algorithme de retransmission
rapide:
event: ACK recu, avec un champs ACK egal y

if (y > SendBase) {
SendBase = y
if (il y actuellement des segments pas ecore aquites)
start timer
}
else {
incrementer un compteur count d'ACK dupliques recu pour y
if (le compteur d'y = 3) {
reenvoyer le segment de numero de seq y
}
Un AC dupliqué pour des retransmission rapide

segments déjà acquitté
75
Aller-retour TCP: temps et Timeout
Q: Comment fixer la valeur Q: Comment estimer le RTT?

du timeout TCP ? 
SampleRTT: mesure le temps à

Plus grand que le RTT partir de la transmission d'un
●
mais le RTT varie... segment transmission jusqu'à la
réception d'un ACK

Trop court: timeout
prématuré
●
Ignorer la retransmission
●
Retransmissions inutiles

SampleRTT variera, on veut estimer
un RTT plus lisse

Trop long: lente réaction à ●
Moyenne pondérée sur plusieurs
une perte de paquet
mesures récentes, pas juste un
SampleRTT courant
76
Round Trip Time et Timeout de TCP
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
 Moyenne exponentielle pondérée

 L'influence des échantillons du passé
décroit exponentiellement rapidement
 valeur typique: α = 0.125
77
Aller retour TCP: temps et timeout
Calcul du timeout

EstimtedRTT plus une “marge de sécurite”
●
Grande variation de EstimatedRTT -> plus grande marge de
sécurité

D'abord estimer de combien SampleRTT dévie de EstimatedRTT:
DevRTT = (1-β)*DevRTT +
β*|SampleRTT-EstimatedRTT|
(valeur typique: β = 0.25)
Ensuite fixe l'intervalle de timeout:

TimeoutInterval = EstimatedRTT + 4*DevRTT
78
Chapitre 3: Plan


3.2 Multiplexage and
●
demultiplexage
●
●
Controle de flux

connexion: UDP


Principe
de donnée fiable
●
de TCP

79
Contrôle de flux de TCP
Control de flux
L'expéditeur ne va pas

Le coté destinateur de la surcharger le tampon
connexion TCP à un du destinataire
tampon mémoire de: en transmettant trop de
données et trop vite

Service d “adaptation de
la vitesse de trans.”: sert à
adapter la vitesse de
transmission à la rapidité
de lecture du processus.
 Le processus peut lire
lentement les données
dans la lecture des
données sur le tampon 80
Contrôle de flux de TCP: suite

Le destinataire avertit la
taille de l'espace libre en
includant la valeur de
RcvWindow dans les
segments
(Suppose que le destinataire TCP

L'expéditeur limite le
rejette les segments nombre de donnée non
hors-séquence) acquitée à RcvWindow
●
Guarantie que le tampon de

De l'espace libre dans le tampon réception ne déborde pas
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]
81
Chapitre 3: Plan


demultiplexage ●

3.3 transport sans
●
Controle de flux
connexion: UDP
●


de donnée fiable
●
Principe
●
de TCP

82
Gestion de la connexion TCP
Rappel: L'expéditeur TCP,

Poignée de main en trois
établit une “connexion” avant étapes:
l'échange de données
Etape 1: le client envoie un segment TCP

Initialisation de variables TCP: SYN au serveur
●
seq. # ●
spécifie le seq # initial du client
●
tanpons, info. de contrôle de ●
Ne contient pas de données
flux (e.g. RcvWindow)

Client: initiateur de connexion Etape 2: le serveur reçoit SYN, répond avec
un segment SYNACK
Socket clientSocket = new
Socket("hostname","port ●
Serveur alloué des tampons de
number"); mémoire

Serveur: contacté par le client ●
spécifie le seq. # initial du serveur
Socket connexionSocket = Etape 3: le client reçoit SYNACK, répond
welcomeSocket.accept(); avec un segment ACK segment, qui peut
contenir des données.
83
Gestion de la connexion TCP (suite)
Etape 3: le client reçoit FIN, répond

client server
avec un ACK.
●
Entre dans une phase “timed fermeture
FIN
wait” - répondra avec un ACK
pour des FINs reçus
ACK
fermeture
FIN
Etape 4: le serveur reçoit un ACK.
connexion fermée.
timed wait
ACK
Note: avec de petites modifications,
peut gérer des FINs simultanés. fermé
fermé
84
Gestion de la connexion TCP (suite)
Le cycle de vie
du seveur TCP
Le cycle de vie
du client TCP
85
Chapitre 3: Plan


demultiplexage ●

3.3 transport sans
●
Controle de flux
connexion: UDP
●


de donnée fiable
●
Principe
●
de TCP

86
Principe du contrôle de congestion
Congestion:

informellement: “trop de sources qui envoient trop de
données trop vite pour que le réseau puisse les traiter ”

différent du controle de flux!

manifestations:
●
Perte de paquets (débordement de tampon au niveau
des routeurs)
●
Délais longs (les queues s'allongent dans les tampons
des routeurs)
87
Causes/coûts de la congestion: scénario 1
Host A
λout
λin : original

deux expéditeur, data
deux destinataires
tampon ilimité

un routeur, des Host B partage sur le
lien de sortie
tampons infinis

Pas de
retransmission

De très long délai
lors d'une
congestion

Transmission
maximum faisable
88
Causes/coûts de congestion: scénario 2

Un routeur, des tampons finis

L'expéditeur retransmet les paquets perdus
Hote A λin : donnee λout

originelle
λ'in : donnees originelles,
plus les donnees
retransmises
Hote B tampon limité
partage sur le
lien de sortie
89
Causes/coûts de congestion: scénario 2

toujours: λ = λout
(meilleurs cas)
in

Retransmission “parfaite” seulement lorsqu'il y a des pertes: λ > λ
in out

retransmission de paquets retardés (mais pas perdus) rend plus grande λ
in
(que dans le cas parfait) pour la même λ
out
R/2
R/2
R/3
λout
λout
R/2
λin R/2
λin
a.
b.
“Coûts” de la congestion:
 Plus de travail retransmission
 des retransmissions non nécessaires: le lien transporte de 90
nombreuses copies des paquets.
Méthodes de contrôle de la congestion
Deux approches répandues sont:
Control de congestion de Contrôle de congestion

bout en bout: assisté par le réseau:

Pas de retour direct du réseau 
Les routeurs fournissent des

congestion gérée par les hôtes informations aux hôtes
observant des pertes, des ●
simple bit indiquant la
retards congestion (SNA, DECbit,

approche utilisée dans TCP TCP/IP ECN, ATM)
●
Taux explicite auquel
l'expéditeur doit envoyer
ses données

Approche utilisée dans ATM
91
Contrôle de congestion de TCP:
accroissement additive, décroissance multiplicative
 Approche: augmenter le taux de transmission (taille de
la fenêtre), sondant la bande passante utilisable, jusqu'à
ce qu'une perte de paquet se produise
 Augmentation additive: acroît CongWin d'1 MSS après
chaque RTT jusqu'à détecter une perte
 Reduction multiplicative: réduit la CongWin de moitier
après une perte
c o n g e s tio n
w in d o w
congestion window size
2 4 K b y te s
Comportement en
Dent de scie 1 6 K b y te s
8 K b y te s
temps
tim e
92
Contrôle de congestion TCP : détails

L'expéditeur limite la transmission:
Comment l'expéditeur perçoit
LastByteSent-LastByteAcked la congestion ?
≤ CongWin 
Une perte = timeout ou 3

Plus grossièrememt, ACKs dupliqués

Expéditeur TCP réduit
CongWin
rate = Bytes/sec son taux (CongWin)
RTT
après la détection d'une
perte

CongWin est dynamique, dépent de
Trois mécanismes:
la congestion perçuue du réseau
●
AIMD
●
Départ lent
●
Conservatif après un
timeout
93
Départ lent de TCP
Lorsque une connexion  Lorsque la connexion

commence, CongWin = 1 MSS commence,
●
Exemple: MSS = 500 octets & accroissement
RTT = 200 msec exponentiel du taux
●
Taux initial = 20 kbps
jusqu'à la détection

Bande passante disponible
d'une perte
peut être >> MSS/RTT
●
Il est nécessaire d'accéder
rapidement à un taux de
transmission respectable
94
Départ lent de TCP (suite)

Lorsque la connexion Hote A Hote B
commence, accroissement
exponentielle du taux
RTT
jusqu'à la détection d'une
perte: deux segm
ents
●
double CongWin à chaque
RTT
●
Réalise en incrémentant quatre seg
ments
CongWin pour chaque ACK
reçu

Resumé: taux initial est
faible mais augmente de
façon exponentielle temps
95
Raffinement
Q: A partir de quand la
phase exponentielle doit
être remplacée par une
phase linéaire?
A: Lorsque CongWin arrive à
la moitier de sa valeur
avant le timeout.
Implémentation:

Variable Threshold (seuil)

Lorsqu'une perte se produit,
Threshold est fixé à la moitier
de lavaleur de CongWin avant
la détection de la perte
96
Raffinement: détection des pertes

Après 3 ACKs dupliqués:
●
CongWin est coupé en deux
Philosophie:
●
La fenêtre augmente alors linéairement

Mais après un timeout:
 3 ACKs dupliqués
●
CongWin est fixé à 1 MSS;
●
Le fenêtre augmente alors
indiquent que le reseau
exponentiellement est capable de
●
Jusqu'au seuil Threshold, ensuite transmettre certains
grossit linéairement segments
 timeout indique une
congestion “plus
alarmante”
97
Résumé:
contrôle de congestion de TCP

Lorsque CongWin est en dessous de Threshold,
l'expéditeur est en phase de départ-lent, la fenêtre
augmente exponentiellement.

Lorsque CongWin est au dessus de Threshold,
l'expéditeur est en phase d'évitement de congestion
augmente linéairement.

Lorsqu'un triple ACK dupliqué se produit, Threshold est
fixé a CongWin/2 et CongWin est fixé à Threshold.

Lorsqu'un timeout se produit, Threshold est fixé à
CongWin/2 et CongWin est fixé à 1 MSS.
98
Chapitre 3: Plan


demultiplexage ●

3.3 transport sans
●
Controle de flux
connexion: UDP
●


de donnée fiable
●
Principe
●
de TCP

99
Taux de transmission TCP

Quel est le taux de transmission moyen de TCP en fonction de
la taille de la fenêtre et d'un RTT?
●
On ignore le “départ-lent”

Soit W la taille de la fenêtre lorsqu'une perte se produit (si le
réseau est stable cette valeur est toujours de même grandeur).

Lorsque la fenêtre vaut W, le taux de transmission est W/RTT

Juste après une perte, la taille de la fenêtre descend a W/2, et
le taux de transmission à W/2RTT.

Taux de transmission moyen est de: .75 W/RTT
100
Équité
 K connexions TCP partagent le même lien, chacune devraient avoir

1/K de ce lien
connexion TCP 1
 addition d'1 Unité
multiplication par 0.5
Débit de la connexion TCP2
R partage équitable du Routeur encombré

débit de capacité R
connexion TCP 2
Débit > R provoque une perte: divise la fenêtre par 2
 Faussée car par un navigateur

ouvrant plusieurs connexion
TCP pour une même page
R web
Débit de la connexion TCP1

Chapitre3 Transport Ver2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Chapitre3 Transport Ver2

Загружено:

Авторское право:

Доступные форматы

Cours Réseaux

les fait passer à la couche transport

Deux grands protocoles de

Démultiplexage sur le terminal dest.: Multiplexage sur le terminal exp.:

transport transport transport

reseau reseau reseau

liaison liaison liaison

physique physique physique

DatagramSocket serverSocket = new DatagramSocket(6428);

SP: 6428 SP: 6428

SP: 9157 SP: 5775

SP fournit “adresse de retour”

SP: 9157 SP: 9157

SP: 9157 SP: 9157

 Remarque: les additions sont faites modulo 2^16

(rdt= reliable data transfert)

(rdt= reliable data transfert)

(rdt= reliable data transfert)

rdt_send(): appel par le haut, (e.g., deliver_data(): appelé par

udt_send(): appellé par rdt, rdt_rcv(): appelle lorsqu'un

événement provoquant un changement d'état

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Que se passe-t-il si Gérer les duplicatas:

« stop and wait »

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Nouvelle hypothèse : Le canal Approche adoptée: l'expéditeur

T L (long en bits du pkt) 8kb/pkt

 Uexp: utilisation – fraction du temps ou l'expéditeur est occupé à

les 1er bit du paquet envoyé, t = 0

les 1er bits du paquet arrivent

ACK arrive, envoie du prochain

premier bit du paquet

Premier bit du paquet arrive

 ACK(n): accuse reception de tous les paquets jusqu'au numéro n

if (nextseqnum < base+N) {

expectedseqnum=1 Attente extract(rcvpkt,data)

ACK-seulement: envoie toujours ACK pour des paquets

numéro, avancer la base de la  ACK(n)

Q: Quel relation y a-t-il entre

Hôte A Hôte B Hôte A Hôte B

Evènement chez destin.

Arrivé d'un segment dans Envoyer immédiatemment un

Arrivé d'un segment qui comble Envoyer immédiatemment

event: ACK recu, avec un champs ACK egal y

Un AC dupliqué pour des retransmission rapide

Q: Comment fixer la valeur Q: Comment estimer le RTT?

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

 Moyenne exponentielle pondérée

(valeur typique: β = 0.25)

Ensuite fixe l'intervalle de timeout:

Rappel: L'expéditeur TCP,

Etape 3: le client reçoit FIN, répond

Hote A λin : donnee λout

Deux approches répandues sont:

Control de congestion de Contrôle de congestion

Lorsque une connexion  Lorsque la connexion

 K connexions TCP partagent le même lien, chacune devraient avoir

R partage équitable du Routeur encombré

Débit > R provoque une perte: divise la fenêtre par 2

EstimatedRTT = (1- α)EstimatedRTT + αSampleRTT