Vous êtes sur la page 1sur 67

La couche transport

1
I – Introduction
La couche transport est globalement responsable du transfert de
bout en bout des données d’application.

Ce chapitre est consacré à l’étude du rôle de la couche transport


dans le processus d’encapsulation des données d’application en vue
de leur utilisation par la couche réseau.

2
II – Rôle de la couche transport
1. Objectifs
La couche transport segmente les données et se charge du contrôle nécessaire au
réassemblage des blocs de données dans les divers flux de communication. Elle doit :

 effectuer un suivi des communications individuelles entre les applications résidant


sur les hôtes source et de destination ;

 segmenter les données et gérer chaque bloc individuel ;

 réassembler les segments en flux de données d’application ;

 identifier les différentes applications.

3
II – Rôle de la couche transport
 Suivi des conversations individuelles:

Tout hôte peut héberger plusieurs applications qui communiquent sur le


réseau.

Chacune de ces applications communique avec une ou plusieurs


applications hébergées sur des hôtes distants.

Il incombe à la couche transport de gérer les nombreux flux de


communication entre ces applications.

4
II – Rôle de la couche transport
 Segmentation des données :

Les données crées doivent être préparées pour être expédiées sur le
support sous forme de blocs faciles à gérer.

Les protocoles de la couche transport décrivent les services qui


segmentent ces données provenant des couches applicatives.

Il s’agit notamment d’encapsuler des en-têtes à chaque bloc de données


pour indiquer à quelle communication il est associé.

5
II – Rôle de la couche transport
 Reconstitution des segments :

Au niveau de l’hôte recevant les blocs de données, les protocoles


intervenant au niveau de la couche transport utilisent les informations
d’en-tête de cette couche pour réassembler les blocs de données en
flux qui seront transmis à la couche application.

6
II – Rôle de la couche transport
 Identification des applications

Pour que les flux de données atteignent les applications auxquelles ils
sont destinés, la couche transport doit identifier l’application cible.

Un identificateur appelé numéro de port est affecté à chaque


application.

Ce numéro de port est inclus dans l’en-tête de la couche transport.

7
II – Rôle de la couche transport
 Comment identifier ?

Séparation de communications multiples 8


II – Rôle de la couche transport
 Séparation de communications multiples

La couche transport divise les données en segments qui sont plus faciles
à gérer et à transporter.

La segmentation permet à plusieurs communications différentes d’être


entrelacées (faire l’objet d’un multiplexage) sur le même réseau.

9
II – Rôle de la couche transport

La segmentation des données, conformément aux protocoles de la couche


transport, permet d’envoyer et de recevoir les données tout en exécutant
plusieurs applications simultanément. 10
II – Rôle de la couche transport
2. Contrôle des conversations
Les informations contenues dans les en-têtes de la couche transport assurent:
 Acheminement fiable : tous les blocs doivent atteindre leur destination en
demandant au périphérique source de retransmettre les données qui ont
pu se perdre.
 Livraison dans l’ordre : la couche transport s’assure que les segments sont
réassemblés dans le bon ordre en les numérotant et en les ordonnant.
 Contrôle de flux: en cas d’encombrement au niveau de l’hôte, la couche
transport peut demander à l’application émettrice de réduire le flux. Ce
contrôle contribue à prévenir la perte de segments sur le réseau.

11
II – Rôle de la couche transport
3. Les protocoles TCP et UDP
Les deux protocoles de la couche transport les plus couramment
employés sont le protocole TCP (Transmission Control Protocol) et le
protocole UDP (User Datagram Protocol).
Ces deux protocoles gèrent les communications de nombreuses
applications.

12
II – Rôle de la couche transport
 TCP :
Le protocole TCP est un protocole avec connexion décrit dans le
document RFC 793.
Ce protocole impose une surcharge de l’entêté pour accroître les
fonctionnalités telles que la livraison dans l’ordre, l’acheminement fiable et
le contrôle de flux.
Ce protocole est utilisé par :
 Navigation Web
 Courriel
 Transfert de fichiers 13
II – Rôle de la couche transport
 UDP :
Le protocole UDP est un protocole simple, sans connexion, décrit par
le document RFC 768. Il présente l’avantage d’imposer peu de
surcharge pour l’acheminement des données.
Les blocs de communications utilisés dans le protocole UDP sont
appelés des datagrammes.
Le protocole UDP est notamment utilisé par :
 Système de noms de domaine (DNS)
 Lecture vidéo en continu
 Voix sur IP (VoIP) 14
