9.9. UDP – sende ein Paket, hoffe auf das Beste

UDP, das User Datagram Protocol, ist der einfachere der beiden Dienste, die die Transportschicht anbietet. Jeder UDP-Sendevorgang ist ein Datagramm – ein in sich geschlossener Byte-Block, der an eine IP und einen Port adressiert ist und für sich allein ins Netzwerk geworfen wird. Das Protokoll stellt es zu, wenn es kann; wenn es das nicht kann, versucht es keinen erneuten Versuch, warnt den Sender nicht und bewahrt keine Reihenfolge zwischen Datagrammen.

9.9.1. Was UDP zu IP hinzufügt

UDP ist eine dünne Schicht über IP. Es fügt der rohen IP-Zustellung drei Dinge hinzu:

  • Portnummern an beiden Enden, sodass ein Datagramm an das richtige Programm auf dem Zielhost zugestellt werden kann, nicht nur an den Host (siehe Ports).

  • Ein Längenfeld, damit der Empfänger genau weiß, wie viele Bytes Nutzdaten er lesen muss.

  • Eine kleine Prüfsumme über Header und Nutzdaten, sodass der Empfänger ein korruptes Datagramm erkennen und verwerfen kann.

Das ist alles. Alles andere, was IP tat oder nicht tat, behält UDP bei. Datagramme werden nicht erneut versucht. Sie können in falscher Reihenfolge ankommen. Sie können durch Eigenheiten des zugrunde liegenden Netzwerks dupliziert werden. Sie können stillschweigend verworfen werden, wenn das Netzwerk überlastet ist, der Puffer am Ziel voll ist oder einer der Router dazwischen es so entscheidet.

Ein Diagramm mit dem Sender links und dem Empfänger rechts. Drei Pfeile zeigen von sender zu receiver, beschriftet mit "datagram 1", "datagram 2", "datagram 3". Der Pfeil für datagram 2 ist als gestrichelte Linie mit einem X darüber dargestellt, was Verlust anzeigt.

Jedes UDP-Datagramm wird unabhängig gesendet. Geht eines unterwegs verloren, teilt nichts dies dem Sender oder dem Empfänger mit – die Lücke bleibt stumm.

9.9.2. Warum sollte man es überhaupt verwenden

Wenn UDP so unzuverlässig ist, warum gibt es es dann überhaupt? Drei Gründe.

  • Geschwindigkeit und Overhead. Ein UDP-Sendevorgang ist ein einzelnes Paket, das hinausgeht; kein Handshake, keine Bestätigungen, kein zu pflegender Verbindungszustand. Die Kosten an Latenz und Bandbreite sind minimal.

  • Unabhängige Nachrichten. Mancher Verkehr ist ein Strom von Statusaktualisierungen, bei dem jede Nachricht ein frischer Schnappschuss und eine alte wertlos ist. Eine Kamera, die jede Sekunde „ich bin noch am Leben, hier ist mein aktueller Messwert“ veröffentlicht, kümmert sich darum, jeden neuen Messwert zuzustellen, nicht darum, die verloren gegangenen Messwerte erneut abzuspielen.

  • Multicast. Ein einzelnes UDP-Datagramm kann gleichzeitig an viele Empfänger gesendet werden. (TCP kann das nicht; jede TCP-Verbindung besteht zwischen genau zwei Endpunkten.) Nützlich für Dienste-Erkennung, Telemetrie an viele Zuhörer und Video-Streaming.

Wo das Netzwerk gut ist und die Verlusttoleranz des Senders hoch ist, ist UDP die richtige Antwort. Wo Zustellung und Reihenfolge garantiert sein müssen, braucht UDP entweder eine weitere Zuverlässigkeitsschicht obendrauf, oder die Anwendung sollte einfach stattdessen TCP verwenden.

9.9.3. Wann man es nicht verwenden sollte

Es lohnt sich, auch das Gegenteil ausdrücklich festzuhalten. UDP ist die falsche Wahl, wenn:

  • Jedes Byte zählt. Konfigurationsdaten, Code-Updates, signierte Transaktionen – jeder Fall, in dem ein fehlendes Byte das Ergebnis falsch macht.

  • Die Reihenfolge wichtig ist. UDP-Datagramm 2 könnte vor Datagramm 1 ankommen.

  • Die Nachricht groß ist. Große Nutzdaten müssen von der Anwendung in kleinere Datagramme aufgeteilt werden; die Transportschicht erledigt das nicht. Geht eines der Teile verloren, ist die gesamte Nachricht unvollständig.

Wenn einer dieser Punkte zutrifft, greifen Sie stattdessen zu TCP.

9.9.4. Konkrete Beispiele auf einer Kamera

Kameraseitige Beispiele für UDP-Verkehr in der Praxis:

  • Erkennung. Eine Kamera sendet beim Start ein „wer ist hier“-Datagramm als Broadcast an das lokale Netzwerk; andere Geräte antworten.

  • Telemetrie. Einmal pro Sekunde sendet die Kamera ein kleines Datagramm mit ihren aktuellen Sensormesswerten an einen Sammler. Den gelegentlichen Verlust einer Probe macht nichts aus, weil die nächste ohnehin in einer Sekunde eintrifft.

  • Zeitsynchronisierung. NTP, das Network Time Protocol, läuft über UDP. Der Client sendet eine kleine Anfrage, der Server antwortet mit der aktuellen Zeit; geht die Antwort verloren, fragt der Client einfach später erneut.

  • DNS-Abfragen. Das Fragen an das Netzwerk „auf welche IP wird dieser Name abgebildet?“ läuft über UDP. (Behandelt unter Namen und DNS.)

Die Python-API zum Senden und Empfangen von Datagrammen findet sich unter UDP-Sockets, nachdem der Rest der Geschichte der Transportschicht steht.