On sait tous que le protocole UDP (User Datagram Protocol) ne fait pas le réassemblage, ni la segmentation de la data contrairement au protocole TCP qui le fait grâce à ses fameux numéros de séquence.
Alors comment les protocoles applicatifs utilisant l'UDP gère le désordre des paquets? c’est généralement la couche applicative qui doit gérer la segmentation des données trop grandes en plusieurs paquets UDP, puis leur réassemblage côté destinataire.
Prenons l'exemple de la voix sur IP.
Le protocole UDP est largement utilisé dans les applications temps réel (voix, vidéo) pour sa rapidité et sa simplicité, ce qui évite les problèmes de jitter et de latence, les véritables cauchemars des paquet voice. Mais UDP, par nature, ne garantit ni la segmentation des données ni leur réassemblage, ni l’ordre d’arrivée. Cela pose un défi important pour la transmission de flux continus comme la voix.
C'est là où entre en jeu le protocole RTP (Real-time Transport Protocol) qui agit dans la couche Application du modèle OSI.
RTP découpe le flux média en paquets de taille raisonnable définie par l’application ou codec, (par exemple: 160 octets pour 20 ms de voix avec le codec G.711 ou le codec G.729: 20 octets pour 20 ms de voix).
RTP divise le flux média en petites unités appelées paquets RTP, chaque paquet RTP correspond à une portion précise du flux temporel ( par exemple 20 ms de voix). Ces paquets sont ensuite encapsulés dans un datagramme UDP. A cela RTP ajoute un timestamp indiquant le moment précis dans le flux auquel correspond la portion audio.
Tous les protocoles n’ont pas besoin de segmentation/réassemblage, et DNS en est un bon exemple.
Qu'en est du protocole DNS qui utilise l'UDP?
Les requêtes DNS sont courtes, les réponses tiennent en général dans un seul paquet UDP de 512 octets max.
Alors comment DNS gère le désordre des paquets ? Il n’a pas besoin de gérer le réassemblage, ni de segmentation : 1 requête = 1 datagramme UDP = 1 paquet IP, donc pas de risque de désordre.
