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 dich 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: Client schickt ein SYN, Server antwortet mit SYN/ACK, 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.

Aber in der Praxis geht es 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, Window Scaling – all das wird im Handshake festgelegt. Was hier falsch konfiguriert ist oder nicht passt, 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, MSS-Mismatch, 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 IP-Header minus TCP-Header).
• Window Size: Wie viel Daten der Client empfangen kann, bevor er eine Bestätigung erwartet.
• TCP Options: Hier stecken entscheidende Parameter – Window Scaling (WSCALE), Selective Acknowledgement (SACK Permitted), 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 – beide Seiten kommunizieren in der Folge mit dem jeweils kleineren Wert.
• 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 – oft schon im selben Paket (TCP Fast Open), manchmal unmittelbar danach.

In Wireshark erkennst du diesen Moment daran, dass nach dem ACK direkt 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 Filter

tcp.flags.syn == 1

zeigt dir alle Pakete, bei denen das SYN-Flag gesetzt ist – also sowohl SYN als auch SYN/ACK. Willst du nur die reinen SYN-Pakete (keine SYN/ACKs), nutze:

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 – ohne Window Scaling noch angewendet.
• Options: Hier findest du MSS, WSCALE, SACK Permitted, Timestamps. Alles in einem Paket.
• Calculated Window Size: Wireshark rechnet dir den tatsächlichen Wert bereits 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 Verbindungsaufbau gestartet wurde – kann es den Window-Scaling-Faktor nicht ermitteln und zeigt falsche Werte. Du erkennst das an der Wireshark-Warnung „[TCP ZeroWindow]” oder unrealistisch kleinen Window-Größen.

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.
• Der Port ist zwar offen, aber kein Dienst hört – selten, aber möglich.
• Routing-Problem: Das Paket kommt nie an oder die Antwort findet keinen Weg zurück.

Wichtig: Retransmittierte SYNs erhöhen spürbar die Verbindungsaufbauzeit. 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 Update.

SYN/ACK kommt – aber der Client antwortet nicht

Seltener, aber vorkommend: Der Client schickt 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), NAT-Problem, oder der Client hat die Verbindung bereits intern verworfen.

Wenn du systematisch Verbindungsabbrüche analysieren möchtest, hilft 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 aktivierst du dafür die Spalte „Time” (relativ zum ersten Paket) oder schaust in der Detailansicht auf [SEQ/ACK analysis] → [The RTT to ACK the segment was…]. Noch einfacher: Klick auf das ACK des Clients (das dritte Paket) – Wireshark zeigt dir automatisch die gemessene RTT an.

Anhand folgendes 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. 25ms später am Client an. Die RTT beträgt in diesem Fall also 25ms.

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, satellitenähnliche Verbindungen 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 – noch unverfälscht von Applikationsverhalten oder Retransmissions. Wenn du verstehen möchtest, warum dein Netz trotz hoher Bandbreite langsam wirkt, ist der Artikel 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 Ethernet-MTU 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. Tatsächlich verwendet wird der kleinere der beiden Werte. Problematisch wird es, wenn ein Gerät auf dem Pfad – oft ein VPN-Gateway oder eine Firewall – die MSS nicht korrekt anpasst. Die Folge: Fragmentation oder stillschweigende Drops großer Pakete, die sich als mysteriöse Performance-Einbrüche oder Verbindungsabbrüche zeigen.

In Wireshark erkennst du einen MSS-Mismatch 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 1323) erlaubt Window Sizes bis zu 1 Gigabyte. Der Skalierungsfaktor wird im Handshake ausgehandelt und kann nicht mehr nachträglich 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 = Window Size / 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. Alles Details dazu findest du im Artikel TCP Window Size & Scaling einfach erklärt.

SACK – Selective Acknowledgement

SACK (Selective Acknowledgement) 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” (SACK Permitted) 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 sich im Zusammenspiel mit Duplicate ACKs und Out-of-Order-Paketen verhält, 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

Das Bild war eindeutig: Kein Window Scaling auf Serverseite, dazu eine RTT von 68 ms. Mit der Formel gerechnet: 65.535 Byte / 0,068 Sekunden = rund 960 KB/s maximaler Durchsatz – pro Verbindung. Die Applikation öffnete mehrere parallele Verbindungen, aber selbst dann war das Limit spürbar.

Der MSS-Unterschied (1460 vs. 1380) wies auf ein VPN-Gateway hin, das zwar MTU-Anpassung vornahm, aber keine ICMP Path MTU Discovery ermöglichte. 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 via netsh interface tcp set global autotuninglevel=normal).
• MSS Clamping auf dem VPN-Gateway konfiguriert, um konsistente MSS-Werte sicherzustellen.
• ICMP-Typ 3 (Destination Unreachable) am Firewall erlaubt, damit Path MTU Discovery funktionieren kann.

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 den 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.

Netzwerkanalyse funktioniert dann am besten, wenn man weiß, wo man anfangen muss. Der Handshake ist dieser Anfang.