Chapter3-Protocoles de Transport

Chapitre 3
Protocoles de transport de
l‟Internet
Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 1

Chapter 3: Couche Transport
Nos objectifs:
 Comprendre les services  Etudier les protocoles de
implémentés par la couche couche transport :
transport:  UDP: transport sans connexion
 multiplexage/demultiplexage  TCP: transport orienté
 fiabilité du transfert de connexion
données  le contrôle de congestion TCP
 contrôle de flux
 contrôle de congestion

Couche transport vs. Couche réseau
 La couche réseau :
communication logique entre les Analogie avec commu postal:
hôtes 12 enfants envoient des
lettres à 12 autres enfants
 La couche transport:  processus = enfant
communication logique entre les  messages app = letters
processus dans l‟ enveloppe
 hôte = maison
 apporter des améliorations de
 protocole de transport =
fiabilité par rapport à celle de Alice et Bob
la couche réseau  protocole de couche réseau
= service postal

Multiplexage/demultiplexae
Demultiplexage au hôte récep: Multiplexage au hôte émett:
Colleter les données de
Délivrer les segments à la
plusieurs sockets et enveloppe
bonne socket
les données avec l‟en-tête
(utile pour le démultiplexage)
= socket = process
P3 P1
P1 P2 P4 application
application application
transport transport transport
network network network
link link link
physical physical physical
hôte 2 hôte 3
hôte 1
Comment le démultiplexage
 Hôte recevant les datagramme IP
 Chaque datagramme a une 32 bits
adresse IP source et une
port source port dest
adresse IP destination
 chaque datagramme
encapsule un segment de
Les autres champs de
l‟en-tête
couche transport
 Chaque segment a un numéro
de port source et un num de Les données de
port destination spécifiques à l‟application
l‟application
(message)
 hôte utilise les adresses IP et les
numéros de port pour diriger le
Format d‟un segment TCP/UDP
segment à la bonne socket

Démultiplexage sans connexion
DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P1
P1
P3
PS: 6428 PS: 6428

PD: 9157 PD: 5775
PS: 9157 PS: 5775

client PD: 6428 PD: 6428 Client
serveur
IP: A IP: C IP:B

Démultiplexage orienté connexion
 socket TCP identifiée par 4-  L‟hôte serveur peut supporter
tuple: simultanément plusieurs
 Adresse IP source sockets :
 num de port source  chaque socket est identifiée
 Adresse IP dest par ses 4-tuple
 num de port dest  Les serveurs Web ont des

 l‟hôte récepteur utilise sockets différents pour
toutes les 4 valeurs pour chaque connexion d‟un client
diriger le segment à la  HTTP non-persistant aura une
socket appropriée socket différente pour
chaque requête

Démultiplexage orienté connexion
P1 P4 P5 P6 P2 P1P3
PS: 5775
PD: 80
IP-S: B
IP-D:C
PS: 9157 PS: 9157

client PD: 80 PD: 80 Client
serveur
IP: A IP-S: A
IP: C IP-S: B IP:B
IP-D:C IP-D:C

Le protocole UDP
 Souvent utilisé pour des app
multimédias
32 bits
 tolère la perte
 mais c‟est un service La longueur totale port source port dest
rapide (en octet)du longueur checksum
 autres utilisations de UDP segment UDP
 DNS y compris
l‟en-tête
 SNMP
 fiabilité de transfert à
travers UDP: ajouter des Données de
fonctions de contrôle au Application
niveau de la couche application (message)
pour améliorer la fiabilité
 recouvrement spécifique
d‟erreurs au niveau Format d‟un segment UDP
applicatif

checksum UDP
But: detecter des “erreurs” (e.g., bits altérés) dans la transmission du
segment
Emetteur: Récepteur:
 traite le contenu du segment  Calcule le cheksum du segment
comme étant une séquence
reçu
d‟entiers de 16 bits
et vérifie si la valeur calculée du
checksum: le complément à un de


la somme de tous les mots de 16 checksum est égale à la valeur

bits du segment en éliminant tout mise dans le champ checksum:
dépacement de capacité  NON - détection d‟erreur
 met la valeur du checksum dans le
 OUI - pas d‟erreur
