Wie lese ich einen TCP Stream richtig? – Schritt für Schritt mit Wireshark

Wer schon mal eine Wireshark-Aufzeichnung geöffnet und auf Tausende von Paketen gestarrt hat, kennt das Gefühl: Wo fange ich überhaupt an? Die einzelnen Pakete sagen dir zwar viel – aber erst im Zusammenhang ergibt sich das vollständige Bild. Genau dafür gibt es die Stream-Analyse. Und wenn du lernst, TCP Streams wirklich zu lesen – nicht nur zu öffnen –, findest du Fehlerquellen, die in der Paketliste schlicht unsichtbar bleiben.

In diesem Artikel zeige ich dir, wie du systematisch vorgehst: vom ersten Rechtsklick über Sequenznummern und Latenz-Messung bis zur richtigen Interpretation von FIN und RST. Mit Beispielen aus der Praxis, nicht aus dem Lehrbuch.

Was ist ein TCP Stream und warum ist er so wichtig?

Ein TCP Stream ist keine eigene Datenstruktur – er ist eine logische Zusammenfassung aller Pakete, die zu einer einzelnen TCP-Verbindung gehören. Wireshark identifiziert diese Verbindung anhand des sogenannten 5-Tupels: Quell-IP, Ziel-IP, Quellport, Zielport und Protokoll (TCP). Jede Verbindung bekommt von Wireshark eine eigene Stream-ID – beginnend bei 0, in der Reihenfolge, in der die Verbindungen im Trace auftauchen.

Die ID findest du im Paketdetail unter TCP als Stream index. Per Rechtsklick und Apply as Column blendest du sie als Spalte tcp.stream in der Paketliste ein. Aber das ist nur der Einstieg. Der eigentliche Wert der Stream-Perspektive liegt darin, dass du den Datenfluss als Ganzes bewertest – nicht einzelne Pakete isoliert.

Stell dir vor, du untersuchst ein Performance-Problem: Eine Anwendung lädt langsam, die Nutzer beschweren sich. In der Paketliste tauchen TCP-Retransmissions auf – auf den ersten Blick ein klarer Fall von Paketverlust. Schaust du dir aber den Stream an, siehst du vielleicht: Die beiden Retransmissions kosten zusammen ein paar hundert Millisekunden. Die eigentliche Wartezeit von drei Sekunden liegt aber zwischen Request und Response – und hat mit den Retransmissions gar nichts zu tun. Einzelne Pakete lügen, der Stream erzählt die Wahrheit.

„Follow TCP Stream“ – der erste Schritt

Der einfachste Einstieg in die Stream-Analyse ist die Funktion „Follow TCP Stream“. Du erreichst sie per Rechtsklick auf ein beliebiges Paket der Verbindung, die dich interessiert – dann Follow → TCP Stream. Alternativ geht es über Analyze → Follow → TCP Stream oder die Tastenkombination Strg+Alt+Shift+T. Wireshark filtert daraufhin automatisch alle Pakete dieses Streams und öffnet ein separates Fenster mit dem rekonstruierten Datenstrom.

Im Dialogfenster siehst du zwei Farben:

• Rot steht für die Daten der Seite, die im Trace zuerst gesendet hat – in der Regel der Client (Anfragen, Uploads, Kommandos).
• Blau steht für die Gegenrichtung, meist vom Server zum Client (Antworten, Daten, Fehlermeldungen).

Startet deine Aufzeichnung mitten in einer laufenden Verbindung, können die Rollen vertauscht sein. Im Auswahlfeld unten links im Dialog siehst du beide Richtungen mit IP-Adresse und Port – ein kurzer Blick dorthin schafft Klarheit.

Über Show data as wählst du die Darstellung. ASCII ist ideal für Klartext-Protokolle wie HTTP, SMTP oder FTP – du siehst Header, Anfragen und Antworten direkt lesbar. Hex Dump zeigt Offset, Hex-Bytes und ASCII nebeneinander und ist die beste Wahl bei binären Protokollen. Raw liefert die reinen Hex-Bytes ohne Formatierung, vor allem zum Weiterverarbeiten oder Exportieren. Bei verschlüsseltem Traffic hilft dir ohne Schlüssel allerdings keine dieser Ansichten weiter.

