Les protocoles de transport

Computer Networks · course

Voir tous les documents en réseaux

Les protocoles de transport

Objectifs :

Cette séquence définit les fonctions du protocole de transport et étudie les protocoles de

transport utilisés dans Internet : TCP et UDP.

A la fin de ce cours, l’étudiant doit être en mesure de :

• Définir le rôle de la couche transport en matière de transfert, de bout en bout, de

données entre applications

• Décrire le rôle de deux protocoles utilisés par la couche transport TCP/IP, à savoir

les protocoles TCP et UDP

• Décrire l’intérêt des numéros de ports dans l’identification des processus

• Décrire les principales fonctions du protocole TCP en tant que protocole fiable

fonctionnant en mode connecté.

• Expliquer la différence des protocoles TCP et UDP

• Reconnaître les situations où l’utilisation des protocoles TCP ou UDP s’impose

Plan :

1. Introduction

2. Notion de port et de socket

3. UDP

4. TCP

4.1. Format du segment TCP

4.2. phases d’une connexion TCP

4.2.1. ouverture de connexion TCP

4.2.2. fermeture de connexion TCP

4.2.3. Transfert de données

4.3. Contrôle de congestion

5. Résumé

1. Introduction

La couche transport est globalement responsable du transfert de bout en bout des données

applicatives. Elle a pour rôle de segmenter et d’encapsuler les données provenant de

l’application en vue de leur transport par le réseau. Différents blocs provenant de différentes

applications sont multiplexées par la couche de transport afin d’être acheminées au même

temps par le réseau. La couche transport a pour rôle de vérifier que les données envoyées sont

fiables et dans l’ordre afin d’être réassemblées et remontées à la couche applicative

destinataire. Ce suivi se fait d’une manière individuelle, d’où la nécessité de pouvoir identifier

chaque flux et chaque application. La couche transport affecte un identificateur à chaque

application, appelé dans le cas de TCP/IP numéro de port.

Aussi bien le processus source que le processus destination est associé un numéro de port. Ce

numéro est présent dans l’entête de l’unité de données de la couche transport afin de

déterminer à quelle application appartient ce bloc.

Vu que les applications sont diverses et leurs besoins sont différents, il existe plusieurs

protocoles de transport. En effet, certains services exigent que toutes les données doivent

arriver et dans l’ordre, alors que d’autres peuvent tolérer certaines pertes.

On distingue deux types de protocoles de transport dans Internet: TCP et UDP.

2. Notion de port et de socket

Les adresses IP désignent les machines entre lesquelles les communications sont établies.

Lorsqu'un processus désire entrer en communication avec un autre processus, il doit adresser

le processus d’application s'exécutant sur la machine destination. L'adressage de ce processus

(service applicatif) est effectué selon un concept abstrait: les numéros de ports (valeur sur 16

bits). L'émission d'un message se fait sur la base d'un port source et un port destinataire.

Les services, sur n’importe quelle machine, ont des numéros de ports fixés et bien connus

(RFC 1700). Les numéros de 0 à 1023 (well known port numbers) sont fixés par l’IANA

(Internet Assigned Number Authority) et affectés aux services bien connus, tel que le numéro

21 pour le transfert de fichiers (FTP), le numéro 23 pour le service Telnet, le numéro 53 pour

le DNS, etc.

Les numéros supérieurs à 1024 peuvent être donnés librement à n’importe quelle application.

Les applications Internet sont orientées client-serveur. Si le processus serveur a un numéro de

port fixé et connu par la source et la destination, du coté client le numéro de port est choisi

dynamiquement et attribué par le système parmi les numéros non encore attribués.

Une session entre deux applications est identifiée de manière unique par l’ensemble (type de

protocole, adresse IP source, numéro de Port source, adresse IP destination, numéro de Port

destination).

Les opérations sur les ports sont tamponnées, ainsi des files d'attente sont définies pour

chaque port.

La combinaison de l’adresse IP et du port est appelée socket. Une paire de sockets (une socket

pour la machine émettrice et une socket pour la machine réceptrice) détermine une connexion

pour le protocole orienté connexion (TCP).La notion de socket est cependant beaucoup plus

large. Une socket définit une interface de programmation ou API (Application Programming

Interface) dans le monde UNIX.

3. UDP

UDP (User Datagramme Protocol) est un protocole de transport sans connexion de service

applicatif. Il permet donc d’émettre des messages applicatifs sans établissement de connexion