champs checksum du segment
UDP à envoyer

Exemple de checksum Internet
 Note
 En additionnant les mots de 16 bits, les retenues
sortantes du bit du poids fort doivent être ajoutées au
résultat final
 Exemple: addition de deux entiers 16-bits
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
Retenue
sortante 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
somme 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
TCP: vue générale
RFCs: 793, 1122, 1323, 2018, 2581
application application
Écrit données Lit données
Interface Interface
socket socket
Tampon Tampon de
d ‟envoi de réception
TCP de TCP
segment

structure d‟un segment TCP
32 bits
URG: données urgentes Compte le nombre
port source port dest
d‟octets
sequence number de données
ACK: séq de l‟ACK
pris en considération acknowledgement number (non du segment !)
head not
PSH: passer donnée à U A P R S F Fenêtre réception
len used Nombre d‟octets
la couche application checksum Pointeur donn.URG pouvant être
acceptés
RST, SYN, FIN: Options (longueur variable)
pour établissement
et fermeture
de connexion
données
Checksum application
Internet (longueur variable)
(comme pour UDP)

Numéro de séquence et d‟accusé de
réception TCP
Numéro de séquence: Hôte A Hôte B
 Le numéro dans le Utilisateur
flux de données du tappe
„C‟
premier octets de Aquitte
„C‟,
chaque segment envoie „C‟
Numéro ACKs:
 le num de seq du
Aquitte
prochain octet qu‟il „C‟,
envoie „C‟
attend de l‟autre
côté
 ACK cumulatif temps
Exemple de scénario Telnet

RTT et Timeout TCP
Q: Comment choisir la Q: Comment estimer RTT?

valeur de timeout?  SampleRTT: : mesure le temps entre
la transmission du segment et la
 Supérieur à RTT
réception de son ACK
 mais RTT varie
 ignore les retransmissions
 plus petit
 SampleRTT va varier selon le niveau
 des retransmissions
de congestion
inutiles
 Ne peut pas être une valeur
 beaucoup plus grand: fiable de RTT
ralentit la reaction face à  On considère une moyenne des
la perte des segments mesures et non le SampleRTT
courant

RTT et Timeout TCP
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 Une moyenne pondérée des différentes valeurs de

SampleRTT
 plus de poids aux échantillons récents qu‟aux échantillons plus
anciens
 valeur typique:  = 0.125

Exemple d‟estimation RTT :
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
250
RTT (milliseconds)
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
SampleRTT Estimated RTT

RTT et Timeout TCP
Configurtion du timeout
 Première estimation de combient SampleRTT dévie de
EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typiquement,  = 0.25)
TimeoutInterval = EstimatedRTT + 4*DevRTT

Transfer de données fiable TCP
 TCP crée un service de transfert fiable au dessus du service
IP non fiable
 Piplinage des segments
 acks cumulatifs
 TCP utlise un seul timer de retransmission
 Initialement considérons la version simplifié de TCP

 ignorer la dupplication des acks
 ignorer, le contrôle de flux et le contrôle de congestion

Evenements de l‟expéditeur TCP:
Données reçues de l‟app: timeout:
 créer un segment avec un  retransmettre le segment
numéro de séquence qui a causé le
 le num de séq est le numéro déclanchement du timeout
dans le flux de données du
 redémarrer le timer
premier octet de chaque
segment réception d‟un Ack:
 actionner le timer s‟il n‟est  s‟il accuse réception des
pas encore déclanché segments non acquittés
(pensez que le timer est  mettre à jour ce qu‟il n‟est
pour le plus ancien segment pas encore acquitté
non acquitté)  démarrer le timer s‟il y
 intervalle d‟expiration: des segments envoyés non
TimeOutInterval encores acquittés

Vérsion simplifiée de l‟expéditeur
TCP:
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
event: données reçues de la couche application
créer un segment TCP avec le num de séq= NextSeqNum
if (timer n’est pas encore déclanché)
start timer Commentaire:
pass segment to IP • SendBase-1: num
NextSeqNum = NextSeqNum + length(data) de séq du dernier
event: timer timeout octet reçu intact
retransmettre le segment non encore acquitté avec le plus et dans l‟ordre
petit numéro de séquence •Example:
start timer • SendBase-1 = 71;
event: ACK reçu, avec séq ACK= y
y= 73, récepteur
if (y > SendBase) {
SendBase = y demande 73+ ;
if (S’il reste des segments non encore acquittés) y > SendBase, donc
start timer de nouvelle données
} sont acquittées
} /* end of loop forever */