In diesem Beispiel siehst du den Aufruf einer HTTP-Webseite. Der Benutzer stellt einen HTTP-Request auf die URI /control/status des Webservers adguard.fritz.box:

Was du im Follow-Fenster nicht siehst

Ein Punkt, der in vielen Anleitungen fehlt: Das Follow-Fenster zeigt dir die rekonstruierte Nutzlast – keine TCP-Header, keine Flags, keine Sequenznummern und keine Retransmissions als solche. Es beantwortet die Frage „Was wurde übertragen?“, aber nicht „Wie gut wurde es übertragen?“. Seit Wireshark 4.4 kannst du dir im Dialog immerhin Delta-Zeiten zwischen den Richtungswechseln anzeigen lassen. Für die eigentliche Analyse von Timing, Seq/ACK und Fehlern gehst du aber zurück in die gefilterte Paketliste.

Ein praktischer Nebeneffekt: Wireshark setzt nach dem „Follow“-Aufruf automatisch einen Display-Filter auf den jeweiligen Stream. Den kannst du ablesen, anpassen und für weitere Analysen nutzen – die Zahl am Ende ist die Stream-ID:

Wenn du mit Display-Filtern noch nicht vertraut bist, lohnt sich ein Blick in meinen Artikel zu den 10 wichtigsten Wireshark Display-Filtern.

Sequenznummern & ACKs im Stream verstehen

Sobald du im Stream bist, wird es technisch – und genau hier trennt sich die oberflächliche Paket-Betrachtung von echter Analyse. TCP ist ein verbindungsorientiertes, sequenzbasiertes Protokoll. Jedes Byte, das über eine TCP-Verbindung übertragen wird, hat eine Sequenznummer. Der Empfänger bestätigt den Empfang mit einem ACK, das die nächste erwartete Sequenznummer enthält.

In Wireshark arbeitest du in der Regel mit relativen Sequenznummern, was die Lesbarkeit deutlich erhöht. Die Option ist standardmäßig aktiv; du findest sie unter Edit → Preferences → Protocols → TCP → Relative sequence numbers. Wichtig für das Lesen: Der SYN bekommt die relative Sequenznummer 0 und „verbraucht“ selbst eine Nummer. Das erste Nutzdaten-Byte hat deshalb Seq 1, nicht 0.

Den Datenfluss ablesen

In der Paketliste erkennst du am Zusammenspiel von Seq- und ACK-Nummern, wie Daten fließen. Ein einfaches Beispiel direkt nach dem Handshake:

Die Rechnung dahinter ist simpel:

Seq + Len = nächste erwartete Sequenznummer = ACK der Gegenseite

Wireshark nimmt dir diese Rechnung sogar ab und zeigt das Ergebnis im Paketdetail als tcp.nxtseq (Next Sequence Number) an. Übrigens: Nach dem Handshake ist das ACK-Flag in jedem Segment gesetzt – auch im Request des Clients. Wenn du dieses Muster erkennst und es gleichmäßig weiterläuft, ist der Stream gesund.

Was ein Gap in den Sequenznummern bedeutet

Kritisch wird es, wenn Sequenznummern springen. Du erwartest Seq 1461, aber das nächste Paket hat Seq 2921 – ohne dass die Bytes dazwischen irgendwo im Trace auftauchen. Das ist ein Gap. Wireshark markiert das betroffene Paket mit [TCP Previous segment not captured].

Gaps sind heimtückisch, denn sie bedeuten zunächst nur: Dein Capture-Punkt hat dieses Segment nicht gesehen. Ob es wirklich verloren ging, verrät dir das Verhalten der Gegenseite:

• Echter Paketverlust: Der Empfänger schickt Dup ACKs, die immer wieder die fehlende Sequenznummer anfordern, und der Sender schickt das Segment per Retransmission erneut.
• Capture-Artefakt: Der Empfänger bestätigt die fehlenden Bytes ganz normal. Wireshark markiert das mit [TCP ACKed unseen segment] – die Daten sind angekommen, nur eben nicht an deinem Mitschnittpunkt vorbeigekommen.

Mit diesem Filter findest du beide Fälle auf einen Blick:

Mehr dazu, wie du echten Paketverlust von Capture-Artefakten unterscheidest, habe ich in meinem Artikel zu Packet Loss messen – warum Pings oft lügen beschrieben.

