Netzwerk langsam trotz Gigabit? So findest du Performance-Engpässe mit Wireshark

„Das Netzwerk ist langsam.“ Jeder Admin kennt diesen Satz. Er ist die IT-Variante von „Ich habe Bauchschmerzen“: unspezifisch, frustrierend und schwer zu greifen. Das Kuriose daran: Im Monitoring leuchten alle Ports grün, die Auslastung der Gigabit-Strecke liegt bei mageren 5 %. Trotzdem dauert das Öffnen einer Excel-Datei vom Fileserver gefühlt ewig, und die Abfragen der Warenwirtschaft kriechen über die Leitung.

In meinen Analysen erlebe ich oft, dass an diesem Punkt Hardware getauscht wird. Neue Switche, neue Glasfaser, ein neuer Server – und das Problem bleibt. Der Grund ist simpel: Bandbreite ist nicht gleich Durchsatz, und Durchsatz ist nicht gleich Antwortzeit. Ein breites Rohr nützt nichts, wenn am Ende ein Ventil sitzt, das nur tröpfchenweise öffnet. In diesem Artikel zeige ich dir, wie du mit Wireshark herausfindest, wo dieses Ventil sitzt: im Netz, im TCP-Stack, auf dem Server oder in der Anwendung selbst.

Typisches Szenario: Ping grün, SMB schnell, Anwendung lahm

Stell dir ein mittelständisches Unternehmen vor. Die Infrastruktur ist modern: Cat.6A-Verkabelung, performante Core-Switche, SSD-Storage im SAN. Ein Fachbereich meldet, dass eine Client-Server-Anwendung seit dem letzten Wochenende extrem langsam reagiert. Der Ping zum Server zeigt unauffällige Werte unter einer Millisekunde, ein Dateitransfer per SMB erreicht fast die volle Gigabit-Rate.

Genau diese Kombination ist ein wichtiger Hinweis. Wenn große Dateitransfers schnell sind, die Anwendung aber hakt, ist die Leitung selbst selten das Problem. Dann geht es meist um die Response Time auf Applikationsebene: Wie lange braucht der Server für eine Antwort? Wie viele Hin-und-her-Zyklen braucht die Anwendung für einen einzigen Klick? Und gibt es kleine Störungen im TCP-Stack, die bei vielen kurzen Anfragen viel stärker ins Gewicht fallen als bei einem großen Datenstrom?

Und noch etwas steckt im Satz „seit dem letzten Wochenende“: Irgendetwas hat sich geändert. Bevor du den ersten Trace startest, frag nach Windows-Updates, neuen Treibern oder Firmware, geänderten Firewall-Regeln, einem Update des Virenscanners oder EDR-Agents oder einer neuen Version der Anwendung. Diese eine Frage spart oft Stunden.

Technischer Hintergrund: Warum Bandbreite nicht alles ist

Um zu verstehen, warum ein Netzwerk trotz hoher Kapazität langsam sein kann, lohnt ein Blick auf TCP. Das Protokoll ist auf Zuverlässigkeit getrimmt und funktioniert wie ein ständiger Dialog: Der Sender schickt Daten, der Empfänger bestätigt sie mit einem ACK. Drei Faktoren bestimmen, wie schnell dieser Dialog läuft.

1. Die Round Trip Time (RTT)

Die RTT (Round Trip Time) ist die Zeit, die ein Paket zum Ziel und die Bestätigung zurück braucht. Im kabelgebundenen LAN liegt sie typischerweise deutlich unter einer Millisekunde. Steigt sie – etwa durch überlastete Hops, eine Firewall mit aktiver Paketinspektion oder einen fehlerhaften Media-Converter –, sinkt der erreichbare Durchsatz pro Verbindung, auch wenn die Leitung frei ist. Wie du die RTT sauber misst, habe ich im Artikel Hohe Latenz im Firmennetz – RTT analysieren ausführlich beschrieben.

2. Das TCP Window

Der Empfänger teilt dem Sender über das Receive Window mit, wie viele Daten er unbestätigt aufnehmen kann. Daraus ergibt sich eine harte Obergrenze für jede einzelne Verbindung:

Maximaler Durchsatz pro Verbindung = TCP Window Size / RTT

