Couche Transport

Faculté des sciences de Monastir LFI 3
Département des sciences informatiques 2017 - 2018
Couche Transport
TCP/UDP
LFI 3 1 Couche Transport

Plan du cours
1. Services de la couche 6. Contrôle de congestion

transport – Principe
2. Multiplexage et – Contrôle de congestion de TCP
démultiplexage
3. Transport sans connexion:
UDP
4. Principe du transfert de
données fiable
5. Transport orienté connexion:
TCP
– Structure des segments
– Transfert de données fiable
– Contrle de flux
– Gestion de la connexion
LFI 3 Couche Transport 2

Ouvrages de références
• Analyse Structurée des Réseaux, J. Kurose & K.
Ross, Pearson Education, 2002
• Réseaux, A. Tanenbaum, D. Wetherall,
Nouveaux Horizons, 5e édition, 2014

Objectifs du cours
Nos objectifs:
• Comprendre les principes derrière les services de la
couche transport:
– Multiplexage/démultiplexage
– Transfert de donnée fiable
– Contrôle de flux
– Contrôle de congestion
• Apprendreles protocoles de la couche transport
d'internet:
– UDP: transport sans connexion
– TCP: transport orienté connexion
– Contrôle de congestion de TCP

Le modèle OSI
Problématique ?
 Réseau: Service de remise de paquets de machine à
machine
 Comment faire passer ce service à un canal de
communication de processus à processus ?

Services et protocoles transport
Le rôle de la couche transport peut être défini assez formellement
sous forme des quatre propriétés suivantes :
application
1. Transport de bout en bout transport
réseau
liaison réseau
Le service de transport permet la physique
réseau
liaison
physique
communication de deux utilisateurs liaison
physique
situés dans différents systèmes réseau
liaison
o émetteur: divise le message en physique réseau
liaison
segments, les passe à la couche physique
réseau
o récepteur: reforme le message à réseau
liaison
partir des segments obtenus de la physique
couche réseau application

transport
réseau
liaison
fournit une communication logique entre physique
les processus applicatifs exécutés sur des

sites différents

Services et protocoles transport
2. Sélection d'une qualité de service
Le protocole de transport doit optimiser les ressources réseaux disponibles
pour atteindre la qualité de service souhaitée et ceci au moindre coût.
La notion de qualité de service est définie par la valeur de certains paramètres:
• délai d’établissement d'une connexion de transport
• probabilité d'échec de l'établissement d'une connexion
• débit des informations sur une connexion de transport
• taux d'erreur résiduel…
3. Transparence
Les informations sont échangées sur une connexion de transport
indépendamment de leur format, codage ou signification.
4. Adressage
Réaliser une correspondance entre l'adresse de transport d'un utilisateur
donné et l'adresse de réseau correspondante pour pouvoir initialiser la
communication.

Transport vs. réseau
 Couche réseau: analogie:
communication logique 5 enfants envoient des lettres à 5
entre sites autres enfants
 Couche transport : • processus = enfants
communication logique • messages appli= lettres dans les
enveloppes
entre processus
• sites = maisons
– Construit sur les services de
• protocole transport= Ann et
la couche réseau
Bill
– Enrichit le service de la
• Protocole réseau = le service
couche réseau
postal

Protocoles Transport Internet
 Mode connecté : TCP (Transport Control Protocol)
o Phase de connexion / de transfert des données / déconnexion
o Contrôle de flux
o Contrôle des erreurs + acquittements + retransmission
o Garantie du séquencement
o Segmentation des messages
o Usage : Applications critiques
 Mode non connecté : UDP (User Datagram Protocol)

o Overhead réduit par rapport à TCP (8 octets / 20 octets)
o Envoi direct des informations
o Support du multi-points
o Pas de garantie de séquencement
o Contrôle des erreurs
o Usage : Applications multimédias

Protocoles Transport Internet
• Fiable, délivrance dans
application
l’ordre (TCP) transport
réseau
liaison
– Contrôle de congestion physique
réseau
liaison
réseau physique
– Contrôle de flux liaison
physique
– Connexion réseau
liaison
• Non fiable, dans le désordre: physique réseau

liaison
physique
UDP
– extension du protocole “best- réseau
liaison
effort” IP physique
application
• Services non disponibles: transport
réseau
– garantie des délais liaison
physique
– garantie largeur de bande

Plan du cours