II – Rôle de la couche transport
 TCP vs UDP

15
II – Rôle de la couche transport
4. Les ports de communication
Pour différencier les segments et les datagrammes de chaque
application, les protocoles TCP et UDP utilisent chacun des champs
d’en-tête qui sont les numéros de port.
L’en-tête de chaque segment ou datagramme contient un port source
et un port de destination.

16
II – Rôle de la couche transport
4. Les ports de communication

numéro de port (couche transport)


+ interface de connexion
adresse IP (couche réseau)

Cet ensemble identifie de façon unique un processus précis s’exécutant


sur un périphérique spécifique.

17
II – Rôle de la couche transport
4. Les ports de communication
Par exemple:

une requête de page Web HTTP envoyée à un serveur Web (port 80)
s’exécutant sur un hôte avec une adresse IP égale à 192.168.1.20 sera
destinée à l’interface de connexion 192.168.1.20 : 80

18
II – Rôle de la couche transport
4. Les ports de communication
 Les 3 plages de l'IANA (Internet Assigned Numbers Authority)
- 0 à 1023: ports systèmes assignés par l'IANA (system ports ou
"well-known ports")
- 1024 à 49151: ports enregistrés assignés par l'IANA (registered
ports)
- 49152 à 65535: port éphémères non gérés par l'IANA (dynamic
ports)
19
II – Rôle de la couche transport
Comment vérifier la plage de port de mon système
d'exploitation ?
 Sous Windows :
Dans l’invite de commandes tapez la commande :
netsh int ipv4 show dynamicport tcp

 Sous Linux :
Dans un terminal , tapez la commande :
cat /proc/sys/net/ipv4/ip_local_port_range

20
II – Rôle de la couche transport
Ports TCP

21
II – Rôle de la couche transport
Ports UDP

22
II – Rôle de la couche transport
Ports TCP et UDP communs

23
II – Rôle de la couche transport
5. Segmentation et reconstitution
Les volumes de données transmises pouvant atteindre plusieurs Go.

L’envoi massif de ces volumes serait peu pratique pour plusieurs raisons :
o aucun autre trafic ne pourrait être transmis sur le réseau pendant l’envoi de
ces données.
o le temps de transmission pourrait être important (plusieurs minutes à
plusieurs heures).
o si une erreur se produisait, l’ensemble du fichier de données serait perdu ou
devrait être réexpédié.
o la mémoire tampon des périphériques réseau ne serait pas suffisante pour
stocker autant de données pendant leur transmission ou leur réception. 24
II – Rôle de la couche transport
5. Segmentation et reconstitution
Donc, diviser les données en blocs permet de s’assurer qu’elles sont
transmises en tenant compte des limites du support et que les données
différentes peuvent faire l’objet d’un multiplexage sur le support.

Les protocoles TCP et UDP traitent différemment la segmentation.

25
II – Rôle de la couche transport
5. Segmentation et reconstitution
Avec le protocole TCP, chaque en-tête de segment contient un numéro
d’ordre qui permet aux fonctions de la couche transport, au niveau de
l’hôte de destination, de réassembler les segments dans l’ordre de leur
envoi.
Par contre, les services du protocole UDP ne prêtent pas attention ni à
l’ordre de transmission ni au maintien de la connexion.
 Un en-tête UDP ne contient pas de numéro d’ordre.
26
II – Rôle de la couche transport

27
III – Protocole TCP
1. Fiabilité des conversations
La fiabilité est la principale caractéristique du protocole TCP.

Elle est assurée à l’aide de sessions de connexion.

Une conversation TCP complète exige l’établissement d’une session


entre les hôtes dans les deux directions.

28
III – Protocole TCP
1. Fiabilité des conversations
Lorsqu’une session est établie, la destination envoie des reçus à la source
pour les segments qu’elle reçoit.
Ces reçus constituent l’élément de base de la fiabilité dans la session TCP.
Quand la source reçoit un reçu, elle sait que les données ont été bien
livrées et qu’elle peut cesser d’en effectuer le suivi. Si la source ne reçoit
pas de reçu dans un délai prédéterminé (Timer), elle retransmet ces
données vers la destination.
 Avantage et inconvénient à la fois.

29
III – Protocole TCP
1. Fiabilité des conversations
La fiabilité est assurée par des champs du segment TCP ayant chacun une
fonction précise.

Indique le Précise le
numéro du prochain octet
premier octet attendu par la
d’un segment destination

Utilisé dans la Valeur de