Retransmission, Reorder und Dup ACKs

Wireshark markiert viele dieser Anomalien automatisch – in der Spalte Info tauchen dann Einträge wie [TCP Retransmission], [TCP Out-Of-Order] oder [TCP Dup ACK] auf. Was diese Markierungen genau bedeuten und wie du sie richtig interpretierst, erkläre ich ausführlich in meinem Artikel TCP Retransmissions, Dup ACKs & Out-of-Order – Unterschiede.

Kurz zusammengefasst: Eine Retransmission zeigt, dass der Sender davon ausgeht, dass etwas nicht angekommen ist. Ob das tatsächlich so war, ist eine andere Frage – nicht ohne Grund kennt Wireshark die Markierung [TCP Spurious Retransmission] für Daten, die der Empfänger längst bestätigt hatte. Vor allem aber gilt: Retransmissions sind nicht die Ursache – sie sind die Reaktion. Die Ursache liegt woanders: im Netz, in der Anwendung oder im Betriebssystem.

Dass Retransmissions mehr Auswirkung auf die Performance haben, als viele denken, zeige ich auch in meinem Artikel TCP Retransmissions: Der stille Performance-Killer.

Wo steckt die Latenz? RTT im Stream ablesen

Einer der häufigsten Anlässe für eine Stream-Analyse ist die Frage: „Warum ist die Anwendung so langsam?“ Und die Antwort liegt fast immer in der Latenz-Struktur des Streams – nicht in einzelnen Paketen.

Zeit zwischen Request und Response messen

Das Werkzeug der Wahl ist die Zeitdifferenz zwischen Paketen. Dafür bietet Wireshark mehrere Felder, die du dir als Spalten einblenden kannst:

• Zeit seit dem vorherigen Paket im selben Stream – tcp.time_delta. Anders als frame.time_delta bezieht sich dieser Wert nur auf deine Verbindung. Pakete anderer Streams verfälschen die Messung also nicht.
• Zeit seit Beginn des Streams – tcp.time_relative. Zeigt, wie lange es ab dem ersten Paket der Verbindung bis zu einem bestimmten Paket dauert.
• Initial RTT – tcp.analysis.initial_rtt. Wireshark berechnet die Round-Trip-Time aus dem Handshake. Du findest sie im Paketdetail unter TCP → [SEQ/ACK analysis] → iRTT. Fehlt der Handshake im Trace, fehlt auch dieser Wert.

Tauchen die beiden Zeitfelder bei dir nicht auf, aktiviere unter Edit → Preferences → Protocols → TCP die Option Calculate conversation timestamps.

Der praktischste Ansatz: Rechtsklick auf das Paket mit dem Request (z. B. HTTP GET) und Set/Unset Time Reference wählen (oder Strg+T). Ab jetzt zeigt dir die Zeitspalte für alle folgenden Pakete die Zeit relativ zum Request – du liest die Antwortzeit direkt am ersten Antwort-Paket ab.

Wenn du gezielt nach Wartezeiten suchst, ist dieser Filter ein guter Startpunkt. Er zeigt alle Pakete, vor denen in ihrer Verbindung mehr als 500 ms Funkstille war:

Nicht jeder Treffer ist ein Problem: Keep-Alives und Verbindungen im Leerlauf tauchen hier ebenfalls auf. Interessant sind die Pausen, auf die ein Nutzer wartet – typischerweise zwischen Request und Response.

Und was ist „normal“? Die gemessene Antwortzeit setzt sich immer aus Netzwerk-RTT und Server-Zeit zusammen. Als grobe Orientierung für die reine RTT: im LAN deutlich unter einer Millisekunde, über eine innerdeutsche WAN- oder MPLS-Strecke typischerweise 10–30 ms, über Kontinente hinweg auch 100 ms und mehr. Entscheidend ist aber nicht der absolute Wert, sondern der Vergleich: Wie viel länger dauert die Antwort als die RTT der Verbindung? Wie du RTT-Werte sauber misst und einordnest, zeige ich ausführlich in meinem Artikel Hohe Latenz im Firmennetz – RTT analysieren.

Unterschied: Netzwerklatenz vs. Server-Verarbeitungszeit