démultiplexage
UDP
données fiable
TCP

Multiplexage/démultiplexage
Multiplexage
Demultiplexage sur le site rcpt : sur le site emetteur:
Assembler les données de
livre les segments reçus
plusieurs sockets, ajouter
à la bonne socket
un entête (utilisé ensuite
pour le demultiplexage),
= socket = process
P3 P1
P1 P2 P4 application
application application
transport transport transport
réseau réseau réseau
liaison liaison liaison
physique physique physique
site 2 site 3
site 1

Principe du démultiplexage
• Le site reçoit des datagrammes

32 bits
– chaque datagramme a l’adresse IP
de l’émetteur et du destinataire source port # dest port #
– chaque datagramme (couche réseau)
contient un segment (couche Autres champs d’entête
transport)
– chaque segment a le numéro de port
de l’émetteur et du destinataire
(les numéros de port sont Données application
spécifiques à chaque applications)
(message)
• Les sites utilisent les adresses IP et les
numéros de port pour diriger les
segments vers la socket appropriée
Format segmentTCP/UDP

Démultiplexage sans connexion
• Quand un site reçoit un
• Crée des sockets avec des segment UDP:
numéros de port: – contrôle le numéro de port du
DatagramSocket mySocket1 = new dest dans le segment
DatagramSocket(99111); – Dirige le segment UDP vers la
• Socket UDP identifiée par un socket attachée à ce numéro de
port
couple:
• Les datagrammes IP avec
(adresse IP dest, numéro port dest)
des adresses IP et/ou des
numéros de port d’émetteurs
différents sont dirigés vers la
même socket

Mode sans connexion
DatagramSocket serverSocket = new DatagramSocket(6428);
P3 P1
P1
P2
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
PS fournit “l’adresse de retour”

Démultiplexage orienté connexion
• Socket TCP identifiée par • Un site serveur peut avoir
un 4-uplet: plusieurs sockets TCP
– Adresse IP source simultanément:
– #port source – Chaque socket est identifiée
– Adresse IP destination par son propre 4-uplet
– #port destination • Les serveurs WEB ont des
• Le site récepteur utilise tous sockets différentes pour
ces champs pour diriger le chaque client connecté
segment vers la socket
appropriée

Démultiplexage orienté connexion
P3 P2 P4 P1
P1
PS: 80 PS: 80
PD: 9157 PD: 5775
PS: 9157 PS: 5775

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

Plan du cours

démultiplexage
UDP
données fiable
TCP

UDP: User Data Protocol [RFC 768]
• Protocole de transport simple,
sans valeur ajoutée pourquoi UDP?
• Service “best effort”, les • Pas d’établissement de
segments UDP peuvent être: connexion (qui ajoute des
– Perdus délais)
– Livrés dans le désordre aux • Simple: sans état connexion à la
applications source et au receveur
• Sans connexion: • Entête de segment petit
– Pas de “poignée de main” • Pas de contrôle de congestion:
entre émetteur et récepteur UDP peut circuler aussi vite que
– Chaque segment UDP est possible
traité indépendamment des
autres

Entête UDP
• Utilisé pour les flux d’applications 32 bits
multimédia
port source # port dest #
– Tolérantes aux pertes
longueur Somme ctrl
– Sensibles à la vitesse
• Autres usages
– DNS
• Transfert fiable sur UDP: la Données application
fiabilité est ajoutée par la couche (message)
applicative
– Correction d’erreur spécifique à
l’application
Format de segment UDP

Somme de contrôle UDP
But: détecter les “erreurs” (ex: bits inversés) dans le segment
transmis
Emetteur Récepteur:
• Traite le segment comme une • Calcule la somme de contrôle du
séquence d’entiers 16-bit segment reçu
• Somme de contrôle: addition • Contrôle si la somme calculée
du contenu du segment correspond au champ ad hoc du
• L’émetteur met la somme de segment reçu:
contrôle dans le champ ad hoc – NON - erreur détectée
du segment UDP – OUI – pas d’erreur détectée
Mais peut être présente ….

Somme de contrôle UDP
• Le champ checksum est • Calcule le checksum du
initialement mis à 0 segment reçu
• La suite à protéger est • Vérifie si le checksum
considérée comme une calculé est 11 11...
suite de mots de 16 bits – NON - erreur détectée. Le
• Calcul du Checksum segment est abandonné
– OUI - pas d’erreur détectée
• Addition des mots de 16
bits (modulo 65 535) puis • Cas particulier: Le checksum
dans le segment reçu est à 0
• Complément à 1 (inverse bit = il n’a pas été calculé
à bit) du résultat de
l’addition
• Insertion du checksum dans
l’entête

