transport layer1 plan r origines de tcp-ip r les protocoles de transport m fonctions m ports r udp r...
TRANSCRIPT
Transport Layer 1
PLAN Origines de TCP-IP Les protocoles de transport
Fonctions Ports
UDP TCP
Éléments de base de TCP Fiabilité Fenêtres Reprise sur erreurs Algorithmes de contrôle de congestion
Transport Layer 2
Adresse IP
Transport Layer 3
Origine de TCP/IP
Transport Layer 4
TCP-IP: origine
Commutation de paquets Approche « informatique » vs « télécom » 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 Le Web
Transport Layer 5
Réseau 1
BA
Réseau 2
Réseau 3
Réseau 4
P1
P2
C
DE G
F
Interconnexion de réseauxInterconnexion de réseaux
Les réseaux d'entreprise
Les passerelles Les protocoles Les adresses Le monde TCP-IP
Transport Layer 6
Transport Layer 7
L’architecture Internet
Transport Layer 8
L’architecture TCP/IP
L’architecture TCP/IP contient trois niveaux protocolaires : -Le niveau IP (Internet Protocol) qui est un niveau paquet.-Le niveau TCP (Transmission Control Protocol) qui regroupe les niveaux
message et session.-Le niveau applicatif qui regroupe les niveaux présentation et application.Il est à noter que l’architecture TCP/IP s’appuie sur des niveaux trames quelconque.
Transport Layer 9Réseau R1
Protocole d'accès à R1
Protocole IP
Transport
Réseau R2
Protocole d'accès à R2
Protocole IP
Transport
R1 R2
Protocole IP
Machine A Machine DPasserelle
Architecture TCP-IPArchitecture TCP-IP
Applicationsstandards
Applicationsstandards
Transport Layer 10
Bordure du réseau : services
2 types de services de transport fournis par Internet (et, plus généralement, les réseaux TCP/IP) :
Service orienté connexion
Service sans connexion
Lors de la création d'une application Internet, le développeur doit choisir l'un de ces services.
Transport Layer 11
Bordure du réseau : service en mode connecté
Objectif : Transfert de données entre terminaux
Handshake : établissement de la connexion avant le transfert de données Échange de messages de contrôle
• Comme dans les protocoles humains Pourquoi orienté connection ?
• Seuls les hôtes connaissent cette connexion, les routeurs l'ignorent
• Allocation des ressources et définition d’états dans les deux hôtes
TCP - Transmission Control Protocol Service en mode connecté sur Internet
Transport Layer 12
FlashbackProtocoles réseau : Relient des machines
Toutes les communications sur Internet sont gouvernées par des protocoles
Les machines qui communiquent doivent utiliser le même protocole
Connexion TCP req.
Connection TCPréponse.
<file>
Transport Layer 13
Bordure du réseau : service en mode connecté
Service TCP [RFC 793]
3-way handshake
Transfert de données fiable transmission de tous les flots d'octets sans erreur et dans
l’ordre acquittements et retransmissions
Contrôle de flot: L’émetteur ne submerge pas le récepteur : adaptation du
débit d'émission
Contrôle de congestion : Pour éviter de saturer les buffers des routeurs L’émetteur réduit son débit d’émission quand le réseau est
congestionné Alerte pour les hôtes : plus d'acquittement des données
Transport Layer 14
Bordure du réseau : service en mode connecté
Transport fiable, contrôle de flux et de congestion non obligatoires dans un service orienté connexion
Service orienté connexion : handshake TCP = service de transport en mode connecté d'Internet
• fournit des fonctionnalités supplémentaires
Au niveau de l'application :
Connaissance des services fournis
Aucune idée de la façon dont ce service est fourni• Architecture en couches
Transport Layer 15
Bordure du réseau : service en mode non connecté
Objectif : Transfert de données entre terminaux L’objectif ne change pas
Service en mode non connecté sur Internet = UDP - User Datagram Protocol [RFC 768]
Pas d'établissement de connexion• Données émises immédiatement
Transfert de données non fiable• Pas d'acquittement : on ignore si les paquets sont arrivés ou non
Pas de contrôle de flux• Pas de limitation du débit d'émission
Pas de contrôle de congestion• Pas de limitation du débit d'émission
Transport Layer 16
Bordure de réseau : service en mode non connecté
Applications utilisant TCP : HTTP (WWW) FTP (transfert de fichiers) Telnet (login distant) SMTP (email)
Applications utilisant UDP : Streaming d'audio et de vidéo Visioconférence Téléphonie sur Internet
Transport Layer 17
Rôle du transport
Transport Layer 18
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
Séparation des fonctions Contrôle -> hôte Acheminement -> routeur
Protocole IP
Hôte
Protocole IP
Hôte
Routeur
Bout en bout
Transport Layer 19
Services et protocoles de transport
Fournissent une 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 relies on, enhances,
network layer services
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport Layer 20
Principe du bout en bout
Service réseau Modes d’acheminement
• Circuit virtuel• Datagramme
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
Transport Layer 21
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 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 UDP : Vérification des erreurs
Transport Layer 22
Rôle du Transport Général
Communication inter-process Identification des points d‘extrémités Bout en bout
A la demande de l'application 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 Mode connecté fiable, sur un réseau datagramme non
fiable Séparation du service fourni par l’opérateur et offert
à l’utilisateur
Transport Layer 23
Ports Pour identifier une cible plus spécifique que l’adresse IP car les
datagrammes sont destinés à des process et pas au système. 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)
Deux types de ports : well-known : appartiennent aux serveurs standards
• 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 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 24
applicationtransportnetwork
MP2
applicationtransportnetwork
Multiplexing/demultiplexing
Recall: segment - unit of data exchanged between transport layer entities aka TPDU: transport
protocol data unitreceiver
HtHn
Demultiplexing: delivering received segments to correct app layer processes
segment
segment Mapplicationtransportnetwork
P1M
M MP3 P4
segmentheader
application-layerdata
Transport Layer 25
Multiplexing/demultiplexing
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
gathering data from multiple app processes, enveloping data with header (later used for demultiplexing)
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Multiplexing:
Transport Layer 26
Multiplexing/demultiplexing: examples
host A server Bsource port: xdest. port: 23
source port:23dest. port: x
port use: simple telnet app
Web clienthost A
Webserver B
Web clienthost C
Source IP: CDest IP: B
source port: x
dest. port: 80
Source IP: CDest IP: B
source port: y
dest. port: 80
port use: Web server
Source IP: ADest IP: B
source port: x
dest. port: 80
Transport Layer 27
TSAP/NSAP
Host 1 Host 2
Application
Couche transport
Couche réseau
Couche liaison
Couche physique
Serveur
TSAP m
NSAP
La connexion transportcommence ici
La connexion réseaucommence ici
TSAP n
Transport Layer 28
Adressage TSAP 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
Validation
Transport Layer 29
Problèmes de transport
Etablissement de connexion Déséquencement
entité de transport A
entité de transport B TPDU
demande de connexion
TPDU confirmation de
connexion
TPDU de données
Entité de transport A
Entité de transport B
TPDU CR
TPDU CC
TPDU DT ou AK
TPDU DT
Etablissement en 3 étapes
Transport Layer 30
Three Way handshake
Etablissement d’une connexion bidirectionnelle avec des numéros de séquence indépendants
Utilisation d’un échange de 3 TPDU 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
Transport Layer 31
Problèmes de transport
Perte
Temporisateur de retransmission• Difficulté: dimensionnement
A B
CR
CC
T_CONNECT.requestT_CONNECT.indication
T_CONNECT.responseTemporisateur de retransmission
T1
CR
CCT_CONNECT.confirmation
Transport Layer 32
Problèmes de transport
Etablissement de connexion Survivance
Solutions • Limitation de la durée de vie des paquets
• numérotation étendue et valeur initiale
aléatoire
• Gel du numéro de port
A Bouverture d'une connexion
entre A et B
TPDU DT 0
TPDU AK 1
T1
TPDU DT 1
TPDU AK 2
fermeture de la connexion
établissement d'une nouvelle connexion
TPDU DT 1
La TPDU DT 1 est reçue sans erreur mais hors séquence Elle est gardée en attente de reséquencement D
up
licati
on
N
on
Dété
ctée
.
TPDU DT 0
TPDU AK 2TPDU DT 1
.
.
La seconde TPDU DT 1 est détectée comme dupliquée Elle est écartée mais acquittée
TPDU AK 2
La TPDU DT 0 ayant été reçue, l'acquittement peut se faire
Pert
e
Non
Dété
ctée
Transport Layer 33
Etablissement d’une connexion : bilan 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 34
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts 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 35
Go-Back-NSender: 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 36
GBN inaction
Transport Layer 37
Selective Repeat
receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order
delivery to upper layer
sender only resends pkts for which ACK not received sender timer for each unACKed pkt
sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts
Transport Layer 38
Selective repeat: sender, receiver windows
Transport Layer 39
Selective repeat
data from above : if next available seq # in
window, send pkt
timeout(n): resend pkt n, restart
timer
ACK(n) in [sendbase,sendbase+N]:
mark pkt n as received if n smallest unACKed
pkt, advance window base to next unACKed seq #
senderpkt n in [rcvbase, rcvbase+N-
1]
send ACK(n) out-of-order: buffer in-order: deliver (also
deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1]
ACK(n)
otherwise: ignore
receiver
Transport Layer 40
Selective repeat in action
Transport Layer 41
Selective repeat: dilemma
Example: 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 42
Protocoles de bout en bout : bilan Réseau “best effort” sous jacent
Perte de paquets Dé-séquencement Limite la taille des paquets Temps de transfert aléatoire
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
machine
Transport Layer 43
Problèmes de transport
Contrôle de flux Adaptatif: fenêtre à taille variable
Dissociation du rôle des ACK: Contrôle d’erreur Contrôle de flux
Numérotation séquentielle (modulo 27 ou 231)
CDT
A B
ACK2, CDT=3
DT2
DT3
DT4
ACK5, CDT=0
DT0
DT1
ACK5, CDT=1
DT5
• • •
Dernier octet acquité
Fenêtre
Limite supérieurede fenêtre
Transport Layer 44
Problèmes de transport
Libération Brutale
Ordonnée
Temporisateur d’effacement
effacement de connexion
DR
DC
AK
temporisateur de retransmission
effacement de connexion
utilisateur utilisateurfournisseur
T_DATA.ind
T_DISC.req
T_DISC.req
T_DATA.req
T_DATA.req
absence de T_DATA.ind après le T_DISC.req
Action synchronisée sur réseau non fiable
A B
DT3
AK6
DT8
AK10
DT4
CR5T_CLOSE.request
T_CLOSE.indicationFermeture effective de la demi-conexion
CR9T_CLOSE.request
T_CLOSE.indication
T_DATA.indication
T_DATA.request
Transport Layer 45
Terminaison de connexion
Symétrique Terminaison indépendante des deux
directions Fin de connexion lorsque chaque extrémité
à terminé Asymétrique
Fin de connexion dès qu’une des extrémités le demande
• Petres possibles car plus de données acceptées après le DR
Transport Layer 46
Automate d’état
IDLE
Passive establishmentpending
Active establishmentPending
Establishment
Connection requestTPDU received
Connection primitive executed
Connection accepted TPDU receivedConnection primitive executed
Passive disconnectpending
Active disconnectpending
IDLE
Disconnect primitive executedDisconnect requestTPDU received
Disconnect primitive executed Disconnection requestTPDU received
Transitions déclenchées par des primitives locales ou des arrivées de TPDU
Transport Layer 47
UDP
Transport Layer 48
UDP 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 Attention : pas de contrôle de congestion
Transport Layer 49
UDP: User Datagram Protocol [RFC 768]
“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
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
Transport Layer 50
Communication entre les couches
process 1 process nprocess 2
UDP : démultiplexage de ports
port x port y port z
IP
Transport Layer 51
Datagrammes UDP (1)
Port Source indique le numéro de
port du processus émetteur,
toute réponse y est dirigée.
Port Destinataire Longueur :
nombre d'octets dans le datagramme entier (avec en-tête).
>8
port source port destination
données
longueur checksum
32 bits
0 15 16 31
Transport Layer 52
Datagrammes UDP (2)
Contrôle d’erreur Optionnel en IPv4, obligatoire en IPv6 Pseudo-header + en-tête + données Pseudo-header:
• @ IP source• @ IP destination• protocole
port source port destination
données
longueur checksum
32 bits
0 15 16 31
Transport Layer 53
UDP checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
Receiver: compute checksum of
received segment check if computed checksum
equals checksum field value: NO - error detected YES - no error detected.
But maybe errors nonethless? More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Transport Layer 54
Applications d’UDP 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
Transport Layer 55
UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses (why?): DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific
error recover!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
Transport Layer 56
TCP
Transport Layer 57
TCP RFC 793 - Transmission Control Protocol 90% du trafic Principes
Bonne utilisation des ressources du réseau Couche de transport des systèmes d’extrémités (i.e. utilisateurs des données)
• Communication bidirectionnelle et point à point sur des réseaux hétérogènes Transfert fiable de données ( UDP)
• 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:
• application écrit des octets• TCP émet des segments• application lit des octets
Récepteur le plus simple possible -> complexité chez l’émetteur• interopérabilité maximum recherchée
Utilisé parTELNET, FTP, HTTP …
Transport Layer 58
Caractéristiques de TCP
Flot d’octets Séquencés Segmentation des
données au niveau TCP Circuit virtuel en mode
connecté La connexion est établie
et considérée comme un circuit physique
fiabilité Transfert bufferisé
Attendre d’avoir assez de données pour émettre (performance)
Full duplex Pour les ACKs
Application process
Octets écrits
TCPBuffer émission
Segment Segment Segment
TSegments transmis
Application process
Octetslus
TCPBuffer réception
…
… …
Transport Layer 59
Caractéristiques de TCP
Numéros de séquence indépendants dans les 2 directions 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 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 • Les deux numéros sont présents dans les mêmes
paquets
Transport Layer 60
Caractéristiques de TCP 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• Go back N
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
Transport Layer 61
Caractéristiques de TCP
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.
Transport Layer 62
Segments
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
Application
TCP
IP
Buffer d’émission
TCPheader
IPheader
Transport Layer 63
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>.
Transport Layer 64
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
Transport Layer 65
Communication entre applications
process 1
TCP
port x
IP
Hôte 1
TCP
port y
IP
Hôte 2
connexion
socket
Adresse IP
connexion TCP fiable
paquets IP non fiable
process 2
TCP headerport:x Données
Données
Transport Layer 66
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
Transport Layer 67
Vie d’une Connexion
Si deux processus désirent communiquer, établissement d’une connexion TCP
Internet => best effort 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
Transport Layer 68
Établissement d’une connexion Appel OPEN passif (serveur)/actif (client) Fermeture d’une connexion avec le bit FIN
(à faire dans les deux sens)
Process 1 Process 2Passive open
attend une requête active
Active OPENSend SYN, seq=n Receive SYN
Send SYN, seq=m, ACK=n+1
Receive SYN+ACK
Send ACK=m+1
Transport Layer 69
Connexion TCP
Trois phases Etablissement de la connexion Transfert des informations avec
• Contrôle de flux • Contrôle de congestion
Libération de la connexion
Transport Layer 70
Etablissement de la connexion TCP 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
Transport Layer 71
Exemple
SYN , seq= x
ACK, seq= x+1, Acknb= y+1
SYN + ACK, seq= y, Acknb= x+1
attente demande d’ouverture…
envoi demande d’ouverture
ouverture à trois phases (‘three-way handshake’)
échange d’options : - MSS (max segment size) - numéros de séq. initiaux - extensions...
<Transfert de données>
FIN, seq=i
seq=i+1, ACKnb= j+1
seq=j, ACKnb= i+1
FIN, seq= j, ACKnb=i+1
application effectue close()
envoi EOF à l’application
application effectue close()
Attente de 2*MSL
ouverture passive ouverture active
Transport Layer 72
Libération de la connexion
Normale Fin demandée par l’une des extrémités (flag
FIN=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
Transport Layer 73
Automate TCPCLOSED
LISTEN
Listen/-Close/-
RST/-
SYN/SYN+ACK Simultaneous open
ESTABLISHEDACK/- SYN+ACK/ACK
CLOSE/FIN
CLOSE/FIN
FIN WAIT 1
FIN WAIT 2
CLOSING
TIME WAIT
ACTIVE CLOSE
FIN/ACK
FIN+ACK/ACKACK/-
FIN/ACK
ACK/-
CLOSE WAIT
LAST ACK
PASSIVE CLOSE
CLOSE/FIN
FIN/ACK
SYN RCVD SYN SENT
Connect/SYN
Close/-
Send/SYN
SYN/SYN+ACK
ACK/-CLOSED
Timeout/-
Transport Layer 74
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)
Acknowledgement + Advertised Window
Sender Receiver
Transport Layer 75
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
Lancer nam ici
Data
récepteurémetteur
DataEnvoi du paquet 1
RéceptionACK
Envoi paquet 2
ACK
Réception paquet 1Envoi ACK 1
Transport Layer 76
Contrôle de flux TCP
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
Transmis et acquittéTransmis
non acquittéNon transmis Non transmissible
Fenêtre annoncée
Transport Layer 77
Fenêtre d’émission
F=min (cwnd, W) Cwnd est une variable maintenue par la
source• Tient compte de la congestion du réseau
W : fixé par la destination, champ fenêtre annoncé
• Tient compte de la capacité du récepteur
Transport Layer 78
Fenêtres
But : optimiser les ressources 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
émetteur récepteur
DATA 6
DATA 1DATA 2DATA 3DATA 4DATA 5
1 98765432
fenêtreglissante
ACK2
Transport Layer 79
Silly window syndrome
L’émetteur a beaucoup de données à transmettre
Petite fenêtre annoncée => émission de petits segments
Solution pour le récepteur 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
Transport Layer 80
Fiabilité avec Go-back-N
Fenêtre d’anticipation Détection d’erreurs par l’émetteur Retransmission continue (go-back-n) ou
sélective (stockage en désordre)A B
ACK2
DT2
DT3
DT4
ACK3
DT0
DT1
DT3
• • •
Transport Layer 81
La reprise sur erreurs
Exemples Paquet 2 perdu:
• 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
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
émetteur récepteur
DATA 1DATA 2DATA 3DATA 4DATA 5
ACK2ACK2ACK2ACK2
T
DATA 2
ACK6
émetteur
récepteur
DATA 1DATA 2DATA 3DATA 4DATA 5
ACK2ACK3
ACK4
Transport Layer 82
Sender Receiver
Segment 1 (seq. 1000)Receives 1000, send ACK 1500
Segment 2 (seq. 1500)
Segment 3 (seq. 2000)
Receives ACK 1500Slide the window
Segment 4 (seq. 2500)
Waiting for ACK
Receive ACK 1500which does not slide the window
Timeout -> retransmissionOf segment 2
Receives one of the frames and replies with ACK 1500
Exemple de reprise sur erreurs
Transport Layer 83
TCP: retransmission scenarios
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
time lost ACK scenario
Host B
X
Seq=92, 8 bytes data
ACK=100
Host A
Seq=100, 20 bytes data
ACK=100
Seq=
92
tim
eout
time premature timeout,cumulative ACKs
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
10
0 t
imeou
t
ACK=120
Transport Layer 84
TCP ACK generation [RFC 1122, RFC 2581]
Event
in-order segment arrival, no gaps,everything else already ACKed
in-order segment arrival, no gaps,one delayed ACK pending
out-of-order segment arrivalhigher-than-expect seq. #gap detected
arrival of segment that partially or completely fills gap
TCP Receiver action
delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK
immediately send singlecumulative ACK
send duplicate ACK, indicating seq. #of next expected byte
immediate ACK if segment startsat lower end of gap
Transport Layer 85
Conséquences de ces mécanismes Fiabilité des transmissions Bonne utilisation de la bande passante Contrôle de flux orienté récepteur : la
taille de la fenêtre varie au cours de la connexion
Transport Layer 86
Temporisateurs de TCP
Temporisateur de retransmission Temporisateur de peristence
Pour débloquer la situation après une fenêtre d’émission réduite à zéro et une ouverture perdue
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 87
TCP et Long Fat Networks
Performance maximum si l’émetteur toujours en activité
Eviter l’épuisement de la numérotation en séquence• durée de rebouclage > MSL• Seq number: 32 bits
Eviter la fermeture de la fenêtre• 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
Cas des Long Fat Networks:
Extension TCP pour les LFNs (RFC1323) facteur d’échelle sur la fenêtre d’émission ajout d’une estampille temporelle sur 32 bits
nature du réseau bande passante RTT type bande passante * RTT
Ethernet 10 Mbps 3 ms 3,7 ko
Canal T1 satellite 1,54 Mbps 500 ms 95 ko
Gigabit transcontinental 1 Gbps 60 ms 7,5 Mo
Transport Layer 88
Ajustement des timeouts :Contrôle d’erreur Délais variables sur Internet
Distance Temps de traversée du réseau (charge,
saturation des liens …) Le timeout est calculé en fonction de
l’estimation du RTT (Round Trip Time) Log du moment où un paquet est envoyé
et quand il est acquitté Moyenne pondérée des RTT mesurés Permet de trouver une valeur de timeout
pour le segment suivant
Transport Layer 89
Ajustement des timeouts:Contrôle d’erreur Temporisateur de retransmission adaptatif
Mesure de RTT et en déduire une estimation
Mesure du RTT Cas d’erreurs
Actions:• pas de mesure de RTT quand il y a eu une retransmission • Doublement de la valeur du temporisateur après chaque retransmission
AlgorithmeErr = SampleRTT - EstRTTEstRTT = EstRTT + ( x Err)Var = Var + (|Err| - Var)
Prise en compte de la varianceTemporisateur = x EstRTT + x VarOù = 1 et = 4
récepteurémetteur
ACK
retransmission
RTT
mes
uré
récepteurémetteur
ACK
retransmission
RTT
mes
uré
Transport Layer 90
TCP Round Trip Time and TimeoutQ: how to set TCP
timeout value? longer than RTT
note: RTT will vary too short: premature
timeout unnecessary
retransmissions too long: slow
reaction to segment loss
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
Transport Layer 91
TCP Round Trip Time and TimeoutEstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
Exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.1
Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
Transport Layer 92
TCP congestion control:
two “phases” slow start congestion avoidance
important variables: Congwin threshold: defines
threshold between two slow start phase, congestion control phase
“probing” for usable bandwidth: 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
Transport Layer 93
Congestion Goulot d'étranglement
Contrôle de congestion
Réponses:- niveau réseau: gestion des ressources- niveau transport: adaptation du débit
tem
ps d
e tr
ansf
ert
trafic offert
Routeur
Réseau 1
Réseau 3
Réseau 2
routeur
Datagrammes en attente de relayage
• Effondrement des performances
Transport Layer 94
Causes/costs of congestion: scenario 1
two senders, two receivers
one router, infinite buffers
no retransmission
large delays when congested
maximum achievable throughput
Transport Layer 95
Causes/costs of congestion: scenario 2
one router, finite buffers sender retransmission of lost packet
Transport Layer 96
Causes/costs of congestion: scenario 2 always: (goodput)
“perfect” retransmission only when loss:
retransmission of delayed (not lost) packet makes
larger (than perfect case) for same
in
out
=
in
out
>
in
out
“costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt
Transport Layer 97
Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit
in
Q: what happens as and increase ?
in
Transport Layer 98
Causes/costs of congestion: scenario 3
Another “cost” of congestion: when packet dropped, any “upstream transmission capacity
used for that packet was wasted!
Transport Layer 99
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
Network-assisted congestion control:
routers provide feedback to end systems single bit indicating
congestion (SNA, DECbit, TCP/IP ECN, ATM)
explicit rate sender should send at
Two broad approaches towards congestion control:
Transport Layer 100
Contrôle de congestion TCP
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
Transport Layer 101
Contrôle de 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: 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)
Source Destination
É
Transport Layer 102
Algorithmes de contrôle de congestion et gestion des fenêtres Slow Start Multiplicative decrease Fast recovery RED Delayed ACK etc.
Transport Layer 103
Slow Start
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
Lancer nam ici
Transport Layer 104
Congestion avoidance
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
Transport Layer 105
Congestion avoidance 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
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 106
TCP et grands RTTs
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
Transport Layer 107
Fast recovery
Empêche le slow start après la congestion
Slow start utilisé en cas de perte de paquets (expiration de timer)
Transport Layer 108
Fast retransmit
Modification de congestion avoidance
3 DUPACKs -> paquet supposé perdu et donc retransmission
Après la transmission, tout continue normalement (on attend pas d’ACK)
Si 3 DUPACKs 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
Lancer nam ici
récepteurémetteur
P1
P2
P3
P4
P5
P6
Retransmission P3
A2
A3
A3
A3
A3
Ack dupliqué
Transport Layer 109
RED (Random Early Detection) Dans les routeurs 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 110
Delayed ACKs
Possibilité d’acquitter plusieurs paquets d’un coup
Lancer nam ici
Transport Layer 111
Contrôle de congestion
Evolution de cwnd
temps
2
4
6
8
10
12
14
1618
20
0
perte de segment
croissanceexponentielle
croissance linéaire
réduction fenêtre à 1 segment
réduction de moitié du seuil
segment
Transport Layer 112
TCP Congestion Avoidance
/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++ }threshold = Congwin/2Congwin = 1perform slowstart
Congestion avoidance
1
1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs
Transport Layer 113
Segment TCP Port source (16 bits) : le numéro de port de la source. Port Destination (16 bits) : Le numéro de port du destinataire. Numéro de séquence (32 bits) : Le numéro du premier octet de
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é.
source port number destination port number
sequence numberacknowledgement number
window size
urgent pointer
options
data (optionel)
checksum
4 bits header length
6 bits reserved
SYN
URG
PSH
RST
ACK
F I N
32 bits
0 15 16 31
Transport Layer 114
Segment TCP
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 dans l'accusé de réception que le récepteur est capable de recevoir.
source port number destination port number
sequence numberacknowledgement number
window size
urgent pointer
options
data (optionel)
checksum
4 bits header length
6 bits reserved
SYN
URG
PSH
RST
ACK
F I N
32 bits
0 15 16 31
Transport Layer 115
Segment TCP
En-tête de 20 octets (+ options) = IP Zéro ou plus octets de données 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 116
Versions de TCP 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
Transport Layer 117
TCP FairnessFairness goal: if N TCP
sessions share same bottleneck link, each should get 1/N of link capacity
TCP congestion avoidance:
AIMD: additive increase, multiplicative decrease increase window by
1 per RTT decrease window
by factor of 2 on loss event
AIMD
TCP connection 1
bottleneckrouter
capacity R
TCP connection 2
Transport Layer 118
Why is TCP fair?
Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally
R
R
equal bandwidth share
Connection 1 throughputConnect
ion 2
th
roughput
congestion avoidance: additive increaseloss: decrease window by factor of 2
congestion avoidance: additive increaseloss: decrease window by factor of 2
Transport Layer 119
TCP latency modeling
Q: How long does it take to receive an object from a Web server after sending a request?
TCP connection establishment
data transfer delay
Notation, assumptions: Assume one link between
client and server of rate R
Assume: fixed congestion window, W segments
S: MSS (bits) O: object size (bits) no retransmissions (no
loss, no corruption)Two cases to consider: WS/R > RTT + S/R: ACK for first segment in
window returns before window’s worth of data sent
WS/R < RTT + S/R: wait for ACK after sending window’s worth of data sent
Transport Layer 120
TCP latency Modeling
Case 1: latency = 2RTT + O/R Case 2: latency = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]
K:= O/WS
Transport Layer 121
TCP Latency Modeling: Slow Start
Now suppose window grows according to slow start. Will show that the latency of one object of size O is:
R
S
R
SRTTP
R
ORTTLatency P )12(2
where P is the number of times TCP stalls at server:
}1,{min KQP
- 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.
Transport Layer 122
TCP Latency Modeling: Slow Start (cont.)
RTT
initia te TCPconnection
requestobject
first w indow= S /R
second w indow= 2S /R
third w indow= 4S /R
fourth w indow= 8S /R
com pletetransm issionobject
delivered
tim e atc lient
tim e atserver
Example:
O/S = 15 segments
K = 4 windows
Q = 2
P = min{K-1,Q} = 2
Server stalls P=2 times.
Transport Layer 123
TCP Latency Modeling: Slow Start (cont.)
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
stallTimeRTTR
O
P
kP
k
P
pp
)12(][2
]2[2
2latency
1
1
1
windowth after the timestall 2 1 kR
SRTT
R
S k
ementacknowledg receivesserver until
segment send tostartsserver whenfrom time RTTR
S
window kth the transmit totime2 1
R
Sk
RTT
initia te TCPconnection
requestobject
first w indow= S /R
second w indow= 2S /R
third w indow= 4S /R
fourth w indow= 8S /R
com pletetransm issionobject
delivered
tim e atc lient
tim e atserver
Transport Layer 124
Conclusion et synthèse Protocoles de transport => de bout-en-bout
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 : On quitte la bordure du réseau (couches application et
transport)... ... pour entrer au coeur du réseau.
Transport Layer 125
Chapter 3: Summary
principles behind transport layer services:
instantiation and implementation in the Internet UDP TCP