5.3 KiB
title: "Réseaux et Protocole: couche transport" date: 2024-01-22 tags: ["OSI", "application"] categories: ["Réseaux et protocoles", "Cours"] mathjax: true
Nous parlons ici de la communication entre deux processus dans la couche 4 du OSI. Les messages sont découpés et insérés dans des segments . Le destinataire va ensuite réassemblé ces segments et pour les passer à la couche applicative.
La couche transport ajoute les entêtes aux message qui lui sont transmis.
Deux protocoles principaux compose cette couche : TCP pour Transmission Control Protocol et UDP pour User Datagram Protocol.
UDP est un protocole simple, sans overhdead mais aussi sans contrôle et sans connexion.
TCP est plus complexe, il intègre des contrôles (congestion, ordre des segments, flux). C'est aussi un protocole connecté.
Multiplexage, démultiplexage
Tous les segments passent par le même chemin, il faut donc passer par une opération de multiplexage (emetteur) et démultiplexage (recepteur).
+-----------+ +------------------+ +---------------------+
| processus | o==> | couche transport | o==> | process de l'entête | o=
+-----------+ +------------------+ +---------------------+
+-----------+
=> | couche IP |
+-----------+
Le message envoyé par le processus passe par la couche transport qui y ajoute l'entête. Le segnemt qui en résulte est esuite envoyé à la couche IP
Sur le système du destinataire, l'adresse IP et les ports sont utilisés pour déterminer la bonne socket à utiliser. Chaque socket est alors un tuple de 4 éléments:
- IP source
- IP destination
- port source
- port destination
UDP dans le détail
C'est un protocole non orienté connexion, en mode best effort. Il est donc moins fiable mais comme nous l'avons dit sans overhead. Les segments sont indépendants les un des autres. C'est un protocole particulièrement adapté pour le streaming, la VoIP, les jeux en ligne. Tout ces usage qui privilégient la vitesse de transmission. Il est aussi utilisé pour HTTP3 et d'autres protocoles tolérants à la panne. La fiabilité est alors implementée dans la couche applicative.
0 32
+-----------------+------------------+
| source port | destination port |
+-----------------+------------------+
| checksum | lenght |
+-----------------+------------------+
| D A T A |
| |
| ... |
Le checksum est un contrôle élémentaire du paquet reçu afin de vérifier les paquets reçus. Cependant une erreur peut être non détetée.
TCP dans le détail
C'est un protocole point à point fiable, avec ordre (chaque paquet a un ordre
précis dans la file), avec acquitement (ACK), avec gestion des flux et de ala
congestion.
C'est un protocole orenté connexion (accept()), l'établissement d'une
connexion se fait au moyen d'une poignée de main en trois étapes SYN ->
SYN-ACK -> SYN
L'entête est aussi plus complexe:
0 15 32
+-------------------------------+-------------------------------+
| source port | destination port |
+-------------------------------+-------------------------------+
| numéro de séquence |
+---------------------------------------------------------------+
| numéro de d'acquitement |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| header size | |E| |A| |R|S|F| receive window |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| checksum | destination port |
+-------------------------------+-------------------------------+
| options (taille variable) |
+---------------------------------------------------------------+
Le numéro d'acquitement contient le numéro de séquence reçue plus la taille su
segment. Dans ce même paquet, le numéro de séquence est le numéro d'ACK.
L'ACK est cumulatif, il couvre les acquitement précédents.
Le fast retransmit permet la reduction du temps de retransmission. Le mécanisme de double aquitement permet d'accélérer lea retransmisison de segments perdus. Lorsque l'emmeteur reçoit le même acquitement en double, alors il renvoi le paquet suivant correpondant.
Contrôle de flux
TCP dispose d'une receive window qui représente la quantité de données pouvant être reçue à un instant T. Ce mécanisme permet d'éviter que le réseaux n'envoie plus de données que la capacité de traitement du terminal.
Les donnees reçues par la socket sont stockées dans une structure rcvbuffer,
la receive window* correspond à la qantité de données disponible dans ce
buffer.
Contrôle de la congestion
L'approche est simple: on augmente le taux d'envois jusqu'à constater de pertes de paquets, alors on le diminue. Le principe est le suivant:
- additive increase: on agmente le taux de 1
- multiplicative decrease: on divise le taux par 2 lorsque l'on reçoit
trois fois le même numéro d'
ACK(sinon on diminue de 1 la Maximum Segment Size en cas de détection de perte par timeout)