Calcul de la somme de contrôle
Au niveau de l’émetteur Au niveau du destinateur
0110011001100110 0110011001100110
+ 0101010101010101 +0101010101010101
+ 0000111100001111 +0000111100001111
= 1100101011001010 =1100101011001010
0011010100110101 +0011010100110101
(complément à 1)
=1111111111111111
(ok)
=1111111101111111
(Erreur)

Fragmentation
• En théorie: les segments UDP peuvent être
fragmentés par IP
• En pratique: la plupart des applications
utilisant UDP limitent leurs segments à 512
octets
– Pas de fragmentation
– Pas de risque de message incomplet

Plan du cours

démultiplexage
UDP
4. Principe du transfert fiable
de données
TCP

Principes du transfert fiable
• important dans les couches applications, transport, liaison
• un des sujets importants pour les réseaux
• Les caractéristiques du canal non fiable déterminent la

complexité du protocole de transfert fiable

Principe du transfert fiable des données
• Si le canal peut inverser les bits: somme de contrôle pour

détecter les erreurs
• Correction des erreurs:
– Accusé de réception (ACKs): le receveur dit
explicitement que le paquet reçu est OK
– Accusé de réception négatif (NAKs): le receveur dit
explicitement qu’il y a une erreur dans le paquet reçu
– L’émetteur retransmet le paquet si nécessaire-

Et si les ACK/NACK sont corrompus?
• L’émetteur n’a plus de retour du Traiter les dupliquas:
récepteur • L’émetteur ajoute un numéro de
• S’il retransmet: duplication séquence à chaque paquet
possible • L’émetteur retransmet le paquet
courant si ACK/NAK corrompu
Que faire? • Le récepteur ignore (ne livre
pas) les paquets reçus en double
• L’émetteur ACK/NAK les
ACK/NAK du récepteur? Et si ces
ACK/NAK sont perdus?
• Retransmettre, même si le paquet stop & wait
a été reçu sans erreur? L’émetteur envoi un paquet
et attend la réponse du
récepteur

Gestion des pertes
• Timeout  l’émetteur attend un temps “raisonnable”
l’ACK/NACK
• Retransmission si l’ACK n’est pas reçu à temps
• Si paquet (ou ACK) simplement retardé (et pas perdu):
– La retransmission créera un dupliqua, l’usage du
numéro de séquence évite la livraison multiple
– Le receveur doit indiquer le numéro de séquence du
paquet pour lequel il envoie ACK
• Nécessite l’évaluation du temps

Stop-and-wait
émetteur receveur
Premier bit du paquet transmis
t=0, t = L / R
premier bit du paquet

arrivé
RTT Dernier bit du paquet arrivé,
envoie de ACK
ACK arrive, envoie du

paquet suivant, t = RTT + L
/R
U L/R .008
émetteur= = 30.008 = 0.00027
RTT + L / R microsec
onds

Protocoles en pipeline (avec anticipation)
Pipelining: l’émetteur envoie “avec anticipation” plusieurs
paquets, çà acquitter par le récepteur
– La plage des numéros de séquence doit être étendue
– Tampons chez l’émetteur et/ou le récepteur
• Deux types de protocoles en pipeline: go-Back-N, selective

repeat
Envoie en pipeline des segments
expéditeur expéditeur
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

Go-Back-N (fenêtre glissante)
Emetteur
• “fenêtre” jusqu’a N paquets consécutifs non acquittés,
 ACK(n): ACKs acquiite tous les paquets jusqu’à n “ACK

cumulatif”
 timeout(n): retransmet le paquet n et tous les paquets envoyés
ayant un numéro de séquence supérieur à n

Go-Back-N en action

Répétition sélective
• Le destinataire accuse réception individuellement tous
les paquets reçus 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
– Numéro de seq. consécutifs
– Limite encore les numéro de seq. des paquets envoyés
mais non acquités

Répétition sélective: fenêtre chez l’émetteur
et le récepteur

Répétition sélective en action

Répétition sélective en action
• Exemple:
• seq #’s: 0, 1, 2, 3
• Taille de la fenêtre=3
• Le destinataire ne voit
aucune différence entre
les 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?

