February 14, 2026

TCP 3-Way Handshake: Zu welcher OSI-Schicht gehört er?

Der TCP 3-Way Handshake ist einer der wichtigsten Abläufe im klassischen Netzwerkbetrieb, weil er festlegt, ob zwei Endpunkte überhaupt zuverlässig miteinander kommunizieren können. Wer verstehen möchte, warum eine Verbindung zustande kommt – oder warum sie scheitert –, kommt an diesem Mechanismus nicht vorbei. Gleichzeitig taucht immer wieder eine grundlegende Frage auf: Zu welcher OSI-Schicht gehört der TCP 3-Way Handshake? Die kurze Antwort lautet: Er ist ein Kernbestandteil der Transport Layer (OSI-Schicht 4). In der Praxis spielt jedoch auch das Zusammenspiel mit den darunterliegenden Ebenen (vor allem IP auf Schicht 3 und Ethernet/WLAN auf Schicht 2) eine große Rolle, denn der Handshake kann nur funktionieren, wenn die Zustellung von Paketen grundsätzlich möglich ist. In diesem Artikel lernen Sie, warum der Handshake eindeutig zur Schicht 4 gehört, welche Aufgaben er dort übernimmt, wie er konkret abläuft (SYN, SYN/ACK, ACK), welche Felder und Zustände entscheidend sind und wie Sie typische Fehlerbilder systematisch analysieren – etwa mit Wireshark oder über Log-Ausgaben und Metriken. Dadurch gewinnen Sie ein solides Fundament für Troubleshooting, Performance-Analysen und Sicherheitsbewertungen in modernen Netzwerken.

Table of Contents

Kurze Einordnung: Was macht OSI-Schicht 4 eigentlich?

Die OSI-Transport-Schicht (Schicht 4) ist dafür zuständig, eine Ende-zu-Ende-Kommunikation zwischen Anwendungen zu ermöglichen. Während Schicht 3 (Network Layer) sich darum kümmert, dass Pakete überhaupt von A nach B geroutet werden, beantwortet Schicht 4 andere Fragen:

Welche Anwendung soll die Daten erhalten? (Port-Nummern als Adressierung auf dem Endsystem)
Soll die Übertragung zuverlässig und geordnet sein? (TCP) oder eher leichtgewichtig ohne Garantien? (UDP)
Wie wird Datenfluss gesteuert? (Flow Control, Congestion Control)
Wie werden Verbindungen aufgebaut und beendet? (Connection Management)

Der TCP 3-Way Handshake ist genau der Mechanismus, der den Verbindungsaufbau (Connection Establishment) organisiert. Damit ist er fachlich klar in der Transport Layer verankert.

Zu welcher OSI-Schicht gehört der TCP 3-Way Handshake?

Der TCP 3-Way Handshake gehört zur OSI-Schicht 4 (Transport Layer), weil er Teil des TCP-Protokolls ist. TCP ist ein Transportprotokoll, das unter anderem folgende Eigenschaften liefert:

Verbindungsorientierung: Kommunikation startet nicht „einfach so“, sondern wird explizit etabliert.
Zuverlässigkeit: Bestätigungen (ACKs), Wiederholungen (Retransmissions) und Sequenznummern sorgen dafür, dass Daten korrekt ankommen.
Reihenfolge: Daten werden beim Empfänger wieder in die richtige Reihenfolge gebracht.
Fluss- und Staukontrolle: Sender und Empfänger passen Sendeverhalten an Kapazität und Netzsituation an.

Der Handshake ist die notwendige Voraussetzung, damit diese Mechanismen sinnvoll arbeiten können. Deshalb ist er kein „Anwendungsding“ (Schicht 7) und auch kein „Routingding“ (Schicht 3), sondern ein Transportthema: Er etabliert eine logische Verbindung zwischen zwei Socket-Endpunkten (IP-Adresse + Port).

Warum ist das nicht Schicht 3 oder Schicht 7?

Es ist hilfreich, typische Missverständnisse auszuräumen. Der Handshake nutzt zwar IP (Schicht 3) und läuft häufig im Kontext einer Anwendung (z. B. Browser öffnet Website), aber die Verantwortung liegt bei TCP:

Nicht Schicht 3: IP liefert „Best-Effort“-Zustellung ohne Verbindungszustand. Der Handshake setzt jedoch Zustände (SYN-SENT, SYN-RECEIVED, ESTABLISHED) und Sequenzlogik voraus – das ist typisch Transport Layer.
Nicht Schicht 7: Anwendungen wie HTTP oder SMTP entscheiden nicht, wie SYN/ACK/ACK aussehen. Sie profitieren von einer bestehenden TCP-Verbindung, aber definieren den Handshake nicht.

Ein guter Merksatz: Schicht 3 bringt Pakete zum Zielnetz, Schicht 4 baut eine zuverlässige Verbindung zum Zielprozess auf.

TCP 3-Way Handshake Schritt für Schritt erklärt

Der klassische Verbindungsaufbau besteht aus drei Nachrichten. Diese drei Schritte sind so konzipiert, dass beide Seiten ihre Startwerte (Initial Sequence Numbers) austauschen und gleichzeitig die Erreichbarkeit verifizieren.