Hier liegt einer der häufigsten Denkfehler in der Praxis: Nicht jede Verzögerung im Stream ist Netzwerklatenz. Wireshark misst Zeiten auf dem Kabel – und damit siehst du im Stream auch die Zeit, die ein Server braucht, um eine Antwort zu berechnen. Du musst also unterscheiden:

• Netzwerklatenz: die Zeit, die ein Paket hin und zurück braucht. Sie ist über die Verbindung hinweg weitgehend konstant und lässt sich am saubersten am Handshake messen – clientseitig zwischen SYN und SYN/ACK, serverseitig zwischen SYN/ACK und dem ACK des Clients. Mehr dazu in meinem Artikel zum TCP Handshake analysieren mit Wireshark.
• Server-Verarbeitungszeit: die Zeit, die der Server – oder etwas dahinter wie Datenbank, Storage oder Authentifizierung – braucht, bis er die Antwort losschickt. Clientseitig gemessen ist das die Zeit zwischen dem letzten Request-Paket und dem ersten Antwort-Paket mit Daten, abzüglich einer RTT.

Server-Zeit ≈ Zeit bis zur ersten Antwort − Netzwerk-RTT (iRTT)

Besonders aussagekräftig ist ein Muster, das du oft siehst: Der Server bestätigt den Request sofort mit einem leeren ACK – und die eigentlichen Daten kommen erst deutlich später. Das schnelle ACK beweist: Das Netz hat den Request zügig zugestellt. Die Lücke zwischen ACK und Antwort liegt komplett auf der Serverseite. Ein kleiner Haken: Viele Systeme verzögern ACKs bewusst (Delayed ACK, je nach Betriebssystem bis etwa 40–200 ms). Ein ACK, das so lange auf sich warten lässt, ist deshalb noch kein Netzwerkproblem.

Wenn du clientseitig mitschneidest und zwischen dem letzten Request-Paket und dem ersten Antwort-Paket eine Lücke siehst, die deutlich größer ist als die Netzwerk-RTT, dann liegt das Problem auf der Serverseite, nicht im Netz.

Die wichtigsten Messgrößen im Überblick:

Praxisbeispiel: HTTP-Request über WAN-Strecke

In einem Kundenprojekt bei einem mittelständischen Fertigungsunternehmen haben wir genau dieses Muster gesehen: Eine webbasierte ERP-Anwendung war über eine 50-Mbit-MPLS-Strecke angebunden. Die Nutzerbeschwerden lauteten klassisch: „Die Anwendung hängt.“ Die Netzwerkabteilung zeigte auf den Auslastungsgraphen – keine Überlastung. Der Server-Administrator zeigte auf den CPU-Monitor – auch unauffällig.

Im TCP Stream haben wir Folgendes gesehen: Netzwerk-RTT laut Handshake ca. 18 ms. Zeit zwischen Request und erster Response: 1,4 Sekunden. Von diesen 1,4 Sekunden entfielen gerade einmal 18 ms auf das Netz – der Rest lag auf dem Server. Das Netz war nicht das Problem – die Anwendungslogik war es.

Eine unauffällige CPU widerspricht dem übrigens nicht. Eine Anwendung kann auch dann langsam antworten, wenn sie die meiste Zeit wartet – etwa auf Datenbankabfragen, Sperren oder Backend-Dienste. Wie solche Fälle im Trace aussehen, zeige ich in den Praxisfällen zu sequentiellen DB-Requests und N+1 Queries und zu SQL über eine WAN-Strecke.

Erst mit diesem Nachweis aus dem Trace war die Diskussion beendet. Statt Fingerpointing zwischen Netzwerk- und Serverteam gab es eine klare, objektive Faktenlage.

Häufige Fehler beim Lesen von TCP Streams

Stream-Analyse klingt methodisch – ist es auch. Aber es gibt klassische Denkfallen, in die selbst erfahrene Analysten gelegentlich tappen.

Falsche Schlüsse aus einzelnen Paketen ziehen

Ein einzelnes Paket mit dem Flag [RST] sieht dramatisch aus. Aber ohne Kontext aus dem Stream weißt du nicht, ob die Anwendung die Verbindung nach getaner Arbeit routinemäßig per RST beendet – das machen einige ganz bewusst – oder ob eine Seite die Verbindung mitten in der Übertragung gekappt hat. Immer den Stream als Ganzes lesen, bevor du eine Aussage triffst.