gestion de la fenêtre
session et le dynamique
contrôle des
segments (CTL):
URG,ACK,SYN,
FIN,…
30
III – Protocole TCP
2. Etablissement et fermeture d’une connexion TCP
Lorsque deux hôtes communiquent à l’aide de TCP, une session est
établie avant que les données ne puissent être échangées. Une fois la
communication terminée, la session est fermée et il est mis fin à la
connexion.

31
III – Protocole TCP
2. Etablissement et fermeture d’une connexion TCP
Le processus d’établissement de la connexion se fait en trois étapes:

1. Un client envoie une requête avec l’indicateur SYN (SYnchronize


sequence Number),

2. Le serveur envoie une réponse SYN-ACK

3. Le client envoie donc une réponse ACK (Appelé SYN-ACK-ACK) à


l’autre extrémité et la session est établie.

32
III – Protocole TCP
 Etablissement d’une connexion TCP:

33
III – Protocole TCP
 Fermeture d’une connexion TCP:
Un processus en quatre étapes permet d’échanger les indicateurs pour
mettre fin à une connexion TCP.

A envoie une B envoie une


requête FIN à B réponse ACK à A,
ensuite une réponse
FIN.

A envoie une
réponse ACK à B

34
IV – Gestion des sessions TCP
1. Réassemblage des segments TCP
Quand des services envoient des données à l’aide du protocole TCP, il
arrive que les segments parviennent à destination dans le désordre.

Pour que le destinataire puisse comprendre le message, il faut que les


données contenues dans ces segments soient reconstituées dans leur
ordre d’origine.

35
IV – Gestion des sessions TCP
1. Réassemblage de segments TCP
Lors de la configuration de la session, un numéro d’ordre initial (Initial
Sequence Number) est défini.

Ce numéro représente la valeur de départ des octets, de cette session,


qui seront transmis à l’application réceptrice.

Ce suivi des octets de données permet d’identifier chaque segment et


d’en accuser réception individuellement. Il est ainsi possible d’identifier
les segments manquants.
36
IV – Gestion des sessions TCP
1. Réassemblage de segments TCP

37
IV – Gestion des sessions TCP
2. Confirmation de la réception des segments
L’une des fonctions de TCP est de veiller à ce que chaque segment
atteigne sa destination.

Le numéro d’ordre et le numéro de reçu de l’en-tête du segment sont


utilisés ensemble pour confirmer la réception des octets de données
contenus dans les segments.

38
IV – Gestion des sessions TCP
2. Confirmation de la réception des segments
Le numéro d’ordre (SEQ) est le nombre relatif d’octets qui ont été
transmis dans cette session plus 1 (qui est le numéro du premier octet
dans le segment actuel).
TCP utilise le numéro de reçu (ACK) des segments renvoyés à la source
pour indiquer l’octet suivant, de cette session, que le récepteur s’attend à
recevoir. C’est ce que l’on appelle un reçu prévisionnel.
La source est informée que la destination a reçu tous les octets de ce flux
de données jusqu’à l’octet indiqué par l’ACK, mais sans inclure ce dernier.
L’hôte expéditeur est censé envoyer un segment qui utilise un numéro
d’ordre égal au numéro de reçu (SEQ == ACK).
39
IV – Gestion des sessions TCP
2. Confirmation de la réception des segments
Dans l’exemple de cette figure, l’hôte de gauche envoie des données à l’hôte de
droite. Il envoie un segment contenant 10 octets de données pour cette session et
un numéro d’ordre égal à 1 dans l’en-tête.

… 40
IV – Gestion des sessions TCP
2. Confirmation de la réception des segments
Dans cet exemple, si l’hôte émetteur devait attendre un reçu pour chaque
ensemble de 10 octets, le réseau subirait une forte surcharge.

Pour réduire la surcharge de ces reçus, plusieurs segments de données


peuvent être envoyés à l’avance et faire l’objet d’un seul reçu par un
unique message TCP en retour.

Ce reçu contient un numéro basé sur le nombre total d’octets reçus dans
la session.
41
IV – Gestion des sessions TCP
2. Confirmation de la réception des segments
La quantité de données qu’une source peut transmettre avant de devoir
recevoir un reçu est appelée la taille de fenêtre.

La taille de fenêtre est un champ de l’en-tête TCP qui permet de gérer les
données perdues et le contrôle du flux.

42
IV – Gestion des sessions TCP
3.Traitement des pertes de segments
Tous les réseaux, même les mieux conçus, connaissent parfois des pertes
de données. Le protocole TCP fournit donc des méthodes de traitement
de ces pertes de segments. Parmi lesquelles la retransmission des
segments sans numéro de reçu.