Plan du cours

démultiplexage
UDP
données fiable
TCP

TCP: Résumé RFCs: 793, 1122, 1323, 2018, 2581
• Point à point: • Bi-directionnel:

– Un émetteur, un receveur – Flux bi-directionnel dans la même
• Transfert fiable des données connexion
– Contrôle de perte – MSS: (maximum segment size)
– Contrôle de flux taille maximum d’un segment
– Contrôle de congestion: pour les données applicatives
interaction hôte-réseau réactive et • Orienté connexion:
agressive – Poignée de main (échange de
• En pipeline: message de contrôle), initialise
– Largeur de la fenêtre d’émission états émetteur et récepteur avant
l’échange des données
affectée par les contrôles de flux et
de congestion • Orienté flux d’octets:
• Tampons: émetteur et récepteur – application écrit des octets
application application
– TCP émet des segments
Données à envoyer Données à lire – application lit des octets
socket socket
TCP
tampon émetteur
TCP
tampon récepteur
• Récepteur le plus simple possible
segment  complexité chez l’émetteur
– interopérabilité maximum
recherchée

TCP structure d’un segment
32 bits
URG: donnée urgente Compté en octes
(non utilisé en général)
N° port source N° port dest
de données
N° de séquence (Pas en segment)
ACK: n°ACK valide
N°séquence d’acquittement
PSH: délivrance taillenon
en tête
utilisé
UA P R S F Fenêtre de rcpt
immédiate
Somme ctrl Ptr donnée urgente # octets que le
(non utilisé en général)
rcvr peut
RST, SYN, FIN: Options (longueur variable) accepter
Établissement de
la connexion
(commandes) Données de l’application
Somme de contrôle (longueur <MSS)

Internet
(comme dans UDP)

Champs de l’entête TCP
• source port : identifie le • Fiabilité
processus source sur la machine – sequence n° : N° du 1er octet de
source données du segment (sauf si SYN=1 :
ISN)
• destination port : identifie le – acknowledgment n° : acquitte tous les
processus destinataire sur la octets de données de N° strictement
machine destinataire inférieur
• Contrôle de flux
• checksum : obligatoire, calculé
– rcvWindow : # d'octets de données
sur la totalité du segment et sur que le destinataire du segment est
le pseudo en-tête prêt à recevoir
• data offset : lg de l'en-tête en • Flags
mots de 32 bits – RST, SYN et FIN : pour l’établissement
et la fermeture de connexion
• unsused : 6 bits à 0 – ACK : 1 si le champ acknowledment
• options : MSS, … number est significatif
• padding : alignement de l'en- tête – PSH : 1 si fin d'un msg logique (push)
sur 32 bits – URG : 1 si données urgentes
• urgent pointer : pointe sur la fin (comprise)
des données urgentes

Caractéristiques de TCP
• Numéros de séquence indépendants dans les 2 directions
– Initial Sequence Number (ISN) valeurs aléatoires pour les origines
des N° de séquences
– Associés à chaque octets
• Indique le numéro du premier octet transmis
– Mots de 32 bits
• Bouclage théorique en moins de 6 minutes à 100 Mbps mais en pratique,
c’est beaucoup plus long !
– Utilisé pour les acquittements
• Si N octets sont délivrés avec le numéro de séquence X, l’acquittement
aura la valeur X+N (soit le numéro du prochain octet à recevoir)
– Piggybacking
• Les deux numéros sont présents dans les mêmes paquets

• Fiabilité
– Numéro de séquence
– Détection des pertes :
• Aquittements positifs (ACK) du récepteur -> OK
• Pas d’ACK -> timeout (temporisation) -> retransmission
• ACK dupliqué
– Réordonnancement des paquets au récepteur
– Elimination des paquets dupliqués
– Checksum
– Retransmissions :
• Selective repeat
• GobackN
• Contrôle de flux par annonce de fenêtres
– Fenêtre modulée par le récepteur
– Inclus dans l’ACK
• Fenêtre qui indique le plus grand numéro de séquence pouvant être reçu
• Erreur = congestion
• Contrôle de congestion : adaptation à l’état d’occupation du réseau
– Sans signalisation réseau
• Orienté connexion

Multiplexage
– Pour permettre à plusieurs tâches d'une même machine de
communiquer simultanément via TCP, le protocole définit un
ensemble d'adresses et de ports pour la machine.
– Une "socket" est défini par l'association des adresses Internet

