User Datagram Protocol (UDP) ist eines der Kernmitglieder des Internetprotokoll-Gefolges, des Satzes von für das Internet verwendeten Netzprotokollen. Mit UDP können Computeranwendungen Nachrichten, in diesem Fall gekennzeichnet als Datenpakete anderen Gastgebern in einem Netz von Internet Protocol (IP) senden ohne zu verlangen, dass vorherige Kommunikationen spezielle Übertragungskanäle oder Datenpfade aufstellen. Das Protokoll wurde von David P. Reed 1980 entworfen und formell in RFC 768 definiert.

UDP verwendet ein einfaches Übertragungsmodell ohne implizite handshaking Dialoge, um Zuverlässigkeit, Einrichtung oder Datenintegrität zur Verfügung zu stellen. So stellt UDP einen unzuverlässigen Dienst zur Verfügung, und Datenpakete können in Unordnung ankommen, kopiert scheinen oder gehen, ohne Benachrichtigung fehlend. UDP nimmt an, dass Fehlerüberprüfung und Korrektur entweder nicht notwendig oder in der Anwendung durchgeführt sind, die Gemeinkosten solcher Verarbeitung am Netzschnittstelle-Niveau vermeidend. Zeitempfindliche Anwendungen verwenden häufig UDP, weil das Fallen von Paketen dem Warten für verzögerte Pakete vorzuziehend ist, die keine Auswahl in einem Echtzeitsystem sein können. Wenn Fehlerkorrektur-Möglichkeiten am Netzschnittstelle-Niveau erforderlich sind, kann eine Anwendung Transmission Control Protocol (TCP) oder Stream Control Transmission Protocol (SCTP) verwenden, die für diesen Zweck entworfen werden.

Die staatenlose Natur von UDP ist auch für Server nützlich, auf kleine Abfragen von riesigen Zahlen von Kunden antwortend. Domain Name System (DNS), Mediaanwendungen wie IPTV, Begleitkommentar IP (VoIP), Trivial File Transfer Protocol (TFTP), IP tunneling Protokolle und viele Online-Spiele verströmend.

Diensthäfen

UDP Anwendungen verwenden Datenpaket-Steckdosen, um Gastgeber-zu-Gastgeber-Kommunikationen zu gründen. Eine Anwendung bindet eine Steckdose zu seinem Endpunkt der Datenübertragung, die eine Kombination einer IP-Adresse und eines Diensthafens ist. Ein Hafen ist eine Softwarestruktur, die durch die Hafen-Zahl, einen 16-Bit-Wert der ganzen Zahl identifiziert wird, Hafen-Zahlen zwischen 0 berücksichtigend, und. Hafen 0 wird vorbestellt, aber ist ein erlaubter Quellhafen-Wert, wenn der Senden-Prozess Nachrichten als Antwort nicht erwartet.

Das Internet Zugeteilte Zahl-Autorität hat Hafen-Zahlen in drei Reihen geteilt. Hafen-Zahlen 0 bis 1023 werden für allgemeine, wohl bekannte Dienstleistungen verwendet. Auf Unix ähnlichen Betriebssystemen, mit einem dieser Häfen verlangt Überbenutzer Betriebserlaubnis. Hafen-Zahlen 1024 sind durch die eingetragenen für IANA-eingetragene Dienstleistungen verwendeten Häfen. Häfen sind durch dynamische Häfen, die für keinen spezifischen Dienst offiziell benannt werden, und zu jedem Zweck verwendet werden können. Sie werden auch als ephemere Häfen verwendet, aus denen Software, die auf dem Gastgeber läuft, einen Hafen zufällig wählen kann, um sich zu definieren. Tatsächlich werden sie als vorläufige Häfen in erster Linie von Kunden verwendet, wenn man mit Servern kommuniziert.

Paket-Struktur

UDP ist ein minimales nachrichtenorientiertes Transportschicht-Protokoll, das in IETF RFC 768 dokumentiert wird.

UDP stellt keine Garantien dem oberen Schicht-Protokoll für die Nachrichtenübergabe zur Verfügung, und die UDP Protokoll-Schicht behält keinen Staat von UDP einmal gesandten Nachrichten. Deshalb wird UDP manchmal Unzuverlässiges Datenpaket-Protokoll genannt.

UDP stellt Anwendung gleichzeitig sendend (über Hafen-Zahlen) und Integritätsüberprüfung (über die Kontrollsumme) vom Kopfball und der Nutzlast zur Verfügung. Wenn Übertragungssicherheit gewünscht wird, muss sie in der Anwendung des Benutzers durchgeführt werden.

Der UDP Kopfball besteht aus 4 Feldern, von denen jedes 2 Bytes (16 Bit) ist. Der Gebrauch von zwei von denjenigen ist in IPv4 (rosa Hintergrund im Tisch) fakultativ. In IPv6 ist nur der Quellhafen (sieh unten) fakultativ.