Capture-Seite vergessen

Das ist vielleicht der häufigste Fehler überhaupt: Du siehst etwas im Trace – und vergisst dabei, von wo aus du schaust. Siehst du clientseitig eine Retransmission des Servers, ist das Original irgendwo zwischen Server und deinem Capture-Punkt verloren gegangen – wo genau, sagt dir dieser eine Trace nicht. Delays können durch Proxys, Firewalls oder Load Balancer entstehen, die du gar nicht im Blick hast.

Ein Sonderfall, wenn du direkt auf einem Client oder Server mitschneidest: Durch Offloading (TSO/LRO, Checksum Offloading) siehst du die Pakete so, wie das Betriebssystem sie an die Netzwerkkarte übergibt – nicht so, wie sie auf dem Kabel landen. Pakete weit über 1514 Byte oder fehlerhafte Prüfsummen bei ausgehenden Paketen sind dann Capture-Artefakte, keine Netzwerkfehler. Immer dokumentieren: Wo wurde aufgezeichnet, und was liegt zwischen den Endpunkten?

FIN und RST falsch interpretieren

FIN bedeutet: „Ich bin fertig mit Senden.“ Es ist ein geordnetes Ende – und völlig normal. Die Gegenseite darf danach sogar noch Daten schicken, bis sie selbst ihr FIN sendet. RST hingegen bedeutet: „Verbindung sofort beenden.“ Ohne geordneten Abbau, ohne Rückfrage. Das kann ein Fehler sein – muss es aber nicht. Firewalls setzen RST aktiv ein, Load Balancer auch. Mehr dazu, wie du das richtig auseinanderhältst, findest du in meinem Artikel zu Verbindungsabbrüchen analysieren mit Wireshark.

Window Size ignorieren

Die TCP Window Size gibt an, wie viele Daten der Sender verschicken darf, ohne auf eine Bestätigung zu warten – also wie viel Puffer der Empfänger gerade frei hat. Sinkt die Window Size im Stream rapide – bis hin zu [TCP ZeroWindow] –, ist das ein klares Zeichen dafür, dass der Empfänger die Daten nicht schnell genug verarbeitet. Das passiert oft bei langsamen Applikationsservern oder überlasteten Clients.

Eine Falle dabei: Die tatsächliche Fenstergröße ergibt sich erst mit dem Window-Scaling-Faktor, den beide Seiten im Handshake aushandeln. Fehlt der Handshake im Trace, kennt Wireshark den Faktor nicht – im Paketdetail steht dann Window size scaling factor: -1 (unknown) – und zeigt dir ein scheinbar winziges Fenster an. Das ist kein Problem im Netz, sondern eine Lücke in deiner Aufzeichnung. Das Thema erkläre ich ausführlich in meinem Artikel zur TCP Window Size & Scaling.

Wann reicht ein Stream – und wann brauchst du mehr?

Die Stream-Analyse ist ein hervorragender Einstiegspunkt – aber sie ist kein Allheilmittel. Es gibt Situationen, in denen du mit einem einzelnen Stream nicht weiterkommst.

Wann der Stream ausreicht

• Du willst eine einzelne Verbindung bewerten: Läuft sie sauber durch? Gibt es Retransmissions? Wie hoch ist die Latenz?
• Du willst prüfen, was eine Anwendung tatsächlich über das Netz sendet (Protokoll-Debugging).
• Du willst die Server-Verarbeitungszeit vom Netz abgrenzen.

Für den Verlauf einer einzelnen Verbindung lohnt sich zusätzlich ein Blick in Statistics → TCP Stream Graphs. Im Stevens- oder tcptrace-Graphen erkennst du Stillstände, Retransmissions und Fensterengpässe oft schneller als in der Paketliste.

Wann du mehr brauchst