source, destinataire, ainsi que les deux numéros de port à
chaque extrémité. Une connexion nécessite la mise en place de
deux sockets. Une socket peut être utilisée par plusieurs
connexions distinctes.
– L'affectation des ports aux processus est établie par chaque

ordinateur.

Segments
• Les octets de données Application

sont accumulés jusqu’au
moment où TCP décide
d’envoyer un segment Buffer d’émission
• Découpage en segment
indépendant du TCP
TCP
découpage au niveau header
application
• MSS = longueur
maximale d’un segment IP
header IP

Sockets
• Deux process communiquent par des sockets TCP qui fournissent aux
process un flux de données full duplex.
• Ports éphémères
• Port = TCP TSAP = numéro sur 16 bits
– Valeur locale
– 0 à 255 : well-known
– 0 à 1023 : ports système
– 1024 à 65536 : ports utilisateurs
• Une socket TCP :
– Triplet <TCP, IP address, port number>.
• Une connexion TCP :
– 2 sockets <TCP, local IP address, local port, remote IP address, remote
port>.

BSD Sockets
• Primitives pour TCP utilisées par les UNIX BSD
– SOCKET (création d’un nouveau point terminal)
– BIND (attache une adresse à la socket)
– LISTEN (acceptation des connexions avec file d’attente)
– ACCEPT (acceptation bloquante)
– CONNECT (établissement actif de connexion)
– SEND (envoi de données sur une connexion)
– RECEIVE (réception de données d’une connexion)
– CLOSE (terminaison d’une connexion)
• Serveur : SOCKET -> BIND -> LISTEN -> ACCEPT … [SEND,
RECEIVE]… -> CLOSE
• Client : SOCKET –> BIND -> CONNECT … [SEND, RECEIVE]…->
CLOSE

Communication entre applications
process 1 Données process 2 connexion
TCP header
port:x Données
port x port y
socket
connexion TCP fiable
TCP TCP
IP IP Adresse IP
Hôte 2
Hôte 1 paquets IP non fiable

Problèmes pour TCP
• Connexion avec des hôtes différents
– Établissement et libération de connexion
• RTT variable
– adaptation de la temporisation
• Survivance de paquets (très long délai de transfert)
– Attention aux arrivées de très vieux paquets
• Capacité de stockage dynamique des extrémités
– “Apprendre” les ressources disponibles
• Capacité de la route varie dans le réseau
– Ajuster le débit d’émission à la bande passante

Plan du cours

démultiplexage
UDP
données fiable
TCP

Transfert fiable des données TCP
• TCP crée un service • Les retransmissions sont

transfert de données déclanchés par:
fiables (rdt) au dessus du – timeout
service non fiable d'IP – ACKs dupliqués
• Les segments sont • On considère un
pipelinés expéditeur TCP simplifié:
• ACKs cumulatif – ignore ACKs dupliqués
• TCP utilise une minuterie – ignore contrôle de flux et
contrôle de congestion
(timer) pour détecter les
pertes

Num. de seq. et ACKs TCP
Numéro de séquence:
– Fil de “numéro” d'octets du
premier octet dans les données
du segment
ACKs:
– Num. de seq. du prochain octet
attendu
– ACK cumulatif (quitte tous octets
de numéros de seq inférieurs)
• Qustion.: Comment le
destinataire gère les segments
hors-séquence?
– Reponse: TCP ne le spécifie pas –
c'est à la discrétion du
développeur

Transfert de données
• Segmentation
– Découpage du flux en segments selon la MTU locale
– Numérotation des octets
– Gel du numéro de séquence pendant MSL (Maximum Segment Lifetime)
• Contrôle de perte (fiabilité)
– Acquittement positif
– Protection par temporisateur de retransmission chez l'émetteur uniquement
• Contrôle de flux (optimisation des ressources disponibles)
– fenêtres à taille variable
– Progression par acquittement et crédit : fenêtres glissantes
Data (Sequence Number)
Sender Receiver
Acknowledgement +
Advertised Window

Fiabilité : stop and wait
• Envoi d’un paquet et attendre un acquittement avant d’envoyer
un nouveau paquet.
• Si timeout, alors retransmission
• Fiabilité vs. utilisation de la bande passante
émetteur récepteur
Envoi du Données
paquet 1 Réception paquet 1
Envoi ACK 1
ACK
Réception
ACK
Envoi paquet 2 Données

