Diskussion:User Datagram Protocol

Anmerkung

Ich habe diese "Anmerkung" vorerst ausgelagert:

Der "Aufbau einer Verbindung" unter TCP/IP suggeriert einen Sicherheitsaspekt bzw. die Bereitstellung eines absolut sicheren Kanals. Es ist aber auch nach Aufbau einer "Verbindung" keinesfalls sichergestellt, dass ein gesendetes Datenfeld jemals den Empfänger erreicht. Die aufgebaute "Verbindung" ist lediglich eine "Verabredung zur gegenseitigen Aufmerksamkeit" zwischen Sender und Empfänger, die durch unvorhergesehen Ereignisse aber jederzeit gebrochen werden kann (z.B. Stromausfall). Das Handshaking des übergeordneten Transportprotokoll stellt lediglich sicher, dass der Sender mit Sicherheit erfährt, wenn der Empfang der gesendeten Daten nicht den Regeln entsprechend vom Empfänger quittiert wurde. Nicht mehr und nicht weniger. Es ist möglich, dass der Empfänger die Daten vollständig und korrekt erhält, aber der Sender dies nicht erfährt.

Das mag alles stimmen, aber ausgerechnet beim verbindungslosen UDP ist dieser Kommentar m.E. völlig deplaziert. -- Elwood j blues 17:21, 27. Mär 2005 (CEST)

Prüfsummenverfahren

sagt mal, ist es egal welches prüfsummenverfahren man bei udp verwendet (wird die prüfsumme also nur von dem zielprogramm ausgewerdet), oder muss da ein vorgeschriebenes verfahren verwendet werden, weil es sonst vorkommen könnte das n zwichengelagerter server (oder ähnliches) die prüfsumme als falsch ansieht und das packet raushaut? -- SK-Genius 16:23, 6. Aug 2006 (CEST)

NTP UDP

Um keine weiteren Mißverständnisse aufkommen zu lassen: NTP kann auch TCP verwenden. Es ist sowohl 123/udp als auch 123/tcp in der well known ports-Liste--Hubi 15:16, 6. Dez. 2006 (CET)

UDP kann auch Duplikate haben

Bei den verbleibenden Kommunikationsproblemen von UDP fehlte in der Aufzählung, dass Pakete auch doppelt eintreffen können. (Und zwar fehlt diese Angabe genau seit hier: [1]) Die englische Version hat's richtig: UDP garantiert zwar die Korrektheit der Payload (über die Checksum), aber die verbleibenden Probleme sind genau drei:

• Geänderte Reihenfolge (out-of-order delivery)
• Paketverlust
• Empfang von Duplikaten.

Und wer unbedingt ein Beispiel braucht, wie ein Duplikat entstehen kann: Man stelle sich ein tieferes (PHY-) Layer vor, welches ein Paket korrekt empfängt und dies bestätigt, aber dessen ACK geht dann verloren. Sodann wird das Sende-Layer das Paket ein zweites Mal senden. Voila, hier ist das Duplikat. --Cstim 14:15, 7. Mär. 2008 (CET)

Fehler bezüglich Mindestgröße des UDP-Headers?

Auszug: "Im Falle des Internet Protocols (IP) können Datenpakete maximal 65535 Bytes lang sein, wovon der IP-Header und UDP-Header insgesamt mindestens 28 Bytes belegen."

Auszug: "Der UDP-Header besteht aus vier Datenfeldern, die alle jeweils 16 Bit groß sind"

Auszug: "Der Pseudo-Header hat bei IPv4 eine Größe von 12 Byte und setzt sich zusammen aus ..."

16 Bit + 12 Byte = (mind.) 28 Bytes ??? (Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 193.196.4.236 (Diskussion • Beiträge) 13:54, 17. Nov. 2008 (CET))

Der Pseudo-Header wird nicht übermittelt, sondern dient nur zu Berechnung der Prüfsumme. Ein IPv4-Paket hat mindestens 20 Byte. Damit stimmt alles. --Fomafix 19:59, 17. Nov. 2008 (CET)

Oktett versus Byte

