Packet Loss messen und analysieren – warum Pings oft lügen und Wireshark die Wahrheit sagt

Der Admin pingt den Server. Antwortzeit: 2 ms. Paketverlust: 0 %. Alles grün. Und trotzdem rufen die Kollegen aus dem Vertrieb an, weil ihre CRM-Anwendung wieder hängt und der RDP-Desktop ruckelt wie ein Diaprojektor aus den 90ern. Dieses Szenario ist kein Einzelfall, sondern Alltag. Der Ping lügt nicht, aber er erzählt nur einen kleinen Teil der Wahrheit. Er testet einen einzigen Protokolltyp mit winzigen Paketen in großen Abständen. Produktiver Traffic dagegen besteht aus vollen Segmenten, kommt in Schüben, wird anders priorisiert, nimmt unter Umständen einen anderen Pfad und trifft auf ganz andere Engpässe. In diesem Artikel erfährst du, warum ICMP-Pings als Diagnosewerkzeug an ihre Grenzen stoßen, wie echter Paketverlust entsteht, wie du Packet Loss messen kannst und wie du ihn mit Wireshark zuverlässig nachweist und lokalisierst.

---

Warum der Ping als Diagnosewerkzeug trügt

ICMP wird von Netzwerkgeräten anders behandelt als TCP oder UDP. Router und Firewalls beantworten Pings, die an sie selbst gerichtet sind, über ihre CPU (Control Plane) – nicht über die Hardware, die den eigentlichen Datenverkehr weiterleitet. QoS-Regeln ordnen ICMP häufig einer anderen Warteschlange zu als deinen produktiven Traffic. Und eine UTM-Appliance kann Pings einwandfrei durchlassen, während sie beim Inspizieren von TLS-Verbindungen längst am Limit ist. Dazu kommen drei Eigenschaften, die im Alltag gern übersehen werden:

• Ping-Pakete sind klein. Standardmäßig 32 Byte (Windows) bzw. 56 Byte (Linux) Nutzdaten. Probleme, die nur volle 1500-Byte-Pakete treffen – etwa MTU-Fehler oder überlaufende Puffer –, bleiben unsichtbar.
• Ping ist langsam. Ein Paket pro Sekunde. Ein kurzer Engpass, der für 50 Millisekunden Pakete verwirft, fällt da mit hoher Wahrscheinlichkeit einfach durchs Raster.
• Ping nimmt nicht zwingend denselben Weg. Bei Lastverteilung über mehrere Leitungen (ECMP, Port-Channels) entscheidet ein Hash über Adressen und Ports, welchen Weg ein Paket nimmt. ICMP hat keine Ports – und landet unter Umständen auf einer anderen, gesunden Leitung als die betroffene TCP-Verbindung.

Ping misst also ICMP-Erreichbarkeit, keine Verbindungsqualität. Ob TCP-Verbindungen unter Last stabil bleiben und ob im produktiven Datenstrom Pakete verloren gehen, sagt er dir nicht. Das klassische Fehlerbild: Ping zeigt 0 % Verlust und 3 ms Antwortzeit, die Anwendung hängt trotzdem. Der Admin sagt: „Das Netz ist in Ordnung.“ Die Anwender sagen das Gegenteil. Beide haben aus ihrer Sicht Recht – gemessen wird nur das Falsche. Genau an dieser Stelle beginnt das typische Fingerpointing zwischen Netzwerk- und Applikationsteam. Wenn du schon pingst, dann mit großen Paketen und über einen längeren Zeitraum: Windows: Linux:

---

Was Packet Loss wirklich bedeutet

Paketverlust bedeutet, dass IP-Pakete den Weg vom Sender zum Empfänger nicht vollständig zurücklegen. Sie werden irgendwo auf dem Pfad verworfen – von einem vollen Puffer, einer defekten Leitung, einer Firewall unter Last oder vom Empfänger selbst. Grundsätzlich lassen sich zwei Verlusttypen unterscheiden:

• Sporadischer Verlust: Tritt unregelmäßig auf – durch kurzzeitige Überlast, Funkstörungen im WLAN oder Hardware, die nur unter bestimmten Bedingungen Fehler produziert. Genau deshalb oft monatelang ungelöst.
• Systematischer Verlust: Reproduzierbar und konsistent – oft durch eine fehlerhafte Konfiguration, einen Duplex-Mismatch oder eine dauerhaft überlastete Leitung.