Ein Beispiel: Ohne Window Scaling ist das Fenster auf 64 KB begrenzt. Bei 10 ms RTT, etwa zu einem anderen Standort, kommst du damit auf rund 52 Mbit/s – egal ob die Leitung 1 oder 10 Gbit/s hat. Moderne Betriebssysteme skalieren das Fenster automatisch hoch. Entfernt aber eine ältere Firewall oder ein Proxy die Window-Scale-Option aus dem Handshake, fällt die Verbindung auf genau diese Grenze zurück. Mehr dazu findest du unter TCP Window Size & Scaling einfach erklärt.

Kommt der Empfänger mit der Verarbeitung gar nicht mehr hinterher, meldet er ein TCP Zero Window. Dann stoppt der Sender komplett und fragt in Abständen nach, ob wieder Platz ist.

3. Die Anzahl der Application Turns

Der dritte Faktor wird am häufigsten übersehen. Viele Business-Anwendungen übertragen keine großen Datenmengen am Stück, sondern schicken viele kleine Anfragen nacheinander und warten auf jede einzelne Antwort, bevor die nächste rausgeht. Für die Wartezeit gilt dann grob:

Wartezeit ≈ Anzahl Request/Response-Zyklen × (RTT + Verarbeitungszeit Server)

Braucht ein Bildschirmaufbau 3.000 solcher Zyklen, sind das bei 0,5 ms RTT im LAN und 2 ms Serverzeit pro Anfrage schon rund 7,5 Sekunden. Läuft dieselbe Anwendung über eine WAN-Strecke mit 10 ms RTT, werden daraus 36 Sekunden. Die Bandbreite spielt dabei praktisch keine Rolle. Genau so ein Fall steckt hinter meinem Praxisfall zu sequentiellen DB-Requests und der N+1 Query.

Analyse mit Wireshark: Schritt für Schritt zum Engpass

Wireshark ist das Werkzeug der Wahl, um den Engpass sichtbar zu machen. Aber: Einfach mitschneiden und auf bunte Zeilen hoffen führt selten zum Ziel. Du brauchst einen Plan. Wenn du die Vorgehensweise grundsätzlicher angehen willst, schau dir auch meine 5-Schritte-Methodik zum systematischen Eingrenzen von Netzwerkproblemen an.

Schritt 1: Den richtigen Capture-Punkt wählen

Schneide so nah wie möglich an Quelle und Ziel mit, idealerweise zeitgleich am Client und am Server. Nur so siehst du, ob ein Paket unterwegs verloren geht oder ob der Server schlicht zu lange zum Antworten braucht. Liegt eine Firewall dazwischen, lohnt sich ein zusätzlicher Mitschnitt davor und dahinter.

Zwei Fallstricke solltest du dabei kennen:

• Offloading verfälscht lokale Mitschnitte. Schneidest du direkt auf dem Server mit, siehst du durch Large Send Offload (LSO) oft riesige Pakete von 30 oder 60 KB und angebliche Checksum-Fehler. Das sind keine echten Fehler, sondern die Daten, bevor die Netzwerkkarte sie segmentiert und die Prüfsumme berechnet.
• Der Capture-Rechner kann selbst Pakete verlieren. Unter Last verwirft ein Notebook oder ein überlasteter SPAN-Port Pakete, die im Netz nie verloren gingen. Prüfe deshalb unter Statistics → Capture File Properties, ob verworfene Pakete gemeldet werden.

Für längere Mitschnitte unter Last nimmst du besser dumpcap statt der Wireshark-Oberfläche. Ein Ringpuffer verhindert, dass die Platte vollläuft, und eine reduzierte Snaplen senkt die Last, wenn dich nur Timing und TCP-Verhalten interessieren:

Die Nummer des Interfaces findest du mit dumpcap -D. Willst du später auch die Inhalte der Anwendung auswerten, lässt du -s 256 weg.

Schritt 2: Expert Information als Einstieg

Unter Analyze → Expert Information liefert Wireshark einen schnellen Überblick über Auffälligkeiten. Achte vor allem auf die Einträge mit den Schweregraden Warning und Error:

• TCP Retransmission: Ein Segment oder das zugehörige ACK ging verloren, der Sender schickt die Daten erneut. Filter: tcp.analysis.retransmission
• Previous segment not captured: Im Mitschnitt fehlt ein Segment. Das kann ein echter Paketverlust vor dem Capture-Punkt sein – oder ein Verlust beim Mitschneiden selbst. Filter: tcp.analysis.lost_segment
• TCP Dup ACK: Der Empfänger hat ein Segment außerhalb der Reihenfolge erhalten und bestätigt wiederholt das letzte lückenlose. Mehrere Dup ACKs hintereinander lösen in der Regel eine Fast Retransmission aus. Filter: tcp.analysis.duplicate_ack
• TCP Zero Window und Window Full: Der Empfänger kann nichts mehr annehmen beziehungsweise der Sender hat das angebotene Fenster komplett ausgeschöpft. Filter: tcp.analysis.zero_window || tcp.analysis.window_full

Die Unterschiede zwischen diesen Meldungen erkläre ich genauer im Artikel TCP Retransmissions, Dup ACKs & Out-of-Order – was die Unterschiede wirklich bedeuten. Eine kompakte Übersicht findest du außerdem in Die 10 wichtigsten Wireshark Display-Filter.

Wichtig: Ein leeres Expert-Info-Fenster heißt nicht, dass alles in Ordnung ist. Ein Server, der für jede Antwort 300 ms braucht, erzeugt keine einzige Warnung. Deshalb gehört Schritt 4 immer dazu.

Schritt 3: Der I/O-Graph für den Überblick

Unter Statistics → I/O Graphs siehst du den Verlauf über die Zeit. Lass dir den Durchsatz in Bits pro Intervall anzeigen und lege zusätzliche Kurven mit eigenen Display-Filtern an, zum Beispiel eine für tcp.analysis.retransmission und eine für tcp.analysis.zero_window. Bricht der Durchsatz genau dann ein, wenn Retransmissions auftreten, spricht das für Paketverluste im Netz. Fallen die Einbrüche mit Zero Windows zusammen, liegt das Problem beim Empfänger und nicht auf der Leitung.

Die vordefinierte Kurve „TCP Errors“ ist ein guter Einstieg, wirft aber alle TCP-Auffälligkeiten in einen Topf – auch solche, die gar nichts mit dem Netz zu tun haben. Für eine belastbare Aussage solltest du die Kurven deshalb nach Ursache trennen.

Schritt 4: Antwortzeiten messen

Jetzt wird es spannend, denn hier trennt sich Netzwerk von Applikation. Aktiviere unter Edit → Preferences → Protocols → TCP die Option „Calculate conversation timestamps“. Danach steht dir das Feld tcp.time_delta zur Verfügung: die Zeit seit dem vorherigen Paket derselben TCP-Verbindung. Mit diesem Filter findest du Pausen über 200 ms, nach denen wieder Daten fließen:

Entscheidend ist, wer vor der Pause zuletzt gesendet hat. Liegt die Pause zwischen dem Request des Clients und der Antwort des Servers, hat der Server gerechnet – das Netz ist entlastet. Liegt sie zwischen einer Serverantwort und dem nächsten Request, wartet der Client: auf den Nutzer, auf lokale Verarbeitung oder auf einen anderen Dienst. Die reine Netzwerklaufzeit liefert dir zum Vergleich das Feld tcp.analysis.ack_rtt. Für SMB2 berechnet Wireshark die Antwortzeiten auch direkt, zu finden unter Statistics → Service Response Time → SMB2.

Schritt 5: Den TCP-Stream im Detail lesen

Für die verdächtige Verbindung lohnt der Blick in die Grafik unter Statistics → TCP Stream Graphs → Time Sequence (tcptrace). Sie zeigt, wie die Sequenznummern über die Zeit wachsen. Eine gleichmäßig steigende Linie bedeutet freien Fluss. Waagerechte Plateaus sind Pausen, in denen nichts gesendet wurde. Läuft die Datenkurve dabei an die obere Linie an, also an das angebotene Receive Window, bremst das Fenster. Bleibt dagegen Luft nach oben, hatte der Sender schlicht nichts zu senden – ein Hinweis auf die Anwendung oder das Betriebssystem. Wie du einen Stream Schritt für Schritt liest, zeige ich in Wie lese ich einen TCP Stream richtig?