TCP: scénarios de retransmission
Hôte A Hôte B Hôte A Hôte B
Seq=92 timeout
timeout
X
lost
Sendbase
= 100
Seq=92 timeout
SendBase
= 120
SendBase
= 100 SendBase
= 120 déclanchement du Timeout
temps temps
Perte d‟un accusé
TCP: scénarios de retransmission
Hôte A Hôte B
timeout
X
lost
SendBase
= 120
temps
Accusé de réception cumulatif

Génération des ACK TCP [RFC 1122, RFC 2581]
Evénement Réponse du destinataire TCP
Arrivée d‟un segment intact et dans Génération de l‟accusé de réception

l‟ordre, porteur du num de séq attendu. retardé pendant 500 ms, en attente d‟un
Toutes les données jusqu‟à ce num de séq autre segment
sont déjà acquitté
Arrivée d‟un segment intact et dans Envoi immédiat d‟un ACK cumulatif simple,
l‟ordre, doté d‟un num de séq attendu. Un accusant réception des deux segments
segment précédent est en attente de (dans l‟ordre)
l‟émission de son ACK
Arrivée d‟un segment hors séq doté d‟un Envoi immédiat d‟un ACK dupliqué
num de Seq supérieur au num attendu. indiquant le num de séq du prochain octet
(Lacune détectée) attendu (limite inf lacune)
Arrivée d‟un segment remplissant Envoi immédiat d‟un ACK, sous réserve que
complétement ou partiellement la lacune le segment coïncide avec la limite inf de la
dans les données reçues lacune

Retransmission rapide
 La periode du Time-out souvent
est relativement longue :  Si l‟émetteur reçoit 3 ACKs
 Délai long avant la du même segment, il suppose
retransmission d‟un paquet
que ce segment est perdu:
perdu
 Retransmission rapide:
 Détection de perte de segment
avec les ACKs duppliqués. retransmet le segment
 Emétteur envoie souvent un avant l‟expiration du Time-

grand nombre de segment l‟un out
derrière l‟autre
 La perte d‟un segment est
susceptible de générer un
grand nombre d‟accusé de
réception en chaîne.

Algorithme de retransmission rapide
event: ACK received, with ACK field value of y