Quellhafen-Zahl: Dieses Feld identifiziert den Hafen des Absenders, wenn bedeutungsvoll und angenommen werden sollte, der Hafen zu sein, um wenn erforderlich zu antworten. Wenn nicht verwendet dann sollte es Null sein. Wenn der Quellgastgeber der Kunde ist, wird die Hafen-Zahl wahrscheinlich eine ephemere Hafen-Zahl sein. Wenn der Quellgastgeber der Server ist, wird die Hafen-Zahl wahrscheinlich eine wohl bekannte Hafen-Zahl sein.

Bestimmungsort-Hafen-Zahl: Dieses Feld identifiziert den Hafen des Empfängers und ist erforderlich. Ähnlich der Quellhafen-Zahl, wenn der Kunde der Bestimmungsort-Gastgeber dann ist, wird die Hafen-Zahl wahrscheinlich eine ephemere Hafen-Zahl sein, und wenn der Bestimmungsort-Gastgeber der Server dann ist, wird die Hafen-Zahl wahrscheinlich eine wohl bekannte Hafen-Zahl sein.

Länge: Ein Feld, das die Länge in Bytes des kompletten Datenpakets angibt: Kopfball und Daten. Die minimale Länge ist 8 Bytes, da es die Länge des Kopfballs ist. Die Feldgröße legt eine theoretische Grenze von 65,535 Bytes (8-Byte-Kopfball + 65,527 Bytes von Daten) für ein UDP Datenpaket fest. Die praktische Grenze für die Datenlänge, die durch das zu Grunde liegende IPv4 Protokoll auferlegt wird, ist 65,507 Bytes (65,535 − UDP 8-Byte-Kopfball − IP 20-Byte-Kopfball).

: In IPv6 Jumbograms es ist möglich, UDP Pakete der Größe zu haben, die größer ist als 65,535 Bytes. Das berücksichtigt einen maximalen Länge-Wert von 4,294,967,295 Bytes (2^32 - 1) mit 8 Bytes, die den Kopfball und 4,294,967,287 Bytes für Daten vertreten.

Kontrollsumme: Das Kontrollsumme-Feld wird für die Fehlerüberprüfung des Kopfballs und der Daten verwendet. Wenn keine Kontrollsumme durch den Sender erzeugt wird, verwendet das Feld die Wertvollnullen. Dieses Feld ist für IPv6 nicht fakultativ.

Kontrollsumme-Berechnung

Die Methode, die verwendet ist, um die Kontrollsumme zu schätzen, wird in RFC 768 definiert:

: Kontrollsumme ist die 16 Bit jemandes Ergänzung von jemandes Ergänzungssumme eines Pseudokopfballs der Information vom IP Kopfball, dem UDP Kopfball und den Daten, die mit Nulloktetten am Ende (nötigenfalls) ausgepolstert sind, um ein Vielfache von zwei Oktetten zu machen.

Mit anderen Worten werden alle 16-Bit-Wörter mit jemandes Ergänzungsarithmetik summiert. Die Summe ist dann man hat ergänzt, um den Wert des UDP Kontrollsumme-Feldes nachzugeben.

Wenn die Kontrollsumme-Berechnung auf die Wertnull hinausläuft (alle 16 Bit 0), sollte es als jemandes Ergänzung (alle 1s) gesandt werden.

Der Unterschied zwischen IPv4 und IPv6 ist in den Daten, die verwendet sind, um die Kontrollsumme zu schätzen.

IPv4 PSEUDOKOPFBALL

Wenn UDP IPv4 durchgeht, wird die Kontrollsumme mit einem PSEUDOKOPFBALL geschätzt, der etwas von derselben Information vom echten IPv4 Kopfball enthält. Der PSEUDOKOPFBALL ist nicht der echte IPv4 Kopfball hat gepflegt, ein IP Paket zu senden. Der folgende Tisch definiert den PSEUDOKOPFBALL verwendet nur für die Kontrollsumme-Berechnung.

Die Quelle und Bestimmungsort-Adressen sind diejenigen im IPv4 Kopfball. Das Protokoll ist, dass für UDP (sieh Liste von IP Protokoll-Zahlen): 17 (0x11). Das UDP Länge-Feld ist die Länge des UDP Kopfballs und der Daten.

UDP Kontrollsumme-Berechnung ist für IPv4 fakultativ. Wenn eine Kontrollsumme nicht verwendet wird, sollte sie auf die Wertnull gesetzt werden.

IPv6 PSEUDOKOPFBALL

Wenn UDP IPv6 durchgeht, ist die Kontrollsumme obligatorisch. Die Methode, die verwendet ist, um es zu schätzen, wird wie dokumentiert, in RFC 2460 geändert:

:Any-Transport oder anderes Protokoll der oberen Schicht, das die Adressen vom IP Kopfball in seiner Kontrollsumme-Berechnung einschließt, müssen für den Gebrauch über IPv6 modifiziert werden, um die IPv6 128-Bit-Adressen einzuschließen.

man die Kontrollsumme wieder schätzt, wird ein PSEUDOKOPFBALL verwendet, der den echten IPv6 Kopfball nachahmt:

Die Quelladresse ist diejenige im IPv6 Kopfball. Die Bestimmungsort-Adresse ist der endgültige Bestimmungsort; wenn das IPv6 Paket keinen Routenplanungskopfball enthält, der die Bestimmungsort-Adresse im IPv6 Kopfball sein wird; sonst, am entstehenden Knoten, wird es die Adresse im letzten Element des Routenplanungskopfballs, und am Empfang-Knoten sein, es wird die Bestimmungsort-Adresse im IPv6 Kopfball sein. Der Wert des Folgenden Kopfball-Feldes ist der Protokoll-Wert für UDP: 17. Das UDP Länge-Feld ist die Länge des UDP Kopfballs und der Daten.

Zuverlässigkeit und Verkehrsstauung kontrollieren Lösungen

Zuverlässigkeit Mangel habend, müssen UDP Anwendungen allgemein bereit sein, einen Verlust, Fehler oder Verdoppelung zu akzeptieren. Einige Anwendungen wie TFTP können rudimentäre Zuverlässigkeitsmechanismen in die Anwendungsschicht, wie erforderlich, hinzufügen.

Meistenteils verwenden UDP Anwendungen Zuverlässigkeitsmechanismen nicht und können sogar von ihnen gehindert werden. Wenn sie Medien verströmen, sind Echtzeitmehrfachabspiellaufwerk-Spiele und Begleitkommentar IP (VoIP) Beispiele von Anwendungen das verwendet häufig UDP. In diesen besonderen Anwendungen ist der Verlust von Paketen nicht gewöhnlich ein tödliches Problem. Wenn eine Anwendung einen hohen Grad der Zuverlässigkeit verlangt, kann ein Protokoll wie das Übertragungskontrollprotokoll oder die Ausradierungscodes stattdessen verwendet werden.

Potenziell ernstlicher, verschieden von TCP, haben UDP-basierte Anwendungen gute Verkehrsstauungsaufhebung nicht notwendigerweise und kontrollieren Mechanismen. Verkehrsstauung, konnten unempfindliche UDP Anwendungen, die einen großen Bruchteil der verfügbaren Bandbreite verbrauchen, die Stabilität des Internets, als sie oft gefährden, gibt eine Bandbreite-Last, die unelastisch ist. Netzbasierte Mechanismen sind vorgeschlagen worden, um potenzielle Verkehrsstauungszusammenbruch-Effekten der nicht kontrollierten, hohen Rate UDP Verkehrslasten zu minimieren. Netzbasierte Elemente wie Router mit dem Paket Schlange stehende und fallende Techniken sind häufig das einzige Werkzeug, das verfügbar ist, um übermäßigen UDP Verkehr zu verlangsamen. Datagram Congestion Control Protocol (DCCP) wird als eine teilweise Lösung dieses potenziellen Problems durch das Hinzufügen entworfen, dass Ende TCP-freundliches Verkehrsstauungskontrollverhalten zur hohen Rate UDP Ströme wie strömende Medien veranstaltet.

Anwendungen

Zahlreiche Schlüsselinternetanwendungen verwenden UDP, einschließlich: Domain Name System (DNS), wo Abfragen schnell sein und nur aus einer einzelnen Bitte bestehen müssen, die von einem einzelnen Antwort-Paket, Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP) und Dynamic Host Configuration Protocol (DHCP) gefolgt ist.

Stimme und Videoverkehr werden allgemein mit UDP übersandt. Echtzeitvideo und strömende Audioprotokolle werden entworfen, um gelegentliche verlorene Pakete zu behandeln, so nur geringe Degradierung kommt qualitativ, aber nicht große Verzögerungen vor, wenn verlorene Pakete wiederübersandt wurden. Weil sowohl TCP als auch UDP dasselbe Netz durchgehen, finden viele Geschäfte, dass eine neue Zunahme im UDP Verkehr aus diesen Echtzeitanwendungen die Leistung von Anwendungen mit TCP, wie Punkt des Verkaufs, der Buchhaltung und der Datenbanksysteme hindert. Wenn TCP Paket-Verlust entdeckt, wird er zurück seinen Datenrate-Gebrauch erdrosseln. Seitdem sind sowohl schritthaltende als auch kommerzielle Anwendungen für Geschäfte wichtig, das Entwickeln der Qualität von Dienstlösungen wird als entscheidend von einigen gesehen.