In der Erklärung des Längenfelds im Abschnitt UDP-Datagramm wird der Begriff Oktett verwendet, sonst überall Byte. Hat das einen besonderen Sinn? Mbutscher 22:06, 2. Feb. 2009 (CET)

Ein Oktett ist das selbe wie ein Byte! :) --41.66.98.77 15:56, 15. Feb. 2024 (CET)

Maximale Größe eines Segments

Im Artikel steht dazu folgendes:

"UDP übernimmt die Eigenschaften der darunterliegenden Vermittlungsschicht. Im Falle des Internet Protocols (IP) können Datenpakete maximal 65535 Bytes lang sein, wovon der IP-Header und UDP-Header insgesamt mindestens 28 Bytes belegen. UDP-Datagramme haben daher maximal 65507 Nutzdatenbytes. Solche Pakete werden jedoch von IP fragmentiert übertragen."

Das ist doch aber falsch. Die max. Größe von UDP-Segmenten ist doch völlig unabhängig von irgendeinem anderen Protokoll. Die max. Größe beträgt 65.535 Byte, denn das ist der max. Wert des Length-Feldes im UDP-Header. Segmente dieser Größe können auch noch mit IP übertagen werden, denn IP kann Datenblöcke bis zu einer Größe von eben genau 65.535 fragmentiert übertragen (13-bit FragmentOffset-Feld im IP-Header). Somit ist die Aussage gleich doppelt falsch, denn die max. Größe ist 1. genau festgelegt und 2. können sich auch größere UDP-Segmente als 65.515 Byte große mit IP übertragen lassen. Oder bin ich falsch? (nicht signierter Beitrag von 91.89.188.37 (Diskussion) 19:51, 5. Nov. 2010 (CET))

Wozu Prüfsumme?

Ethernet hat doch bereits eine Prüfsumme eingebaut und vermutlich andere Protokolle auf Schicht 1/2 ebenfalls. Wozu gibt es also diese zweite Prüfsumme. Wie wahrscheinlich ist es, dass die von Ethernet stimmt und die von UDP nicht - wohl praktisch unmöglich, oder? -- 81.10.203.175 22:22, 26. Aug. 2011 (CEST)

UDP kann auch über andere Physikalische Schichten übertragen werden. Grundsätzlich sollten Protokoll Schichten als unabhängig betrachtet werden, somit auch ihre eigenen Prüfsummen haben. Schichten-übergreifende Optimierung :sollte vermieden werden, da es die Protokoll Flexibilität reduziert. (nicht signierter Beitrag von 87.123.199.135 (Diskussion) 08:46, 8. Apr. 2014 (CEST))

Da die Prüfsumme vom UDP ja auch Informationen aus dem IP beinhaltet, kann UDP also nicht über andere Schichten übertragen werden, jedenfalls kann keine Prüfsumme gebildet werden?! --MA-Maddin (Diskussion) 19:12, 4. Mai 2017 (CEST)

Datagramm = Datensegment?

Der Begriff "Segment" suggeriert hier eine Ordnung, die gerade bei UDP (im Gegensatz etwa zu TCP) nicht gegeben ist. TCP überträgt die Daten in einer geordneten Reihenfolge von Segmenten. Die Datagramme bei UDP stehen dagegen für sich. In meinen Fachbüchern steht grundsätzlich "Datagramm", Google findet bei der Suche nach "Benutzerdatensegmentprotokoll" auch nur Wikipedia und Klone... also, wenn keine gut begründeten Einwände kommen, ändere ich das. --NurDieHalbeWahrheit (Diskussion) 08:30, 19. Nov. 2014 (CET)

Prüfsumme doch keine Integritätsprüfung?

Unter Funktionsweise steht: "Zusätzlich bietet UDP die Möglichkeit einer Integritätsüberprüfung an, indem eine Prüfsumme mitgesendet wird. Dadurch kann eine fehlerhafte Übertragung erkannt werden."

Danach steht dann aber: "Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen."

Wenn ich aber doch eine Prüfsumme über die Daten x bilde, dann kann ich doch genau damit erkennen, ob die Daten x unverändert sind (indem der Empfänger wieder eine Prüfsumme über die Daten x bildet).