Wie TCP auf Paketverlust reagiert

TCP bemerkt Verlust auf zwei Wegen – und beide kosten Performance:

• Fast Retransmit: Kommen beim Sender drei Duplicate ACKs an, schließt er auf ein verlorenes Segment und sendet es sofort erneut, ohne auf einen Timeout zu warten. Gleichzeitig verkleinert er das Congestion Window – je nach Algorithmus etwa auf die Hälfte (Reno) oder auf rund 70 % (CUBIC). Der Durchsatz sinkt, die Verbindung läuft aber weiter.
• Retransmission Timeout (RTO): Kommen keine Duplicate ACKs, wartet der Sender auf den Ablauf eines Timers. Das passiert, wenn das letzte Paket einer Übertragung verloren geht, wenn mehrere Pakete am Stück fehlen – und besonders häufig bei interaktiven Anwendungen, die nur wenige Pakete auf einmal senden. RFC 6298 empfiehlt als Untergrenze eine Sekunde, Linux arbeitet mit 200 ms, Windows mit rund 300 ms. Geht dasselbe Segment erneut verloren, verdoppelt sich der Timer jedes Mal. Danach startet die Verbindung mit minimalem Congestion Window praktisch neu.

Für den Anwender ist der RTO der eigentliche Schmerz: Die Anwendung steht für Hunderte Millisekunden still. Schon eine Handvoll solcher Ereignisse pro Minute macht eine interaktive Anwendung praktisch unbenutzbar – auch wenn die Verlustrate lächerlich klein aussieht. Die Unterschiede im Detail erkläre ich im Artikel TCP Retransmissions, Dup ACKs und Out-of-Order – was die Unterschiede wirklich bedeuten.

Wie stark bremst Paketverlust den Durchsatz?

Für eine einzelne TCP-Verbindung gibt es eine bekannte Faustformel nach Mathis et al. Sie schätzt den maximal erreichbaren Durchsatz in Abhängigkeit von Segmentgröße (MSS), Laufzeit (RTT) und Verlustrate (p):

Max. Durchsatz ≈ (MSS / RTT) × (1,22 / √p)

Ein Rechenbeispiel mit einer MSS von 1460 Byte und einer RTT von 20 ms, wie sie zwischen zwei Standorten typisch ist: Die Formel bildet das klassische Reno-Verhalten ab; CUBIC schneidet etwas besser ab, BBR reagiert auf einzelne Verluste kaum (siehe Vergleich der TCP-Congestion-Control-Algorithmen). Die Größenordnung stimmt trotzdem: Schon 0,1 % Verlust deckeln eine einzelne Verbindung über eine WAN-Strecke auf einen Bruchteil der Bandbreite – egal ob die Leitung 100 Mbit/s oder 1 Gbit/s hat. Zusätzlich begrenzt die Fenstergröße den Durchsatz, siehe TCP Window Size und Scaling einfach erklärt.

Ab wann merken Anwender den Verlust?

• VoIP und Video (RTP über UDP): Verlorene Pakete werden nicht erneut gesendet, sie sind einfach weg. Moderne Codecs kaschieren einzelne Verluste mit Packet Loss Concealment. Gleichmäßig verteilter Verlust wird in der Praxis ab etwa 1 % hörbar, gebündelter Verlust – mehrere Pakete am Stück – deutlich früher.
• RDP und Citrix: Klassisches RDP und ICA laufen über TCP. Jedes fehlende Segment hält den gesamten Datenstrom an, bis es wiederholt wurde – das Bild friert ein, Eingaben hängen nach. Spürbar wird das schon im Promillebereich. Die UDP-Transporte (RDP über UDP, Citrix EDT) gehen mit Verlust meist besser um, beseitigen das Problem aber nicht.
• Dateitransfer und Datenbankzugriffe über TCP: Die Daten kommen vollständig an, aber der Durchsatz bricht ein. Bei Anwendungen mit Tausenden kleinen Abfragen summiert sich jeder RTO schnell zu Sekunden.

---

Packet Loss messen – welches Werkzeug was kann

Vor dem Mitschnitt liefern einige Werkzeuge schnell eine erste Einschätzung. Jedes sieht nur einen Ausschnitt – entscheidend ist, zu wissen, welchen.

mtr und pathping richtig lesen