Vergleich von UDP und TCP

Übertragungskontrollprotokoll ist ein verbindungsfreies Netzprotokoll, was bedeutet, dass es verlangt, dass handshaking der Länge nach Kommunikationen aufstellt. Sobald eine Verbindung aufgestellt wird, können Benutzerdaten bidirektional über die Verbindung gesandt werden.

• Zuverlässig - führt TCP Nachrichtenanerkennung, Weitermeldung und Pause. Vielfache Versuche, die Nachricht zu liefern, werden gemacht. Wenn es entlang dem Weg verloren wird, wird der Server um den verlorenen Teil wiederbitten. In TCP gibt es entweder keine fehlenden Daten, oder im Falle vielfacher Pausen, die Verbindung ist fallen gelassen.
• Bestellt - wenn zwei Nachrichten über eine Verbindung in der Folge gesandt werden, wird die erste Nachricht die Empfang-Anwendung zuerst erreichen. Wenn Datensegmente in die falsche Ordnung ankommen, puffert TCP in Unordnung Daten, bis alle Daten richtig wiederbestellt und an die Anwendung geliefert werden können.
• Schwergewicht - TCP verlangt, dass drei Pakete eine Steckdose-Verbindung aufstellen, bevor irgendwelche Benutzerdaten gesandt werden können. TCP behandelt Zuverlässigkeits- und Verkehrsstauungskontrolle.
• Einteilung - Daten werden als ein Byte-Strom gelesen, keine unterscheidenden Anzeigen werden übersandt, um Nachricht (Segment) Grenzen Zeichen zu geben.

UDP ist ein einfacheres nachrichtenbasiertes connectionless Protokoll. Protokolle von Connectionless stellen keinen hingebungsvollen der Länge nach Verbindung auf. Kommunikation wird durch das Übertragen der Information in einer Richtung von der Quelle zum Bestimmungsort erreicht, ohne die Bereitschaft oder den Staat des Empfängers nachzuprüfen. Jedoch ist ein primärer Vorteil von UDP über TCP die Anwendung auf das Begleitkommentar-Internetprotokoll (VoIP), wo jeder handshaking klare Sprechverbindung hindern würde. Es wird in VoIP UDP angenommen, dass die Endbenutzer jede notwendige Echtzeitbestätigung zur Verfügung stellen, dass die Nachricht erhalten worden ist.

• Unzuverlässig - Wenn eine Nachricht gesandt wird, kann es nicht bekannt sein, ob es seinen Bestimmungsort erreichen wird; es konnte entlang dem Weg verloren werden. Es gibt kein Konzept der Anerkennung, Weitermeldung oder Pause.
• Nicht bestellt - Wenn zwei Nachrichten demselben Empfänger gesandt werden, kann die Ordnung, in die sie ankommen, nicht vorausgesagt werden.
• Leichtgewichtler - Es gibt keine Einrichtung von Nachrichten, keine Verfolgen-Verbindungen usw. Es ist eine kleine oben auf IP entworfene Transportschicht.
• Datenpakete - Pakete werden individuell gesandt und werden für die Integrität nur überprüft, wenn sie ankommen. Pakete haben bestimmte Grenzen, die auf die Einnahme beachtet werden, bedeutend, dass eine gelesene Operation an der Empfänger-Steckdose eine komplette Nachricht nachgeben wird, weil es ursprünglich gesandt wurde.
• Keine Verkehrsstauungskontrolle - UDP selbst vermeidet Verkehrsstauung nicht, und es ist für hohe Bandbreite-Anwendungen möglich, Verkehrsstauungszusammenbruch auszulösen, wenn sie Verkehrsstauungskontrollmaßnahmen am Anwendungsniveau nicht durchführen.

Siehe auch

• Liste von TCP und UDP Hafen-Zahlen
• Reliable User Datagram Protocol (RUDP)
• SCTP
• Transportprotokoll-Vergleich-Tisch
• UDP Überschwemmung greift an
• UDP Datentransport
• UDP Lite, eine Variante, die Pakete liefern wird, selbst wenn sie missgebildeter sind
• UDP Helfer-Adresse

RFC Verweisungen

• RFC 768 - Benutzerdatenpaket-Protokoll
• RFC 2460 - Internetprotokoll, Spezifizierung der Version 6 (IPv6)
• RFC 2675 - IPv6 Jumbograms
• RFC 4113 - Verwaltungsinformationsbasis für den UDP
• RFC 5405 - Unicast UDP Gebrauch-Richtlinien für Anwendungsentwerfer

Links

• IANA Hafen-Anweisungen
• Die Schwierigkeiten mit UDP, der (PDF) scannt
• Die Depression von UDP rahmt ein
• UDP auf MSDN Zeitschrift-Steckdosen und WCF
• UDP Verbindungen