• Viele parallele Verbindungen: Moderne Anwendungen nutzen Connection Pooling, HTTP/2-Multiplexing oder mehrere TCP-Sessions gleichzeitig. Ein einzelner Stream zeigt dir nur einen Bruchteil davon. Hier brauchst du eine aggregierte Sicht – z. B. über Statistics → Conversations, sortiert nach Dauer oder Datenmenge, oder über Statistics → I/O Graphs.
• Serverseitiger Kontext fehlt: Du siehst clientseitig Delays, kannst aber nicht sagen, ob der Server die Requests überhaupt rechtzeitig erhalten und verarbeitet hat. Dann brauchst du einen serverseitigen Capture – am besten zeitgleich mit dem clientseitigen Trace und mit synchronisierten Uhren, um Timestamps vergleichen zu können.
• Verschlüsselter Traffic: TLS-verschlüsselte Verbindungen kannst du im Stream sehen, aber nicht lesen. Für eine tiefere Analyse brauchst du die Sitzungsschlüssel – viele Browser und Clients schreiben sie über die Umgebungsvariable SSLKEYLOGFILE heraus. Danach steht dir Follow → TLS Stream zur Verfügung. Alternativ schneidest du hinter dem Punkt mit, an dem TLS terminiert wird, etwa hinter einem Reverse Proxy oder Load Balancer.
• Intermittierende Probleme: Wenn das Problem nur sporadisch auftritt, reicht ein einzelner Stream nicht aus. Du brauchst einen Langzeit-Capture mit Ringpuffer.

Für den Ringpuffer eignet sich dumpcap, das bei Wireshark mitinstalliert wird. Dieser Aufruf schreibt bis zu 50 Dateien à rund 100 MB und überschreibt dann die jeweils älteste – du stoppst die Aufzeichnung einfach, nachdem das Problem aufgetreten ist:

Die passende Interface-Nummer für -i zeigt dir dumpcap -D; IP-Adresse und Port passt du an deine Umgebung an.

Die Stream-Analyse ist also der erste Schritt einer Diagnose, nicht das Ergebnis. Sie zeigt dir, wo du tiefer graben musst – und erspart dir die blinde Suche durch Tausende von Paketen. Wie du von dort aus strukturiert weitermachst, beschreibe ich in meiner 5-Schritte-Methodik zum systematischen Eingrenzen von Netzwerkproblemen.

Fazit

Einen TCP Stream richtig zu lesen ist eine Fähigkeit, die man sich erarbeitet – nicht durch das Auswendiglernen von Flags und Feldern, sondern durch das systematische Anschauen echter Verbindungen. Mit der Zeit entwickelst du ein Gespür dafür, wie ein gesunder Stream aussieht – und erkennst sofort, wenn etwas nicht stimmt.

Die wichtigsten Punkte aus diesem Artikel noch einmal zusammengefasst:

• Wireshark identifiziert Streams anhand des 5-Tupels – prüfe immer als Erstes, welchen Stream du gerade analysierst.
• „Follow TCP Stream“ ist dein Einstieg, kein Endpunkt – er zeigt dir den Inhalt, aber nicht das Timing. Dafür gehst du zurück in die Paketliste.
• Sequenznummern und ACKs erzählen den Datenfluss – Gaps, Sprünge und Wiederholungen sind Warnsignale, aber nicht jeder Gap ist echter Paketverlust.
• Latenz setzt sich zusammen aus Netzwerk-RTT und Server-Verarbeitungszeit – beides musst du im Stream auseinanderhalten können.
• FIN ist normal, RST ist kontextabhängig – nie ohne Blick auf den Gesamtverlauf bewerten.
• Der Capture-Punkt bestimmt, was du siehst – dokumentiere ihn immer mit.
• Ein Stream reicht nicht immer – manchmal brauchst du serverseitige Captures, parallele Traces oder eine aggregierte Sicht.

Wenn du nach diesem Artikel deine nächste Wireshark-Aufzeichnung öffnest, weißt du, wo du anfängst – und was du suchst. Und wenn du merkst, dass die Stream-Analyse allein nicht ausreicht, weißt du auch, wann es Zeit ist, tiefer zu graben.

Hast du gerade einen konkreten Fall auf dem Tisch? Vielleicht einen Trace, aus dem du nicht schlau wirst, eine Anwendung, über die sich die Nutzer beschweren, oder eine Diskussion zwischen Netzwerk- und Applikationsteam, die sich seit Wochen im Kreis dreht? Schreib mir gern – das Erstgespräch ist kostenlos. Solche Praxisfälle sind genau das, womit ich in meiner täglichen Arbeit zu tun habe, und oft lässt sich schon im ersten Gespräch einschätzen, wo du ansetzen solltest.