En général, un service TCP sur l’hôte de destination ne génère de reçu


que pour les séquences contiguës d’octets.

43
IV – Gestion des sessions TCP
3.Traitement des pertes de segments
Par exemple, en cas de réception des segments dont les numéros
d’ordre vont de 1 à 2000 et de 2500 à 3500, le numéro du reçu sera
2001. Ceci s’explique par le fait que certains segments n’ont pas été
reçus entre les numéros d’ordre 2001 et 2499.

Quand le protocole TCP sur l’hôte source n’a pas reçu accusé réception
après un délai prédéterminé, il revient au dernier numéro de reçu et
retransmet les données depuis ce point.
44
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Le protocole TCP inclut également des mécanismes de contrôle de flux
qui contribuent à la fiabilité des transmissions TCP.

Le champ Taille de fenêtre dans l’en-tête TCP précise la quantité de


données pouvant être transmise avant qu’il ne soit nécessaire de recevoir
un reçu.

La taille de fenêtre initiale est déterminée lors du démarrage de la


session.
45
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
La figure suivante donne une représentation simplifiée de la taille de
fenêtre et des reçus.

46
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Dans cet exemple, la taille de fenêtre initiale d’une session TCP
représentée est définie à 3000 octets.

Lorsque l’expéditeur a transmis 3000 octets, il attend le reçu de ces


octets avant de transmettre d’autres segments.

Une fois que l’expéditeur reçoit le reçu du destinataire, il peut


transmettre 3000 octets supplémentaires.

47
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Fenêtre dynamique:
L’utilisation d’une fenêtre de taille dynamique permet également de
contrôler le flux de données.
Quand les ressources réseau sont soumises à de fortes contraintes, le
protocole TCP peut réduire la taille de fenêtre afin d’imposer l’envoi plus
fréquent de reçus (pour les segments reçus). Ceci a pour effet de ralentir
le taux de transmission puisque la source attend des reçus de données
fréquemment.
 La fenêtre dynamique permet de réduire les conflits
d’utilisation des ressources.
48
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Fenêtre dynamique:

A l’établissement de la session, l’hôte récepteur envoie la valeur de la


taille de fenêtre à l’expéditeur afin de lui indiquer le nombre d’octets qu’il
est prêt à recevoir dans le cadre de cette session.

L’hôte récepteur, si sa mémoire tampon est limitée, peut ralentir le taux


de communication en envoyant une valeur de taille de fenêtre plus petite
à la source.
49
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP

Segment 3 perdu à cause d’un


encombrement au niveau du récepteur

50
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Après un certain temps écoulé sans perte de données ni contraintes
excessives sur les ressources, le destinataire pourra recommencer à
augmenter la taille de fenêtre.

La taille continuera à augmenter jusqu’à ce que des données soient à


nouveau perdues, ce qui entraînera une réduction de la taille de fenêtre.

51
IV – Gestion des sessions TCP
4. Contrôle de flux sur TCP
Ces augmentations et réductions dynamiques de la taille de fenêtre
constituent un processus continu dans le protocole TCP, ce processus
détermine la taille de fenêtre optimale pour chaque session TCP.

52
V – Protocole UDP
1. UDP: faible surcharge contre fiabilité
Le protocole UDP est un protocole simple offrant des fonctions de base
de la couche transport.
Il crée beaucoup moins de surcharge que le protocole TCP car il est sans
connexion et ne propose pas de mécanismes sophistiqués de
retransmission, de séquençage et de contrôle de flux.
Mais cela ne signifie pas que les applications utilisant le protocole UDP
manquent toujours de fiabilité. Cela signifie simplement que ces fonctions
ne sont pas fournies par le protocole de la couche transport et qu’elles
doivent être implémentées à un autre niveau, le cas échéant.

53
V – Protocole UDP
1. UDP: faible surcharge contre fiabilité
Plusieurs services de la couche application utilisent le protocole UDP,
notamment :
◦ DNS (Domain Name System)
◦ SNMP (Simple Network Management Protocol)
◦ DHCP (Dynamic Host Configuration Protocol)
◦ RIP (Routing Information Protocol)
◦ TFTP (Trivial File Transfer Protocol)
◦ …
54
V – Protocole UDP
1. UDP: faible surcharge contre fiabilité
Certaines applications, comme les jeux en ligne ou la voix sur IP,
peuvent tolérer la perte d’une certaine quantité de données.

