Si UDP n'est pas fiable, pourquoi l'utiliser ?

Pour de nombreuses applications, une livraison rapide importe plus qu'une livraison parfaite. La voix et la vidéo en temps réel peuvent tolérer des pertes occasionnelles mais pas de délai, DNS bénéficie d'une requête rapide à échange unique, et certaines applications implémentent leur propre fiabilité. L'absence d'établissement de connexion et de limitation de congestion d'UDP leur confère une latence plus faible et un contrôle accru.

UDP fait-il quelque chose au-delà d'IP ?

Oui, mais peu de choses. UDP ajoute des numéros de port afin que les données atteignent le processus d'application correct sur un hôte (multiplexage et démultiplexage), et une somme de contrôle facultative pour détecter la corruption. Au-delà de cela, il laisse inchangée la livraison en mode non connecté (best-effort) d'IP.

UDP et transport sans connexion

Le protocole de datagramme utilisateur (UDP) est le protocole de transport sans connexion léger d'Internet, n'ajoutant guère plus que le multiplexage de processus et une somme de contrôle facultative au service en mode non connecté (best-effort) d'IP, permettant ainsi aux applications de bénéficier d'une surcharge et d'une latence minimales au détriment des garanties de fiabilité.

Trouver un sujet avec PaperMindBientôtFind papers & topics

Tools & resources

Télécharger les diapositives

Learn & explore

VidéoBientôt

Definition

Le protocole de datagramme utilisateur (UDP) est un protocole de la couche transport sans connexion qui fournit une livraison en mode non connecté (best-effort) et orientée message entre les processus, ajoutant le multiplexage basé sur les ports et une somme de contrôle facultative à la couche réseau mais n'offrant aucune fiabilité, aucun ordonnancement, aucun contrôle de flux ou de congestion.

Scope

Ce sujet traite du transport sans connexion : le format du segment UDP, son multiplexage et son démultiplexage via les numéros de port, sa somme de contrôle facultative, et les raisons pour lesquelles une application le choisirait plutôt que TCP — pas de délai d'établissement de connexion, pas de limitation due au contrôle de congestion, un contrôle plus fin sur ce qui est envoyé et quand, et une faible surcharge par paquet. Il examine les applications typiques basées sur UDP et les responsabilités (telles que la fiabilité ou le contrôle de débit) qui incombent à l'application. Il exclut les mécanismes de fiabilité et de congestion de TCP.

Core questions

Quels services minimaux UDP ajoute-t-il par-dessus IP ?
Comment UDP multiplexe-t-il et démultiplexe-t-il les données à l'aide des numéros de port ?
Pourquoi une application préférerait-elle UDP à TCP ?
Quelles responsabilités, telles que la fiabilité et le contrôle de débit, sont transférées à l'application avec UDP ?
Quels types d'applications utilisent généralement UDP ?

Key concepts

service sans connexion
orientation datagramme (message)
format du segment UDP
multiplexage/démultiplexage basé sur les ports
somme de contrôle facultative
faible surcharge et latence
pas de contrôle de congestion
fiabilité au niveau de la couche application

Key theories

Service minimal sans connexion: UDP expose le service de datagramme en mode non connecté (best-effort) d'IP aux applications presque sans altération, n'ajoutant que le multiplexage par port et une somme de contrôle facultative ; il n'a donc pas d'établissement, pas d'état et pas de récupération automatique — échangeant les garanties contre la simplicité et une faible latence.
Transport contrôlé par l'application: En évitant le contrôle de congestion et la fiabilité de TCP, UDP donne à une application un contrôle direct sur le timing et ce qu'il faut retransmettre, ce qui convient aux protocoles en temps réel et personnalisés, mais oblige l'application à gérer les pertes et à éviter de surcharger le réseau lui-même.

Clinical relevance

UDP est à la base de services où une faible latence ou un contrôle fin importe plus qu'une livraison garantie : les requêtes DNS, la voix et la vidéo en temps réel, les jeux en ligne et la gestion de réseau. Des transports plus récents tels que QUIC sont construits sur UDP précisément pour obtenir un contrôle sur le transport tout en contournant les contraintes de TCP, faisant du transport sans connexion un élément central des réseaux modernes à faible latence.

History

UDP a été spécifié dans la RFC 768 (1980) comme un transport minimal pour les applications qui n'avaient pas besoin des mécanismes de TCP, lorsque TCP et IP ont été séparés en protocoles distincts. Il est resté essentiellement inchangé, et son rôle s'est accru à mesure que les applications sensibles à la latence se sont multipliées et que les développeurs ont construit de nouvelles fonctionnalités de transport, y compris le protocole QUIC, par-dessus.

Key figures

Jon Postel
James F. Kurose
Keith W. Ross

Seminal works

rfc768
kurose2021

Frequently asked questions

Si UDP n'est pas fiable, pourquoi l'utiliser ?: Pour de nombreuses applications, une livraison rapide importe plus qu'une livraison parfaite. La voix et la vidéo en temps réel peuvent tolérer des pertes occasionnelles mais pas de délai, DNS bénéficie d'une requête rapide à échange unique, et certaines applications implémentent leur propre fiabilité. L'absence d'établissement de connexion et de limitation de congestion d'UDP leur confère une latence plus faible et un contrôle accru.
UDP fait-il quelque chose au-delà d'IP ?: Oui, mais peu de choses. UDP ajoute des numéros de port afin que les données atteignent le processus d'application correct sur un hôte (multiplexage et démultiplexage), et une somme de contrôle facultative pour détecter la corruption. Au-delà de cela, il laisse inchangée la livraison en mode non connecté (best-effort) d'IP.