au préalable. Les unités de données UDP sont appelées des datagrammes UDP.

UDP est un protocole qui ne garantit ni l’arrivée, ni le séquencement des datagrammes. Ainsi,

ce protocole n’apporte pas un service meilleur que celui de IP qualifié de « best effort ». Il

repose entièrement sur les protocoles de couche supérieure pour le contrôle des erreurs et la

retransmission des données. Ainsi, UDP est connu pour être un protocole basé sur les

transactions. Il est utilisé par les applications ayant des échanges simples et qui ne doivent pas

assembler de séquences de segments, tels que le DNS (Domain Name Server), TFTP(trivial

Publicité

File Transfer Protocol), DHCP(Dynamic Host Configuration Protocol) ou SNMP (Simple

Network Management Protocol). Aussi il est utilisé avec les applications ayant des contraintes

temporelles strictes et qui peuvent tolérer certaines pertes telles que les applications audio et

vidéo.

Le seul objectif de UDP est le multiplexage et le démultiplexage des blocs de données en

utilisant les numéros de ports présents dans l’entête du datagramme UDP.

Lorsque le protocole de transport reçoit un datagramme, il vérifie que celui-ci est un des ports

actuellement actifs (associé à une application) et le délivre à l'application responsable (mise

en queue). Si ce n'est pas le cas, il émet un message ICMP « port unreachable », et détruit le

datagramme.

Format de message UDP

0 16 31

Port Source

Longueur message

Port destination

checksum

Données

Figure 1 : Format du message UDP

• Port source et Port destination : définissent les numéros de port utilisés par UDP pour

le processus source et destination et servent pour

identifier respectivement

démultiplexer les datagrammes destinés aux processus en attente de les recevoir.

• Longueur du message : exprimée en octets (8 au minimum), elle correspond à la

longueur de tout le datagramme (en-tête + données).

• Checksum : champ de contrôle optionnel. Il est à 0 si non utilisé. Sinon, il est calculé

sur tous les champs du datagramme (entête + données) en utilisant un pseudo-en-tête

non transmis dans le datagramme. Le pseudo entête couvre plus de données, en

ajoutant des champs de niveau IP (figure 2).

0 16 31

Adresse IP source

Adresse IP destination

Zéro

Protocole

Longueur de données

Figure 2 : Format du pseudo-entête

• Le champ Protocole indique l'identificateur du protocole UDP dans IP (17)

• Le champ Longueur de données spécifie la longueur du datagramme UDP sans le

pseudo-en-tête.

4. TCP

TCP (Transmission Control Protocol) assure un transport fiable en mode connecté entre 2

stations. Avant qu’un hôte, utilisant le protocole TCP, n’envoie de données à un autre hôte, la

couche transport initie un processus pour établir une connexion avec la destination. Cette

connexion rend possible le suivi de la communication entre les hôtes de façon à vérifier si il y

perte ou pas. En effet TCP se base sur le principe de notification des données pour s’assurer

de leur bonne réception de la part de la destination.

La fiabilité est le principal élément qui le différencie du protocole de transport UDP.

En effet, TCP remédie à la perte des segments en réémettant les segments détectés perdus.

TCP assure également la séquence des paquets arrivés en désordre en se basant sur un numéro

de séquence présent dans l’entête des segments TCP.

Un contrôle de flux basé sur le principe de fenêtrage est utilisé par TCP afin de contrôler la

communication entre source et destination.

Les connexions TCP peuvent causer la surcharge du réseau et causer des problèmes de

congestion, c’est pour cela que des mécanismes de contrôle de congestion sont prévus pour

pallier à ce problème.

4.1. Format du segment TCP

0 4 10 16 31

Port Source

Port Destination

HLEN

Réservé

checksum

Numéro de séquence

Numéro d’acquittement

Codes

Options éventuelles

Données

fenêtre

Pointeur urgence

padding

Figure 3 : Format du segment TCP

• Port Source, Port destination définissent les numéros des processus sources et

destination.

• Numéro de séquence : indique le numéro du segment. Dans le cas de TCP, la

numérotation est orientée octet et pas segment, donc ce champ définit le numéro du

premier octet transmis dans le segment. Si le bit SYN (5éme bit du champ CODES)

est positionné, le numéro de séquence contient une valeur d’initialisation de séquence

(ISN). Le premier octet du premier segment sera égal à ISN +1.

