2
UDP Flusskontrolle?
Ich weiß UDP hat keine Flusskontrolle. Aber was passiert eigentlich bei folgendem Beispiel?
Ich möchte eine sehr große gespeicherte Datenmenge per UDP senden. Der PC ist mit Gigabit Ethernet an den Router angebunden. Der Router hat aber nur ne 10Mbit Internet-Leitung.
Der PC würde dann ja die Daten mit 1 Gigabit/Sekunde an den Router übertragen. Der kommt natürlich mit dem Senden nicht hinterher, der Puffer läuft über und alle Daten sind kaputt. Passiert das auch so in der Praxis? Wie und wo wird kontrolliert, dass so eins Übertragung doch korrekt läuft? Wenn der PC einfach langsamer senden würde, gäbe es ja gar kein Problem.
Führt irgend eine Komponente da doch eine Flusskontrolle durch oder geht sowas wirklich immer in die Hose?
Ich möchte eine sehr große gespeicherte Datenmenge per UDP senden. Der PC ist mit Gigabit Ethernet an den Router angebunden. Der Router hat aber nur ne 10Mbit Internet-Leitung.
Der PC würde dann ja die Daten mit 1 Gigabit/Sekunde an den Router übertragen. Der kommt natürlich mit dem Senden nicht hinterher, der Puffer läuft über und alle Daten sind kaputt. Passiert das auch so in der Praxis? Wie und wo wird kontrolliert, dass so eins Übertragung doch korrekt läuft? Wenn der PC einfach langsamer senden würde, gäbe es ja gar kein Problem.
Führt irgend eine Komponente da doch eine Flusskontrolle durch oder geht sowas wirklich immer in die Hose?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 375095
Url: https://administrator.de/contentid/375095
Ausgedruckt am: 13.11.2024 um 01:11 Uhr
2 Kommentare
Neuester Kommentar
Bei UDP würde der Router einfach die Pakete weiter routen, die er durch die Leitung bekommt, den Überschuss Buffern bis der Buffer voll ist und was dann weder durch die Leitung noch in den Buffer passt, wird dann einfach verworfen.
Möglicherweise sendet der Router eine ICMP Source-Squench-Nachricht und möglicherweise reagiert der Client darauf.
Wenn nicht, ist das halt Pech.
Deshalb nutzt man für größere Datenmengen/Bandbreiten bevorzugt TCP oder DCCP oder es gibt Anwendungsspezifisch auf Layer 5-7 eine Art Flusskontrolle.
Bei RTP-Datenströmen nutzt du z.B. den Aufsatz "RTCP", wobei da einfach alle X Sekunden ein Paket mit Statistiken an die Gegenstelle geschickt wird, wie viele Pakete verloren/defekt empfangen wurden, so dass man Gegenseitig da regulieren könnte.
Möglicherweise sendet der Router eine ICMP Source-Squench-Nachricht und möglicherweise reagiert der Client darauf.
Wenn nicht, ist das halt Pech.
Deshalb nutzt man für größere Datenmengen/Bandbreiten bevorzugt TCP oder DCCP oder es gibt Anwendungsspezifisch auf Layer 5-7 eine Art Flusskontrolle.
Bei RTP-Datenströmen nutzt du z.B. den Aufsatz "RTCP", wobei da einfach alle X Sekunden ein Paket mit Statistiken an die Gegenstelle geschickt wird, wie viele Pakete verloren/defekt empfangen wurden, so dass man Gegenseitig da regulieren könnte.
UDP hat wie oben schon richtig gesagt bekanntlich per Design keinerlei Congestion- oder Flußkontrolle und es gibt keinerlei Segmentierung.
Zusätzlich gibt es keinerlei Handshaking oder Retransmission Kontrolle bei UDP. Das Protokoll an sich hat also schlicht "keine Ahnung" davon ob die gesendeten Pakete am Ziel ankommen oder nicht.
All sowas müsste dann die Anwendung kontrollieren die den UDP Socket benutzt. Außer dem oben genannten RTCP gibt es z.B. ein neues, noch experimentelles Protokoll QUIC
https://de.wikipedia.org/wiki/Quick_UDP_Internet_Connections
https://www.heise.de/ct/ausgabe/2018-9-Jana-Iyengar-ueber-das-kommende-I ...
Was diese Defizite ausgleichen könnte und die Übertragung damit effizienter machen kann.
Damit obligt aber die vollständige Kontrolle dem Endgerät bzw. der Applikation und nicht mehr dem Protokoll an sich wie bei TCP.
In deinem Falle schmeisst der Router einfach die Pakete wech die er nicht mehr loswerden kann in der Inbound Queue. Der Empfänger bekommt dann eben nur das was der Router oder ein Switch oder irgendein anderes Netzwerk Gerät zw. Sender und Empfänger noch übertragen kann. Siehe die bekannten Sprachaussetzer bei VoIP wo UDP Pakete mit Sprachdaten auf dem Wege zum Ziel verloren gehen.
Eine rudimentäre "Rettung" mit ICMP Source Quench wie Kollege @LordGurke oben schon erwähnt hat ist eher die seltene Ausnahme. Ganz besonders im Consumer Bereich.
Nimm dir einen Wireshark zur Hand dann könntest du das UDP Verhalten auch selber live und kostenlos erleben !
Zusätzlich gibt es keinerlei Handshaking oder Retransmission Kontrolle bei UDP. Das Protokoll an sich hat also schlicht "keine Ahnung" davon ob die gesendeten Pakete am Ziel ankommen oder nicht.
All sowas müsste dann die Anwendung kontrollieren die den UDP Socket benutzt. Außer dem oben genannten RTCP gibt es z.B. ein neues, noch experimentelles Protokoll QUIC
https://de.wikipedia.org/wiki/Quick_UDP_Internet_Connections
https://www.heise.de/ct/ausgabe/2018-9-Jana-Iyengar-ueber-das-kommende-I ...
Was diese Defizite ausgleichen könnte und die Übertragung damit effizienter machen kann.
Damit obligt aber die vollständige Kontrolle dem Endgerät bzw. der Applikation und nicht mehr dem Protokoll an sich wie bei TCP.
In deinem Falle schmeisst der Router einfach die Pakete wech die er nicht mehr loswerden kann in der Inbound Queue. Der Empfänger bekommt dann eben nur das was der Router oder ein Switch oder irgendein anderes Netzwerk Gerät zw. Sender und Empfänger noch übertragen kann. Siehe die bekannten Sprachaussetzer bei VoIP wo UDP Pakete mit Sprachdaten auf dem Wege zum Ziel verloren gehen.
Eine rudimentäre "Rettung" mit ICMP Source Quench wie Kollege @LordGurke oben schon erwähnt hat ist eher die seltene Ausnahme. Ganz besonders im Consumer Bereich.
Nimm dir einen Wireshark zur Hand dann könntest du das UDP Verhalten auch selber live und kostenlos erleben !
