Begriff
TCP Handshake (3-Way)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
TCP ist ein zuverlässiges Protokoll (garantiert Ankunft). Bevor du Daten sendest, musst du sicherstellen, dass der andere da ist und zuhört. Das ist wie beim Telefonieren. Man ruft nicht an und schreit sofort den Text los.
- A: "Hallo, hörst du mich?" (SYN)
- B: "Ja, ich höre dich. Hörst du mich auch?" (SYN-ACK)
- A: "Ja, passt." (ACK) Erst jetzt fließen Daten. Dieser Tanz heißt 3-Way-Handshake. Alles, was TCP nutzt (Webseiten, Email, SSH), macht das bei jedem Start.
Merksatz: Der dreistufige Prozess (SYN, SYN-ACK, ACK), mit dem eine TCP-Verbindung aufgebaut und synchronisiert wird, bevor Nutzdaten übertragen werden.
Du merkst davon nichts (macht der Kernel).
Aber du siehst es in Wireshark oder tcpdump.
Filter: tcp.flags.syn == 1.
Wenn du google.com aufrufst:
- Dein PC -> Google: [SYN]
- Google -> Dein PC: [SYN, ACK]
- Dein PC -> Google: [ACK] Wenn Schritt 2 fehlt (Timeout), ist Google down oder eine Firewall blockiert (Drop). Wenn Schritt 2 "RST" (Reset) ist, läuft auf dem Port kein Server.
1. SYN Flood Attack (DDoS)
Ein Angreifer sendet Millionen SYN Pakete (mit gefälschter Absender-IP). Der Server antwortet SYN-ACK und wartet auf das ACK. Das ACK kommt nie. Der Server hält den "Halb-Offenen" Verbindungsslot im RAM offen (für 60 Sekunden). Der RAM läuft voll. Der Server kann keine echten User mehr annehmen. Lösung: SYN Cookies. Der Server speichert den State nicht im RAM, sondern codiert ihn kryptografisch in der Sequence Number des SYN-ACKs. Erst wenn das ACK zurückkommt (mit der richtigen Nummer), reserviert er RAM.
2. Sequence Numbers (ISN)
Das ACK ist nicht nur "Ja". Es synchronisiert Nummern. A: "Ich starte bei Byte 1000" (SYN, Seq=1000). B: "Alles klar, ich erwarte als nächstes Byte 1001" (ACK=1001). Warum zufällige Startnummern (ISN - Initial Sequence Number)? Security. Wenn die Nummer vorhersehbar wäre (immer 0), könnten Hacker Pakete in eine fremde Verbindung einschmuggeln ("TCP Hijacking").
3. TCP Fast Open (TFO)
Der Handshake kostet Zeit (1 RTT - Round Trip Time). Wenn der Server in USA ist (100ms Ping), verlierst du 100ms bevor das erste Byte fließt. TFO erlaubt es, Daten schon im SYN Paket mitzuschicken (wenn man sich schon kennt -> Cookie). Das reduziert den Overhead für wiederkehrende Besucher auf 0 RTT.
Der halboffene Memory-Leak (SYN Flood Attack)
Wenn der Server auf das initiale SYN eines Clients ein SYN-ACK antwortet, muss der Kernel-Netzwerkstack (Linux) das entstehende Socket in den TCB-Status (Transmission Control Block) "SYN_RECV" setzen und Ressourcen allokieren (Port-Binding, RAM-Buffer).
Ein fieser Angreifer droppt per DDoS nun Millionen SYN-Pakete mit gespooften Quell-IPs. Der Server ackert und wartet 60 Sekunden verzweifelt auf das finale Client-ACK. Die Memory-Warteschlange (Backlog Queue) lauft komplett über – der Kernel verweigert ehrlichen Usern prompt die Verbindungsoberfläche.
Zur Abwehr springen SYN Cookies (via sysctl net.ipv4.tcp_syncookies) ein: Der Server fälscht seine generierte Sequence Number, in die er den Verbindungs-Hash packt, wirft sie als SYN-ACK in die Welt, verwirft das Socket aber sofort aus dem RAM (Zero-State Allocation). Erst wenn das legitime ACK (Sequence Number + 1) ankommt, hasht er rückwärts validierend zur Identität und initiiert das System erst dann physisch.
Initial Sequence Number (ISN) & Session Hijacking
Oft denken wir, die Seq-Numbers fangen brav bei 0 an. Tödlich.
In den 90er Jahren war die ISN (der Startwert des Handshakes) trivial an die Systemuhr gebunden. Wenn Hacker Kevin Mitnick ein blindes TCP Session Hijacking versuchte, musste er die nächste Sequence Number für die Spoofing-Antwort "erraten", um das Server-ACK zu befriedigen. Mit einer monotonen Uhr war das ein Kinderspiel.
Moderne IP-Stacks in Linux operieren extrem paranoid: Die ISN ist zwingend kryptografisch pseudo-randomisiert. Einem Hijacker aus dem Subnet nützt Spoofing der Source-IP also nichts, solange er das Sniffing (das Lesen des SYN-ACK Geheim-Hashes) nicht sicherstellen kann, weshalb pure IP-Protokoll-Hijacks ohne L2-Mitlesen faktisch ausstarben.
Latenz-Buster: TCP Fast Open (TFO)
Der brutale Latenz-Nachteil an TCP ist, dass Applikations-Daten (Byte-Payloads wie HTTP GET) im Handshake absolut untersagt sind – es regiert der 1 RTT (Round Trip Time) Leerlauf-Zwang, bis Vertrauen vorliegt.
TCP Fast Open umgeht dieses Performance-Problem bei Returning-Clients radikal (z.B. Mobile Apps zu ihren REST-APIs). Beim ersten ordentlichen Handshake vergibt der Server dem Handset heimlich einen MAC-Cookie (TFO-Cookie).
Beim nächsten Disconnect und Re-Connect funkt die Mobile App ihr klassisches SYN, knallt aber im Options-Feld das Cookie rein und schleudert den kompletten GET / Application-Payload als Anhängsel mit ins allererste Handshake-Paket! Der Server validiert das legitime Cookie, leitet den Payload sofort zur CPU hoch und beackert das SYN-ACK zusammen mit dem 200 OK im Return. Zero-RTT Zeitverlust.
Quick-Check
Teardown (Abbau)?
Beenden braucht 4 Schritte (4-Way). A: "Ich bin fertig" (FIN). B: "Okay" (ACK). Dann sendet B noch Restdaten. B: "Ich bin auch fertig" (FIN). A: "Okay" (ACK).State: TIME_WAIT?
Nach dem Schließen bleibt der Port noch kurz (2 MSL = 60s) blockiert. Warum? Falls noch verspätete Pakete eintrudeln, sollen die nicht versehentlich eine neue Verbindung auf demselben Port stören.UDP Handshake?
Gibt es nicht. UDP ist verbindungslos. Einfach senden. Wenn weg, dann weg. Deshalb ist UDP schneller (kein Overhead), aber unzuverlässig (Video Streaming, DNS).