TCP Handshake analysieren: SYN, SYN/ACK, ACK – was Wireshark dir wirklich zeigt
Drei Pakete. Mehr braucht es nicht, um eine TCP-Verbindung aufzubauen. Klingt simpel – und trotzdem steckt in genau diesen drei Paketen oft die Antwort auf Fragen, die Admins tagelang beschäftigen. Warum verbindet sich die Applikation so langsam? Warum kommt der Verbindungsaufbau manchmal gar nicht erst zustande? Warum bricht alles nach wenigen Sekunden wieder zusammen?
Der TCP 3-Way-Handshake ist kein reines Lehrbuchthema. Er ist ein Diagnoseinstrument – und Wireshark macht ihn sichtbar, lesbar und auswertbar. In diesem Artikel zeige ich dir, was in diesen ersten drei Paketen wirklich steckt, wie du sie korrekt interpretierst und was dir ein fehlgeschlagener oder langsamer Handshake über den Zustand deines Netzes verrät.
Was ist der TCP Handshake – und warum ist er mehr als Theorie?
Jede TCP-Verbindung beginnt mit demselben Ritual: Der Client schickt ein SYN, der Server antwortet mit SYN/ACK, der Client bestätigt mit ACK. Erst danach fließen Nutzdaten. Das ist der 3-Way-Handshake – bekannt aus jedem Netzwerklehrbuch, CCNA-Kurs und Prüfungskatalog.
In der Praxis geht es aber nicht ums Auswendiglernen. Es geht darum zu verstehen, was in diesen drei Paketen ausgehandelt wird – und was das für die gesamte Lebensdauer der Verbindung bedeutet. MSS, Window Size, SACK, Timestamps und Window Scaling werden im Handshake festgelegt. Was hier falsch konfiguriert ist oder nicht zusammenpasst, zieht sich durch jeden einzelnen Datentransfer danach.
Ich habe in Projekten erlebt, dass Applikationen über eine WAN-Strecke subjektiv „langsam“ liefen – und der Handshake hat in unter dreißig Sekunden den Grund gezeigt: kein Window Scaling, ein abweichender MSS-Wert, hohe RTT. Kein Rätselraten, keine stundenlange Suche. Drei Pakete, klare Aussage.
Die drei Pakete im Detail: SYN, SYN/ACK und ACK
SYN – der erste Schritt des Clients
Das SYN-Paket ist mehr als ein einfaches „Hallo“. Der Client teilt dem Server bereits hier mit, unter welchen Bedingungen er kommunizieren möchte. Die wichtigsten Felder:
- Sequence Number (ISN): Eine zufällig gewählte initiale Sequenznummer – die Basis für die gesamte Datenübertragung.
- Maximum Segment Size (MSS): Die maximale Datenmenge, die der Client pro TCP-Segment empfangen möchte. Typisch sind 1460 Byte bei Ethernet (MTU 1500 minus 20 Byte IP-Header minus 20 Byte TCP-Header).
- Window Size: Wie viele Daten der Client empfangen kann, bevor er eine Bestätigung erwartet.
- TCP Options: Hier stecken entscheidende Parameter – Window Scaling (
WSCALE), Selective Acknowledgement (SACK_PERM) und Timestamps.
Schon in diesem ersten Paket siehst du, ob der Client grundlegende Performance-Features unterstützt und anbietet. Wenn Window Scaling hier fehlt, wird es für den Rest der Verbindung nicht mehr aktiviert.
SYN/ACK – die Antwort des Servers
Der Server nimmt das SYN entgegen, bestätigt es (ACK) und schickt gleichzeitig sein eigenes SYN mit seinen Verbindungsparametern. Was der Server hier zurückschickt, ist die tatsächlich ausgehandelte Konfiguration.
- Der Server wählt seine eigene initiale Sequenznummer.
- Die MSS im SYN/ACK kann sich von der des Clients unterscheiden. Jede Seite sendet nur Segmente bis zu der Größe, die die Gegenseite angekündigt hat – und die die eigene MTU zulässt.
- Bietet der Server kein Window Scaling an, obwohl der Client es angeboten hat, wird es für diese Verbindung nicht verwendet.
- Gleiches gilt für SACK: Nur wenn beide Seiten es unterstützen und im Handshake ankündigen, wird es aktiv.
Das SYN/ACK ist also nicht nur eine Bestätigung – es ist die verbindliche Aushandlung der Verbindungsparameter.
ACK – die Bestätigung und der Startschuss
Das dritte Paket ist das einfachste der drei. Der Client bestätigt das SYN des Servers. Ab diesem Moment gilt die Verbindung als etabliert, und Nutzdaten können fließen. Meist folgen sie unmittelbar nach dem ACK, manchmal hängt der Client sie direkt an. Mit TCP Fast Open stecken sie sogar schon im SYN.
In Wireshark erkennst du diesen Moment daran, dass nach dem ACK die ersten Applikationsdaten folgen, zum Beispiel ein HTTP GET oder ein Datenbank-Request.
TCP Handshake in Wireshark analysieren – Schritt für Schritt
Die einfachste Methode, einen Handshake in Wireshark zu isolieren: Display-Filter setzen. Der folgende Filter zeigt dir alle Pakete, bei denen das SYN-Flag gesetzt ist – also sowohl SYN als auch SYN/ACK:
tcp.flags.syn == 1
Willst du nur die reinen SYN-Pakete ohne die SYN/ACKs, nutze diesen Filter:
tcp.flags.syn == 1 && tcp.flags.ack == 0
Damit siehst du ausschließlich den Verbindungsaufbau durch Clients – nützlich, wenn du in einem vollen Capture-File nach neuen Verbindungen suchst. Weitere hilfreiche Filter findest du im Artikel Wireshark – Die 10 wichtigsten Display-Filter.
Was du in der Paketdetailansicht siehst
Klickst du auf ein SYN-Paket und öffnest in der mittleren Wireshark-Ansicht den Bereich Transmission Control Protocol, siehst du alle TCP-Header-Felder aufgeklappt. Die interessantesten Punkte:
Sequence Number (raw): Die initiale Sequenznummer des Clients.Window Size Value: Der rohe Wert aus dem Header. In SYN-Paketen wird das Window Scaling nie angewendet.Options: Hier findest du MSS, WSCALE, SACK_PERM und Timestamps. Alles in einem Paket.Calculated Window Size: Wireshark rechnet dir den tatsächlichen Wert aus, sofern es den Window-Scaling-Faktor aus dem Handshake kennt.
Ein wichtiger Hinweis: Wenn Wireshark den Handshake nicht gesehen hat – zum Beispiel weil der Mitschnitt erst nach dem Verbindungsaufbau gestartet wurde –, kann es den Window-Scaling-Faktor nicht ermitteln. Du erkennst das an einem Scaling-Faktor von -1 (unknown) und an unrealistisch kleinen Window-Größen. Bewerte solche Werte nicht, ohne vorher den Verbindungsaufbau im Mitschnitt zu prüfen.
Was ein fehlgeschlagener Handshake verrät
Nicht jeder Handshake läuft sauber durch. Und genau die Fehlerbilder sagen viel aus. Hier die häufigsten Szenarien:
SYN ohne Antwort
Du siehst ein SYN, dann – nichts. Kein SYN/ACK, kein RST. Nach einigen Sekunden erscheint ein retransmittiertes SYN. Was dahintersteckt:
- Eine Firewall verwirft das Paket lautlos (DROP statt REJECT).
- Der Zielhost ist nicht erreichbar oder down.
- Eine Host-Firewall oder Security Group auf dem Ziel lässt den Port nicht durch.
- Routing-Problem: Das Paket kommt nie an oder die Antwort findet keinen Weg zurück.
Wichtig: Retransmittierte SYNs erhöhen die Verbindungsaufbauzeit spürbar. Einen Überblick über die Auswirkungen von Paketverlusten findest du im Artikel TCP Retransmissions: Der stille Performance-Killer.
RST statt SYN/ACK
Der Server antwortet mit einem TCP RST. Das ist eine explizite Ablehnung – der Port ist geschlossen, kein Dienst lauscht dort. Schnelle Diagnose: Zieldienst nicht gestartet, falscher Port, Portwechsel nach einem Update.
SYN/ACK kommt – aber der Client antwortet nicht
Seltener, aber vorkommend: Der Client schickt ein SYN, der Server antwortet korrekt mit SYN/ACK, aber das abschließende ACK bleibt aus. Mögliche Ursachen: asymmetrisches Routing (der Mitschnitt sieht nicht alle Pakete), ein NAT-Problem, oder der Client hat die Verbindung bereits intern verworfen.
Wenn du Verbindungsabbrüche systematisch analysieren möchtest, hilft dir der Artikel Verbindungsabbrüche analysieren mit Wireshark weiter.
Handshake-Dauer messen – RTT aus dem ersten Paket ablesen
Eine der nützlichsten Informationen, die du aus dem Handshake ziehen kannst: die Round-Trip-Time (RTT). Sie ergibt sich aus dem Zeitdelta zwischen dem SYN des Clients und dem eintreffenden SYN/ACK des Servers.
In Wireshark kannst du die Zeitdifferenz in der Spalte „Time“ ablesen. Noch einfacher: Klick auf das dritte Paket (das ACK des Clients). Im Bereich SEQ/ACK analysis zeigt Wireshark dir die gemessene Initial RTT ([iRTT]) direkt an. Wenn du in einem großen Mitschnitt nach Verbindungen mit langsamem Aufbau suchst, hilft dieser Filter (Wert in Sekunden):
tcp.analysis.initial_rtt > 0.1
Am folgenden Beispiel lässt sich das gut erkennen. Der Messpunkt ist hier der Client, zu erkennen am ersten SYN-Paket. Das SYN/ACK vom Server kommt ca. 25 ms später am Client an. Die RTT beträgt in diesem Fall also 25 ms.
Was hohe Handshake-Latenz bedeutet
Eine RTT von 1 ms ist im LAN normal. Über WAN-Strecken können 20–80 ms noch akzeptabel sein. Aber:
- RTT > 100 ms beim Handshake: Deutet auf eine lange Netzwerkstrecke, Satellitenverbindungen oder einen stark ausgelasteten Server hin.
- Schwankende RTT zwischen Handshakes: Jitterprobleme, Warteschlangen, QoS-Probleme.
- Erste RTT deutlich höher als Folge-RTTs: Server-Überlastung beim Verbindungsaufbau (SYN-Backlog, Ressourcenproblem).
Die Handshake-RTT ist der sauberste Messwert, den du hast – weitgehend unverfälscht von Applikationsverhalten oder Retransmissions. Wie du Latenzprobleme darüber hinaus systematisch eingrenzt, zeige ich dir im Artikel Hohe Latenz im Firmennetz – RTT analysieren. Und wenn du verstehen möchtest, warum dein Netz trotz hoher Bandbreite langsam wirkt, ist Warum ist mein Netzwerk langsam trotz 1 Gbit? ein guter nächster Schritt.
TCP Options im Handshake – diese Parameter beeinflussen die gesamte Verbindung
Die TCP Options im SYN und SYN/ACK sind keine Nebensache. Was hier nicht ausgehandelt wird, steht für die gesamte Verbindungsdauer nicht zur Verfügung. Die drei wichtigsten:
MSS – Maximum Segment Size
Die MSS gibt an, wie groß ein einzelnes TCP-Segment maximal sein darf. Der Wert leitet sich aus der MTU ab: Bei einer Ethernet-MTU von 1500 Byte ergibt sich typisch eine MSS von 1460 Byte (minus 20 Byte IP-Header, minus 20 Byte TCP-Header).
Beide Seiten kommunizieren ihre MSS im Handshake. Jede Seite sendet nur Segmente bis zu der Größe, die die Gegenseite angekündigt hat – und die die eigene MTU zulässt. Unterschiedliche MSS-Werte sind also zunächst normal. Problematisch wird es, wenn ein Gerät auf dem Pfad – oft ein VPN-Gateway oder eine Firewall – die MTU verkleinert, die MSS nicht korrekt anpasst und zusätzlich ICMP-Meldungen blockiert. Die Folge: Fragmentierung oder stillschweigende Drops großer Pakete, die sich als mysteriöse Performance-Einbrüche oder Verbindungsabbrüche zeigen.
In Wireshark erkennst du das daran, dass nach dem Handshake Retransmissions bei bestimmten Paketgrößen auftreten, während kleine Pakete problemlos durchkommen.
Window Scaling – ohne dieses Flag drosselt Latenz die Verbindung
Die ursprüngliche TCP Window Size ist auf 65.535 Byte begrenzt – ein Wert, der zu Zeiten langsamer Modem-Verbindungen entworfen wurde. Auf modernen Hochgeschwindigkeitsstrecken – erst recht über WAN – ist das viel zu wenig.
Window Scaling (RFC 7323, ursprünglich RFC 1323) erlaubt Window Sizes bis zu 1 Gigabyte. Der Skalierungsfaktor wird im Handshake ausgehandelt und kann danach nicht mehr geändert werden. Fehlt er auf einer Seite, läuft die Verbindung mit der ursprünglichen Begrenzung – und bei hoher Latenz kann das die Durchsatzrate drastisch reduzieren.
Die Formel ist simpel:
Maximaler Durchsatz = TCP Window Size / Latenz (RTT)
Mit einer Window Size von 65 KB und einer RTT von 50 ms ergibt das gerade mal ~1,3 MB/s – egal, wie viel Bandbreite physisch vorhanden ist. Alle Details dazu findest du im Artikel TCP Window Size & Scaling einfach erklärt.
SACK – Selective Acknowledgement
SACK löst ein klassisches TCP-Problem: Ohne SACK muss bei Paketverlusten ab dem verlorenen Paket alles neu übertragen werden – auch Daten, die bereits korrekt angekommen sind. Mit SACK kann der Empfänger mitteilen, welche Bereiche er bereits hat, und der Sender überträgt gezielt nur das Fehlende.
Im Handshake erkennst du SACK daran, dass in den TCP Options des SYN das Feld SACK_PERM erscheint. Fehlt es auf einer Seite, wird SACK für diese Verbindung nicht aktiviert. Gerade in verlustbehafteten Netzen ist das ein spürbarer Unterschied.
Wie SACK im Zusammenspiel mit Duplicate ACKs und Out-of-Order-Paketen funktioniert, erkläre ich ausführlich im Artikel Dup ACKs & Out-of-Order: Was die Unterschiede wirklich bedeuten.
Praxisbeispiel – Handshake-Analyse in einem realen Projekt
Ich war in einem Projekt, bei dem eine Fachanwendung über eine SD-WAN-Strecke zwischen zwei Standorten betrieben wurde. Die Nutzer klagten über träges Verhalten – jede Aktion dauerte gefühlt eine Ewigkeit, obwohl die gemessene Bandbreite mehr als ausreichend war.
Der erste Schritt: Wireshark auf dem Client, Mitschnitt gestartet, Applikation geöffnet. Blick auf die ersten drei Pakete der Verbindung zur Serverkomponente.
Was der Handshake gezeigt hat
| Parameter | Client (SYN) | Server (SYN/ACK) | Bewertung |
|---|---|---|---|
| MSS | 1460 Byte | 1380 Byte | Abweichung – Tunnel-Overhead auf dem Pfad, MSS nicht angeglichen |
| Window Scaling | WSCALE=8 (Faktor 256) |
Nicht vorhanden | Kein Scaling – Window auf 65 KB begrenzt |
| SACK | SACK_PERM gesetzt |
SACK_PERM gesetzt |
OK – beide Seiten unterstützen SACK |
| RTT (SYN → SYN/ACK) | – | – | 68 ms – hohe WAN-Latenz |
Das Bild war eindeutig: Kein Window Scaling auf Serverseite, dazu eine RTT von 68 ms. Mit der Formel gerechnet:
65.535 Byte / 0,068 s ≈ 960 KB/s maximaler Durchsatz pro Verbindung
Die Applikation öffnete mehrere parallele Verbindungen, aber selbst dann war das Limit spürbar.
Die abweichende MSS (1460 vs. 1380) wies auf Tunnel-Overhead auf dem Pfad hin, vermutlich durch das VPN-Gateway. Das Gateway verkleinerte die MTU, ließ aber keine ICMP Path MTU Discovery zu. Das führte zu gelegentlichen Retransmissions bei größeren Paketen.
Wie die Erkenntnisse zur Lösung geführt haben
Auf Basis des Handshake-Befundes wurden drei Maßnahmen eingeleitet:
- Window Scaling auf dem Server aktiviert (Betriebssystem-Einstellung, unter Windows über das TCP-Autotuning, Befehl siehe unten).
- MSS Clamping auf dem VPN-Gateway konfiguriert, um konsistente MSS-Werte sicherzustellen.
- ICMP Typ 3, Code 4 (Fragmentation Needed) an der Firewall erlaubt, damit Path MTU Discovery funktionieren kann.
Unter Windows aktivierst du das TCP-Autotuning und damit das Window Scaling mit diesem Befehl:
netsh interface tcp set global autotuninglevel=normal
Den aktuellen Stand prüfst du mit diesem Befehl:
netsh interface tcp show global
Wichtig: Auch Firewalls oder WAN-Optimierer können die Option im Handshake entfernen. Vergleiche deshalb im Zweifel das SYN/ACK auf Client- und Serverseite, bevor du die Ursache im Betriebssystem suchst.
Das Ergebnis: Die subjektive Performance verbesserte sich deutlich – ohne Hardware-Upgrade, ohne neue Leitung. Nur auf Basis dessen, was drei Pakete am Anfang einer Verbindung verraten haben.
Fazit – der Handshake als Diagnoseinstrument
Der TCP 3-Way-Handshake ist der kompakteste Performance- und Konfigurationsreport, den du in einem Netzwerk abrufen kannst. Drei Pakete, wenige Millisekunden – und du weißt, wie die Verbindung konfiguriert ist, wie hoch die Latenz ist und ob grundlegende Features wie Window Scaling und SACK aktiv sind.
Wenn du das nächste Mal mit einem Performance-Problem konfrontiert wirst: Bevor du anfängst, Bandbreite zu messen, Switches zu tauschen oder dem Server-Team die Schuld zu geben, schau dir den Handshake an. Filter setzen, SYN-Paket aufklappen, TCP Options lesen, RTT notieren. Das dauert keine zwei Minuten – und liefert oft die Antwort.
Wie es nach dem Handshake weitergeht, zeigt dir der Artikel Wie lese ich einen TCP Stream richtig?. Und wenn du Netzwerkprobleme von Anfang an strukturiert angehen willst, findest du den Ablauf in Netzwerkprobleme systematisch eingrenzen – 5-Schritte-Methodik.
Netzwerkanalyse funktioniert dann am besten, wenn man weiß, wo man anfangen muss. Der Handshake ist dieser Anfang.
Das Problem ist reproduzierbar – aber die Ursache bleibt im Dunkeln?
Dann braucht es einen zweiten Blick auf die Pakete. Wireshark kennt die Antwort – manchmal fehlt nur die Erfahrung, sie darin zu lesen.
Als spezialisierter Netzwerkanalyst helfe ich dir dabei:
- Ursachen präzise zu lokalisieren – statt auf Verdacht Hardware zu tauschen.
- Komplexe Packet-Traces auszuwerten und in klare Handlungsempfehlungen zu übersetzen.
- Die Schuldfrage objektiv zu klären – mit Beweisen auf Paketebene, die das Fingerpointing zwischen Netzwerk- und Applikationsteam beenden.
Im ersten Gespräch schauen wir uns gemeinsam die Ausgangslage an: Symptome, bisheriges Troubleshooting und mögliche nächste Schritte. Danach entscheiden wir, wie es weitergeht.
Schreib mir eine kurze Nachricht mit deiner Herausforderung – ich melde mich für ein unverbindliches Erstgespräch.
Du musst das Thema erst intern vorstellen? Hier sind Nutzen und Ablauf einer Analyse zum Weiterreichen (PDF) für deine IT-Leitung oder Geschäftsführung.