Der häufigste Fehler: Ein Hop in der Mitte zeigt 30 % Verlust – und schon steht der Schuldige fest. Meistens zu Unrecht. Router begrenzen die Rate, mit der sie selbst ICMP beantworten, um ihre CPU zu schützen. Verlust an einem Zwischen-Hop ist nur dann echt, wenn er sich bis zum Ziel fortsetzt. Zeigt das Ziel 0 %, leitet der Hop einwandfrei weiter. mtr kann außerdem mit TCP statt ICMP messen und kommt damit dem echten Traffic näher (benötigt Root-Rechte):

Verlust unter Last mit iperf3 messen

Viele Verluste entstehen erst unter Last. iperf3 erzeugt gezielt Traffic zwischen zwei Endpunkten: Im UDP-Modus zeigt die Zusammenfassung Lost/Total Datagrams, im TCP-Modus die Spalte Retr die Retransmissions. Wähle die Bandbreite unterhalb der Leitungskapazität und teste außerhalb der Hauptzeit – sonst misst du den Verlust, den du selbst erzeugst.

Zähler auf Netzkomponenten und Hosts

• Interface-Statistiken der Netzkomponenten: CRC- bzw. FCS-Fehler, Input Errors, Output Drops und Discards. CRC-Fehler deuten auf Kabel, SFP-Module oder Duplex-Probleme hin, Output Drops auf einen überlasteten Port. Fehlerhafte Frames verwirft bereits die Netzwerkkarte – im Wireshark-Capture tauchen sie nie auf.
• TCP-Statistiken auf dem Host: Unter Windows zeigt netstat -s -p tcp den Wert Segments Retransmitted, unter Linux liefern nstat -az TcpRetransSegs oder ss -ti (pro Verbindung) die entsprechenden Zahlen. Vergleiche zwei Abfragen im Abstand einiger Minuten – der Wert seit Systemstart sagt wenig.

Diese Werkzeuge sagen dir, ob Verlust auftritt. Wo und in welcher Verbindung, zeigt erst der Paketmitschnitt.

---

Packet Loss mit Wireshark nachweisen

Den richtigen Capture-Punkt wählen

Der häufigste Fehler bei der Wireshark-Analyse ist ein falsch gewählter Capture-Punkt. Wo du mitschneidest, bestimmt, was du siehst:

• Beim Sender siehst du keine Lücken im Datenstrom – er hat ja alles verschickt. Du siehst aber die Reaktion: Duplicate ACKs vom Empfänger und die anschließenden Retransmissions.
• Beim Empfänger siehst du die Lücken direkt, denn die fehlenden Segmente kommen schlicht nicht an.
• Dazwischen siehst du Lücken nur dann, wenn der Verlust vor deinem Capture-Punkt passiert ist. Genau das nutzt du später bei der Lokalisierung.

Die sauberste Methode ist ein Netzwerk-TAP. Ein gespiegelter Port (SPAN/Mirror Port) funktioniert auch, hat aber einen Haken: Wird mehr Traffic gespiegelt, als der Zielport transportieren kann – eine ausgelastete 1-Gbit-Leitung ergibt in beide Richtungen zusammen bis zu 2 Gbit/s –, verwirft der Switch Pakete im Mirror. Dann siehst du Verlust, den es im Netz gar nicht gibt. Ohne TAP arbeitest du mit parallelen Captures auf Client und Server. Achtung: Firewalls, die Sequenznummern zufällig neu vergeben (z. B. Cisco ASA) oder per NAT umschreiben, machen den direkten Vergleich schwieriger.

Zuerst prüfen: Hat der Mitschnitt selbst Pakete verloren?

Bevor du dem Netz Paketverlust bescheinigst, schließ den eigenen Mitschnitt als Ursache aus:

• Unter Statistics → Capture File Properties zeigt Wireshark, ob beim Aufzeichnen Pakete verworfen wurden (Dropped).
• Der Hinweis „ACKed segment that wasn’t captured“ (Filter tcp.analysis.ack_lost_segment) bedeutet: Der Empfänger bestätigt Daten, die dein Mitschnitt nie gesehen hat. Die Daten sind also angekommen – gefehlt hat das Paket nur im Capture, nicht im Netz.
• Bei Mitschnitten direkt auf Servern verfälschen Offloading-Funktionen der Netzwerkkarte (TSO, LRO) das Bild: Du siehst riesige Segmente, die so nie über die Leitung gegangen sind.

Sequenznummern analysieren: Lücken im Stream erkennen