Schritt 1: SYN – der Client startet

Der Client sendet ein TCP-Segment mit gesetztem SYN-Flag an den Server. Dieses Paket enthält eine Initial Sequence Number (ISN), also den Startpunkt für die Sequenzierung. In vereinfachter Darstellung:

Client → Server: SYN, Seq = x

Zusätzlich werden häufig Optionen ausgehandelt, etwa MSS (Maximum Segment Size), Window Scaling oder SACK (Selective Acknowledgments). Diese Optionen sind wichtig für Performance und Robustheit.

Schritt 2: SYN/ACK – der Server antwortet

Der Server bestätigt den Empfang des SYN und sendet gleichzeitig seinen eigenen SYN. Dadurch wird deutlich: „Ich habe dich gehört und bin bereit.“

Server → Client: SYN/ACK, Seq = y, Ack = x + 1

Das ACK bezieht sich auf die nächste erwartete Sequenznummer. In TCP bedeutet eine Bestätigung typischerweise: „Alles bis einschließlich (Ack-1) ist angekommen.“

Schritt 3: ACK – der Client bestätigt

Der Client bestätigt wiederum die Sequenznummer des Servers. Damit gilt die Verbindung als etabliert (ESTABLISHED), und die Anwendung kann Daten senden.

Client → Server: ACK, Seq = x + 1, Ack = y + 1

Was genau wird im Handshake „ausgehandelt“?

Der Handshake ist mehr als nur ein „Hallo“. In der Praxis ist er die Phase, in der wichtige Parameter für die spätere Datenübertragung festgelegt werden. Dazu zählen vor allem TCP-Optionen und Fenstermechanismen:

MSS (Maximum Segment Size): Wie groß dürfen TCP-Segmente (Payload) maximal sein, ohne Fragmentierung zu riskieren?
Window Scaling: Erweiterung des TCP-Fensters, um hohe Bandbreite-Latenz-Produkte effizient zu nutzen.
SACK: Ermöglicht selektive Bestätigungen, damit bei Verlust nicht unnötig große Datenbereiche erneut übertragen werden.
Timestamps: Hilfreich für RTT-Messung und bessere Verlustbehandlung.

Diese Aushandlung ist ein starkes Indiz dafür, dass wir uns auf Schicht 4 befinden: Es geht um Transportverhalten und Ende-zu-Ende-Optimierung, nicht um Routing oder Anwendungslogik.

TCP-Zustände: Warum der Handshake „Stateful“ ist

Ein entscheidender Unterschied zu vielen Schicht-3-Mechanismen ist, dass TCP zustandsbehaftet ist. Der Handshake führt die Endpunkte durch definierte Zustände. Typisch sind unter anderem:

SYN-SENT: Client hat SYN gesendet und wartet auf SYN/ACK.
SYN-RECEIVED: Server hat SYN erhalten und SYN/ACK gesendet.
ESTABLISHED: Beide Seiten haben bestätigt – Datenfluss kann starten.
FIN-WAIT / CLOSE-WAIT / TIME-WAIT: Zustände für kontrollierten Verbindungsabbau.

Genau dieses Zustandsmodell ist typisch für OSI-Schicht 4. Es erklärt auch, warum Verbindungsprobleme oft Ressourcen binden: Ein Server muss Verbindungszustände verwalten.

Wie erkennt man den TCP 3-Way Handshake in Wireshark?

Wireshark ist eines der besten Werkzeuge, um den Handshake sichtbar zu machen. In der Paketliste sehen Sie häufig bereits in der „Info“-Spalte SYN, SYN/ACK und ACK. Noch besser funktioniert es mit Display Filtern. Offizielle Grundlagen finden Sie in der Wireshark-Dokumentation sowie in der Display-Filter-Referenz.

Nützliche Display Filter

Handshake-Start (SYN): tcp.flags.syn == 1 and tcp.flags.ack == 0
SYN/ACK: tcp.flags.syn == 1 and tcp.flags.ack == 1
Reset (RST): tcp.flags.reset == 1
Bestimmter Port: tcp.port == 443 (HTTPS) oder tcp.port == 80 (HTTP)
Bestimmte IP: ip.addr == 203.0.113.10

Wenn Sie eine Webseite aufrufen, sehen Sie häufig zuerst DNS (oft UDP), dann den TCP-Handshake zu Port 443 und anschließend einen TLS-Handshake. Der TCP 3-Way Handshake ist dabei die Schicht-4-Grundlage, auf der TLS und HTTP aufbauen.

Typische Fehlerbilder: Was sagt der Handshake über das Problem aus?

Der Handshake ist ein sehr zuverlässiger Indikator dafür, wo eine Störung liegen könnte. Die folgenden Muster sind in der Praxis besonders häufig:

SYN ohne SYN/ACK

Mögliche Ursache: Server nicht erreichbar, Firewall blockt eingehend, Routingproblem, falsche IP, Server down.
Hinweis: Wenn der Client SYN mehrfach sendet, sehen Sie Retransmissions (Timeout-basiert).

SYN/ACK kommt, aber ACK fehlt