Fenêtre d’émission
• F=min (cwnd, RcvWnd)

– Cwnd est une variable maintenue par la source
• Tient compte de la congestion du réseau
– RcvWnd : fixé par la destination, champ fenêtre
annoncé
• Tient compte de la capacité du récepteur

Fenêtres
• But : optimiser les ressources
– Contrôle de flux et contrôle de congestion
• L’émetteur peut envoyer N segments dans une fenêtre de taille n sans recevoir
d’ACK.
• L’émetteur fait glisser la fenêtre sur réception d’un ACK.
• Fenêtre effective = Fenêtre annoncée - (octets transmis - octets non acquittés)
• Arrêt de la transmission quand fenêtre effective=0
émetteur récepteur
DATA 1
DATA 2
DATA 3
DATA 4 1 2 3 4 5 6 7 8 9
DATA 5
ACK2
fenêtre
DATA 6 glissante

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
de seq a 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 • S'il acquite des segments
segment précédement non acquité
• Lancement de la minuterie – Mettre à jour ce que l'on sait
(timer) si elle n'est pas déjà en être acquité
train de tourner (penser à la – Démarrer le minuteur s'il reste
minuterie pour le plus ancien des segments en suspens
segment non acquité)
• intervalle d'expiration:
TimeOut

TCP: scenarios de retransmission
Host A Host B Host A Host B
Seq=92 timeout
Seq=100 timeout
timeout
X
loss
time time premature timeout,

lost ACK scenario
cumulative ACKs

TCP : Emission d'un ACK [RFC 1122, RFC 2581]
Evènement chez Dest. Action TCP chez le Dest.

Arrive d'un segment dans l'ordre avec un N° Génération retardée de l'ACK: attendre jusqu'a
de séquence attendu. Toutes les données 500ms pour envoyer l'ACK. Si aucun segment
jusqu'à ce N° de séquence ont été Acquitées. n'arrive durant ces 500ms alors envoyer l' ACK.
Arrivé d'un seqment dans l'ordre avec le Envoyer immédiatement d'un ACK cumulatif.
N° de seq attendu. Un autre segment a Accuse réception des deux segments arrivés
un ACK non encore envoyé. dans l'ordre (celui dont l'envoie de l'ACK est
retardé + celui qui vient d'arriver).
Arrivé d'un segment dans le désordre. D'un Envoyer immédiatement un ACK dupliqué indiquant
plus haut N° de seq que celui attendu. Un le numéro de seq. du prochain octet attendu
écart est détecté.
Arrivé d'un segment qui comble Envoyer immédiatemment un ACK, si le segment

partiellement l'écart. augmente la valeur de base window de l'expéditeur

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 renvoie suppose que le segment
d'un paquet perdu après une donnée aquittée
• Segments perdu détectés a été perdue:
par réception d'ACKs – retransmettre: réenvoyer un
dupliqués. segment avant que le timeout
ne se produise.
– L'expéditeur envoie souvent
beaucoup de segment
successivement.
– Si un segment est perdu, il y
aura probablement beaucoup
d'ACKs dupliqués.

Calcul du 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
– mais le RTT varie... d'un segment transmission
• Trop court: timeout jusqu'à la réception d'un ACK
prématuré – Ignorer la retransmission
– Retransmissions inutiles • SampleRTT variera, on veut
• Trop long: lente réaction à estimer un RTT plus lisse
une perte de paquet – Moyenne pondérée sur
plusieurs mesures récentes,
pas juste un SampleRTT
courant

Calcul du timeout
Calcul du RTT
EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT
• Moyenne exponentielle pondérée
– L'influence des échantillons du passé décroit exponentiellement
rapidement
– valeur typique: a= 0.125
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-b)*DevRTT + b*|SampleRTT-EstimatedRTT|
(valeur typique: b= 0.25)
Ensuite fixe l'intervalle de timeout
TimeoutInterval = EstimatedRTT + 4*DevRTT

Plan du cours

démultiplexage
UDP
données fiable
TCP

Contrôle de flux TCP
Fenêtre annoncée
Transmis
Transmis et acquitté Non transmis Non transmissible
non acquitté
• Basé sur la fenêtre glissante

– Pointeur de début de fenêtre
– Pointeur indiquant la partie transmise et non
acquittée
– Pointeur indiquant la fin de la fenêtre
– Envoi de données urgentes toujours possible