Häufige Ursachen: Wo es wirklich klemmt

In der Praxis landen die meisten Fälle bei einem von vier Verdächtigen.

1. Paketverluste und Retransmissions

In einer idealen Welt gehen im LAN keine Pakete verloren. In der Realität sorgen defekte Patchkabel, schlecht aufgelegte Dosen, verschmutzte LWL-Stecker oder Duplex-Mismatches für CRC-Fehler und Drops. Schon geringe Paketverluste haben eine massive Wirkung, weil verlustbasierte TCP-Algorithmen wie Reno oder CUBIC jeden Verlust als Überlast deuten und die Senderate drosseln. Wie stark, hängt vor allem von der RTT ab: 1 % Verlust kann den Durchsatz einer einzelnen Verbindung schon im LAN um mehr als die Hälfte drücken, über WAN-Strecken noch deutlich stärker. BBR orientiert sich dagegen in erster Linie an gemessener Bandbreite und RTT und reagiert weniger empfindlich auf einzelne Verluste. Die Details findest du unter Congestion Control – wie TCP Reno, CUBIC und BBR den Datendurchsatz steuern.

Richtig teuer wird es, wenn die Wiederholung erst nach einem Retransmission Timeout (RTO) passiert. Eine Fast Retransmission nach drei Dup ACKs kostet ungefähr eine RTT. Ein RTO liegt dagegen unter Windows bei mindestens 300 ms, unter Linux bei 200 ms – bei einer LAN-RTT von 0,5 ms ist das das Mehrhundertfache. Gerade bei Anwendungen mit vielen kleinen Requests fehlen oft die nachfolgenden Pakete, die Dup ACKs auslösen könnten. Dann bleibt nur das RTO, und jeder einzelne Verlust kostet eine spürbare Gedenkpause.

Wie du Verluste zuverlässig misst und warum Ping dabei oft täuscht, liest du in Packet Loss messen – warum Pings oft lügen. Konkrete Gegenmaßnahmen findest du in TCP Retransmissions analysieren und beheben.

2. Zero Window: Der Empfänger kommt nicht hinterher

Liest die Anwendung auf dem Empfänger die Daten nicht schnell genug aus dem Socket – etwa wegen CPU-Last, langsamem Storage oder einem blockierenden Virenscanner –, läuft der Empfangspuffer voll. Der Empfänger meldet ein TCP Zero Window, der Sender muss warten und schickt in wachsenden Abständen Zero Window Probes, um nachzufragen, ob wieder Platz ist. Das kann auf beiden Seiten passieren, nicht nur beim Server: Ein Client, der große Datenmengen langsam verarbeitet, erzeugt genau dasselbe Bild. Zero Windows sind ein klassischer Engpass auf Systemebene, nicht auf der Leitung. Neue Switche helfen hier keinen Millimeter.

3. Langsame Server-Antworten und „geschwätzige“ Anwendungen

Diese Ursache taucht in keinem Expert-Info-Fenster auf – und trotzdem landet in meinen Analysen ein großer Teil der Fälle genau hier. Entweder braucht der Server für jede Antwort zu lange, etwa wegen Datenbank-Locks, fehlender Indizes, einer überlasteten VM oder Single-Threading. Oder die Anwendung ist chatty: Sie schickt hunderte oder tausende Mini-Requests nacheinander, statt Daten gebündelt abzurufen. Im Trace erkennst du das an vielen kleinen Paketen mit Pausen dazwischen, während die Leitung fast leer bleibt.

Hier entsteht auch das klassische Fingerpointing: Das Applikationsteam verweist aufs Netz, das Netzwerkteam auf die Anwendung. Der Mitschnitt beendet diese Diskussion, weil er objektiv zeigt, wo die Zeit verloren geht. Zwei Beispiele aus meiner Praxis findest du in Single-Threading als Performance-Killer und im Praxisfall SQL über WAN-Strecke.

4. MTU, MSS und Path-MTU-Probleme

