Cours 2

R eseaux - Cours 2
UDP et TCP : Protocoles de Transport de TCP/IP
Cyril Pain-Barre
IUT Informatique Aix-en-Provence
Semestre 2 - version du 22/3/2011
1/67
Cyril Pain-Barre
Transport UDP et TCP
1/90
Services et Limitations dIP

Services dIP :
interconnexion de r eseaux remise de datagrammes ` a des h otes (adresses IP) adaptation aux MTU des r eseaux dur ee de vie limit ee des datagrammes d etection des erreurs sur len-t ete signalisation de certaines erreurs via ICMP
Limitations dIP :
pas dadressage des applications (client/serveur Web, client/serveur FTP, etc.) livraison des datagrammes non garantie duplication possible des datagrammes ! d es equencement possible des datagrammes erreurs possibles sur les donn ees pas de contr ole de ux
2/67
Cyril Pain-Barre
2/90
R ole du Transport
Aller au-del` a des limites dIP Assurer, si possible, la correction derreurs :

signal ees par ICMP non signal ees
2 protocoles de transport disponibles dans TCP/IP :

UDP : transport rapide, non connect e, permettant la multi-diusion TCP : transport able en mode connect e point-` a-point
distinguent les applications au sein dun m eme h ote garantissent lind ependance des communications
3/67
Cyril Pain-Barre
3/90
Adressage des applications

Plusieurs applications r eseaux peuvent sex ecuter en parall` ele sur un ordinateur Probl` eme : comment un emetteur peut-il pr eciser ` a quelle application est adress e un message ? La solution retenue sur Internet est lutilisation de destinations abstraites : les ports (ne pas confondre avec les ports physiques des hubs/switchs)
entiers positifs sur 16 bits UDP et TCP fournissent chacun un ensemble de ports ind ependants : le port n de UDP est ind ependant du port n de TCP le syst` eme permet aux applications de se voir aecter un port UDP et/ou TCP (choisi ou de mani` ere arbitraire) certains num eros de port sont r eserv es et correspondent ` a des services particuliers
Ladresse dune application Internet est le triplet : (adresse IP, protocole de transport, num ero de port)
4/67
Cyril Pain-Barre
4/90
D emultiplexage des ports
applications UDP DHCP (serveur) 67
applications UDP/TCP
applications TCP
TFTP
...
53
DNS
...
53
FTP
SMTP
HTTP
...
69
selon Port
21
25
80
UDP
TCP
17
selon champ Protocole
IP
5/67
Cyril Pain-Barre
5/90
Le protocole UDP : User Datagram Protocol

(RFC 768)
6/67
Cyril Pain-Barre
6/90
Services dUDP
Utilise IP pour acheminer les messages dun ordinateur ` a un autre. Service rendu :
adressage des applications par num ero de port multiplexage/d emultiplexage par num eros de port contr ole facultatif de lint egrit e des donn ees
M eme type de service non able, non connect e que IP :

possibilit e de perte, duplication, d es equencement de messages pas de r egulation de ux
Un programme utilisant UDP doit g erer lui-m eme ces probl` emes !
7/67
Cyril Pain-Barre
7/90
Format des datagrammes UDP
En-t ete : pas doption possible, nombre xe doctets = 8 Donn ees : nombre variable doctets ( 65 535)
bits : 0 1 1 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 entte
Port UDP Source Longueur Totale
Port UDP Destination Checksum
taille variable
Donnes
8/67
Cyril Pain-Barre
8/90
Champs UDP : ports source et destination

Port UDP Source : indique le num ero de port de l emetteur. Peut etre ` a 0 si aucune r eponse nest attendue. Port UDP Destination : num ero de port du destinataire. Si ce port na et e allou e` a aucun processus, UDP renverra un message ICMP de destination inaccessible car port non allou e (type 3, code 3) et d etruit le datagramme D emultiplexage UDP selon le port destination :
Appli 1 port x Appli 2 port y Appli 3 port z
UDP selon champ Protocole (17) IP

9/67
Cyril Pain-Barre
9/90
Serveurs et ports r eserv es UDP

Voir http://www.iana.org/assignments/port-numbers Well known Port Assignment : certaines applications bien connues ont des ports UDP r eserv es [0, 1023] Exemples : Num (d ecimal) Application 7 Serveur echo 13 Serveur daytime 19 Serveur chargen 53 Serveur DNS 67 Serveur BOOTP/DHCP 68 Client BOOTP/DHCP 69 Serveur TFTP 123 Serveur NTP les ports [1024, 49151] sont enregistr es (mais peuvent etre utilis es) les ports [49152, 65535] sont dits dynamiques et/ou ` a usage priv e
Cyril Pain-Barre Transport UDP et TCP
10/67
10/90
Champs UDP : Checksum

Facultatif : tout ` a 0 si non calcul e V erie la totalit e du datagramme + Pseudo en-t ete UDP. Permet de sassurer :
que les donn ees sont correctes que les ports sont corrects que les adresses IP sont correctes
M eme calcul que IP sur tout le datagramme UDP (bourrage eventuel 1 octet ` a 0) + pseudo en-t ete UDP Pseudo en-t ete UDP (interaction avec IP) : (12 octets)
bits : 0 1 1 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Adresse IP Source Adresse IP Destination Zone Zro Protocole