TCP nummeriert nicht Pakete, sondern jedes einzelne Byte im Datenstrom. Jedes Segment trägt im Header die Sequence Number seines ersten Bytes, dazu kommt die Länge der Nutzdaten. Daraus ergibt sich, mit welcher Sequenznummer das nächste Segment beginnen muss – Wireshark zeigt diesen Wert als Next Sequence Number an. Ein Beispiel: Ein Segment mit Seq=1000 und 500 Byte Nutzdaten enthält die Bytes 1000 bis 1499. Das nächste Segment muss also mit Seq=1500 beginnen. Folgt stattdessen ein Segment mit Seq=2000, fehlen die Bytes 1500 bis 1999 – irgendwo auf dem Weg ist ein Segment verloren gegangen. Diese Rechnung musst du nicht selbst machen. Wireshark erkennt solche Sprünge automatisch, markiert das Folgesegment mit „TCP Previous segment not captured“ und hebt es mit der Farbregel „Bad TCP“ (schwarzer Hintergrund, rote Schrift) hervor. Grafisch zeigt Statistics → TCP Stream Graphs → tcptrace Lücken und Retransmissions als Sprünge im Verlauf. Mehr dazu im Artikel Wie lese ich einen TCP Stream richtig?

Die wichtigsten Wireshark-Filter

Für die Suche nach Verlustsignalen brauchst du vor allem diese Filter (einen allgemeinen Überblick bietet der Artikel die wichtigsten Wireshark-Filter im Alltag): Zeigt Segmente, vor denen eine Lücke in den Sequenznummern liegt. Das ist das direkteste Signal für Paketverlust vor dem Capture-Punkt – vorausgesetzt, der Mitschnitt selbst ist vollständig. Duplicate ACKs sind die Art des Empfängers zu sagen: „Mir fehlt etwas.“ Sie tauchen auch in Mitschnitten auf der Senderseite auf und sind dort oft das erste Verlustsignal. Zeigt alle Retransmissions einschließlich der Fast Retransmissions. Achtung: Eine Retransmission ist die Reaktion auf Verlust, nicht der Verlust selbst. Unnötige Wiederholungen: Die Daten waren längst angekommen, aber ACKs gingen verloren oder der Timer lief wegen Laufzeitschwankungen zu früh ab. Viele Spurious Retransmissions deuten eher auf Latenzspitzen als auf Datenverlust hin. Segmente in falscher Reihenfolge, etwa durch Lastverteilung über mehrere Pfade. Wireshark entscheidet hier über eine Zeit-Heuristik und stuft auch manche schnelle Retransmission so ein – im Zweifel den Stream prüfen. Der Sammelfilter für den ersten Überblick über einen unbekannten Mitschnitt.

Expert Information auswerten

Unter Analyze → Expert Information siehst du auf einen Blick, wie viele Lost Segments, Duplicate ACKs und Retransmissions der Mitschnitt enthält. Entscheidend ist dabei das Verhältnis, nicht die absolute Zahl. 300 Retransmissions in einem Mitschnitt mit fünf Millionen Paketen sind etwas völlig anderes als 300 Retransmissions bei 20.000 Paketen. Und: Die Expert Information liefert Hinweise auf Basis von Heuristiken, keine fertigen Befunde.

I/O-Graph: Verlustmuster zeitlich darstellen

Der I/O-Graph (Statistics → I/O Graphs) zeigt Retransmissions als Zeitreihe – am besten mit einer zweiten Kurve für den Gesamtdurchsatz. So erkennst du, ob Verlust gleichmäßig auftritt oder mit Lastspitzen, Backup-Fenstern oder Cronjobs zusammenfällt. Stell das Intervall auf 100 ms oder feiner, sonst verschwinden kurze Spitzen im Durchschnitt.

---

Paketverlust lokalisieren – wo im Netz steckt das Problem?

Packet Loss nachzuweisen ist der erste Schritt. Den genauen Entstehungsort zu finden ist die eigentliche Diagnosearbeit. Die Methode funktioniert wie eine binäre Suche entlang der Datenflussrichtung – also vom Sender der betroffenen Daten zum Empfänger. Bei einem langsamen Download ist der Server der Sender, bei einem langsamen Upload der Client.

