9.9. UDP – envoyer un paquet et espérer pour le mieux

UDP, le User Datagram Protocol, est le plus simple des deux services qu’offre la couche transport. Chaque envoi UDP est un datagramme – un bloc d’octets autonome adressé à une IP et un port, lâché seul dans le réseau. Le protocole le livre s’il le peut ; s’il ne le peut pas, il ne réessaie pas, n’avertit pas l’expéditeur et ne préserve aucun ordre entre les datagrammes.

9.9.1. Ce que UDP ajoute à IP

UDP est une fine couche reposant sur IP. Il ajoute trois choses à la livraison IP brute :

  • Des numéros de port aux deux extrémités, afin qu’un datagramme puisse être livré au bon programme sur l’hôte de destination, et non au seul hôte (voir Ports).

  • Un champ de longueur afin que le destinataire sache exactement combien d’octets de charge utile lire.

  • Une petite somme de contrôle sur l’en-tête et la charge utile, afin que le destinataire puisse détecter un datagramme corrompu et le rejeter.

C’est tout. Tout ce qu’IP faisait ou ne faisait pas, UDP le conserve. Les datagrammes ne sont pas renvoyés. Ils peuvent arriver dans le désordre. Ils peuvent être dupliqués par des particularités du réseau sous-jacent. Ils peuvent être perdus silencieusement si le réseau est congestionné, si le tampon à destination est plein, ou si l’un des routeurs intermédiaires en décide ainsi.

Un diagramme avec l'expéditeur à gauche et le destinataire à droite. Trois flèches pointent de l'expéditeur vers le destinataire, intitulées « datagram 1 », « datagram 2 », « datagram 3 ». La flèche du datagramme 2 est représentée par une ligne pointillée barrée d'un X, indiquant une perte.

Chaque datagramme UDP est envoyé indépendamment. Si l’un est perdu en transit, rien n’en informe l’expéditeur ni le destinataire – le manque est silencieux.

9.9.2. Pourquoi quelqu’un l’utiliserait-il

Si UDP est si peu fiable, pourquoi l’avoir du tout ? Trois raisons.

  • Rapidité et surcharge. Un envoi UDP est un seul paquet qui part ; pas de poignée de main, pas d’acquittements, pas d’état de connexion à maintenir. Le coût en latence et en bande passante est minimal.

  • Messages indépendants. Une partie du trafic est un flux de mises à jour de statut où chaque message est une capture fraîche et où un ancien message est sans valeur. Une caméra publiant « je suis toujours en vie, voici ma lecture actuelle » chaque seconde se soucie de livrer chaque nouvelle lecture, pas de rejouer les lectures qui ont été perdues.

  • Multicast. Un seul datagramme UDP peut être envoyé à de nombreux destinataires à la fois. (TCP ne le permet pas ; chaque connexion TCP relie exactement deux extrémités.) Utile pour la découverte de services, la télémétrie vers de nombreux auditeurs, la diffusion vidéo.

Là où le réseau est bon et où la tolérance de l’expéditeur à la perte est élevée, UDP est la bonne réponse. Là où la livraison et l’ordre doivent être garantis, UDP nécessite soit une couche de fiabilité supplémentaire par-dessus, soit l’application devrait simplement utiliser TCP à la place.

9.9.3. Quand ne pas l’utiliser

L’inverse mérite aussi d’être explicité. UDP est le mauvais choix lorsque :

  • Chaque octet compte. Données de configuration, mises à jour de code, transactions signées – tout cas où un octet manquant rend le résultat erroné.

  • L’ordre compte. Le datagramme UDP 2 pourrait arriver avant le datagramme 1.

  • Le message est volumineux. Les charges utiles importantes doivent être découpées en datagrammes plus petits par l’application ; la couche transport ne le fera pas. Si une seule partie est perdue, le message entier est incomplet.

Si l’un de ces cas s’applique, tournez-vous vers TCP à la place.

9.9.4. Exemples concrets sur une caméra

Exemples côté caméra de trafic UDP dans la pratique :

  • Découverte. Une caméra diffuse au démarrage un datagramme « qui est là » vers le réseau local ; d’autres appareils répondent.

  • Télémétrie. Une fois par seconde, la caméra envoie un petit datagramme contenant ses lectures de capteur actuelles à un collecteur. Perdre un échantillon de temps en temps n’a pas d’importance, car le suivant arrive de toute façon une seconde plus tard.

  • Synchronisation horaire. NTP, le network time protocol, fonctionne sur UDP. Le client envoie une petite requête, le serveur répond avec l’heure actuelle ; si la réponse est perdue, le client redemande simplement plus tard.

  • Résolutions DNS. Demander au réseau « à quelle IP ce nom correspond-il ? » fonctionne sur UDP. (Traité dans Noms et DNS.)

L’API Python pour envoyer et recevoir des datagrammes se trouve dans Sockets UDP, une fois le reste du récit de la couche transport en place.