17 (en dcimal) pour IP
11/67
Longueur Datagramme UDP
Cyril Pain-Barre
11/90
Interface socket BSD (Unix) pour UDP

int socket(int domain, int type, int protocol) : retourne un Service Access Point (SAP) aupr` es dUDP, utilis e en premier param` etre des primitives ci-apr` es int bind(int sock, const struct sockaddr *addr, socklen t addrlen) associe au SAP ladresse dapplication addr ssize t sendto(int sock, const void *buf, size t len, int ags, const struct sockaddr *to, socklen t tolen) demande lenvoi de len octets contenus dans buf, ` a ladresse to ssize t recvfrom(int sock, void *buf, size t len, int ags, struct sockaddr *from, socklen t *fromlen) re coit dans buf un message dau plus len octets ; ladresse de l emetteur est plac ee dans from int close(int sock) : lib` ere le SAP
12/67
Cyril Pain-Barre
12/90
Mod` ele Client/Serveur utilisant UDP

Le serveur est d emarr e sur un ordinateur en ecoute sur un port. Son adresse est le triplet : (adresse IP, UDP, port) L ecoute consiste ` a attendre quun message parvienne ` a ce port ; les clients devront conna tre le port du serveur (int er et des ports r eserv es) Le client envoie une requ ete au serveur (` a son adresse) :
pour recevoir une r eponse du serveur, il doit avoir acquis un num ero de port UDP. Le plus souvent, ce port est quelconque. Rares sont les clients (comme BOOTP/DHCP) qui n ecessitent un port pr ecis. la requ ete est un message applicatif : suite doctets constituant un PDU (Protocol Data Unit) du protocole quimpl ementent le client et le serveur. UDP fabrique un datagramme UDP avec pour champ Donn ees ce message, et pour champ Port Destination celui du serveur. Le Port Source est celui du client. Le datagramme UDP est ensuite envoy e via un datagramme IP avec les adresses IP du serveur (destination) et du client (source).
Le serveur re co t le message du client, ainsi que son adresse. Il peut alors traiter le message et r epondre au client. Selon le protocole, la discussion peut se poursuivre, ou sarr eter l` a.
13/67
13/90
Files dattente et r eception
Attribution de port allocation le dattente R eception dun datagramme :

port destination non attribu e : destruction + message ICMP port allou e : si le non pleine, ajout e dans la le, sinon d etruit (pas de message ICMP !)
Appli consomme les el ements de la le, par acc` es synchrone :

si aucun datagramme, processus plac e en attente sinon, consommation du premier datagramme (FIFO)
Une application peut demander plusieurs ports
14/67
Cyril Pain-Barre
14/90
Utilisation UDP : mod` ele requ ete/r eponse

Soit AppliB qui utilise 2 ports :
si re coit datagramme sur port x, renvoie les donn ees en majuscules si re coit datagramme sur port y, renvoie les donn ees ` a lenvers
pour ce genre de service, AppliB peut traiter les datagrammes au f ur et ` a mesure

A1 A2 AppliB C1
x UDP Hte A UDP Hte B
y UDP Hte C
15/67
Cyril Pain-Barre
15/90
Utilisation UDP : suivi de la discussion

Si la discussion est longue et complexe, il est plus simple de d el eguer Exemple : serveur TFTP
re coit un premier datagramme dun client sur le port 69 demande un nouveau port cr ee un ls pour traiter ce client sur ce nouveau port renvoie un datagramme au client indiquant sur quel port poursuivre la discussion (transfert de chier) retourne ` a l ecoute de larriv ee de nouveaux clients la discussion se poursuit entre le client et le ls TFTP d edi e
Client TFTP Fils TFTP Serveur TFTP Fils TFTP Client TFTP
x UDP Hte A
69 UDP Hte B
y UDP Hte C
16/67
Cyril Pain-Barre
16/90
Utilisation UDP : multidiusion

UDP ore un service en mode non connect e Une application peut ainsi exploiter la multidiusion IP et emettre un seul datagramme qui sera re cu par un ensemble de stations, en utilisant comme destination, une adresse :
broadcast : diusion ` a toutes les stations dun r eseau, ou du r eseau local pour ladresse de diusion limit ee (255.255.255.255) multicast : adresses de classe D pour diuser ` a un ensemble de stations se trouvant eventuellement sur des r eseaux di erents (les routeurs qui les s eparent doivent etre congur es pour cela). Utilis ees notamment pour la diusion de m edias audio/vid eo.
Exemple Envoi par un client DHCP dun message ` a tous les serveurs DHCP du r eseau local. Ladresse destination du message DHCP est (255.255.255.255, UDP, 67)
17/67
Cyril Pain-Barre
17/90
Mise en uvre du transfert able
18/67
Cyril Pain-Barre
18/90
Transfert able en mode connect e
Bien souvent les applications ont besoin d echanger de gros volumes de donn ees de mani` ere able Exemples : FTP, SMTP, HTTP, . . . Il est toujours possible dorir ce service en sappuyant sur un service non able non connect e comme IP ou UDP Pour cela, on a besoin de quelques el ements essentiels :
les accus es de r eception (ACK) des temporisateurs : alarmes qui expirent (timeout) la num erotation des paquets (ou donn ees)
19/67
Cyril Pain-Barre
19/90
Accus es de r eception (ACK)

L emetteur dun paquet attend une conrmation de r eception de la part du r ecepteur avant denvoyer un autre paquet Le r ecepteur accuse r eception dun paquet en envoyant un ACK
metteur
mission paquet 1 rception paquet 1 envoi dun ACK rception ACK mission paquet 2
Rseau
Rcepteur
Protocole de type envoyer et attendre

20/67
Cyril Pain-Barre
20/90
Temporisateurs
Des paquets peuvent etre perdus dans le r eseau Si paquet perdu , pas dACK donc blocage Utilisation dun timer arm e lors de l emission du paquet :
si expire, renvoie le paquet si r eception ACK avant expiration, d esactivation du timer
metteur
mission paquet 1 + armement timer
Rseau
Rcepteur
timeout mission paquet 1
envoi de lACK
21/67
Cyril Pain-Barre
21/90
Temporisateurs : probl` eme de r eglage

Sc enario du timer trop court et mise en cause abilit e:
metteur
mission paquet 1 + armement timer envoi de lACK
Rseau
Rcepteur
timeout mission paquet 1 mission paquet 2
envoi de lACK
mission paquet 3
Le paquet 1 est accept e deux fois par le r ecepteur ! Le deuxi` eme ACK est pris pour celui du paquet 2 ! Mais si timer trop long, on perd en ecacit e. . .
22/67
22/90
ACK : probl` eme de lACK perdu

Sc enario de lACK perdu et mise en cause abilit e:
metteur
mission paquet 1 + armement timer envoi de lACK
Rseau
Rcepteur
timeout mission paquet 1
envoi de lACK
mission paquet 2
Le paquet 1 est accept e 2 fois par le r ecepteur !

23/67
Cyril Pain-Barre
23/90
Num erotation des paquets et des ACK

Les paquets et les ACK portent des num eros : r esoud les probl` emes dACK perdu et dalarme trop courte.
metteur
mission paquet 1 + armement timer envoi de lACK n1 (paquet 2 attendu)
Rseau
Rcepteur
timeout mission paquet 1 ignore paquet 1 envoi de lACK n1
mission paquet 2
24/67
Cyril Pain-Barre
24/90
Num erotation des paquets et des ACK

Les paquets et les ACK portent des num eros : r esoud les probl` emes dACK perdu et dalarme trop courte.
metteur
mission paquet 1 + armement timer envoi de lACK n1 (paquet 2 attendu)
Rseau
Rcepteur
timeout mission paquet 1 mission paquet 2
ignore paquet 1 envoi de lACK n1 accepte paquet 2 envoi de lACK n2
ACK n1 ignor timeout mission paquet 2
24/67
Cyril Pain-Barre
25/90
Fen etre glissante (ou ` a anticipation)

Principe : emettre n paquets sans attendre dACK (n est la taille de la fen etre)
fentre initiale (taille 8)
1 2 3 envoys 4 5 6 7 8 9 10 11
...
envoi autoris
envoi interdit
un temporisateur par paquet emis la r eception du ACK du premier paquet de la fen etre la fait glisser :
la fentre a gliss
1 acquitts 2 3 4 5 6 7 8 9 10 11
...
envoys
envoi autoris
envoi interdit
25/67
Cyril Pain-Barre
26/90
Ecacit e de la fen etre glissante

La fen etre glissante permet dexploiter au mieux le r eseau :
metteur
mission paquet 1 mission paquet 2 mission paquet 3 mission paquet 4 mission paquet 5 mission paquet 6 mission paquet 7 mission paquet 8 mission paquet 9 envoi de lACK n1 envoi de lACK n2 envoi de lACK n3 envoi de lACK n4 envoi de lACK n5 envoi de lACK n6 envoi de lACK n7
Rseau
Rcepteur
26/67
Cyril Pain-Barre
27/90
Fen etre glissante et gestion des acquittements
Si un paquet de donn ees est perdu, deux possibilit es : rejet total (ou global) rejet s electif
27/67
Cyril Pain-Barre
28/90

Rejet total : aucun paquet suivant celui perdu nest acquitt e
metteur
mission paquet 1 mission paquet 2 mission paquet 3 mission paquet 4 mission paquet 5 mission paquet 6 mission paquet 7 mission paquet 8 mission paquet 9 timeout, rmission paquet 4 rmission paquet 5 accept : envoi de lACK n1 accept : envoi de lACK n2 accept : envoi de lACK n3
Rseau
Rcepteur
rejet : envoi de lACK n3 rejet : envoi de lACK n3 rejet : envoi de lACK n3 rejet : envoi de lACK n3
la fen etre en r eception a une taille de 1

28/67
29/90

Rejet s electif : paquet de donn ees i perdu la fen etre en r eception a une certaine taille m (de pr ef erence m = n) ceux qui entrent dans la fen etre sont gard es, les autres sont ignor es mais les ACK pour ces paquets ont pour num ero i 1 si timeout, l emetteur nenvoie que le premier paquet non acquitt e lorsque paquet i r e emis et re cu, lACK renvoy e est celui du dernier paquet re cu (ou celui avant un autre paquet eventuellement perdu)
Fentre dmission (taille 15) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
...
Fentre de rception (taille 10) :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
...
29/67
Cyril Pain-Barre
30/90
Rejet s electif : exemple
metteur
mission paquet 1 mission paquet 2 mission paquet 3 mission paquet 4 mission paquet 5 mission paquet 6 mission paquet 7 mission paquet 8 mission paquet 9 mission paquet 10 mission paquet 11 mission paquet 12 rmission paquet 2 mission paquet 13 mission paquet 14 mission paquet 15 mission paquet 16
Rseau
Rcepteur
accept : envoi de lACK n1
gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 rejet : envoi de lACK n1 accept : envoi de lACK n11 gard : envoi de lACK n11 gard : envoi de lACK n11
mission paquet 17
gard : envoi de lACK n11
30/67
Cyril Pain-Barre
31/90
Rejet s electif : am elioration par NACK

Envoi dun (seul) NACK si r ecepteur se rend compte dune erreur :
metteur
mission paquet 1 mission paquet 2 mission paquet 3 mission paquet 4 mission paquet 5 mission paquet 6 mission paquet 7 mission paquet 8 mission paquet 9 rmission paquet 2 mission paquet 10 mission paquet 11 mission paquet 12 mission paquet 13 mission paquet 14 mission paquet 15 mission paquet 16 mission paquet 17 gard : envoi de NACK n2 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n1 gard : envoi de lACK n9 gard : envoi de lACK n10 gard : envoi de lACK n11 gard : envoi de lACK n12 gard : envoi de lACK n13 gard : envoi de lACK n14 accept : envoi de lACK n1
Rseau
Rcepteur
31/67
Cyril Pain-Barre
32/90
Transmission bidirectionnelle et superposition
Pour une transmission bidirectionnelle : equiper les deux c ot es de fen etres d emission et de r eception pas forc ement de m eme taille de chaque c ot e! am elioration par superposition ou piggybacking : les paquets de donn ees contiennent un indicateur ACK (oui ou non le paquet contient aussi un ACK) et un champ no ACK :
...
ACK Num ACK Num Paquet Donnes
32/67
Cyril Pain-Barre
33/90
Le protocole TCP : Transmission Control Protocol

(RFC 793 corrig ee par RFC 1122 et 1323)
33/67
Cyril Pain-Barre
34/90
Propri et es du service de TCP
Orient e connexion : transfert de ots doctets. La suite doctets remise au destinataire est la m eme que celle emise Circuits virtuels : une fois une connexion demand ee et accept ee, les applications la voient comme un circuit d edi e Transferts tamponn es : quelle que soit la taille des blocs de donn ees emis par les applications, TCP est libre de les d ecouper ou de les regrouper Connexions non structur ees : pas de fronti` ere plac ee par TCP entre les messages emis par les applications Connexions full-duplex : les donn ees s echangent dans les deux sens mais un sens de transmission peut etre lib er e par l emetteur
34/67
Cyril Pain-Barre
35/90
Adresse dapplication, port et connexion

Comme pour UDP, ladresse dune application est un triplet (adresse IP, TCP, port) : le serveur et le client doivent en poss eder une. Le port du client est g en eralement quelconque. Mais ` a la di erence dUDP, on ne peut envoyer un message directement ` a une adresse : il faut que le client etablisse une connexion avec le serveur. Ils ne peuvent echanger des messages que via une connexion Etablissement dune connexion :
Serveur : eectue une ouverture passive en ecoutant sur un port, cest ` a dire en demandant un port et en attendant quun client sy connecte Client : eectue une ouverture active en demandant l etablissement dune connexion entre son adresse et celle du serveur. Le serveur doit etre en ecoute. Les modules TCP du client et du serveur int eragissent pour etablir cette connexion.
Une fois la connexion etablie, le serveur et le client doivent lutiliser pour envoyer/recevoir des messages. TCP est charg e dassurer la abilit e de la connexion (notamment soccupe des acquittements/ retransmissions)
35/67
36/90
Serveurs et ports r eserv es TCP

Voir http://www.iana.org/assignments/port-numbers Well known Port Assignment : certaines applications bien connues ont des ports UDP r eserv es [0, 1023]. Exemples : Num (d ecimal) 7 13 20 21 22 23 25 53 80 119 Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur Application echo daytime FTP (donn ees) FTP (commandes) SSH TELNET SMTP (transfert de mail) DNS HTTP (www) NNTP (news)
les ports [1024, 49151] sont enregistr es (mais peuvent etre utilis es) les ports [49152, 65535] sont dits dynamiques et/ou ` a usage priv e
36/67
37/90
Interface socket BSD (Unix) pour TCP

socket() et bind() ont la m eme fonction que pour UDP int listen(int sock, int backlog) (serveur) pr epare le SAP pour une ouverture passive int accept(int sock, struct sockaddr *addr, socklen t *addrlen) (serveur) attend une demande de connexion (ouverture passive). Renvoie un SAP pour la connexion etablie et addr contient ladresse du client int connect(int sock, const struct sockaddr *addr, socklen t addrlen) (client) demande l etablissement dune connexion (ouverture active) au serveur dadresse addr ssize t send(int sock, const void *buf, size t len, int ags) envoie len octets contenus dans buf ` a travers la connexion sock ssize t recv(int sock, void *buf, size t len, int ags) re coit dans buf au plus len octets de la connexion sock int close(int sock) : lib` ere un SAP (socket d ecoute ou connexion)
37/67
38/90
Ports et connexions
Plus complexe quUDP car un port peut etre utilis e pour plusieurs connexions simultan ement :
un serveur peut accepter plusieurs clients ` a la fois : chaque appel daccept() retourne une nouvelle connexion utilisant le port du serveur plus rare, un client peut aussi utiliser son port pour etablir plusieurs connexions (mais pas vers la m eme adresse serveur)
En dehors des SAP douverture passive, TCP g` ere surtout des objets connexion Une connexion est identi ee par le quadruplet form e avec ladresse de ses deux extr emit es : (adresse IP locale, port local, adresse IP distante, port distant) Les connexions sont g er ees ind ependamment les unes des autres Chaque connexion dispose de ses propres tampons en emission/ r eception et de chaque c ot e
38/67
Cyril Pain-Barre
39/90
Ports et connexions : exemple

AppliB (serveur)
Interface TCP
TCP
Hte B (139.124.187.4)
39/67
Cyril Pain-Barre
40/90

AppliB (serveur)
socket
Ouverture passive socket() bind() listen() accept()
port 80
TCP
Hte B (139.124.187.4)
39/67
Cyril Pain-Barre
41/90

A1 (client) AppliB (serveur)
socket
Interface TCP
port 80
TCP
Hte A (32.128.54.97)
TCP
Hte B (139.124.187.4)
39/67
Cyril Pain-Barre
42/90

A1 Ouverture active socket() connect() (client) AppliB (serveur)
socket
Interface TCP
port 80
TCP
Hte A (32.128.54.97)
TCP
Hte B (139.124.187.4)
39/67
Cyril Pain-Barre
43/90

A1 Ouverture active socket() connect()
E
AppliB (serveur)
socket E connexion #1 R socket
(client)
socket R
Interface TCP
port 4321
port 80
TCP
Hte A (32.128.54.97)
TCP
Hte B (139.124.187.4) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321)
39/67
Cyril Pain-Barre
44/90

A1 (client)
socket E R connexion #1 socket E R
AppliB (serveur)
socket
Interface TCP
port 4321
port 80
TCP
Hte A (32.128.54.97)
TCP
39/67
Cyril Pain-Barre
45/90

A1 (client)
AppliB (serveur)
socket
C1 (client)
port 4321
port 80
TCP
Hte A (32.128.54.97)
TCP
TCP
Hte C (195.10.134.12)
39/67
Cyril Pain-Barre
46/90

A1 (client)
AppliB (serveur)
socket E socket R connexion #2 E
C1 (client)
socket R
port 4321
port 80
port 5678
TCP
Hte A (32.128.54.97)
TCP
Hte B (139.124.187.4) Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321) Connexion #2 : (139.124.187.4, 80) et (195.10.134.12, 5678)
TCP
Hte C (195.10.134.12)
39/67
Cyril Pain-Barre
47/90
Flots doctets et segments
pour TCP une connexion sert ` a transmettre des ots doctets dans les deux sens les ots sont transmis par des segments (PDU de TCP) un segment est transmis par un seul datagramme IP (sauf fragmentation pendant lacheminement) l emetteur transmet ` a TCP des blocs de donn ees de taille quelconque le r ecepteur r ecup` ere des blocs de donn ees de taille quelconque mais le nombre doctets transport es par un segment est d ecid e par TCP :
pour des raisons decacit e pour la r egulation de ux
40/67
Cyril Pain-Barre
48/90
Flots doctets et segments : exemple

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
49/90

AppliA donnes transmettre send()
socket E R socket E R socket
AppliB
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
50/90

AppliA AppliB
socket E placement dans le tampon dmission R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
51/90

AppliA autres donnes transmettre send()
AppliB
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
52/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
placement dans le tampon dmission
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
53/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
TCP dcide de transmettre un segment
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
54/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321 entte TCP
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
55/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
entte IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
56/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
traverse du rseau (fragmentation possible)
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
57/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
traverse du rseau (fragmentation possible)
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
58/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
59/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
placement dans le tampon de rception
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
60/90

AppliA AppliB
socket E R
socket E R
socket
connexion tablie
port 4321
TCP peut envoyer un ACK maintenant ou plus tard
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
61/90

AppliA AppliB
lecture des donnes recv()
socket E R
socket E R
socket
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
62/90

AppliA mise jour des tampons
AppliB
connexion tablie
port 4321
port 80
TCP
TCP
IP
IP
Hte A (32.128.54.97)
Hte B (139.124.187.4)
41/67
Cyril Pain-Barre
63/90
Num ero de s equence et fen etre glissante

Pour une transmission ecace, TCP utilise une fen etre glissante TCP nacquitte pas les segments mais les octets re cus Tous les octets de donn ees transmis portent un num ero : le num ero de s equence Les acquittements indiquent le num ero du prochain octet attendu La fen etre glissante ( emission) comporte alors 3 pointeurs :
Fentre dmission
...
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
...
octets transmis et acquits
octets transmis mais non encore acquitts
octets non encore transmis mais qui peuvent ltre
octets quon nest pas encore autoris transmettre
Chaque c ot e de la connexion poss` ede une fen etre d emission et une fen etre de r eception Les acquittements peuvent transiter avec les donn ees (superposition)
42/67
Cyril Pain-Barre
64/90
Taille de fen etre variable et contr ole de ux

