UDP bezeichnet ein, im Gegensatz zu TCP, schlankes und verbindungsloses Protokoll. Wie TCP auch arbeitet UDP auf der Transportschicht und ist demnach für den Datentransport zuständig. Verbindungslos bedeutet, dass UDP im Gegensatz zu TCP keine Verbindung aufbaut, sondern einfach dafür sorgt, dass die Daten auf der Anwendungsschicht der richtigen Anwendung zugeordnet werden. Die Daten werden also quasi einfach ohne Sicherung und Kontrolle „weitergeleitet“ und „gesendet“. Erfunden wurde UDP für Anwendungen, die schnelle Verbindungsaufbauten benötigen.
Ein UDP-Paket enthält nicht nur die eigentlichen Daten, die übertragen werden, sondern auch einige grundgelegene Informationen im „Kopf“ des Pakets – dem sogenannten Header. Ein UDP-Paket sieht also folgendermaßen aus:
| Quell-Port | Ziel-Port |
| Länge | Prüfsumme |
| Daten | |
Die vier Felder sind jeweils 16 Bit groß. Da UDP, um die Daten Diensten, also im Prinzip, Anwendungen zuzuordnen sogenannte Ports verwendet, sind in einem UDP-Paket der Quell-Port, also der Port, wovon das Paket kommt, und der Ziel-Port, also der Port, an dem die Daten zugestellt werden sollen, vermerkt - die IP-Adressen sind bei UDP/IP-Verbindungen ja bereits im IP-Header enthalten. Ferner werden noch die Länge des Pakets in Oktetten und eine Prüfsumme mit übertragen. Die Prüfsumme muss nicht verwendet werden, ist also optional und des Weiteren lediglich dazu da, um fehlerhafte Pakete zu erkennen, mehr nicht – UDP kann fehlerhafte Pakete nicht korrigieren und erst Recht keine verlorengegangene Pakete nachsenden. UDP-Anwendungen müssen also ihre eigenen Kontroll- und Korrekturroutinen implementieren, um auch im Fehlerfall noch korrekt zu funktionieren.
UDP hat den Vorteil, dass es ein relativ simples und einfaches Protokoll ist - Während bei TCP erst eine Verbindung mittels des Drei-Wege-Handshakes aufgebaut werden muss, können bei UDP sofort Daten übertragen werden. Somit spart man hier aufgrund des fehlenden Verbindungsaufbaus viel Zeit und - vor allem - Bandbreite, UDP ist einfach schneller und belastet den Traffic weniger. Insbesondere bei Diensten und Anwendungen, die viel und häufig Daten austauschen kann die Leistung durch die Verwendung von UDP skaliert bzw. maximiert werden. Allerdings hat UDP auch den großen Nachteil, dass es keine Sicherheit gegenüber Fehlern, wie z.B Paketenverluste und Korruptionen bietet und nicht zuverlässig ist. Eine UDP-Anwendung muss also seine eigenen Schutz- bzw. Korrekturroutinen gegen diese Fehler aufweisen können. TCP hat entsprechende Routinen bereits im Protokoll integriert, sie sind fester Bestandteil von TCP. TCP agiert hier sicherer und störungsresistenter und sendet z.B. verlorengegangene Pakete solange nach, bis ihr Ankommen bestätigt wird. Zwar gibt es, wie man auf der Tabelle sieht, einen Bereich für eine Prüfsumme in einem UDP-Paketheader - diese dient aber lediglich dazu, um fehlerhafte Pakete zu erkennen. Die fehlerhaften Pakete müssen von den Anwendungen manuell verworfen und z.B. neue angefordert werden.
Viele Protokolle und Anwendungen benutzen UDP zur Datenübertragung – anbei eine kleine Auswahl mit kurzer Erläuterung.
DNS, das Domain Name System rechnet Hostnamen, wie z.B. www.google.de in IP-Adressen und umgekehrt um, damit ein Programm, wie z.B. ein Webbrowser eine Verbindung herstellen kann. DNS benutzt UDP auf Port 53, um Anfragen zu übermitteln. DNS erlaubt auch Anfragen über TCP, standardmäßig wird aber UDP verwendet, um Bandbreite zu sparen. Benutzt DNS UDP statt TCP entsteht ein höherer Traffic. Je nachdem, wie viel Zugriffe auf den Service erfolgen, kann dadurch ein enorm hoher Datenaustausch entstehen, der das Netzwerk schwer belastet.
Das Dynamic Host Configuration Protocol (DHCP), welches dazu verwendet wird, um ein nahezu konfigurationsfreies Netzwerk zu erstellen, verwendet ebenfalls UDP, um die Netzwerkkonfiguration (IP-Adresse, DNS-Server, Netzmaske, etc,…) den Hosts (den „einwählenden“ Rechnern) zuzuweisen. TCP kann hier nicht verwendet werden, da die Rechner, die sich z.B. in einem Heimnetz über DHCP einwählen noch keine Netzwerkkonfiguration aufweisen können. Es ist z.B. keine IP-Adresse vorhanden. TCP ist verbindungsorientiert und kann hier aufgrund dieser fehlenden Konfiguration nicht agieren. UDP hingegen ist verbindungslos und erlaubt auch die Kommunikation über MAC-Adressen und Broadcast. DHCP lauscht also einfach auf Anfragen und sendet die Netzwerkkonfiguration über Broadcast und die MAC-Adresse an den Zielrechner. Diese Technik bezeichnet man auch als “Gruppenkommunikation“ - TCP unterstützt diese nicht.
Das Trivial File Transfer Protocol (TFTP) ist im Heimgebrauch eher unbekannt, es wird für einfache Dateiübertragungen zwischen Server und Client benutzt, vorallem findet es Verwendung bei Embedded-Geräten oder im Rahmen von Netzwerkboot-Vorgängen. Da es ein abgespecktes und sehr primitives Protokoll ist, das nur einen reduzierten Befehlssatz aufweisen kann, benutzt es im Rahmen seiner Minimalität auch UDP statt TCP. Als Port wird neben dem TFTP-Port 69 noch ein dynamischer Port verwendet, d.h. anhand einer Übertragungskennzeichnung wird ein Port errechnet, den Server und Client benutzen, um die Dateien zu übertragen.
SNMP, das Simple Network Management Protocol, wird verwendet, um Netzwerkgeräte, wie Switche, Hubs, Router, etc. zu überwachen und fernzusteuern. SNMP verwendet typischerweise die Ports 161 und 162, die Konfiguration kann allerdings auch von der Hardware und dem Hersteller abhängen. Da SNMP-Geräte viele Informationen über aktuelle Systeminformationen und -zustände versenden, muss das UDP-Protokoll verwendet werden, um die Bandbreite zu schonen. Würde SNMP TCP benutzen, wäre der Netztraffic, je nach Anzahl und Anfragen der SNMP-Geräte, hoch und würde unnötig die Bandbreite belasten.
Nachfolgend das Beispiel einer typischen Client/Server-Dateiübertragung mit TCP und UDP:
| Schritt | TCP | UDP |
|---|---|---|
| 1 | Client: SYN an Server (Anfrage nach Verbindung) | (nichts passiert) |
| 2 | Server: SYN+ACK (Server bereit) | (nichts passiert) |
| 3 | Client: ACK („Okay, los geht's!“) | (nichts passiert) |
| 4 | Client: Anwendung schickt Anfrage | |
| 5 | Server: Schickt Datei | |
Eine TCP-Verbindung kommt über den sogenannten Drei-Wege-Handshake (grau) zustande, während es diesen bei UDP nicht gibt. Das hat den Vorteil, dass diese Verbindung, die genau genommen bei UDP keine ist, da Daten einfach nur weitergeleitet und nicht gesichert übertragen werden, schneller aufgebaut wird – allerdings ist die Verbindung trotz Prüfsummen in den Paketen auch störanfälliger, da diese Prüfsummen nicht zur Korrektur verwendet werden können sondern lediglich fehlerhafte Pakete identifizieren. Übertragungsfehler sind also eher möglich und wahrscheinlich als bei TCP, welches eine eigene Verbindungssicherung innerhalb des Protkolls mitbringt. UDP sichert also nicht, dass jedes Paket ankommt – es können Pakete, und somit für die Anwendung wichtige Informationen, einfach fehlen und ausgelassen werden. TCP hingegen schickt nicht angekommene Pakete so lange nach, bis sie angekommen sind und bestätigt wurden. Für Anwendungen, die schnelle Verbindungsaufbauten benötigen und ihre eigene Verbindungssicherung für Störfälle mitbringen oder generell sehr simpel oder minimalistisch sind, ist UDP also zweifelsfrei die richtige Wahl. Programme, die keine eigene Sicherheit vorweisen können oder die wichtige und anfällige Daten austauschen und verarbeiten, sollten sinnvollerweise TCP statt UDP verwenden. Dienste, wie TFTP und DHCP verwenden UDP statt TCP, weil die Verbindungen aufgrund des fehlenden Handshakes schneller aufgebaut werden und dadurch Zeit und – vor allem – viel Bandbreite gespart werden kann. Insbesondere in größeren Netzwerken ist das ein wichtiger Faktor. Einige Dienste benutzen aus anderen Gründen UDP statt TCP: DHCP z.B. benutzt UDP statt TCP, weil die sogenannte Gruppenkommunikation benötigt wird. TCP setzt immer eine gültige Netzwerkkonfiguation voraus, was aber, wenn nur eine MAC-Adresse vorhanden ist? Genau hier liegt wieder der Vorteil von UDP – es kann auch ohne IP-Adresse und Subnetzmaske agieren und setzt bei DHCP genau an dieser Stelle an.