Jede Strecke hat eine maximale Paketgröße, die MTU (Maximum Transmission Unit), im Ethernet standardmäßig 1.500 Byte. Daraus leitet sich die MSS (Maximum Segment Size) ab, die jede Seite im TCP-Handshake ankündigt. Problematisch wird es bei Tunneln wie IPsec-VPN, GRE oder VXLAN und bei PPPoE-Anschlüssen: Der Overhead verkleinert die nutzbare MTU, die Endgeräte wissen davon aber nichts.

Da TCP-Pakete heute fast immer mit gesetztem Don’t-Fragment-Bit verschickt werden, wird dabei nicht fragmentiert. Stattdessen verwirft der Router zu große Pakete und meldet per ICMP „Fragmentation Needed“ (IPv4: Type 3, Code 4; bei IPv6 „Packet Too Big“) die passende Größe zurück. Blockiert eine Firewall diese Meldungen, entsteht ein Black Hole: Handshake und kleine Requests funktionieren, große Antworten bleiben einfach hängen. Typisches Symptom: Die Anmeldung klappt, aber das Laden einer Liste oder eines Dokuments hängt. Im Trace siehst du dann wiederholte Retransmissions von Segmenten mit voller Größe, während kleine Pakete durchkommen. Nach den ICMP-Meldungen suchst du mit icmp.type == 3 && icmp.code == 4. Mehr zu hängenden und abbrechenden Verbindungen findest du in Verbindungsabbrüche analysieren mit Wireshark.

Spickzettel: Vom Symptom zur Ursache

Die folgende Übersicht hilft dir, Beobachtungen im Trace schnell einzuordnen:

Lösung und Best Practices

Welche Maßnahme greift, hängt davon ab, was dein Mitschnitt zeigt. Diese Punkte haben sich in der Praxis bewährt:

• Physik prüfen: Schau in die Interface-Statistiken der Switche nach CRC- und Input-Errors sowie Drops, bei Cisco zum Beispiel mit show interfaces counters errors. Bei Verdacht misst du die Verkabelung mit einem Zertifizierungsgerät. „Link ist da“ reicht nicht.
• Flow Control bewusst einsetzen: IEEE 802.3x Pause Frames können zu Head-of-Line-Blocking führen. Prüfe die Pause-Counter, bevor du etwas änderst, und halte dich bei Storage-Netzen wie iSCSI an die Vorgaben des Herstellers.
• QoS für kritischen Traffic: Priorisiere Sprache, Terminaldienste und zeitkritische Anwendungen, vor allem an Engstellen wie WAN-Uplinks.
• TCP-Stack und Netzwerkkarte prüfen: Receive Window Auto-Tuning ist unter Windows meist die richtige Wahl, den Status zeigt dir netsh int tcp show global. Prüfe im Handshake, ob die Window-Scale-Option auf beiden Seiten ankommt. Offloading-Funktionen wie LSO sind in der Regel hilfreich, fehlerhafte Treiber oder Firmware können aber genau hier Probleme verursachen – gerade nach einem Update.
• MTU konsistent halten: Standard sind durchgängig 1.500 Byte. Jumbo Frames nur dann, wenn wirklich alle Switche und Endgeräte im Segment mitspielen. Für Tunnel gehört MSS-Clamping auf das VPN-Gateway, und ICMP „Fragmentation Needed“ sollte nicht pauschal blockiert werden.
• Die Applikation mit ins Boot holen: Zeigt der Trace lange Server-Antwortzeiten oder tausende Mini-Requests, liegt die Lösung nicht im Netz. Mit dem Mitschnitt hast du belastbare Zahlen für das Gespräch mit Entwicklern oder dem Hersteller.

Vor dem Hardwarekauf: Erst messen, dann investieren

Für IT-Leiter und Entscheider ist ein Punkt besonders wichtig: Ein Switch-Tausch oder ein Bandbreiten-Upgrade kostet schnell einen fünfstelligen Betrag und löst keines der beschriebenen Probleme, wenn die Ursache im TCP-Stack, auf dem Server oder in der Anwendung liegt. Eine gezielte Paketanalyse dauert dagegen oft nur wenige Tage und liefert eine klare Antwort darauf, wo die Zeit verloren geht und wer das Problem lösen kann. Das spart nicht nur Budget, sondern auch die Wochen, in denen sich Teams gegenseitig die Verantwortung zuschieben.

Fazit: Gewissheit statt Raten