• Numéro d’acquittement : le prochain numéro de séquence du prochain octet attendu

par l’émetteur de cet acquittement.

Publicité

• HLEN (4 bits): longueur de l’entête en mots de 32 bits

• Codes (6 bits): chaque bit indique une fonction du segment

o URG : le pointeur de données urgentes est valide

o ACK: ce segment acquitte des données reçues. La valeur du champ

« acquittement » peut être prise en compte.

o PSH (push) : les données reçues doivent être immédiatement transmises à la

couche supérieure. Par exemple dans l’application émulation terminal, pour

envoyer chaque caractère entré au clavier (mode caractère asynchrone).

o RST (reset): fermeture de la connexion à cause d’une erreur irrécupérable

o SYN : c’est un segment d’ouverture de la connexion

o FIN : c’est un segment de libération de la connexion (plus de donnée à

émettre)

• Fenêtre: le nombre d’octets que le récepteur peut accepter. Permet de gérer le contrôle

de flux en indiquant à l’entité distante combien d’octets au maximum la station peut

recevoir.

• Chescksum: calcul du champ de contrôle : utilise un pseudo-en-tête (tel que le cas de

UDP) et s'applique à la totalité du segment obtenu (entête + message). Dans le pseudo-

entête (Figure 2), le champ protocole porte la valeur 6 (valeur du protocole TCP dans

IP).

• Pointeur urgence : indique les octets qui doivent êtres traités en priorité. Lié au bit

URG.

• Options : différentes options peuvent être codées dans un segment TCP afin d’assurer

certaines fonctionnalités supplémentaires. Par exemple, l’option « calcul de MSS)

permet de négocier la taille maximale des segments échangés (MSS). Cette option

n'est présente que dans les segments d'initialisation de connexion (avec bit SYN).

4.2. Phases d’une connexion TCP

Une connexion TCP passe par trois phases : établissement de connexion, transfert de données

et fermeture de connexion.

4.2.1. Ouverture de connexion TCP

Une connexion TCP est établie en trois étapes de manière à assurer la synchronisation

nécessaire entre les extrémités (Figure 4). L’hôte faisant office du client initie la session

auprès du serveur en envoyant un message de demande d’ouverture de connexion portant un

numéro d’ordre initial (ISN) et positionnant le bit SYN à 1. Le serveur répond par un segment

contenant un numéro de reçu égal au numéro d’ordre reçu plus 1, ainsi que son propre numéro

d’ordre de synchronisation. Le bit SYN est toujours positionné à 1. Le client initiant la session

répond par un numéro de reçu égal au numéro d’ordre reçu plus un. Ceci achève le processus

d’établissement de la connexion. Notons que dans le troisième message, le bit SYN n’est pas

positionné.

TCP source

Ouverture active

Id local de la

connexion

SYN seq=xinit

TCP destination

Accepte toutes

les connexions

(ouverture passive)

Id local de la connexion

Ouverture réussie

SYN ACK seq=yinit, ack= xinit +1

ACK ack= yinit+1

Ouverture réussie

Figure 4 : Scénario d’ouverture de connexion

4.2.2. Fermeture de connexion TCP

Une fois le transfert des données achevé, l’une des deux extrémités peut initier la fermeture de

connexion. Afin de fermer une session unidirectionnelle, il faut deux messages : un message

de demande de déconnexion (FIN) et un accusé. Ainsi la fermeture d’une connexion TCP

bidirectionnelle nécessite en tout 4 étapes (Figure 5). Quand le client n’a plus de données à

envoyer, il envoie un segment de demande de déconnexion dont l’indicateur FIN est

positionné à 1. Le serveur envoie un segment ACK pour accuser la réception du segment FIN

afin de fermer la session du client au serveur. Le serveur envoie un segment FIN au client

pour mettre fin à la session du serveur au client. Le client répond à l’aide d’un segment ACK

pour accuser la réception du segment FIN envoyé par le serveur.

TCP source

TCP destination

Demande de déconnexion

FIN seq= x

Confirmation de

déconnexion

ACK ack=x+1

FIN seq=y ack=x+1

ACK ack= y+1

Indication de

déconnexion

Figure 5 : Scénario de fermeture de connexion

4.2.3. Transfert de données

Principe d’acquittement

Pour qu'un transfert de données soit fiable, les paquets envoyés ne doivent être ni perdus, ni

endommagés, ni dupliqués ou reçus dans un ordre différent. Une solution simple consiste,