1. Einen Mitschnitt vor dem verdächtigen Gerät oder Leitungsabschnitt aufnehmen (aus Sicht des Senders).
2. Gleichzeitig einen Mitschnitt dahinter aufnehmen.
3. Lücken erst dahinter? → Der Verlust entsteht im Gerät oder auf dem Abschnitt dazwischen.
4. Lücken schon davor? → Der Verlust entsteht weiter vorn. Den nächsten Messpunkt in Richtung Sender setzen.
5. Auf der gesamten Strecke keine Lücken, aber trotzdem Retransmissions? → Den Rückweg der ACKs und den Empfänger selbst prüfen.

Bei langen Pfaden beginnst du in der Mitte und halbierst den verbleibenden Abschnitt mit jedem Schritt. Die Gesamtmethodik beschreibt der Artikel Netzwerkprobleme systematisch eingrenzen, speziell für abreißende Verbindungen gibt es Verbindungsabbrüche analysieren mit Wireshark und TCP.

Microbursts: Verlust, den kein Monitoring sieht

Ein häufig unterschätzter Verlustverursacher sind Microbursts: sehr kurze Lastspitzen im Millisekundenbereich, in denen mehr Daten auf einen Port treffen, als er weitergeben kann. Typisch dort, wo schnelle Ports auf langsamere treffen (10 auf 1 Gbit/s) oder viele Server gleichzeitig an einen Empfänger senden. Der Switch-Puffer läuft über, Pakete werden verworfen. Das Tückische: Im Monitoring ist davon nichts zu sehen. Eine Auslastung von 30 % im Fünf-Minuten-Mittel schließt nicht aus, dass der Port für 20 Millisekunden bei 100 % lag. Hinweise liefern die Output Drops in der Interface-Statistik und ein I/O-Graph mit feinem Intervall, in dem die Verluste exakt mit den Traffic-Spitzen zusammenfallen. Nicht zu verwechseln mit Bufferbloat, dem umgekehrten Problem: Zu große Puffer halten Pakete lange fest, statt sie zu verwerfen – das Ergebnis ist steigende Latenz statt Verlust. Mehr dazu im Artikel Hohe Latenz im Firmennetz – RTT analysieren.

---

Häufige Ursachen für Packet Loss im Unternehmensnetz

• Überlastete Uplinks oder WAN-Leitungen: Liegt mehr Traffic an, als die Leitung transportieren kann, werden Pakete verworfen. Im Capture erkennbar an Verlusten, die mit der Auslastung korrelieren – tagsüber stärker als nachts.
• Defekte Hardware: Fehlerhafte Netzwerkkarten, beschädigte Kabel oder schlechte SFP-Module erzeugen oft sporadischen, schwer reproduzierbaren Verlust. Wichtigster Hinweis sind CRC-Fehler in der Interface-Statistik.
• Duplex-Mismatch: Eine Seite ist fest auf 100 Mbit/s Full Duplex eingestellt, die Gegenseite steht auf Auto-Negotiation und fällt auf Half Duplex zurück. Ergebnis: Late Collisions auf der einen, CRC-Fehler auf der anderen Seite und Verluste, die mit der Last zunehmen. Bei Gigabit über Kupfer ist Auto-Negotiation Pflicht – das Problem betrifft heute vor allem ältere Geräte, Industriekomponenten und fest konfigurierte Ports.
• Überlastete Firewalls oder UTM-Appliances: Deep Packet Inspection, SSL-Inspection und IDS/IPS kosten CPU. Unter Last verwirft die Appliance Pakete – ein Ping durch dieselbe Firewall zeigt davon nichts. Prüf CPU-Last und Session-Tabelle zum Zeitpunkt des Problems.
• WLAN: WLAN wiederholt gestörte Funkpakete selbst auf Layer 2, viele Probleme kommen bei TCP daher als schwankende Latenz an. Was trotzdem verloren geht, interpretiert TCP als Überlast und drosselt – obwohl das Kabelnetz einwandfrei ist. Schnelltest: den Client testweise per Kabel anschließen.
• Die Endgeräte selbst: Volle Empfangspuffer der Netzwerkkarte, alte Treiber, fehlerhaftes NIC-Teaming oder überlastete virtuelle Switches. Die Zähler liefern ethtool -S (Linux) bzw. Get-NetAdapterStatistics (Windows).

---

Packet Loss vs. Retransmissions – was ist der Unterschied?

• Packet Loss ist das eigentliche Verschwinden eines Pakets im Netzwerkpfad. Ein Gerät verwirft das Paket, es erreicht sein Ziel nicht.
• Retransmission ist die Reaktion des TCP-Stacks auf vermuteten Verlust. TCP bemerkt, dass ein ACK ausbleibt oder Duplicate ACKs ankommen, und sendet die Daten erneut. Retransmissions sind also ein Symptom, kein Auslöser.