Wieso gibts dann keine Garantie dafür das die Daten unverfälscht sind? Bei TCP gibt schließlich auch Prüfsummen und da gibts die Garantie ja auch.... (nicht signierter Beitrag von Jimbov360v (Diskussion | Beiträge) 23:34, 30. Nov. 2014 (CET))

Wenn auf der Strecke ein Datenpaket abgefangen und ersetzt wird hilft dir weder bei TCP noch bei UDP die Prüfsumme. --Kgfleischmann (Diskussion) 06:42, 1. Dez. 2014 (CET)

Okay aber dann ist der Satz falsch: "Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen."

dann müsste es heißen:

"Es gibt auch keine Gewähr dafür, dass die Daten unzugänglich für Dritte beim Empfänger eintreffen oder das komplette Datenpaket vor dem Eintreffen manipultiert wird."

das mit dem Wort unverfälscht zu beschreiben ist ziemlich verwirrend. (nicht signierter Beitrag von Jimbov360v (Diskussion | Beiträge) 12:39, 1. Dez. 2014 (CET))

Wieso ist tatsächlich verfügbare Länge der Nutzdaten mit IPv6 um 20 Bytes höher als mit IPv4?

Im Artikel steht "Die tatsächlich verfügbare Länge der Nutzdaten ist bedingt durch das zugrundeliegende IP-Protokoll jedoch auf 65.507 Bytes (65.535 – 8 Byte UDP Header – 20 Byte IP Header) bei Verwendung von IPv4 und 65.527 Bytes bei Nutzung von IPv6 beschränkt". Im verlinkten RFC steht das für IPv6 auch so, aber müsste der Wert für IPv6 nicht eigentlich 20 Bytes kleiner als der Wert für IPv4 sein, da der IPv6 Header um 20 Bytes größer ist, als der IPv4 Header? Ist das ein Fehler im RFC? (nicht signierter Beitrag von 2003:C5:BD7:8400:9072:6A51:A2D5:D025 (Diskussion | Beiträge) 20:02, 9. Apr. 2017 (CEST))

Das Längen-Feld des IPv4-Paketes definiert die Gesamtgröße des IP-Paketes (also Header + Nutzdaten)

Das Längen-Feld des IPv6-Paketes definiert nur die Größe der Nutzdaten.

Im Vergleich zu IPv4 stehen den Nutzdaten im IPv6-Paket also diese 20 Byte (IPv4-Header-Größe) mehr zur Verfügung!

--MA-Maddin (Diskussion) 01:39, 5. Mai 2017 (CEST)

Grund der Einführung von UDP

Seit der Bearbeitung vom 25.08.2006 [[2]] steht im Artikel "Die Entwicklung von UDP begann 1977, als man für die Übertragung von Sprache ein einfacheres Protokoll benötigte als das bisherige verbindungsorientierte TCP. ...". Eine Quelle wurde seit dem nicht hinzugefügt. Ich halte den Passus schlicht für falsch.

• 1977 war noch keine Rede von Sprachübermittlung über IP. Das kam erst viele Jahre später.
• Die RFC für TCP wurde erst nach UDP fertig (1981).
• In der RFC zu UDP steht, dass die Hauptanwendungen der "Internet File Server" und der "Trivial File Transfer" sind.

Falls keine Quellen für den Abschnitt geliefert werden, werde ich diesen ändern. --Uweschwoebel (Diskussion) 21:10, 21. Aug. 2019 (CEST)

Ich bin genauso überrascht wie du. Ich kann mich noch gut daran erinnern, wie die ersten Pakete mit Sprache im Internet übertragen worden sind und da gab es UDP schon seit gefühlten Jahrzehnten. Ich bin auch dafür diesen Satz zu entfernen.--2003:E9:9709:930B:DDFE:141F:A037:9AAC 20:57, 1. Mär. 2024 (CET)

Änderungsvorschlag: Spezial:Diff/242724213 --Matthäus Wander 23:05, 1. Mär. 2024 (CET)

Dem Vorschlag kann ich zustimmen. Danke für die Änderung!--2003:E9:9709:937B:2F7C:76A0:3876:9D23 18:09, 3. Mär. 2024 (CET)