La fen etre glissante na pas une taille xe Les segments (en particulier ACK) contiennent une information taille de fen etre :
A segment avec taille = x
... ... ... ... ... ... ...

fentre actuelle
A indique ` a B la place disponible dans son tampon de r eception
La r eaction de B d epend de la taille annonc ee :

augmentation : B augmente sa fen etre et envoie les octets suppl ementaires quelle comprend
... ... ... ... ... ... ...

fentre augmente
diminution : lors du glissement, B diminue sa fen etre (sans exclure les octets qui y etaient d ej` a)
... ... ... ... ... ... ...

fentre diminue
43/67
65/90
Format des segments TCP

Unit e de donn ees de protocole (PDU) echang ee pour etablir/lib erer une connexion et transf erer/acquitter des donn ees
bits : 0 1 1 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 partie fixe (20 octets)
Port TCP Source
Port TCP Destination
Numro de Squence Numro dAccus de Rception

LET Rserv Flags
entte
Fentre Pointeur Urgent
Checksum
taille variable
Options TCP (ventuelles)

Bourrage
taille variable
Donnes
44/67
Cyril Pain-Barre
66/90
Format des segments TCP

Unit e de donn ees de protocole (PDU) echang ee pour etablir/lib erer une connexion et transf erer/acquitter des donn ees
Port TCP Source