Mögliche Ursache: Rückwegprobleme, Paketverlust, Client-Firewall, NAT/State-Tracking-Probleme.
Hinweis: Der Server bleibt ggf. in SYN-RECEIVED und wartet.

RST statt SYN/ACK oder nach dem Handshake

Mögliche Ursache: Port geschlossen, Dienst nicht aktiv, Security-Regel lehnt aktiv ab, falsch konfigurierter Load Balancer.
Hinweis: RST ist eine aktive Ablehnung, kein „stilles“ Timeout.

Handshake erfolgreich, aber danach Probleme

Mögliche Ursache: Anwendungsebene (HTTP 4xx/5xx), TLS-Fehler, MTU-Probleme, Paketverlust im Datenstrom, Congestion.
Hinweis: Dann ist Schicht 4 grundsätzlich ok, aber nicht zwingend performant.

Performance-Aspekt: RTT und „Handshake-Zeit“ richtig interpretieren

Der Handshake kann auch als grober Indikator für Latenz dienen: Die Zeit zwischen SYN und SYN/ACK nähert oft die Round-Trip Time (RTT) an. Wenn Sie Zeitdifferenzen in Sekunden sehen, ist die Umrechnung in Millisekunden in Troubleshooting-Berichten üblich:

$t (ms) = t (s) \times 1000$

Beispiel: Wenn zwischen SYN und SYN/ACK 0,120 s liegen, entspricht das 120 ms. Wichtig ist, das Ergebnis im Kontext zu bewerten (VPN, Mobilfunk, internationale Strecken) und nicht vorschnell als „Fehler“ zu interpretieren.

Der Handshake im Kontext von Sicherheit: Warum er häufig angegriffen wird

Weil TCP zustandsbehaftet ist, ist der Handshake ein beliebter Angriffspunkt. Ein klassisches Beispiel ist die SYN-Flood: Angreifer senden viele SYN-Pakete, ohne den Handshake zu vervollständigen, wodurch Server Ressourcen für halboffene Verbindungen binden. In vielen Umgebungen helfen Mechanismen wie SYN-Cookies oder vorgeschaltete Schutzsysteme, um die Auswirkungen zu minimieren.

Warum relevant: Der Angriff nutzt die Zustandsverwaltung auf Schicht 4 aus.
Woran erkennbar: Viele SYNs, wenige/keine abschließenden ACKs, wachsende Queue halboffener Verbindungen.

Für eine formale, technische Referenz zu TCP selbst eignet sich die Spezifikation RFC 9293 (Transmission Control Protocol).

Abgrenzung zur Session-Schicht: Warum manche trotzdem an Schicht 5 denken

Manchmal wird der TCP 3-Way Handshake fälschlich mit „Session“ gleichgesetzt. Das liegt daran, dass TCP eine Verbindung etabliert und damit eine Art Sitzung ermöglicht. Im OSI-Modell ist die Session Layer (Schicht 5) jedoch eher für Sitzungssteuerung auf höherer Ebene gedacht (z. B. Dialogsteuerung, Checkpoints), während TCP die Transportverbindung bereitstellt. In modernen Stacks sind viele Session-Funktionen in Anwendungen oder Bibliotheken gelandet, während TCP weiterhin klar zur Schicht 4 zählt.

Praxisbezug: Welche Anwendungen hängen direkt vom Handshake ab?

Viele Standardprotokolle im Internet basieren auf TCP und benötigen daher einen erfolgreichen 3-Way Handshake, bevor die eigentlichen Nutzdaten fließen:

HTTP/1.1 und HTTPS: Webzugriffe (bei HTTPS folgt nach TCP typischerweise TLS).
SMTP, IMAP, POP3: E-Mail-Transport und Postfachzugriff.
SSH: Remote-Administration.
FTP (klassisch): Dateiübertragung (historisch, heute seltener).

Selbst wenn Sie nur „eine Website öffnen“, ist der Handshake die unsichtbare Voraussetzung. Wenn er nicht funktioniert, helfen meist keine Browser-Einstellungen, weil das Problem unterhalb der Anwendungsebene liegt.

Checkliste: Handshake-Probleme strukturiert eingrenzen

Wenn eine Verbindung nicht klappt, ist es sinnvoll, den Fehler schrittweise zu lokalisieren. Diese Checkliste orientiert sich an typischen Ursachenketten – ohne sich in Details zu verlieren:

Schicht 3 Basis: IP-Adresse korrekt, Route vorhanden, Ziel grundsätzlich erreichbar (z. B. per ICMP, sofern erlaubt).
Schicht 4 Fokus: SYN geht raus? Kommt SYN/ACK zurück? Gibt es RST? Gibt es Retransmissions?
Stateful Devices: Firewall/NAT/Load Balancer: Werden Sessions korrekt erstellt und zurückübersetzt?
Port/Service: Lauscht der Dienst am Ziel wirklich auf dem Port? Wird er lokal oder upstream geblockt?
Timing: Hohe RTT oder Paketverlust? Hinweise durch Retransmissions und verzögerte ACKs.

Outbound-Quellen zur Vertiefung

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.