les protocoles de transport TCP et UDP PLAN Origine de TCP

PLAN
❒ Origines de TCP-IP
❒ Les protocoles de transport
❍ Fonctions
❍ Ports
les protocoles de transport
TCP et UDP
❒ UDP
❒ TCP
❍ Éléments de base de TCP
❍ Fiabilité
❍ Fenêtres
❍ Reprise sur erreurs
❍ Algorithmes de contrôle de congestion
Transport Layer
Transport Layer
1
2
TCP-IP: origine
❒ Commutation de paquets
❒ Approche « informatique » vs « télécom »
Origine de TCP/IP
❒ Expérimentations de chercheurs
❒ Approche intégrée : des applications aux
outils techniques
❒ Approche de complémentarité par rapport
à l’existant
❒ Déploiement rapide
❒ Devient standard de fait
❒ Internet
Transport Layer
3
Interconnexion de réseaux
❒
❒
❒
❒
❒
Les réseaux
d'entreprise
Les passerelles
Les protocoles
Les adresses
Le monde TCP-IP
A
Machine A
C
Réseau 1
Réseau 3
P1
D
P2
4
F
Transport Layer
5
Machine D
Applications
standards
Transport
Transport
Protocole
d'accès à R1
G
Passerelle
Applications
standards
Protocole
IP
Réseau 4
E
Transport Layer
Architecture TCP-IP
B
Réseau 2
❒ Le Web
Réseau R1
Protocole
IP
R1
R2
Protocole
IP
Protocole
d'accès à R2
RéseauTransport
R2 Layer
6
1
Le principe du bout en bout
❒ Pas d’intelligence dans le réseau
❍ Traitement simple dans le réseau -> haut débit
❍ Réseau généraliste -> évolution de l’utilisation
du réseau
❍ Pas de redondance de contrôle
Rôle du transport
❒ Séparation des fonctions
❍ Contrôle -> hôte
❍ Acheminement -> routeur
Bout en bout
Hôte
Protocole
IP
Transport Layer
network
data link
physical
s
an
tr
• Circuit virtuel
• Datagramme
network
data link
physical
network
data link
physical
❍
po
rt
❍
d
en
den
❒
al
❒
application
transport
network
data link
physical
Mode non connecté et sans garantie
❒ Robustesse
❍ Indépendance du fonctionnement
• Le fonctionnement du système d’extrémité n’est pas
lié à celui du réseau
relies on, enhances, network
layer services
Transport Layer
Transport Layer
9
Fonction des protocoles de
transport
❒
Protocoles de bout en bout (pas comme à la
couche réseau par exemple)
❍ Service connecté ou non
❍ fiabilité
❍ performance
❒ Transport d’un message d’un émetteur au
récepteur
Général
❍
❍
❍
❒
❍
❍
❒
❒
❒
❒
Contrôle des échanges
Corriger les défauts du service réseau
Compte rendu sur la performance de la
communication
Construction du service attendu par les
applications distinct de celui fourni par la couche
réseau
❍
11
Communication inter-process
Identification des points d‘extrémités
Bout en bout
A la demande de l'application
❍
Indépendamment des réseaux qui véhiculent l’information
• Pas de connaissance sur les réseaux traversés
« Interface » entre les applications et le réseau
S’appuie sur des protocoles (des couches basses)
pour l’acheminement des données.
❒ Deux protocoles principaux :
❍ TCP : fiabilité, contrôle d’erreur, de flux,
d’ordre
Transport Layer
❍ UDP : Vérification des erreurs
10
Rôle du Transport
❒
❍
8
❒ Service réseau
❍ Modes d’acheminement
network
data link
physical
network
data link
physical
c
gi
❒
application
transport
network
data link
physical
Transport Layer
Principe du bout en bout
lo
❒
communication logique entre
des processus applicatifs
s’exécutant sur des hôtes
différents
transport protocols run in
end systems
transport vs network layer
services:
network layer: data transfer
between end systems
transport layer: data
transfer between processes
Protocole
IP
7
Services et protocoles de transport
❒ Fournissent une
Hôte
Routeur
Mode connecté fiable, sur un réseau datagramme
non fiable
Séparation du service fourni par l’opérateur
et
Transport Layer
offert à l’utilisateur
12
2
Ports
❒
❍
PID -> trop dynamique
par un point d’extrémité:
• le port
• n° de port sur 2 octets
Ceci est réalisé avec les ports
❍
16-bits qui identifient quel process est associé à quel datagramme.
Attachement du processus au port
Identification: (@ IP, n° port)
❍
well-known : appartiennent aux serveurs standards
❍
❍
❒
Recall: segment - unit of data
exchanged between
transport layer entities
❍ aka TPDU: transport
protocol data unit
Pour identifier une cible plus spécifique que l’adresse IP car les
datagrammes sont destinés à des process et pas au système.
❍
❒
Multiplexing/demultiplexing
application-layer
data
Deux types de ports :
•
•
•
•
❍
segment
header
Numéro impair entre 1 et 1023
Utilisation d’un seul port sauf BOOTP (ports 67 et 68)
telnet utilise le port 23
Permettent aux clients de trouver des serveurs sans information de
configuration
segment
Demultiplexing: delivering
received segments to
correct app layer processes
receiver
P3
M
P1
M
Ht M
Hn segment
M
P4
application
transport
network
application
transport
network
M
P2
application
transport
network
ephemeral
• Les clients utilisent des ports spécifiés dans les paquets UDP
• Entre 1024 et 5000 habituellement
• <transport protocol, IP address, port number> doit être unique.
Transport Layer
Multiplexing/demultiplexing
Multiplexing:
gathering data from multiple
app processes, enveloping
data with header (later used
for demultiplexing)
host A
source port #
Web client
host C
Source IP: C
Dest IP: B
source port: y
dest. port: 80
port use: simple telnet app
application
data
(message)
TCP/UDP segment format
Web client
host A
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
Web
server B
port use: Web server
Transport Layer
15
16
Adressage TSAP
Host 1
Host 2
Application
La connexion réseau
commence ici
server B
source port:23
dest. port: x
other header fields
TSAP/NSAP
La connexion transport
commence ici
source port: x
dest. port: 23
dest port #
Transport Layer
TSAP n
14
Multiplexing/demultiplexing: examples
32 bits
multiplexing/demultiplexing:
❒ based on sender, receiver
port numbers, IP addresses
❍ source, dest port #s in
each segment
❍ recall: well-known port
numbers for specific
applications
Transport Layer
13
Couche transport
Couche réseau
Serveur
TSAP m
NSAP
Couche liaison
Couche physique
Transport Layer
17
❒ Transport Service Access Point
❍ Identification des applications en
communication
❍ Ex : adresse IP + Port
❒ Scénario de connexion
❍ Serveur sur host2 associé au TSAP n
❍ Client sur host1 s’associe localement au TSAP m
(source) et demande le TSAP n sur host 2
(destination)
❍ Établissement de la connexion réseau entre la
source (host 1) et la destination (host 2)
❍ Demande d’établissement d’une connexion au
niveau transport entre TSAP n et TSAP m
Transport Layer
❍ Validation
18
3
Problèmes de transport
Three Way handshake
❒ Etablissement de connexion
❍ Déséquencement
❒ Etablissement d’une connexion
entité de
transport B
bidirectionnelle avec des numéros de
séquence indépendants
❒ Utilisation d’un échange de 3 TPDU
Etablissement en 3 étapes
entité de
Entité de
transport B
TPDU transport A
demande de
connexion
Entité de
transport A
❍
TPDU
CR
TPDU
de données
TPDU
D
TPDU
confirmation de
connexion
T ou
AK
DT
TPD U
Transport Layer
CONNECTION_REQUEST
• Init. Envoie son numéro de séquence vers la
destination
• CONNECTION_ACCEPTED
– Acquittement et envoi de numéro de séquence
• DATA
– Init. Acquitte avec les premières données vers le
destinataire
CC
TPD U
Transport Layer
19
Problèmes de transport
Problèmes de transport
❒ Perte
❒ Etablissement de connexion
A
T_CONNECT.request
Temporisateur de
T1
retransmission
❍
B
CR
CC
A
B
ouverture d'une connexion
entre A et B
Survivance
TPDU DT 0
TPDU AK 1
T_CONNECT.indication
T_CONNECT.response
T1
CR
T_CONNECT.confirmation
20
CC
TPDU DT 1
TPDU AK 2
Temporisateur de retransmission
Solutions
• Difficulté: dimensionnement
• Limitation de la durée de vie des paquets
• numérotation étendue et valeur initiale
aléatoire
• Gel du numéro de port
Transport Layer
21
Etablissement d’une connexion :
bilan
TPDU DT 1
TPDU AK 2
TPDU DT 1
TPDU AK 2
.
.
.
La TPDU DT 1 est reçue sans
erreur mais hors séquence
Elle est gardée en attente de
reséquencement
La TPDU DT 0 ayant été reçue,
l'acquittement peut se faire
La seconde TPDU DT 1 est
détectée comme dupliquée
Elle est écartée mais acquittée
Transport Layer
22
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts
❒ Envoi d’un CONNECTION_REQUEST
TPDU, avec possibilité de
❍
Perte
❍ Mémorisation
❍ Duplication
❍
❍
❒ Eviter la duplication avec
❍ Génération d’un nouveau TSAP à chaque
connexion
❍ Utilisation d’identificateurs uniques de
connexion (état)
❍ Élimination des anciens (=TTL mais circulaire)
Transport Layer
établissement d'une
nouvelle connexion
TPDU DT 0
Perte
Non Détéctée
❍
Duplication
Non Détéctée
fermeture de la connexion
❒
23
range of sequence numbers must be increased
buffering at sender and/or receiver
Two generic forms of pipelined protocols: go-Back-N,
selective repeat
Transport Layer
24
4
GBN in
action
Go-Back-N
Sender:
❒ k-bit seq # in pkt header
❒ “window” of up to N, consecutive unack’ed pkts allowed
❒ ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
❍
may deceive duplicate ACKs (see receiver)
❒ timer for each in-flight pkt
❒
timeout(n): retransmit pkt n and all higher seq # pkts in window
Transport Layer
Selective Repeat
❒
Selective repeat: sender, receiver windows
buffers pkts, as needed, for eventual in-order delivery
to upper layer
sender only resends pkts for which ACK not
received
❍
❒
26
receiver individually acknowledges all correctly
received pkts
❍
❒
Transport Layer
25
sender timer for each unACKed pkt
sender window
❍
❍
N consecutive seq #’s
again limits seq #s of sent, unACKed pkts
Transport Layer
27
Selective repeat
sender
data from above :
timeout(n):
❒ in-order: deliver (also
ACK(n) in [sendbase,sendbase+N]:
❒ mark pkt n as received
❒ if n smallest unACKed pkt,
advance window base to
next unACKed seq #
Transport Layer
30
Selective repeat in action
❒ send ACK(n)
❒ resend pkt n, restart timer
28
receiver
pkt n in [rcvbase, rcvbase+N-1]
❒ if next available seq # in
window, send pkt
Transport Layer
❒ out-of-order: buffer
deliver buffered, in-order
pkts), advance window to
next not-yet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
❒ ACK(n)
otherwise:
❒ ignore
Transport Layer
29
5
Selective repeat:
dilemma
Protocoles de bout en bout :
bilan
Example:
❒ Réseau “best effort” sous jacent
❍ Perte de paquets
❍ Dé-séquencement
❍ Limite la taille des paquets
❍ Temps de transfert aléatoire
❒ seq #’s: 0, 1, 2, 3
❒ window size=3
❒ receiver sees no
difference in two
scenarios!
❒ incorrectly passes
duplicate data as new
in (a)
Q: what relationship
between seq # size
and window size?
Transport Layer
31
Problèmes de transport
❒ Libération
❍ Brutale
utilisateur
fournisseur
A
DT0
B
Action synchronisée sur réseau non fiable
utilisateur
temporisateur de
retransmission
T_DATA.req
T_DATA.ind
DT1
Dernier octet
acquité
CDT
Fenêtre
ACK2, CDT=3
T_DATA.req
❒ Dissociation du rôle des ACK:
❍ Contrôle d’erreur
❍ Contrôle de flux
effacement de
connexion
T_DISC.req
absence de T_DATA.ind
après le T_DISC.req
T_DISC.req
DT2
DR
DC
AK
Temporisateur
d’effacement
effacement de
connexion
DT3
DT4
Limite supérieure
de fenêtre
32
Problèmes de transport
❒ Contrôle de flux
❍ Adaptatif: fenêtre à taille variable
Numérotation séquentielle
(modulo 2 7 ou 231)
❒ Services courants de bout en bout
❍ Remise garantie des messages
❍ Séquencement
❍ Taille des messages quelconque
❍ Synchronisation récepteur - émetteur
❍ Plusieurs processus applicatif sur une même
Transport Layer
machine
❍
ACK5, CDT=0
Ordonnée
A
B
DT3
DT4
T_CLOSE.request
CR5
ACK5, CDT=1
DT5
•
•
•
Fermeture
effective de la
demi-conexion
T_CLOSE.indication
AK6
DT8
T_DATA.indication
CR9
T_CLOSE.indication
T_DATA.request
T_CLOSE.request
AK10
Transport Layer
Transport Layer
33
34
Automate d’état
Terminaison de connexion
❒ Symétrique
❍ Terminaison indépendante des deux directions
❍ Fin de connexion lorsque chaque extrémité à
terminé
Connection request
TPDU received
IDLE
Passive establishment
pending
❒ Asymétrique
❍ Fin de connexion dès qu’une des extrémités le
demande
Connection primitive executed
Active establishment
Pending
Connection accepted TPDU received
Disconnect primitive executed
Passive disconnect
pending
Active disconnect
pending
Disconnect primitive executed
IDLE
Transport Layer
35
Transitions déclenchées par des
primitives locales ou des arrivées
de TPDU
Establishment
Disconnect request
TPDU received
• Petres possibles car plus de données acceptées après le DR
Connection primitive executed
Disconnection request
TPDU received
Transport Layer
36
6
UDP
❒
❒
❒
❒
UDP
❒
❒
❒
❒
❒
❒
Transport Layer
UDP: User Datagram Protocol
❒ “no frills,” “bare bones”
Internet transport
protocol
❒ “best effort” service, UDP
segments may be:
❍ lost
❍ delivered out of order
to app
❒ connectionless:
❍ no handshaking between
UDP sender, receiver
❍ each UDP segment
handled independently
of others
37
[RFC 768]
38
Communication entre les
couches
Why is there a UDP?
❒ no connection
establishment (which can
add delay)
❒ simple: no connection state
at sender, receiver
❒ small segment header
❒ no congestion control: UDP
can blast away as fast as
desired
process 1
process 2
process n
port y
port z
port x
UDP : démultiplexage de ports
IP
Transport Layer
39
Datagrammes UDP (1)
❒ Port Source
❍ indique le numéro de
port du processus
émetteur,
❍ toute réponse y est
dirigée.
❒
RFC 768
Numéro de protocole 17 quand transporté par IP.
Interface d’application pour IP
Pas de fiabilité, contrôle de flux ou récupération
sur erreur.
Aucun contrôle sur le flot -> simplicité
Peu d’overhead, mécanisme minimaliste
Mode datagramme, non connecté (orienté message)
“multiplexer/demultiplexer'' pour
envoyer/recevoir des datagrammes, en utilisant
des ports pour diriger ces datagrammes.
Qualité “best effort”
création d’un paquet et transmission immédiate au
niveau IP
Transport Layer
Attention : pas de contrôle de congestion
40
Transport Layer
42
Datagrammes UDP (2)
❒ Contrôle d’erreur
❍ Optionnel en IPv4, obligatoire en IPv6
❍ Pseudo-header + en-tête + données
❍ Pseudo-header:
32 bits
0
Transport Layer
15 16
port source
31
• @ IP source
• @ IP destination
• protocole
port destination
longueur
checksum
données
❒ Port Destinataire
❒ Longueur :
❍ nombre d'octets
dans le datagramme
entier (avec en-tête).
❍ >8
32 bits
0
15 16
port source
31
port destination
longueur
checksum
données
Transport Layer
41
7
UDP checksum
Applications d’UDP
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
❒
❒ compute checksum of
❒ treat segment contents
received segment
❒ check if computed checksum
equals checksum field value:
❍ NO - error detected
❍ YES - no error detected.
But maybe errors
nonethless? More later ….
as sequence of 16-bit
integers
❒ checksum: addition (1’s
complement sum) of
segment contents
❒ sender puts checksum
value into UDP checksum
field
❒
❒
Receiver:
Sender:
❒
Transport Layer
❒
❒
la signalisation de certains protocoles
Trivial File Transfer Protocol (TFTP)
Domain Name System (DNS) name server
Remote Procedure Call (RPC), utilisé par Network
File System (NFS)
Network Computing System (NCS)
Simple Network Management Protocol (SNMP)
❒ applications temps réel, visio et audio conférences
❒ applications nécessitant transmission multipoint
(multicast) exemple : applications du MBONE, sdr,
tableau blanc, etc
43
Transport Layer
44
Transport Layer
46
UDP: more
❒ often used for streaming
multimedia apps
❍ loss tolerant
❍ rate sensitive
other UDP uses
(why?):
Length, in
bytes of UDP
segment,
including
header
DNS
SNMP
❒ reliable transfer over UDP:
add reliability at
application layer
❍ application-specific
error recover!
dest port #
length
checksum
❍
TCP
Application
data
(message)
❍
UDP segment format
Transport Layer
45
TCP
Caractéristiques de TCP
❍
Control Protocol
❒ Flot d’octets
❍
Bonne utilisation des ressources du réseau
❍
Couche de transport des systèmes d’extrémités (i.e. utilisateurs des
données)
❍
Transfert fiable de données (¹
❍
• Communication bidirectionnelle et point à point sur des réseaux hétérogènes
❒ Circuit virtuel en mode
UDP)
connecté
• Contrôle de perte
• Contrôle de flux
• Contrôle de congestion: interaction hôte-réseau réactive et agréssive
❍
❍
❍
• TCP suppose que les couches de communication qui lui sont
inférieures lui procurent un service de transmission de paquet simple,
dont la qualité n'est pas garantie.
Mode connecté et commutation de paquets
Orienté flux d’octets:
❍
❍
❍
Attendre d’avoir assez de
données pour émettre
(performance)
Application process
Application process
Octets écrits
TCP
Octets
lus
TCP
Buffer émission
Buffer réception
Segment
Segment… Segment
TSegments transmis
❒ Full duplex
Récepteur le plus simple possible -> complexité chez l’émetteur
• interopérabilité maximum recherchée
❍
Transport Layer
La connexion est établie
et considérée comme un
circuit physique
fiabilité
❒ Transfert bufferisé
• application écrit des octets
• TCP émet des segments
• application lit des octets
❒ Utilisé parTELNET, FTP, HTTP …
Séquencés
Segmentation des
données au niveau TCP
…
❒ RFC 793 - Transmission
❒ 90% du trafic
❒ Principes
…
❒
32 bits
source port #
47
Pour les ACKs
Transport Layer
48
8
Caractéristiques de TCP
Caractéristiques de TCP
❒
❒
Numéros de séquence indépendants dans les 2
directions
❍
Associés à chaque octets
❍
Mots de 32 bits
❍
❍
❍
• Indique le numéro du premier octet transmis
❍
❍
❍
• 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 du paquet avec le numéro de
séquence X, l’acquittement aura la valeur X+N (soit le
numéro du prochain octet à recevoir)
❍
❍
Piggybacking
Transport Layer
• Selective repeat
• Go back N
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
❍
49
Caractéristiques de TCP
❒
Sans signalisation réseau
Les octets de
données sont
accumulés jusqu’au
moment où TCP
décide d’envoyer un
segment
❒ Découpage en
segment indépendant
du découpage au
niveau application
❒ MSS = longueur
maximale d’un
segment
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.
Transport Layer
51
Sockets
BSD Sockets
❒ Deux process communiquent par des sockets TCP qui
❒
fournissent aux process un flux de données full duplex.
❍
❒ 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>.
Transport Layer
Buffer d’émission
TCP
header
TCP
IP
header
IP
Transport Layer
52
Primitives pour TCP utilisées par les UNIX BSD
❍
❒ Ports éphémères
❍
50
Application
❒
❍
❍
Transport Layer
Orienté connexion
Segments
Multiplexage
❍
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 :
Contrôle de flux par annonce de fenêtres
❍
• Les deux numéros sont présents dans les mêmes paquets
❒
Fiabilité
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
Transport Layer
❒
53
54
9
Communication entre
applications
process 1
port x
Données
TCP header
port:x
Données
Problèmes pour TCP
❒ Connexion avec des hôtes différents
❍ Établissement et libération de connexion
process 2
❒ RTT variable
❍ adaptation de la temporisation
connexion
❒ Survivance de paquets (très long délai de
port y
transfert)
socket
TCP
connexion TCP fiable
TCP
❍
Attention aux arrivées de très vieux paquets
❒ Capacité de stockage dynamique des
IP
Adresse IP
IP
extrémités
❍
paquets IP non fiable
Hôte 1
Transport Layer
Hôte 2
55
“Apprendre” les ressources disponibles
❒ Capacité de la route varie dans le réseau
Transport Layer
❍ Ajuster le débit d’émission à la bande passante
Vie d’une Connexion
Établissement d’une connexion
❒ Si deux processus désirent communiquer,
❒ Appel OPEN passif (serveur)/actif (client)
établissement d’une connexion TCP
❒ Internet => best effort
❍
❒ Fermeture d’une connexion avec le bit FIN
(à faire dans les deux sens)
on utilise donc une méthode d'initialisation par
négociation bilatérale basée sur une horloge pour
les numéros de séquence.
❒ A la fin de la connexion
❍ Fermeture qui libère les ressources
❒ 3 phases
❍ Ouverture d’une connexion
❍ Transfert de données
❍ Fermeture de la connexion
Process 1
Active OPEN
Send SYN, seq=n
Process 2
Passive open
attend une requête active
Receive SYN
Send SYN, seq=m, ACK=n+1
Receive SYN+ACK
Transport Layer
57
Send ACK=m+1
Transport Layer
58
Etablissement de la connexion
TCP
Connexion TCP
❒ Trois phases
❍ Etablissement de la connexion
❍ Transfert des informations avec
❒ Procédure à trois échanges
❍ Three way handshake
❒ ISN (Initial Sequence Number)
❍ Numéro de séquence du premier octet
d’information transporté
❍ Le premier octet transporté est alors ISN+1
❍ ISN est généralement dérivé de l’horloge de
l’hôte
• Contrôle de flux
• Contrôle de congestion
❍
56
Libération de la connexion
Transport Layer
59
Transport Layer
60
10
Exemple
Libération de la connexion
ouverture passive
ouverture active
attente demande
d’ouverture…
❒ Normale
❍ Fin demandée par l’une des extrémités (flag
FIN=1)
envoi demande
d’ouverture
SYN , seq= x
ouverture à trois phases
(‘ three-way handshake ’)
SYN + ACK, seq= y, Acknb= x+1
échange d’options :
- MSS (max segment size)
- numéros de séq. initiaux
- extensions...
ACK, seq= x+1, Acknb= y+1
❒ Terminaison brutale
• Envoi de la primitive ABORT (flag RST=1)
• Toutes les transmissions ou réceptions sont
interrompues et les tampons sont vidés
<Transfert de données>
application effectue close()
FIN, seq=i
envoi EOF à l’application
seq=j, ACKnb= i+1
application effectue close()
FIN, seq= j, ACKnb=i+1
seq=i+1, ACKnb= j+1
Attente de 2*MSL
Transport Layer
Automate TCP
CLOSED
Listen/-
SYN/SYN+ACK
ACK/-
❒
Connect/SYN
Simultaneous open
ESTABLISHED
❍
❍
❒
SYN+ACK/ACK
❍
CLOSE WAIT
ACK/-
FIN+ACK/ACK
FIN WAIT 2
FIN/ACK
Acquittement positif
Protection par temporisateur de retransmission chez l'émetteur
uniquement
Contrôle de flux (optimisation des ressources disponibles)
❍
❍
ACK/-
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é)
❍
❒
CLOSING
Segmentation
❍
SYN SENT
FIN/ACK
FIN/ACK
FIN WAIT 1
Transfert de données
Close/-
Send/SYN
RST/-
CLOSE/FIN
CLOSE/FIN
62
Close/-
LISTEN
SYN/SYN+ACK
SYN RCVD
Transport Layer
61
fenêtres à taille variable
Progression par acquittement et crédit : fenêtres glissantes
CLOSE/FIN
TIME WAIT
Data (Sequence Number)
LAST ACK
ACTIVE CLOSE
PASSIVE CLOSE
Timeout/CLOSED
Sender
ACK/-
Transport Layer
63
Fiabilité : stop and wait
Réception
ACK
Envoi paquet 2
Transmis et acquitté
Data
Réception paquet 1
Envoi ACK 1
Data
Transport Layer
Transmis
non acquitté
Non transmis
Non transmissible
❒ 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
récepteur
ACK
64
Fenêtre annoncée
d’envoyer un nouveau paquet.
❒ Si timeout, alors retransmission
❒ Fiabilité vs. utilisation de la bande passante
Lancer nam ici
Envoi du
paquet 1
Transport Layer
Contrôle de flux TCP
❒ Envoi d’un paquet et attendre un acquittement avant
émetteur
Receiver
Acknowledgement +
Advertised Window
65
Transport Layer
66
11
Fenêtre d’émission
Fenêtres
❒ F=min (cwnd, W)
❍ Cwnd est une variable maintenue par la source
❒
❍
Contrôle de flux et contrôle de congestion
L’émetteur peut envoyer n paquets 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
❒
• Tient compte de la congestion du réseau
❍
But : optimiser les ressources
W : fixé par la destination, champ fenêtre
annoncé
• Tient compte de la capacité du récepteur
émetteur
récepteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
1
2
3
4
5
6
ACK2
Transport Layer
67
Silly window syndrome
Fiabilité avec Go-back-N
❒ L’émetteur a beaucoup de données à
❒ Fenêtre d’anticipation
transmettre
❒ Petite fenêtre annoncée => émission de
petits segments
❒ Solution pour le récepteur
❍
Transport Layer
sélective (stockage en désordre)
A
❍
Paquet 2 perdu:
T
• ACK 3 non reçu par S,
• W reste en 1
• R aquitte 3, 4, 5 avec un
ACK 2
• Timout sur S,
retransmission
• ACK 6 envoyé par R
❍
DT0
Paquet 2 arrivé et ACK
perdu
• ACK 3 non reçu mais ACK 4
reçu
• ACK 4 acquitte tous les
paquets avant 4
• S fait glisser sa fenêtre au
paquet 4
B
DT1
ACK2
DT2
DT3
DT4
ACK3
DT3
•
•
•
69
Transport Layer
70
Exemple de reprise sur erreurs
émetteur
Exemples
68
❒ Retransmission continue (go-back-n) ou
La reprise sur erreurs
❒
9
❒ Détection d’erreurs par l’émetteur
Annoncer des fenêtres par tranches plus larges
(MSS par exemple)
❒ Solution pour l’émetteur
❍ Retarder l’envoi de petits segments
❍ Soit PUSH positionné soit on a au moins ½ de la
fenêtre à envoyer
8
fenêtre
glissante
DATA 6
Transport Layer
7
récepteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
Sender
Segment 1 (seq. 1000)
ACK2
ACK2
ACK2
ACK2
Receiver
Receives 1000, send ACK 1500
Segment 2 (seq. 1500)
DATA 2
Segment 3 (seq. 2000)
Receives ACK 1500
Slide the window
ACK6
récepteur
émetteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
Waiting for ACK
Receives one of the frames and
replies with ACK 1500
Receive ACK 1500
which does not slide the window
ACK2
ACK3
ACK4
Transport Layer
Segment 4 (seq. 2500)
71
Timeout -> retransmission
Of segment 2
Transport Layer
72
12
TCP: retransmission scenarios
Host A
, 8 byte
s data
A
X
100
CK=
loss
Seq=92
, 8 byte
s data
ACK
time
Host B
Seq=92
Seq=100 timeout
Seq=92 timeout
timeout
Host A
Host B
Seq=92
TCP ACK generation
, 8 byte
s data
Seq=
100,
20 byt
e s da
0
10
K=
120
A C AC K=
Seq=92
, 8 byte
s data
AC
=100
time
lost ACK scenario
ta
20
K= 1
premature timeout,
cumulative ACKs
Transport Layer
[RFC 1122, RFC 2581]
Event
TCP Receiver action
in-order segment arrival,
no gaps,
everything else already ACKed
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
in-order segment arrival,
no gaps,
one delayed ACK pending
immediately send single
cumulative ACK
out-of-order segment arrival
higher-than-expect seq. #
gap detected
send duplicate ACK, indicating seq. #
of next expected byte
arrival of segment that
partially or completely fills gap
immediate ACK if segment starts
at lower end of gap
Transport Layer
73
Conséquences de ces
mécanismes
Temporisateurs de TCP
❒ Fiabilité des transmissions
❒ Temporisateur de retransmission
❒ Bonne utilisation de la bande passante
❒ Temporisateur de peristence
❍ Pour débloquer la situation après une fenêtre
d’émission réduite à zéro et une ouverture
perdue
❒ Contrôle de flux orienté récepteur : la
taille de la fenêtre varie au cours de la
connexion
74
❒ Temporisateur d’inactivité
❍ Vérifie la présence de l’autre extrémité
❒ Temporisateur de déconnexion
❍ Deux fois la durée de vie des paquets
Transport Layer
Performance maximum si l’émetteur toujours en
activité
❍
Eviter l’épuisement de la numérotation en séquence
❍
Eviter la fermeture de la fenêtre
•
•
•
•
❍
❒ Délais variables sur Internet
❍ Distance
❍ Temps de traversée du réseau (charge,
saturation des liens …)
durée de rebouclage > MSL
Seq number: 32 bits
fenêtre annoncée ≥ bande passante * RTT
• RTT (Round Trip Time) = temps entre émission d’un segment et réception de l’ACK correspondant
• bande passante * RTT = capacité de mémorisation du réseau
Window: 16 bits -> soit 64 Ko
❒ Le timeout est calculé en fonction de
Cas des Long Fat Networks:
nature du réseau
Ethernet
Canal T1 satellite
Gigabit transcontinental
76
Ajustement des timeouts :
Contrôle d’erreur
TCP et Long Fat Networks
❒
Transport Layer
75
l’estimation du RTT (Round Trip Time)
bande passante
RTT type
❒ Log du moment où un paquet est envoyé et
bande passante * RTT
10 Mbps
3 ms
3,7 ko
1,54 Mbps
500 ms
95 ko
1 Gbps
60 ms
7,5 Mo
quand il est acquitté
❒ Moyenne pondérée des RTT mesurés
❒
❒ Permet de trouver une valeur de timeout
Extension TCP pour les LFNs (RFC1323)
❍
❍
facteur d’échelle sur la fenêtre d’émission
ajout d’une estampille temporelle sur 32 bits
Transport Layer
77
pour le segment suivant
Transport Layer
78
13
Ajustement des timeouts:
Contrôle d’erreur
TCP Round Trip Time and Timeout
❒ Temporisateur de retransmission adaptatif
❍
Q: how to set TCP
timeout value?
Mesure de RTT et en déduire une estimation
❒ longer than RTT
Algorithme
Err
= SampleRTT - EstRTT
EstRTT = EstRTT + (d x Err)
Var
= Var + d(|Err| - Var)
note: RTT will vary
❒ too short: premature
timeout
❍ unnecessary
retransmissions
❒ too long: slow reaction
to segment loss
❍
Prise en compte de la variance
Temporisateur = m x EstRTT + f x Var
Où m = 1 et f = 4
❒ Mesure du RTTémetteur
Cas d’erreurs
récepteur
émetteur
Donné
e
retransmission
ACK
❍
récepteur
Donn
ée
RTT mesuré
RTT mesuré
❍
retransmission
ACK
Q: how to estimate RTT?
❒ SampleRTT: measured time from
segment transmission until ACK
receipt
❍ ignore retransmissions,
cumulatively ACKed segments
❒ SampleRTT will vary, want
estimated RTT “smoother”
❍ use several recent
measurements, not just
current SampleRTT
Actions:
• pas de mesure de RTT quand il y a eu une retransmission
• Doublement de la valeur du temporisateur après chaque
Transport Layer
retransmission
Transport Layer
79
TCP Round Trip Time and Timeout
80
TCP congestion control:
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
❒
❒ Exponential weighted moving average
❒ influence of given sample decreases exponentially fast
“probing” for usable
bandwidth:
❍
❒ typical value of x: 0.1
Setting the timeout
❍
❒ EstimtedRTT plus “safety margin”
❒ large variation in EstimatedRTT -> larger safety margin
❍
Timeout = EstimatedRTT + 4*Deviation
ideally: transmit as fast
as possible (Congwin as
large as possible)
without loss
increase Congwin until
loss (congestion)
loss: decrease Congwin,
then begin probing
(increasing) again
❒
two “phases”
❍
❍
❒
slow start
congestion avoidance
important variables:
❍
❍
Congwin
threshold: defines
threshold between two
slow start phase,
congestion control
phase
Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|
Transport Layer
Transport Layer
81
Contrôle de congestion
Causes/costs of congestion: scenario 1
two senders, two
receivers
❒ one router,
infinite buffers
❒ no retransmission
❒
❒ Congestion
❍ Goulot d'étranglement
Réseau 1
Routeur
Réseau 2
82
Datagrammes en
attente de relayage
routeur
Réseau 3
large delays
when congested
❒ maximum
achievable
throughput
❒
temps de
transfert
• Effondrement des performances
Réponses:
- niveau réseau: gestion des ressources
- niveau transport: adaptation du débit
trafic offert
Transport Layer
83
Transport Layer
84
14
Causes/costs of congestion: scenario 2
Causes/costs of congestion: scenario 2
❒ always:
one router, finite buffers
❒ sender retransmission of lost packet
❒
l
=
in
lout
(goodput)
❒ “perfect” retransmission only when loss:
l > lout
in
l
❒ retransmission of delayed (not lost) packet makes
(than perfect case) for same
lout
in
larger
“costs” of congestion:
❒ more work (retrans) for given “goodput”
❒ unneeded retransmissions: link carries multiple copies of pkt
Transport Layer
Causes/costs of congestion: scenario 3
❒ four senders
❒ multihop paths
❒ timeout/retransmit
Transport Layer
85
86
Causes/costs of congestion: scenario 3
Q: what happens as l
in
and l increase ?
in
Another “cost” of congestion:
❒ when packet dropped, any “upstream transmission
capacity used for that packet was wasted!
Transport Layer
Transport Layer
87
Approaches towards congestion control
Contrôle de congestion TCP
Two broad approaches towards congestion control:
❒
End-end congestion
control:
❒ no explicit feedback from
network
❒ congestion inferred from
end-system observed loss,
delay
❒ approach taken by TCP
Ne pas injecter un nouveau paquet tant qu’un vieux n’est
pas sorti du réseau
• nombre de paquets en transit constant
❒ routers provide feedback
❍
to end systems
❍ single bit indicating
congestion (SNA,
DECbit, TCP/IP ECN,
ATM)
❍ explicit rate sender
should send at
Transport Layer
Conservation des paquets
❍
Network-assisted
congestion control:
88
❒
Trouver le point de synchronisation
❍
Utilisation d’une fenêtre dynamique: fenêtre de
contrôle de congestion (cwnd)
❒
Détection de la congestion
❒
Guérison de la congestion
❍
89
Synchronisation sur les acquittements: autosynchronisation
❍
Pertes généralement dues à la congestion
Diminution du débit à la source pour diminuer
la
Transport Layer
congestion
90
15
Algorithmes de contrôle de
congestion et gestion des fenêtres
Contrôle de congestion
Principe
❍ Trouver le point d’équilibre: “additive
increase”
❒ Slow Start
• 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
❍
❍
❍
❍
❍
Source
phase 1: slow start
• Après une perte détectée par expiration de
temporisation
phase 2: congestion avoidance
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)
Destination
❒ Multiplicative decrease
❒ Fast recovery
❒ RED
❒ Delayed ACK
❒ etc.
É
❒
Transport Layer
Transport Layer
91
Slow Start
Congestion avoidance
❒ Fenêtre glissante et taille variable de la
❒ Pour stopper l’augmentation trop rapide (le
fenêtre
❒ Croissance exponentielle de la taille de la
fenêtre (x2 à chaque fois que les paquets
sont transmis correctement)
❍
92
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
Augmentation de 1 segment à chaque
acquittement
❒ Lancer nam ici
Transport Layer
Congestion avoidance
❒
❒
❒
❒
❒
❍
94
TCP et grands RTTs
Initialisation avec cwnd=1 et ssthresh=65536
TCP envoie moins de min(cwnd, fenêtre de
réception)
Congestion => ssthresh = max(fenêtre/2, 2).
Si timeout (cad perte), alors cwnd=1
Nouvel ACK => grandir cwnd
❍
Transport Layer
93
❒ Avec Congestion avoidance, la taille de la
fenêtre augmente de 1 à chaque RTT
❒ Croissance moins rapide si le RTT est grand
❒ Lancer biais.avi
Si cwnd<=ssthresh alors slow start jusque cwnd =
cwnd avant congestion /2
Sinon Congestion avoidance (croissance linéaire de la
taille de la fenêtre)
Avant ces mécanismes : simple-pre-vj.nam
Lancer nam (multiplicative decrease) ici
❒ Lancer simple.avi ici ou nam (simple.nam)
❒
❒
Transport Layer
95
Transport Layer
96
16
Fast recovery
Fast retransmit
❒ Empêche le slow start après la congestion
❒
❒ Slow start utilisé en cas de perte de
Modification de congestion
avoidance
❍
paquets (expiration de timer)
❍
❒
Si 3 DUPACKs
❍
❍
❍
❍
❍
❒
Transport Layer
3 DUPACKs -> paquet supposé
perdu et donc retransmission
Après la transmission, tout
continue normalement (on
attend pas d’ACK)
Sshthresh = ½
min(cwnd,fenêtre récepteur)
Retransmettre le segment
perdu
Cwnd+=3 taille de segment
Autre DUPACK -> cwnd
+=taille de segment et
transmet un paquet
Acquittement de nouvelles
données -> cwnd = ssthresh
émetteur
récepteur
P1
P2
P3
P4
P5
P6
A2
A3
A3 Ack dupliqué
A3
A3
Retransmission P3
Lancer nam ici
Transport Layer
97
RED (Random Early Detection)
Delayed ACKs
❒ Dans les routeurs
❒ Possibilité d’acquitter plusieurs paquets
98
d’un coup
❒ Lancer nam ici
❒ Congestion imminente -> notification à la
source en perdant un paquet
❒ La congestion est calculée en mesurant la
taille moyenne des queues dans les routeurs
❒ Lancer nam ici
❒ Comparaison avec drop tail
Transport Layer
99
Contrôle de congestion
20
réduction
fenêtre à
1 segment
12
10
8
croissance
exponentielle
réduction de moitié du seuil
6
4
2
0
102
/* slowstart is over
*/
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
perform slowstart 1
perte de segment
14
Transport Layer
Congestion avoidance
croissance
linéaire
18
16
100
TCP Congestion Avoidance
❒ Evolution de cwnd
segment
Transport Layer
temps
Transport Layer
1: TCP Reno skips slowstart (fast
recovery) after three duplicate ACKs
101
17
Segment TCP
32 bits
Segment TCP
0
15
4 bits header
length
❒ Port Destination (16 bits) : Le numéro de port du destinataire.
6 bits
reserved
données par rapport au début de la transmission (sauf si SYN est
marqué). Si SYN est marqué, le numéro de séquence est le
numéro de séquence initial (ISN) et le premier octet à pour numéro
ISN+1.
❒ Accusé de réception (32 bits) : si ACK est marqué ce champ
contient le numéro de séquence du prochain octet que le récepteur
s'attend à recevoir. Une fois la connexion établie, ce champ est
toujours renseigné.
32 bits
15 16
31
destination port number
sequence number
acknowledgement number
4 bits header
length
6 bits
reserved
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
window size
urgent pointer
checksum
options
Transport Layer
data
(optionel)
103
Segment TCP
❒ Taille des segments décidés par TCP
❍ Taille max = max (65535o avec entête TCP,
MTU)
❒ Un segment doit tenir dans le MTU
❍ Pour IPv4, la MTU minimale est 556 octets
(payload TCP de 536 octets)
Transport Layer
❍
increase window by 1
per RTT
decrease window by
factor of 2 on loss
event
R
S
T
F
I
N
S
Y
N
window size
urgent pointer
options
data
(optionel)
❒ Header length (4 bits): La taille de l'en-tête TCP en nombre de
mots de 32 bits. Il indique là ou commence les données. L'en-tête
TCP, dans tous les cas à une taille correspondant à un nombre
entier de mots de 32 bits.
❒ Réservé (6 bits) : réservés pour usage futur. Doivent
nécessairement être à 0.
❒ Bits de contrôle (6 bits - de gauche à droite):
- URG: Pointeur de données urgentes significatif
- ACK: Accusé de réception significatif
- PSH: Fonction Push
- RST: Réinitialisation de la connexion
- SYN: Synchronisation des numéros de séquence
- FIN: Fin de transmission
❒ Fenêtre (16 bit): le nombre d'octets à partir de la position marquée
Transport Layer 104
dans l'accusé de réception que le récepteur est capable
de recevoir.
Two competing sessions:
❒ Additive increase gives slope of 1, as throughout increases
Fairness goal: if N TCP
sessions share same
bottleneck link, each
should get 1/N of link
capacity
❒ multiplicative decrease decreases throughput proportionally
equal bandwidth share
R
TCP connection 1
bottleneck
router
capacity R
Transport Layer
106
Why is TCP fair?
TCP Fairness
TCP
connection 2
Transport Layer
105
Connection 2 throughput
❍
P
S
H
❒ Unix
❍ BSD 4.2 (1983) 1ére souche TCP/IP largement
disponible
❍ BSD 4.3 Tahoe (1988), slow start, congestion
avoidance
❍ BSD 4.3 Reno (1990), fast recovery
❍ BSD 4.3 Vegas (1990), Estimateur de BP
❒ Zéro ou plus octets de données
TCP congestion
avoidance:
❒ AIMD: additive
increase,
multiplicative
decrease
A
C
K
Versions de TCP
❒ En-tête de 20 octets (+ options) = IP
AIMD
U
R
G
checksum
❒ Numéro de séquence (32 bits) : Le numéro du premier octet de
source port number
31
destination port number
sequence number
acknowledgement number
❒ Port source (16 bits) : le numéro de port de la source.
0
16
source port number
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
107
Transport Layer
108
18
TCP latency modeling
TCP latency Modeling
K:= O/WS
Q: How long does it take to Notation, assumptions:
receive an object from a ❒ Assume one link between
client and server of rate R
Web server after sending
❒ Assume: fixed congestion
a request?
❒ TCP connection establishment
❒ data transfer delay
window, W segments
❒ S: MSS (bits)
❒ O: object size (bits)
❒ no retransmissions (no loss,
Two cases to consider:
no corruption)
❒ WS/R > RTT + S/R: ACK for first segment in
Case 1: latency = 2RTT + O/R
window returns before window’s worth of data
sent
❒ WS/R < RTT + S/R: wait for ACK after sending
Transport Layer
window’s worth of data sent
Transport Layer
109
TCP Latency Modeling: Slow Start
Example:
❒ Will show that the latency of one object of size O is:
O/S = 15 segments
O
Sù
S
é
+ P ê RTT + ú - ( 2 P - 1)
R
Rû
R
ë
initiate TCP
connection
request
object
K = 4 windows
where P is the number of times TCP stalls at server:
first window
= S/R
RTT
second window
= 2S/R
Q=2
third window
= 4S/R
P = min{K-1,Q} = 2
P = min{Q, K - 1}
Server stalls P=2 times.
fourth window
= 8S/R
- where Q is the number of times the server would stall
if the object were of infinite size.
- and K is the number of windows that cover the object.
complete
transmission
object
delivered
time at
client
Transport Layer
TCP Latency Modeling: Slow Start (cont.)
+
❒ Protocoles de transport => de bout-en-bout
❍
❍
❍
request
object
éS
k -1 S ù
êë R + RTT - 2 R úû = stall time after the kth window
first window
= S/R
RTT
second window
= 2S/R
third window
= 4S/R
latency =
P
O
+ 2 RTT + å stallTime p
R
p =1
P
O
S
S
+ 2 RTT + å [ + RTT - 2k -1 ]
R
R
k =1 R
O
S
S
= + 2 RTT + P[ RTT + ] - (2 P - 1)
R
R
R
112
Conclusion et synthèse
initiate TCP
connection
S
= time to transmit the kth window
R
time at
server
Transport Layer
111
S
+ RTT = time from when server starts to send segment
R
until server receives acknowledgement
2 k -1
110
TCP Latency Modeling: Slow Start (cont.)
❒ Now suppose window grows according to slow start.
Latency = 2 RTT +
Case 2: latency = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
fourth window
= 8S/R
❍
multiplexing/demultiplexing
reliable data transfer
flow control
congestion control
❒ Principalement deux protocoles de transport
❍
❍
UDP : non fiable, seulement vérification des erreurs
TCP : fiable, contrôle de congestion, reprise sur erreurs (ACK +
timeout)…
❒ Implémentés partout
Cours suivant :
=
complete
transmission
object
delivered
time at
client
Transport Layer
❒ On quitte la bordure du réseau (couches application et
transport)...
❒ ... pour entrer au coeur du réseau.
time at
server
113
Transport Layer
114
19
Chapter 3: Summary
❒
principles behind
transport layer services:
❒ instantiation and
implementation in the Internet
❍ UDP
❍ TCP
Transport Layer
115
20