LET Rserv Flags
entte
Checksum U R G
taille variable
A P R S F C S S Y I Options TCP (ventuelles) K H T N N

Bourrage
6 bits
taille variable
Donnes
44/67
Cyril Pain-Barre
67/90
Segment TCP : champ Num ero de s equence

Port TCP Source

LET Rserv Flags
entte
Fentre
Checksum Indique le numro que porte Pointeur le premier Urgent
taille variable
octet de donnes
Bourrage premier octet
taille variable
Donnes
45/67
Cyril Pain-Barre
68/90
Segment TCP : champ LET

Port TCP Source
entte
Port TCP Destination multiplier par 4 pour Numro de Squence longueur de lentte ( cause des options) Numro dAccus de Rception
Flags
LET
Rserv
Checksum
taille variable

Bourrage
taille variable
Donnes
46/67
Cyril Pain-Barre
69/90
Segment TCP : champ Fen etre

Port TCP Source

LET Rserv Flags
entte
Checksum
taille variable

Bourrage
taille variable
indique la place disponible dans le tampon de rception

Donnes
47/67
Cyril Pain-Barre
70/90
Segment TCP : Checksum

Obligatoire V erie la totalit e du segment + Pseudo en-t ete TCP. Comme pour UDP, permet de sassurer :
que les donn ees sont correctes que les ports sont corrects que les adresses IP sont correctes
M eme calcul que IP/UDP (bourrage eventuel 1 octet ` a 0) + pseudo en-t ete TCP Pseudo en-t ete TCP (interaction avec IP) : (12 octets)
bits : 0 1 1 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Adresse IP Source Adresse IP Destination Zone Zro Protocole

6 (en dcimal) pour IP
48/67
Longueur Segment TCP
Cyril Pain-Barre
71/90
Segment TCP : option MSS

Utilis ee eventuellement pendant la phase de connexion (uniquement) Format (4 octets) :
8 bits 8 bits
Type (2)
Longueur Option (4) Valeur MSS
Chaque c ot e indique la taille max des donn ees des segments quil veut recevoir, appel ee MSS (Maximum Segment Size) :
souvent MTU - 40 (en-t etes IP et TCP sans option) d ependant de la taille des buers de reception par d efaut 536 (576 octets pour le datagramme IP)
Dicile ` a choisir pour lInternet :

si trop petit, perte decacit e si trop grand, risque de fragmentation
Lid eal est le plus grand tel quaucun datagramme nest fragment e
49/67
Cyril Pain-Barre
72/90
Donn ees Urgentes (Hors Bande)

Emetteur veut envoyer des donn ees en urgence, sans attendre que le r ecepteur ait lu les donn ees pr ec edentes Exemple : envoi de Ctrl-C pour arr eter le traitement de lapplication destinataire Le TCP emetteur place les donn ees urgentes et envoie imm ediatement le segment Le TCP r ecepteur interrompt lapplication destinataire (sous Unix, signal SIGURG) Mise en uvre par bit URG et Pointeur Urgent :
si bit URG = 1 : donn ees urgentes pr esentes et Pointeur Urgent indique leur n dans le segment (mais pas leur d ebut) si bit URG = 0 : pas de donn ees urgentes, Pointeur Urgent ignor e
flags (6 bits) 16 bits U R G A C K P S H R S T S Y N F I N
Pointeur Urgent
50/67
Cyril Pain-Barre
73/90
Remise forc ee
Application emettrice demande de ne pas retarder l emission des donn ees, plut ot que de tamponner Particuli` erement utile dans le cas dun terminal virtuel : apr` es le retour ` a la ligne, il faut envoyer, voire m eme pour chaque caract` ere tap e ou d eplacement de souris (X-Window) TCP emetteur place le bit PSH ` a1:
flags (6 bits) U R G A C K P S H R S T S Y N F I N
Le TCP r ecepteur doit remettre les donn ees au plus vite (ne pas tamponner dans sa m emoire)
51/67
Cyril Pain-Barre
74/90
Acquittements et Retransmissions
Le bit ACK ` a 1 indique que le champ Num ero dAccus e de R eception doit etre utilis e
flags (6 bits) 32 bits U R G A C K P S H R S T S Y N F I N
Numro dAccus de Rception
Un segment non acquitt e est retransmis apr` es timeout Un segment retransmis peut contenir plus de donn ees que le pr ec edent Num ero ACK nacquitte pas le segment : indique le num ero du prochain octet attendu LACK est cumulatif : a des avantages et des inconv enients Rejet global ou s electif (le plus courant) En pratique l emetteur ne renvoie que le premier segment non acquitt e
52/67
Cyril Pain-Barre
75/90
Etablissement dune connexion

U R G A C K P S H R S T S Y N F I N
En 3 temps, avec bits SYN et ACK

metteur mission SYN, sq=x Rseau Rcepteur
Rception SYN mission SYN sq=y, ACK x+1 Rception SYN, ACK mission ACK y+1 (connexion tablie) Rception ACK (connexion tablie)
Permet dignorer des demandes retard ees R esoud aussi les connexions simultan ees des deux c ot es Num ero de S equence choisi (presque) al eatoirement dans chaque sens
53/67
Cyril Pain-Barre
76/90
Lib eration dune connexion

Processus en trois temps modi e, avec bits FIN et ACK
Connexion lib er ee lorsque chaque c ot e a indiqu e quil navait plus de donn ees ` a emettre :
metteur mission FIN sq=x Rception FIN mission ACK x+1 Rception ACK plus de donnes vers rcepteur des donnes peuvent tre transmises mission FIN sq=y, ACK x+1 Rseau Rcepteur
Rception FIN mission ACK y+1 Armement timer Rception ACK Armement timer
` la n, un temporisateur est utilis A e pour laisser le temps aux segments retard es darriver ou d etre d etruits Puis les donn ees relatives ` a la connexion sont d etruites
54/67
77/90
Fermeture brutale dune connexion
Bit RST ` a1:

Signie quil a y eu un probl` eme grave Connexion lib er ee imm ediatement Donn ees non trait ees/segments retard es sont perdus Applications sont inform ees Utilis e aussi pour refuser une demande de connexion
55/67
Cyril Pain-Barre
78/90
Temporisation et retransmission
Un segment (donn ees) non acquitt e doit etre retransmis Probl` emes importants sur Internet :
comment calculer/estimer le RTT (Round Trip Time) ? quelle dur ee du temporisateur ?
source : TCP/IP Architecture, protocoles, applications. D. Comer, Edts Dunod
56/67
Cyril Pain-Barre
79/90
Ajustement dynamique du RTT estim e

Pour chaque connexion, TCP g` ere une variable RTT Soit M = temps mis pour retour de lACK dun segment RTT est mis ` a jour selon la formule : RTT = RTT + (1 )M o` u 0 1 (g en eralement 7/8) est le poids attribu e` a lanciennce valeur de RTT Valeur du timer T = RTT (` a lorigine du standard = 2) Jacobson (1988) a propos e une am elioration du calcul de RTT et de T , pour tenir compte de la variance. Devenu la r` egle depuis 1989 :
Di = M RTT RTT = RTT Di , o` u g en eralement vaut 1/23 Dev = Dev + (|Di | Dev ), o` u g en eralement vaut 1/22 T = RTT + Dev , o` u g en eralement vaut 4
57/67
Cyril Pain-Barre
80/90
Ajustement dynamique du timer : exemple