Publicité

pour le destinataire, à accuser la réception de chacun des paquets avant que le paquet suivant

ne lui soit envoyé (Figure 6). La valeur de l’acquittement envoyé correspond au numéro du

prochain segment attendu. Dans l’exemple de la figure 6, la source envoie 10 octets de

données dans un message dont le numéro de séquence est 56. Le bit PSH étant positionné, ce

message est délivré à l’application dès sa réception. Le récepteur notifie la réception du

message en envoyant 20 octets de données. La valeur ack que porte le segment est le numéro

du message plus la taille des données envoyées (ack=66). Notons que la connexion TCP est

bidirectionnelle, donc les numéros de séquence et les numéros d’acquittements sont échangés

dans les deux sens.

TCP source

Envoi de 10 octets

Envoi de 10 octets

Indication de 22 octets

TCP destination

Indication de

10 octets

PSH ACK

seq =56

ack = 203

ACK

seq= 203,ack=66

Ack

seq = 66, ack =223

PSH ACK

seq =223

ack = 76

Figure 6 : Scénario de transfert de données avec acquittement

Cependant, le fait d’attendre la notification de chaque message avant l’envoi diminue le débit

d’émission, c’est pour cela que TCP autorise l’envoi de plusieurs segments consécutifs avant

de recevoir une notification. La taille des données pouvant ainsi être transmises avant

réception d'un accusé de réception est connue sous le nom de taille de fenêtre ou fenêtre.

Notion de fenêtrage et contrôle de flux

La taille de la fenêtre initiale est négociée lors du démarrage de la session par l’intermédiaire

de l’échange d’ouverture de connexion en trois étapes. Ensuite, elle peut être réajustée

pendant la session TCP en respectant le flux maximum que la destination et le réseau peuvent

supporter. Cette technique est un mécanisme de contrôle de flux. Dans la figure 7, la taille de

la fenêtre est de 3 messages. La source envoie donc trois segments sans recevoir

d’acquittement. L'émetteur conserve un enregistrement de chaque segment TCP, qu'il envoie,

puis attend un accusé de réception. A la réception d’un accusé de réception, l’émetteur peut

envoyer d’autres segments, mais tout en respectant la taille de la fenêtre. Ainsi à la réception

de la notification du message Mi, l’émetteur peut émettre le message Mi+3. C’est le principe de

la fenêtre glissante.

Source

Réseau

Destination

Emission de Mi

Emission de Mi+1

Emission de Mi+2

Réception de Ai

Réception de Mi

Emission de Ai

Fenêtrage de taille 3*MSS

Figure 7 : Principe de fenêtrage

TCP source

TCP destination

MSS= 1500 octets

seq=1

Fenêtre = 3000 octets

seq=1501

ack=3001

seq=3001

seq=4501

ack=3001

Expiration du

temporisateur

seq=6001

ack=3001

Seq=3001

Figure 8 : Traitement des pertes dans TCP

Traitement de perte des segments

Quand un message est envoyé, un temporisateur est armé. Si aucun accusé n’est reçu au bout

de ce temps prédéterminé, le message est considéré perdu et doit être retransmis. Dans le cas

de la figure 8, l’émetteur a une fenêtre de 3000 octets, donc peut envoyer deux messages

(seq=1 et seq=1501). Le récepteur accuse ces deux messages (ack=3001). A la réception de

cet accusé, l’émetteur peut encore envoyer deux autres messages (seq=3001 et seq=4501).

Cependant, seul le message (seq=4501) est parvenu à la destination. Dans ce cas, le récepteur

répond par un accusé portant toujours le numéro du message attendu (ack=3001).La réception

d’un tel accusé par l’émetteur, lui permet d’envoyer un seul message (seq=6001). A

l’expiration du temporisateur déclenché lors de l’envoi du message en question (seq=3001),

Publicité

l’émetteur décide que celui là est perdu et il faut le réémettre.

4.3 Contrôle de congestion

TCP gère le contrôle de flux de bout en bout mais également les problèmes de congestion

dans le réseau. La congestion correspond à la saturation de nœud (s) dans le réseau

provoquant une augmentation des délais d’acheminement de datagrammes et leurs pertes

éventuelles.

Les extrémités ignorent tout de la congestion sauf les délais. Avec le principe de

retransmission des segments, TCP aggrave encore le phénomène.

Des mécanismes de contrôle de congestion sont introduits dans TCP, basés sur la diminution