Ein langsames Netzwerk ist kein Schicksal, sondern fast immer die logische Folge messbarer Parameter. Mit einer sauberen Netzwerkanalyse in Wireshark wechselst du von der Ebene der Vermutungen auf die Ebene der Beweise.

Die Bandbreite ist nur die Autobahn. Ob der Verkehr fließt, entscheiden die Ampelschaltungen (TCP-Stack), der Zustand des Belags (Layer 1 und 2) und die Geschwindigkeit der Be- und Entladestationen (Server, Storage und Anwendung). Wer nur die Autobahn verbreitert, steht danach oft im selben Stau – nur auf mehr Spuren.

Du steckst gerade mitten in so einem Performance-Rätsel? Egal ob du aus dem Netzwerkteam, aus dem Applikationsbetrieb oder aus der IT-Leitung kommst: In einem kostenlosen Erstgespräch schauen wir gemeinsam auf deine Situation und klären, ob und wie eine Paketanalyse weiterhilft. Hier kannst du direkt Kontakt aufnehmen. Einen Überblick über meine Leistungen findest du auf der Leistungsseite.

FAQ – Häufig gestellte Fragen

Warum sehe ich in Wireshark so viele „TCP Spurious Retransmissions“?

Wireshark markiert eine Retransmission als „spurious“, wenn die wiederholten Daten bereits bestätigt waren – der Empfänger hatte sie also schon. Meist ist das ACK auf dem Rückweg verloren gegangen oder kam so spät, dass der Sender in den Timeout lief. Achte dabei auf den Capture-Punkt: Schneidest du nah am Empfänger mit, siehst du ACKs, die den Sender womöglich nie erreicht haben.

Reicht ein normaler Office-PC für einen Wireshark-Mitschnitt bei 1 Gbit/s?

Für eine erste Einschätzung bei moderater Last oft ja, vor allem mit dumpcap, Capture-Filter und reduzierter Snaplen. Bei Volllast stößt ein Office-PC schnell an Grenzen. Ein SPAN-Port kann zudem überlaufen, weil er Sende- und Empfangsrichtung auf einen einzigen Port spiegelt – bei 1 Gbit/s Vollduplex sind das bis zu 2 Gbit/s. Für belastbare Messungen empfehle ich einen Network TAP oder eine dedizierte Capture-Lösung. Prüfe in jedem Fall, ob dein Mitschnitt verworfene Pakete meldet.

Was ist eine „gute“ RTT im lokalen Netzwerk?

Im kabelgebundenen Gigabit-LAN liegt die RTT zwischen Client und Server am selben Standort typischerweise bei 0,1 bis 0,5 ms. Werte über 5 bis 10 ms ohne VPN- oder WLAN-Strecke deuten fast immer auf eine Fehlkonfiguration, eine Überlastung aktiver Komponenten oder eine bremsende Sicherheitskomponente hin. Im WLAN sind dagegen einige Millisekunden normal.

Kann eine Firewall bremsen, obwohl ihre CPU-Last unauffällig ist?

Ja. Läuft die Session-Tabelle voll, verwirft die Firewall neue Verbindungen, und der Client wiederholt seinen SYN erst nach einer oder mehreren Sekunden. Funktionen wie IPS, Deep Packet Inspection oder TLS-Inspection laufen außerdem oft auf eigenen Engines oder einzelnen Kernen, die überlastet sein können, während die Gesamt-CPU entspannt aussieht. Am sichersten findest du das mit einem Mitschnitt vor und hinter der Firewall: Die Differenz der Zeitstempel zeigt, wie viel Verzögerung sie selbst erzeugt.

Wie erkenne ich, ob das Netzwerk oder die Anwendung bremst?

Vergleiche die reine Netzwerklaufzeit mit der Antwortzeit der Anwendung. Die RTT siehst du im Handshake oder im Feld tcp.analysis.ack_rtt, die Antwortzeit an der Pause zwischen Request und Response. Liegt die RTT bei 0,5 ms, die Antwort aber bei 400 ms, rechnet der Server. Gibt es kaum Pausen, aber viele Retransmissions, liegt das Problem im Netz. Und sind es tausende kleine Anfragen hintereinander, ist das Design der Anwendung der Hebel.