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.