Si ces applications utilisaient le protocole TCP, elles risqueraient d’être


confrontées à de longs délais pendant que TCP détecterait les pertes et
retransmettrait les données. Ces délais seraient plus préjudiciables à
l’application que la perte d’une petite quantité de données.

55
V – Protocole UDP
1. UDP: faible surcharge contre fiabilité
Certaines applications, comme le système DNS, se contentent simplement
de répéter leur requête si elles ne reçoivent pas de réponse. Donc, elles
n’ont pas besoin du protocole TCP pour garantir la livraison du message.

 La faible surcharge qu’engendre le protocole UDP rend celui-


ci très intéressant pour de telles applications.

56
V – Protocole UDP
2. Réassemblage des datagrammes UDP
UDP n’utilise pas de connexion, les sessions ne sont pas établies avant
que la communication n’ait lieu comme c’est le cas avec le protocole TCP.

UDP est connu pour être un protocole basé sur les transactions. En
d’autres termes, quand une application doit envoyer des données, elle les
envoie tout simplement.

57
V – Protocole UDP
2. Réassemblage des datagrammes UDP
Certaines applications utilisant UDP envoient des volumes de données
plus importants qui doivent être découpés en datagrammes.
Les datagrammes envoyés vers une destination, peuvent emprunter des
chemins différents et arriver dans le désordre.
Le protocole UDP n’effectue pas de suivi des numéros d’ordre comme
TCP. Il n’a en effet aucun moyen de réordonnancer les datagrammes.

58
V – Protocole UDP
2. Réassemblage des datagrammes UDP

59
V – Protocole UDP
3. Applications UDP
Comme c’est le cas avec des applications basées sur TCP, des numéros de
ports réservés sont affectés aux applications serveur basées sur UDP.
La communication est initiée par une application cliente qui demande des
données à un processus serveur.
Le processus client UDP sélectionne un numéro de port aléatoire dans
une plage dynamique de numéros de ports et il l’utilise comme port
source pour la conversation.
Le port de destination est généralement le numéro de port réservé
affecté au processus serveur.

60
V – Protocole UDP
3. Applications UDP

61
V – Protocole UDP
2. Processus et requêtes des clients UDP

62
Résumé
 La couche transport fournit plusieurs fonctionnalités au réseau en :
 divisant en segments (ou datagrammes) les données reçues d’une
application ;
 ajoutant un en-tête pour identifier et gérer chaque segment ;
 utilisant les informations de l’en-tête pour réassembler les
segments en données d’application ;
 transférant les données assemblées à l’application adéquate.

 Les protocoles UDP et TCP sont couramment utilisés dans la couche


transport.

63
Résumé
 Les datagrammes UDP et les segments TCP ajoutent aux données
des préfixes, composés d’en-têtes contenant un numéro de port
source et un numéro de port de destination. Ces numéros de ports
permettent d’orienter les données vers l’application correcte
s’exécutant sur l’ordinateur de destination.

64
Résumé
 Le protocole TCP ne transmet aucune donnée au réseau tant qu’il n’a
pas la confirmation que la destination est prête à les recevoir.
 Il gère le flux de données et renvoie tout segment pour lequel la
destination n’a pas envoyé de reçu.
 TCP utilise divers mécanismes comme les connexions en trois étapes,
les minuteurs, les ACK et le fenêtrage dynamique pour assurer la
fiabilité de ces fonctions. Néanmoins, cette fiabilité impose une
surcharge au réseau car elle crée des en-têtes de segments beaucoup
plus volumineux et accroît le trafic réseau entre la source et la
destination.

65
Conclusion
 Dans les réseaux, si les données d’application doivent être rapidement
livrées ou si la bande passante ne peut pas supporter une telle surcharge
(messages de contrôle) les développeurs préfèreront le protocole UDP
pour la couche transport.
 Ceci s’explique par le fait que UDP n’effectue pas de suivi, et n’accuse
pas réception des datagrammes reçus. Il se contente de transmettre les
datagrammes reçus à la couche application dans l’ordre de leur arrivée
et il ne réexpédie pas les datagrammes perdus.
 Ceci n’implique pas nécessairement que la communication elle-même
n’est pas fiable car les protocoles et services de la couche application
peuvent comporter des mécanismes permettant de traiter les
datagrammes perdus.
66
Conclusion
 Les développeurs d’applications choisissent le protocole de la couche
transport répondant le mieux aux exigences des utilisateurs, sans
oublier que les autres couches jouent un rôle dans les communications
sur le réseau.

67