En pointill es, des valeurs al eatoires de RTT. En trait plein, le timer calcul e:

58/67
Cyril Pain-Barre
81/90
RTT et Algorithme de Karn
Probl` eme : si un segment est retransmis et un ACK re cu, doit-il etre pris pour le premier ou le dernier segment ? Selon le choix, le calcul de RTT et de T peut etre grandement fauss e! Algorithme de Karn (radio amateur) :
Ne pas mesurer M pour un segment retransmis Mais augmenter T , selon la formule : T =T o` u g en eralement vaut 2.
59/67
Cyril Pain-Barre
82/90
Timer et grandes variations RTT
Il reste des situations impossibles ` a pr evoir mais la r eaction est g en eralement tr` es bonne.
60/67
Cyril Pain-Barre
83/90
Syndrome de la fen etre stupide
Soit une application qui ne lit les donn ees quoctet par octet L emetteur envoie susamment doctets pour remplir le tampon de r eception Le TCP r ecepteur envoie une taille de fen etre nulle Lorsque lapplication lit un octet, TCP enverra une taille de fen etre de 1 L emetteur peut alors envoyer 1 octet ! Puis taille de fen etre 0 etc. Cest pas mieux si cest l emetteur qui envoie de lui-m eme des petits segments !
61/67
Cyril Pain-Barre
84/90
Eviter la fen etre stupide