if (y > SendBase) {
SendBase = y
if (des segments ne sont pas encore acquittés)
start timer
}
else {
incrémenter le compteur des ACKs reçus pour y
if (compteur des ACKs reçus pour y = 3) {
retransmettre le segment avec le num de séq = y
}
Un ACK duppliqué Retransmission rapide

pour un segment
Déjà acquitté
Contrôle de flux TCP
 Le côte récepteur a un buffer Contrôle de flux
de réception: L‟emetteur ne doit pas
saturer le buffer du
récepteur en
transmettant avec un
rythme trop soutenu
 Eviter la saturation par un

système d‟équilibrage qui
ajuste le rytme d‟envoi à la
vitesse de lecture de
 Le processus applicatif l‟application destinataire
peut prendre du temps
(occupée par d‟autres
activités) pour lire le
contenu du buffer

Contrôle de flux TCP :
comment ça marche
(On suppose que le récepteur TCP supprime les segments hors séquence)
 RcvWindows : Espace mémoire disponible (spare room) en buffer
 RcvBuffer : la taille du buffer de récéption allouée pour la connexion
 LastByteRead : numéro du dernier octet dans le flux de données
retiré du buffer par le processus applicatif
 LastByteRcvd : numéro du dernier octet dans le flux de données
reçus et placé dans le buffer
RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

Contrôle de flux TCP :
comment ça marche
 Récepteur informe l‟émetteur de l‟espace disponible dans son

buffer en insérant RcvWindow dans tous les segments TCP.
 L‟emetteur limite les segments non acquittés à l‟espace
RcvWindow
 Si RcvWindow passe à 0, l’émetteur continue à
émettre des segments TCP contenant un seul octet de
données obligeant le récepteur à envoyer des ACKs
porteurs des nouvelles réactualisation de RcvWindow
(éviter un deadlock)

Gestion de la connexion TCP
Initialisation: Echange de
Trois états d‟échange:
segments TCP de connexion
entre un client et un serveur Etape 1: l‟hôte client envoie un
 Initialisation de variables TCP: segment TCP SYN au serveur
 Spécifie un num de séq initial
 Num de séq
 Pas de données
 buffers, info contrôle de flux
Etape 2: l‟hôte serveur reçoit
(e.g. RcvWindow)
SYN et répond par un
 client: intitiateur de connexion segment SYN+ACK
Socket clientSocket = new
 Serveur alloue les buffers
Socket("hostname","port number");
 Spécifie un num de séq initial
 serveur: contacté par le client serveur
Socket connectionSocket = Etape 3: le client reçoit SYN+ACK
welcomeSocket.accept(); et répond par un segment ACK
qui peut contenir des données

Fermeture de connexion:
client ferme socket:
clientSocket.close(); client serveur
Etape 1: Le système terminal client close

envoie un segmet de contrôle TCP
FIN au serveur
Etape 2: Le serveur reçoit un FIN,
répond avec un segment ACK. close
Ferme la connexion et envoie un
segment FIN
Temps d‟attente
Etape 3: client reçoit FIN, répond
avec un ACK.
 Met un “temps d‟attente” –
pour recevoir les segments de
données en cours de transfert
Etape 4: serveur, reçoit ACK et
ferme la connexion Fermeture

 Représentation d‟une connexion TCP par un automate à états fini :
« schéma complet» C0NNECT/SYN
FERMÉE
CLOSE/-
LISTEN/- CLOSE/-
SYN/SYN+ACK
ÉCOUTE
SYN
SYN émis
reçu
Transfert de données
ACK/- SYN+ACK/ACK
ÉTABLIE
CLOSE/FIN FIN/ACK
FIN/ACK ATTENTE
FIN FERMETURE
ATTENTE 1 EN COURS FERMETURE
CLOSE/FIN
ACK/- ACK/-
FIN+ACK/ACK
Dernier
FIN ATTENTE ACK
ATTENTE 2 TEMPORISÉE
FIN/ACK
ACK/-
FERMÉE

Principe du contrôle de congestion
Congestion:
 Informellement :”plusieurs sources envoient un grand volume de
données sur un court intervalle de temps au réseau.
 Différent du contrôle de flux !
 Les conséquences:
 Perte de paquets (saturation des buffers des routeurs “buffer

overflow”)
 Délai de mise en file d‟attente très long

Causes et effets de congestion: sénario 1
Hôte A lout
 Deux émetteurs, lin : données
deux récepteurs
originales
 Un routeur, buffer de Hôte B Tampons de liaison de

taille infinie sortie de nombre illimité
 Pas de retransmission
 Un long délai quand

c‟est congestionné
 Exploitation de la
liaison au maximum
de sa capacité eq.
Longues files
d‟attentes au
niveau du routeur
Causes et effets de congestion : scenario 2
 Un seul routeur, buffers limités

 L‟émetteur retransmet les paquets perdus
Hôte A lin : données originales lout
l'in : données originales,

plus données retransmises
Hôte B Tampons de liaison de sortie

partagés de nombre limité

 Dans le cas idéal: lin = lout (a)
 retransmission uniquement dans le cas de perte : l‟in > lout (b)
 retransmission des paquets retardé (non perdus) met l‟in encore plus
grand que lout (c)
R/2 R/2 R/2
R/3
lout
lout
lout
R/4
R/2 R/2 R/2

lin lin lin
a. b. c.
“coût” de congestion:
 Plus de travail (retrasmission) au niveau de l‟expéditeur et exploitation
inutile du débit de liaison des routeur
 Retramsmission inutile: la liaison supporte de multiples copies des paquets
 Quatre émetteurs Q: Que ce passe –t-il si lin

 Plusieurs chemins possibles et l‟in croîtent?
 timeout/retransmission
Hôte A lout Serveur D

lin : données originales
l'in : données originale, plus
données retransmisses
Tampons de liaison de sortie
partagés de nombre limité
Hôte B
R4 R1
R2 Serveur C
R3

Hôte A lout
Hôte B
Autre “coût” de congestion:

 Lorsqu‟un paquet est perdu sur son parcours, la capacité de
transmission dépensée par chacun des routeurs en amont
pour le faire progresser (jusqu‟au routeur saturé) s‟en trouve
perdue
contrôle de congestionTCP
Comment l‟émetteur détecte
la congestoin?
Événement de perte =
Contrôle de bout en bout (pas


expiration du timeout ou
d‟assistance du réseau) l‟arrivé de 3 acks
 L‟émetteur limite sa transmission: duppliqués
LastByteSent-LastByteAcked =  L‟émetteur réduit la
Min{CongWin,RcvWindows}  CongWin fenêtre de congestion
 Rééllement, (CongWin) après
l‟événement de perte
CongWin Trois mécanismes:
Vitesse d‟envoi = Bytes/sec
RTT  Accroissement additif et
décroissance multilicative
 CongWin est dynamique et fonction (AIMD)
du niveau de congestion du réseau  Départ lent
 Réactions aux
temporisations

AIMD TCP
décroissance multiplicative: Accroissement additif:
réduire CongWin à sa moitié si augmenter la valeur de
l‟événement de perte apparaît CongWin de 1 MSS après
chaque RTT en absence de
Fenêtre de phénomène de perte
congestion
24 Kbytes
16 Kbytes
8 Kbytes
temps

Départ lent TCP
Quand la connexion démarre, le

Quand la connexion démarre,

taux d‟envoi croît de façon


CongWin = 1 MSS
expoentielle jusqu‟à l‟apparition
Exemple: MSS = 500 bytes &

d‟un événement de perte
RTT = 200 msec
 doubler CongWin chaque RTT
 taux d‟envoi initiale = 20
kbps  conclusion: le taux d‟envoi initial
 La bande passante disponible est lent mais augmente
peut être >> MSS/RTT rapidement en exponentiel
 C‟est souhaitable de
remettre rapidement le taux
d‟envoi aux taux de la bande
passante disponible

Départ lent TCP
Hôte A Hôte B
RTT
time

Réaction aux temporisations
 Après 3 ACKs duppliqués: Philosophie:
 CongWin est divisée à sa
moitiée • 3 ACKs dup indiquent
 La fenêtre croît linéairement que le réseau est capable
 Mais après un timeout : de de délivrer quelques
 CongWin est mise à 1 MSS;
segments
 Puis la fenêtre de congestion
• timeout avant 3 ACKs
croît de façon exponentielle dup est “plus critique”
jusqu‟à un seuil puis elle
progresse linéairement
 La valeur seuil de la fenêtre :
 Initilialiée à valeur élevée (65 Ko)
 S‟il y a un timeout elle passe à la
moitié de CongWin

Réaction aux temporisations
Q: Quand est ce que
l‟accroissement
exponentiel passe au
linéaire?
A: Qaund CongWin
prend le 1/2 de sa
valeur avant le
timeout.
Implementation:
 Variable seuil (Threshold)
 À l‟événement de perte, le seuil est
mis à 1/2 du CongWin juste avant
l‟apparition de l‟événement de perte

contrôle de congestionTCP : synthèse
 Tant que CongWin est inférieure à la valeur du seuil, l‟expéditeur
est en phase de départ lent et la fenêtre connaît une croissance
exponentielle.
 Une fois la valeur de seuil dépassée, l‟expéditeur entre dans la

phase d‟évitement de la congestion durant laquelle la fenêtre
s‟accroît de manière linéaire.
 Lorsqu‟il y a trois ACKs identiques, la valeur du seuil est réglée à la

moitié de la taille de CongWin en cours et cette dernière est
portée à la valeur du seuil
 Lors de l‟expiration du timeout, la valeur du seuil est reglée à la

moitié de la taille de CongWin en cours et cette dernière est portée
à 1 MSS

Contrôle de congestion TCP de
l‟expéditeur
Evénement Etat Action TCP de l’expéditeur Commentaires
Réception d’un Départ Lent CongWin = CongWin + MSS, Doubler la valeur de CongWin à
ACK pour un (DL) If (CongWin > Threshold) chaque RTT
segment non set state to “Evitement de
acquitté Congestion ”
Réception d’un Evitement de CongWin = CongWin+MSS * Accroissement Additif de

ACK pour un Congestion (MSS/CongWin) CongWin par 1 MSS à chaque
segment non (EC) RTT
acquitté
Détection de DL ou EC Threshold = CongWin/2, Recouvrement rapide, par

perte après 3 CongWin = Threshold, implementation de la
ACK duplliqués Set state to “Evitement de décroissance multiplicative.
Congestion ” CongWin ne se met pas à 1
MSS.
Timeout DL ou EC Threshold = CongWin/2, Passe au Départ Lent

CongWin = 1 MSS,
Set state to “Départ Lent ”
ACK duppliqué DL ou EC Incrémentation du compteur des ACK CongWin et le seuil ne changent

dup du segment déja acquitté pas

DébitTCP
 Quel est le débit moyen TCP en fonction de la taille de fenêtre
et RTT?
 On Ignore le départ lent
 Soit W la taille de la fenêtre quand il y a perte.

 Quand la fenêtre a la taille W, le débit est W/RTT
 Juste après la perte, la fenêtre passe à W/2 et le débit passe
à W/2RTT.
Débit moyen0.75W
RTT

Equité TCP
Objectif de l‟équité: Si K sessions TCP partage la même liaison

( responsable d‟un goulet d‟étranglement) de débit R, alors
chaqu‟une doit avoir un débit moyen de R/K
Connexion TCP 1
Routeur encombré
de capacité R
Connexion TCP 2

Comment est implémenté l‟equité
TCP?
Deux sessions compétitives:
 Acroissement additif ajoute 1 MSS à la fenêtre et le débit croît avec
 Décroissance multiplicatif décroit le débit proportionellement
R Partage équitable du débit
perte: fenêtre CongWin/2

Evitement de congestion: Accroissement additif
perte: fenêtre CongWin/2
Evitement de congestion: Accroissement
additif
Débit Connection 1 R

Chapter3-Protocoles de Transport

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Chapter3-Protocoles de Transport

Enviado por

Direitos autorais:

Formatos disponíveis

Chapitre 3

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 1

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 2

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 3

transport transport transport

network network network

link link link

physical physical physical

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 5

DatagramSocket serverSocket = new DatagramSocket(6428);

PS: 6428 PS: 6428

PS: 9157 PS: 5775

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 6

 num de port dest  Les serveurs Web ont des

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 7

PS: 9157 PS: 9157

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 8

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 9

la somme de tous les mots de 16 checksum est égale à la valeur

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 10

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 12

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 13

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 14

Q: Comment choisir la Q: Comment estimer RTT?

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 15

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

 Une moyenne pondérée des différentes valeurs de

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 16

SampleRTT Estimated RTT

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 17

TimeoutInterval = EstimatedRTT + 4*DevRTT

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 18

 Piplinage des segments

 TCP utlise un seul timer de retransmission

 Initialement considérons la version simplifié de TCP

 ignorer, le contrôle de flux et le contrôle de congestion

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 19

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 20

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 21

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 23

Evénement Réponse du destinataire TCP

Arrivée d‟un segment intact et dans Génération de l‟accusé de réception

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 24

 Emétteur envoie souvent un avant l‟expiration du Time-

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 25

event: ACK received, with ACK field value of y

Un ACK duppliqué Retransmission rapide

 Eviter la saturation par un

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 27

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 28

 Récepteur informe l‟émetteur de l‟espace disponible dans son

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 29

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 30

Etape 1: Le système terminal client close

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 31

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 32

 Différent du contrôle de flux !

 Perte de paquets (saturation des buffers des routeurs “buffer

 Délai de mise en file d‟attente très long

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 33

 Un routeur, buffer de Hôte B Tampons de liaison de

 Un long délai quand

 Un seul routeur, buffers limités

Hôte A lin : données originales lout

EstimatedRTT = (1- )EstimatedRTT + SampleRTT