• Le coté destinateur de la • Control de flux

connexion TCP à un – L'expéditeur ne va pas
tampon mémoire de: surcharger le tampon du
destinataire
– en transmettant trop de
données et trop vite
• Service d “adaptation de
• Le processus peut lire la vitesse de trans.”: sert à
lentement les données adapter la vitesse de
dans la lecture des transmission à la rapidité
données sur le tampon de lecture du processus.

• Le destinataire avertit la taille

de l'espace libre en includant la
valeur de RcvWindow dans les
segments
• L'expéditeur limite le nombre de
donnée non acquitée à
RcvWindow
 Guarantie que le tampon de
(Suppose que le destinataire TCP rejette les
segments hors-séquence)
réception ne déborde pas
• De l'espace libre dans le tampon
= RcvWindow
= RcvBuffer-[LastByteRcvd - LastByteRead]

Plan du cours

démultiplexage
UDP
données fiable
TCP

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

FIN, répond avec un ACK.
– Entre dans une phase
“timed wait” - répondra
avec un ACK pour des FINs
reçus
• Etape 5: le serveur reçoit
un ACK. connexion
fermée.
• Note: avec de petites
modifications, peut gérer
des FINs simultanés.

Exemple

Automate TCP
CLOSED Close/-
Close/-
Listen/-
LISTEN
SYN/SYN+ACK
RST/- Send/SYN Connect/SYN
SYN RCVD SYN SENT

SYN/SYN+ACK Simultaneous open
ESTABLISHED SYN+ACK/ACK
ACK/-
CLOSE/FIN
CLOSE/FIN FIN/ACK
FIN/ACK
FIN WAIT 1 CLOSING CLOSE WAIT
ACK/- ACK/- CLOSE/FIN

FIN+ACK/ACK
FIN WAIT 2 TIME WAIT LAST ACK
FIN/ACK
ACTIVE CLOSE PASSIVE CLOSE
Timeout/-
ACK/-
CLOSED

Plan du cours

démultiplexage
UDP
données fiable
TCP

Principe de contrôle de 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
– Perte de segments (overflow des buffers aux routeurs)
– Délais longs(temps d’attente élevés dans les buffers
des routeurs)
• Un des 10 problèmes majeurs en réseau!

Méthodes de contrôle de congestion
Deux grandes approches
Contrôle de congestion de Contrôle de congestion assisté

bout en bout : réseau :
• Pas d’informations • Les routeurs fournissent des
explicites de la part du informations aux systèmes
réseau – Un bit indicateur de
congestion (SNA, DECbit,
• La congestion est supposée ATM, une extension deTCP/IP)
par le système terminal à
partir de l’observation de
pertes et de retards
• Approche mise en œuvre
dans TCP

Plan du cours

démultiplexage
UDP
données fiable
TCP

Contrôle de congestion TCP
• Contrôle de bout en bout
– IP ne fournit aucune information sur l’état du réseau
• Le taux de transmission des segments est limité par la taille de la fenêtre
de contrôle de flux
Rate = w * MSS /RTT=CongWin /RTT Bytes/sec
• w segments, chacun de MSS octets, envoyés chaque RTT sec
Nouveau paramètre: la fenêtre de congestion CongWin
TCP gère 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)

• Conservation des paquets
– Ne pas injecter un nouveau paquet tant qu’un vieux n’est pas
sorti du réseau
– Nombre de paquets en transit constant
– Synchronisation sur les acquittements: auto-synchronisation
• Trouver le point de synchronisation
– Utilisation d’une fenêtre dynamique: fenêtre de contrôle de
congestion (cwnd)
• Détection de la congestion
– Pertes généralement dues à la congestion
• Guérison de la congestion
– Diminution du débit à la source pour diminuer la congestion
• Principe
– Trouver le point d’équilibre: “additive
increase”
• Augmenter la fenêtre de contrôle de congestion
– Détection de la congestion par
l’indication de la perte d’un paquet
– Suppression de congestion en réduisant
la fenêtre
• Algorithme
– phase 1: slow start
• Après une perte détectée par expiration de temporisation
– phase 2: évitement de congestion
– En cas de perte: réduction de la taille de la fenêtre et
récupération
– Récupération : fast recovery
• Après une perte détectée par retransmission rapide (fast
retransmit)