Viele Retransmissions bedeuten also nicht zwingend viel Datenverlust – auch verlorene ACKs oder Laufzeitspitzen lösen sie aus. Deshalb immer im Zusammenhang betrachten: Lost Segments, Duplicate ACKs und Retransmissions. Vertiefend: TCP Retransmissions: Performance-Killer im Wireshark-Trace und Warum ist mein Netzwerk langsam trotz 1 Gbit?

---

Fazit und Handlungsempfehlung

Ping ist kein Netzwerkdiagnose-Tool, sondern ein Erreichbarkeitstest. Wer Paketverlust zuverlässig analysieren will, braucht:

• passende Messwerkzeuge – mtr, iperf3 und die Interface-Zähler
• einen Mitschnitt am richtigen Punkt – und die Gewissheit, dass der Mitschnitt selbst vollständig ist
• die Analyse von Sequenznummern, Duplicate ACKs und Retransmissions im Zusammenhang
• eine methodische Lokalisierung entlang der Datenflussrichtung statt Rätselraten

Der häufigste Fehler ist dabei nicht ein zu schwaches Werkzeug, sondern der falsche Capture-Punkt. Du steckst gerade in genau so einer Situation? Das Netzwerkteam sieht grüne Dashboards, das Applikationsteam sieht Timeouts, und die IT-Leitung will wissen, wann es endlich wieder läuft? Dann bringt ein professioneller Netzwerkmitschnitt mit strukturierter Auswertung meist mehr als wochenlange Trial-and-Error-Suche – mit Befunden, die auch in einer Eskalation oder vor einer Investitionsentscheidung Bestand haben. Das Erstgespräch ist kostenlos: Schildere mir kurz das Problem, und wir klären gemeinsam, ob und wie eine Analyse weiterhilft.

---

FAQ: Packet Loss messen und analysieren

Wie kann ich Packet Loss ohne Wireshark messen?

pathping (Windows) und mtr (Linux/macOS) zeigen Verlust pro Hop, mtr auch per TCP. Für Messungen unter Last eignet sich iperf3, für Hardwarefehler die Interface-Statistik der Switches. Ob produktive Verbindungen tatsächlich Pakete verlieren, zeigt aber erst der Mitschnitt.

Ab welchem Wert ist Packet Loss ein Problem?

Das hängt vom Anwendungstyp ab. Bei VoIP wird verteilter Verlust ab etwa 1 % hörbar, gebündelter Verlust deutlich früher. RDP und Citrix reagieren schon auf Verlust im Promillebereich mit spürbaren Hängern. Als Richtwert gilt: In einem gesunden Unternehmens-LAN sollte der Paketverlust praktisch bei 0 % liegen. Auf einer vollständig ausgelasteten Leitung sind einzelne Verluste dagegen normal – klassische TCP-Algorithmen tasten sich bewusst bis an diese Grenze heran.

Was bedeutet „TCP Previous segment not captured“?

Wireshark hat eine Lücke in den Sequenznummern gefunden: Vor diesem Segment fehlen Daten. Entweder sind sie im Netz vor deinem Capture-Punkt verloren gegangen – oder dein Mitschnitt hat sie nicht erfasst. Taucht später der Hinweis „ACKed segment that wasn’t captured“ auf, hat der Empfänger die Daten erhalten, und das Problem liegt beim Mitschnitt.

Kann Packet Loss durch Software verursacht werden?

Ja. Überlastete Endgeräte, volle Empfangspuffer, Treiberfehler oder fehlerhafte Teaming-Konfigurationen erzeugen Verluste, die wie Netzwerkverlust aussehen, aber im Gerät selbst entstehen. Aufschluss geben die Zähler der Netzwerkkarte.

Warum zeigt Wireshark Retransmissions, obwohl Ping keinen Verlust zeigt?

Ping testet mit kleinen ICMP-Paketen im Sekundentakt, nicht die Qualität deiner TCP-Verbindungen. Retransmissions entstehen, wenn ACKs ausbleiben oder Duplicate ACKs eintreffen – etwa durch kurze Lastspitzen, die volle Datenpakete treffen, aber keinen einzelnen Ping. Genau dieser Unterschied ist der Kern des Problems: Wireshark sieht den produktiven Traffic, Ping nicht.