Datenverlust

Kurz: Der Zustand, wenn Datenpakete auf dem Weg vom Sender zum Empfänger nicht ankommen — z. B. durch überlastete Leitungen, Störungen oder defekte Hardware.

Genauer: Bei TCP wird Datenverlust erkannt und das Paket automatisch erneut gesendet, bei UDP nicht — hier muss die Anwendung selbst entscheiden, ob und wie sie damit umgeht (z. B. kurzer Bildaussetzer bei Streaming statt Warten auf Nachlieferung). Wird häufig in Prozent der gesendeten Pakete angegeben (“Packet Loss”).

Im Detail

Die drei Hauptursachen

Die häufigsten Ursachen für Datenverlust im Netzwerk lassen sich grob in drei Gruppen einteilen. Überlastung ist die häufigste: Ein Router oder Switch bekommt mehr Pakete als er in seinem begrenzten Zwischenspeicher (Buffer) halten oder weiterleiten kann und verwirft überschüssige Pakete (“Congestion Drop” oder “Tail Drop”) — das passiert typischerweise an Engpässen, wo eine schnelle Leitung in eine langsamere mündet. Physische Störungen sind die zweite Gruppe: defekte oder schlecht geschirmte Kabel, elektromagnetische Interferenz bei WLAN (z. B. durch andere Funkquellen im selben Frequenzband), oder schlicht fehlerhafte Hardware wie ein alternder Switch-Port. Die dritte Gruppe ist absichtliches Verwerfen durch Firewalls oder Quality-of-Service-Regeln (QoS), die bestimmten Traffic bei Engpässen bewusst niedriger priorisieren oder sogar komplett blockieren, etwa um kritischen Anwendungen wie Videotelefonie Vorrang vor weniger zeitkritischem Traffic wie Software-Updates zu geben.

Reaktion je nach Transportprotokoll

Wie stark sich Datenverlust auswirkt, hängt entscheidend vom Transportprotokoll ab. TCP erkennt fehlende Pakete über ausbleibende ACKs (bzw. Duplicate ACKs) und sendet sie automatisch erneut — für die Anwendung bleibt der Verlust dadurch grundsätzlich unsichtbar, kostet aber Zeit (Retransmission-Delay) und kann bei hoher Verlustrate den gesamten Durchsatz drastisch einbrechen lassen, weil TCPs Flow-Control-Mechanismus (genauer: die Congestion-Control-Algorithmen wie CUBIC oder BBR) Paketverluste als Überlastsignal interpretiert und die Sendegeschwindigkeit deutlich drosselt, um das Netz nicht weiter zu überlasten. Ab einer bestimmten Verlustrate (oft schon ab wenigen Prozent) bricht der TCP-Durchsatz überproportional ein, weil sich Sender und Empfänger ständig in einem Zyklus aus Beschleunigen und erneutem Drosseln befinden.

UDP dagegen kümmert sich überhaupt nicht um verlorene Pakete — es gibt weder Bestätigung noch automatische Neuübertragung. Bei Video-Streaming äußert sich das als kurzer Bildfehler oder Ruckler statt als spürbare Verzögerung, was für Echtzeitanwendungen (VoIP, Online-Gaming, Live-Streaming) oft der bessere Kompromiss ist als TCPs Warten auf eine Nachlieferung, die ohnehin schon zu spät käme, um noch nützlich zu sein — ein veraltetes nachgeliefertes Videobild bringt niemandem etwas.

Messgrößen und typische Schwellenwerte

Packet Loss wird üblicherweise als Prozentsatz der insgesamt gesendeten Pakete angegeben. Als grobe Richtwerte gelten: unter 1 % meist unbemerkt, 1–2,5 % bereits spürbar bei Echtzeitanwendungen (leichte Aussetzer bei Videocalls), über 5 % macht Videotelefonie oder Online-Gaming praktisch unbrauchbar. Reine Web-/Streaming-Nutzung verträgt vergleichsweise mehr Verlust, weil TCP und Pufferung viel davon kompensieren können.

Diagnose-Tools

In der Praxis lässt sich Packet Loss mit Tools wie ping (zeigt die Verlustrate über mehrere Anfragen, allerdings nur für ICMP-Traffic, der von Firewalls anders behandelt werden kann als der eigentliche Anwendungstraffic) oder mtr/traceroute diagnostizieren — letztere zeigen zusätzlich, auf welchem konkreten Hop im mehrstufigen Übertragungsweg der Verlust tatsächlich auftritt, was die Eingrenzung des Problems (eigenes Netz, ISP, oder Zielserver) erheblich erleichtert.

Siehe auch: Flow-Control, TCP, UDP, Latenz