Départ lent
• Fenêtre glissante et taille variable de la

fenêtre
• Croissance exponentielle de la taille de la
fenêtre (x2 à chaque fois que les paquets sont
transmis correctement)
– Augmentation de 1 segment à chaque
acquittement (démontrer en TD)

Départ lent
• Lorsque la connexion
commence, accroissement
exponentielle du taux
• jusqu'à la détection d'une
perte:
– double CongWin à chaque
RTT
– Réalise en incrémentant
CongWin pour chaque ACK
reçu
• Resumé: taux initial est
faible mais augmente de
façon exponentielle

Évitement de congestion
• Pour stopper l’augmentation trop rapide (le

slow start est exponentiel)
• À partir d’un seuil : augmentation de 1
segment à chaque RTT
• Le seuil vaut la moitié de la fenêtre lors de la
dernière congestion

Évitement de congestion
Congestion avoidance
/* slowstart is over */
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
1
perform slowstart
1: TCP Reno remplace slowstart (fast recovery) après trois
ACKs dupliqués

Contrôle de congestion
• Evolution de cwnd
segment
perte de segment
croissance
20 linéaire
18
16 réduction
fenêtre à
14 1 segment
12
10
croissance
8 exponentielle réduction de moitié du seuil
6
4
2
0
temps

Fast recovery
• Après 3 ACKs dupliqués: • Raisonnement
– CongWin est divisé par – 3 ACKs dupliqués indiquent
deux que le réseau est capable de
– La fenêtre augmente alors transmettre certains
linéairement segments
– timeout indique une
• Mais après une expiration congestion “plus alarmante”
du timeout:
– CongWin est fixé à 1 MSS;
– Le fenêtre augmente alors
exponentiellement
– Jusqu'au seuil Threshold,
ensuite grossit
linéairement

Résumé
• 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.

Langue

Couche Transport

Transféré par

Informations du document

Description :

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Couche Transport

Titre original :

Transféré par

Description :

Droits d'auteur :

Faculté des sciences de Monastir LFI 3

Département des sciences informatiques 2017 - 2018

LFI 3 1 Couche Transport

1. Services de la couche 6. Contrôle de congestion

LFI 3 Couche Transport 2

LFI 3 Couche Transport 3

LFI 3 Couche Transport 4

LFI 3 Couche Transport 5

couche réseau application

les processus applicatifs exécutés sur des

LFI 3 Couche Transport 6

LFI 3 Couche Transport 7

LFI 3 Couche Transport 8

 Mode non connecté : UDP (User Datagram Protocol)

LFI 3 Couche Transport 9

• Non fiable, dans le désordre: physique réseau

– garantie largeur de bande

LFI 3 Couche Transport 10

1. Services de la couche 6. Contrôle de congestion

LFI 3 Couche Transport 11

transport transport transport

réseau réseau réseau

liaison liaison liaison

physique physique physique

LFI 3 Couche Transport 12

• Le site reçoit des datagrammes

LFI 3 Couche Transport 13

LFI 3 Couche Transport 14

PS: 6428 PS: 6428

PS: 9157 PS: 5775

PS fournit “l’adresse de retour”

LFI 3 Couche Transport 15

LFI 3 Couche Transport 16

PS: 9157 PS: 5775

LFI 3 Couche Transport 17

1. Services de la couche 6. Contrôle de congestion

LFI 3 Couche Transport 18

LFI 3 Couche Transport 19

LFI 3 Couche Transport 20

LFI 3 Couche Transport 21

LFI 3 Couche Transport 22

LFI 3 Couche Transport 23

LFI 3 Couche Transport 24

1. Services de la couche 6. Contrôle de congestion

LFI 3 Couche Transport 25

• Les caractéristiques du canal non fiable déterminent la

LFI 3 Couche Transport 26

• Si le canal peut inverser les bits: somme de contrôle pour

LFI 3 Couche Transport 27

LFI 3 Couche Transport 28

LFI 3 Couche Transport 29

premier bit du paquet

ACK arrive, envoie du

LFI 3 Couche Transport 30

• Deux types de protocoles en pipeline: go-Back-N, selective

premier bit du paquet transmis, t = 0

Premier bit du paquet arrive

ACK arrive, envoie du prochain

LFI 3 Couche Transport 32

 ACK(n): ACKs acquiite tous les paquets jusqu’à n “ACK

LFI 3 Couche Transport 33