des débits.

• Slow start ou démarrage lent : l’objectif de ce mécanisme est de commencer la

transmission avec un débit faible, et l’augmenter progressivement si le réseau n’est pas

congestionné. Pour ce faire, TCP maintient une fenêtre virtuelle de congestion qu’il

augmente progressivement. La fenêtre effective d’émission est le minimum entre la

fenêtre de congestion et la fenêtre définie par le récepteur pour le contrôle de flux. La

fenêtre de congestion est initialisée à un segment (MSS). TCP Source suit le principe

suivant :

Fenêtre_congestion = 1,

émission du 1er segment, attente acquittement,

réception acquittement,

Fenêtre_congestion = 2,

émission des 2 segments, attente des acquittements,

réception des 2 acquittements,

Fenêtre_congestion = 4,

émission des 4 segments, etc.

En cas de perte, la fenêtre de congestion est remise à 1.

Le problème de Slow Start est que l’incrémentation de la fenêtre de congestion est

presque exponentielle (augmenter la taille de la fenêtre de 1 segment à chaque envoi d’un

message et la réception de son accusé) et donc risque de croître rapidement et causer la

congestion du réseau. Un deuxième mécanisme est donc introduit : c’est le mécanisme

d’évitement de congestion

• Congestion avoidance ou évitement de congestion : Afin d’éviter la croissance rapide

de la fenêtre de congestion, la phase slow start prend fin au franchissement d’un certain

seuil. A partir du seuil, la fenêtre évolue de façon linéaire en incrémentant sa taille par un

segment à chaque fois qu’une fenêtre de congestion entière est acquittée. A la perte d’un

paquet (détectée par l’expiration du temporisateur), le seuil sera réduit à la moitié de la

fenêtre de congestion, et la fenêtre de congestion est initialisée à 1.

• Fast retransmit ou retransmission rapide : Le problème qui se pose est que la détection

de perte à l’expiration du temporisateur peut créer du retard et cause un temps d’inactivité

élevé. L’idée du mécanisme de retransmission rapide et que pour chaque message reçu, le

récepteur doit envoyer un accusé, même si cet accusé porte la même valeur que ses

précédents (en cas de perte). Ainsi si l’émetteur reçoit des acquittements dupliqués alors

ceci est un signe de perte de paquet et l’émetteur peut anticiper dans la retransmission

avant l’expiration du temporisateur correspondant. Dans ce cas, il suffit de recevoir 3

ACKs dupliqués pour retransmettre le message correspondant. Dans ce dernier cas, le

seuil doit être réduit à sa moitié et la fenêtre de congestion est initialisée à 1.

• Fast recovery ou recouvrement rapide :

implémenté conjointement avec fast

retransmit, son principe et d’éviter de réinitialiser la fenêtre de congestion à 1 (phase slow

start), mais plutôt initialiser la fenêtre de congestion à la moitié de son ancienne valeur

plus 3 * MSS. Et à chaque arrivé d’un ack dupliqué, la taille de la fenêtre de congestion

est augmentée de la taille du segment. En effet, le fait de recevoir un ACK prouve qu’il y

a un message qui a parvenu au récepteur, donc on peut envoyer à sa place un autre

message. À l’arrivée de l’accusé du segment retransmis, le processus fast recovery est

interrompu et in revient à la phase évitement de congestion.

5. Résumé

• La couche transport a pour rôle de diviser en blocs le flux de données arrivé de la

couche applicative.

• Un entête est ajouté pour identifier et gérer chaque bloc. Ces blocs sont assemblés et

dirigés vers leur application en fonction de l’information de l’entête.

• Deux protocoles de transport sont utilisés dans Internet : TCP et UDP.

• TCP et UDP utilisent des numéros de port pour identifier le processus source et

destination.

• TCP est un protocole qui fonctionne en mode connecté, il assure un transport fiable

des données.

• UDP est un protocole en mode non connecté. Il ne garantit pas la transmission des

données.

• TCP utilise la notification pour s’assurer de l’arrivée des paquets. Un paquet non

acquitté est retransmis

• TCP assure un contrôle de flux basé sur le principe de fenêtrage

• TCP offre des mécanismes de contrôle de congestion pour éviter les pertes dues à

l’encombrement du réseau.

Activités

QCM

Travail personnel

Bibliographie

http://www.wireshark.org/download.html

• Laurent Toutain, Réseaux locaux et Internet, Edition Hermès.