C ot e r ecepteur : (Algorithme de Clark) nannoncer une r eouverture de la fen etre que lorsque sa taille est :
soit egale ` a la moiti e du tampon de r eception soit egale au MSS
C ot e emetteur : (Algorithme de Nagle) retarder le plus possible lenvoi :

si des donn ees nont pas et e acquitt ees, placer les nouvelles donn ees en tampon ne les envoyer que si atteint taille maximale du segment ou la moiti e de la fen etre d emission lorsquun ACK arrive, envoyer ce quil y a (m eme si le segment nest pas plein)
ceci m eme en cas de PUSH ! Il est parfois n ecessaire de d esactiver lalgo de Nagle, notamment pour X-Window (il faut envoyer les mouvements de la souris de suite et non les tamponner. . . ).
62/67
85/90
TCP et la congestion
La congestion produit des retards importants et des pertes de datagrammes Retransmettre des segments retard es/d etruits aggrave la congestion jusqu` a leondrement congestif TCP en tient compte et cherche ` a eviter la congestion et r eagit en cas de congestion :
d emarrage lent diminution dichotomique
N ecessite la gestion dune fen etre de congestion Fen etre utilis ee = min(Fen etre r ecepteur, Fen etre congestion)
63/67
Cyril Pain-Barre
86/90
TCP et la congestion : d emarrage lent
Au d ebut de la connexion ou suite ` a une congestion, eectuer un d emarrage lent avec fen etre congestion = 1 segment D emarrage lent : pour chaque segment acquitt e, augmenter de 1 segment la fen etre de congestion lent mais croissance exponentielle !
64/67
Cyril Pain-Barre
87/90
TCP et la congestion : diminution dichotomique
TCP estime que la perte dun segment est due ` a la congestion Si segment perdu, xer un seuil ` a la moiti e de la fen etre de congestion (taille mini = 1 segment) Augmenter la temporisation (algo de Karn) Recommencer un d emarrage lent jusqu` a atteindre le seuil phase d evitement de congestion : ` a partir du seuil, naugmenter que de 1 segment pour lensemble des segments acquitt es (croissance lin eaire)
65/67
Cyril Pain-Barre
88/90
TCP et la congestion : illustration

taille fentre (nombre de segments) 17 16 15 14 13 12 11 non acquitt : nouvelle fentre (vitement partir de 6) + doublement temporisateur
non acquitt : nouvelle fentre (vitement partir de 8) + doublement temporisateur
9 8 7 6 5 4 3 2 1
T et tim
er
10
er
jour RT
tim
et
TT
mise
j ou
mi se
is e
jo ur R
rR
TT
et
tim
er
temps
dmarrage lent
vitement congestion
dmarrage lent
vitement congestion
66/67
Cyril Pain-Barre
89/90
Automate d etats ni de TCP

transitions d etats : ev enement / action, o` u: ev enement :
italiques : primitive appel ee par le programme ACK, SYN, etc. : r eception dun segment avec ce bit positionn e
coute SYN / SYN + ACK RST/ SYN reu ACK / mission / SYN SYN mis Fermer / tempo SYN + ACK / ACK Connexion tablie Fermer / FIN Fin Attente1 ACK / Fin Attente2 FIN / ACK FIN + ACK / ACK FIN / ACK Fermer en cours ACK / Tempori sation
67/67
Dbut
Ferm
Ouverture passive
Fermer Ouverture active / SYN
SYN / SYN + ACK
action :
ACK, SYN, etc. : envoi segment - : rien tempo : temporisation de 2 fois la dur ee de vie dun segment
Fermer / FIN
Attente FIN / ACK Fermer Fermer / FIN Dernier ACK ACK / tempo
en pointill es, les ev enements exceptionnels

Cyril Pain-Barre
90/90

Cours 2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours 2

Transféré par

Droits d'auteur :

Formats disponibles

R eseaux - Cours 2

UDP et TCP : Protocoles de Transport de TCP/IP

Semestre 2 - version du 22/3/2011

Transport UDP et TCP

Services et Limitations dIP

Transport UDP et TCP

Aller au-del` a des limites dIP Assurer, si possible, la correction derreurs :

2 protocoles de transport disponibles dans TCP/IP :

Transport UDP et TCP

Adressage des applications

Transport UDP et TCP

D emultiplexage des ports

applications UDP DHCP (serveur) 67

selon champ Protocole

Transport UDP et TCP

Le protocole UDP : User Datagram Protocol

Transport UDP et TCP

M eme type de service non able, non connect e que IP :

Transport UDP et TCP

Format des datagrammes UDP

Port UDP Source Longueur Totale

Port UDP Destination Checksum

Transport UDP et TCP

Champs UDP : ports source et destination

UDP selon champ Protocole (17) IP

Transport UDP et TCP

Serveurs et ports r eserv es UDP

Champs UDP : Checksum

Adresse IP Source Adresse IP Destination Zone Zro Protocole

Longueur Datagramme UDP

Transport UDP et TCP

Interface socket BSD (Unix) pour UDP

Transport UDP et TCP

Mod` ele Client/Serveur utilisant UDP

Files dattente et r eception

Attribution de port allocation le dattente R eception dun datagramme :

Appli consomme les el ements de la le, par acc` es synchrone :

Une application peut demander plusieurs ports

Transport UDP et TCP

Utilisation UDP : mod` ele requ ete/r eponse

pour ce genre de service, AppliB peut traiter les datagrammes au f ur et ` a mesure

x UDP Hte A UDP Hte B

Transport UDP et TCP

Utilisation UDP : suivi de la discussion

Utilisation UDP : multidiusion

Transport UDP et TCP

Mise en uvre du transfert able

Transport UDP et TCP

Transfert able en mode connect e

Transport UDP et TCP

Accus es de r eception (ACK)

Protocole de type envoyer et attendre

Transport UDP et TCP

timeout mission paquet 1

Transport UDP et TCP

Temporisateurs : probl` eme de r eglage

timeout mission paquet 1 mission paquet 2

ACK : probl` eme de lACK perdu

timeout mission paquet 1

Le paquet 1 est accept e 2 fois par le r ecepteur !

Transport UDP et TCP

Num erotation des paquets et des ACK

timeout mission paquet 1 ignore paquet 1 envoi de lACK n1

Transport UDP et TCP