2. Protocol Overview (Protokollübersicht)
Dieses Kapitel beschreibt den vollständigen Arbeitsablauf von TCP Fast Open, einschließlich Cookie-Anfrage, -Gewährung und -Verwendung.
2.1. TFO-Cookie-Anfrage (Cookie Request)
Der Client muss beim ersten Verbindungsaufbau zum Server zunächst ein TFO-Cookie abrufen.
Nachrichtenfluss
Client Server
| |
| SYN + TFO Cookie-Anfrage (leer) |
|---------------------------------->|
| |
| SYN-ACK + TFO Cookie |
|<----------------------------------|
| |
| ACK |
|---------------------------------->|
| |
| Anwendungsdaten |
|<--------------------------------->|
TCP-Optionsformat
Cookie-Anfrageoption:
- Kind: 34 (TCP Fast Open)
- Length: 2 (nur Optionskopf, keine Cookie-Daten)
- Cookie: leer (zeigt Cookie-Anfrage an)
Schlüsselpunkte
- Transparenz: Server, die TFO nicht unterstützen, ignorieren die Option; die Verbindung wird normal hergestellt
- Kompatibilität: Der Client MUSS auf den Standard-TCP-Drei-Wege-Handshake zurückfallen können
- Cookie-Caching: Der Client SOLLTE empfangene Cookies für spätere Verbindungen im Cache speichern
2.2. TFO-Cookie-Antwort (Cookie Response)
Nach Empfang einer Cookie-Anfrage generiert und gibt der Server ein Cookie zurück.
Cookie-Generierungsalgorithmus
Der Server verwendet folgende Informationen zur Cookie-Generierung:
- Client-IP-Adresse
- Server-Geheimnis (Server Secret)
- Zeitstempel (für Cookie-Ablauf)
Beispiel einer Verschlüsselungsfunktion:
Cookie = AES-128(ServerSecret, ClientIP || Timestamp)
TCP-Optionsformat
Cookie-Gewährungsoption:
- Kind: 34
- Length: 6 bis 18 (2-Byte-Kopf + 4 bis 16 Byte Cookie)
- Cookie: vom Server generiertes verschlüsseltes Token
Serververhalten
- MUSS: TFO-Cookie-Option in SYN-ACK einschließen
- SOLLTE: Algorithmus mit ausreichender Verschlüsselungsstärke zur Cookie-Generierung verwenden
- MUSS: Server-Geheimnis regelmäßig wechseln, um die Sicherheit zu erhöhen
2.3. TCP-Fast-Open-Verbindung (Fast Open Connection)
Der Client verwendet das gecachte Cookie in Folgeverbindungen, um Fast Open zu realisieren.
Nachrichtenfluss
Client Server
| |
| SYN + TFO Cookie + Daten |
|---------------------------------->|
| | (Cookie validieren)
| | (Daten verarbeiten)
| SYN-ACK + Daten |
|<----------------------------------|
| |
| ACK |
|---------------------------------->|
| |
| Weitere Daten |
|<--------------------------------->|
Wesentliche Vorteile
Latenzeinsparung:
- Traditionelles TCP: 1 RTT (Handshake) + 1 RTT (Anfrage-Antwort) = 2 RTT
- TCP Fast Open: 1 RTT (Handshake + Anfrage-Antwort) = 1 RTT eingespart
SYN-Datenbeschränkungen
Um Amplifikationsangriffe zu verhindern, sind die Daten im SYN-Paket begrenzt:
-
Maximale Datenlänge:
- Linux-Implementierung: Standardmäßig auf MSS (Maximum Segment Size) begrenzt
- Typischer Wert: ca. 1460 Byte (Ethernet MTU 1500 - IP/TCP-Kopf)
-
Datenanforderungen:
- MUSS: Daten müssen idempotent sein (können sicher erneut übertragen werden)
- SOLLTE: Daten sollten eine vollständige Anfrage sein (z. B. vollständige HTTP-Anfrage)
Server-Validierungsablauf
Wenn der Server ein Fast-Open-SYN empfängt:
1. TFO-Cookie validieren
├─ Gültig → SYN-Daten akzeptieren, in SYN-RECEIVED-Zustand wechseln
└─ Ungültig → SYN-Daten verwerfen, Standard-TCP-Handshake durchführen
2. Wenn Cookie gültig
├─ SYN-Daten an Anwendungsschicht weiterleiten
├─ Anwendung kann sofort verarbeiten und Antwort generieren
└─ Antwortdaten optional in SYN-ACK einschließen
3. Drei-Wege-Handshake abschließen
└─ Nach Empfang von ACK wechselt Verbindung in ESTABLISHED-Zustand
2.4. Cookie-Wiederverwendung (Cookie Reuse)
Cookie-Lebenszyklus
Gültigkeitsverwaltung:
- Typische Gültigkeitsdauer: Stunden bis Tage
- Aktualisierungsstrategie: Client kann regelmäßig neue Cookies anfordern
- Ablaufbehandlung: Nach Cookie-Ablauf lehnt der Server Fast Open ab; Client fällt auf Standard-Handshake zurück
Cookie-Ungültigkeitsszenarien
Ein Cookie kann in folgenden Situationen ungültig werden:
- Zeitablauf: Überschreitung der vom Server festgelegten Gültigkeitsdauer
- Server-Schlüsselwechsel: Server rotiert den Verschlüsselungsschlüssel
- IP-Adressänderung: Client-IP-Adresse ändert sich (Mobilfunknetz)
- Server-Richtlinie: Server widerruft Cookie aktiv (aus Sicherheitsgründen)
Client-Caching-Strategie
Zu implementierende SOLLTE-Funktionen:
- Für jede Server-IP:Port ein separates Cookie cachen
- Cookie-Ablaufverwaltung implementieren
- Bei Cookie-Ungültigkeit automatisch neu anfordern
- Cookie-Verwaltung für mehrere Server unterstützen
Rückfallmechanismus
Wenn Fast Open fehlschlägt, MUSS der Client zurückfallen können:
Fast Open versuchen
├─ Erfolgreich → weiter verwenden
├─ Cookie abgelehnt → Standard-Handshake abschließen, neues Cookie anfordern
└─ Timeout → SYN erneut übertragen (möglicherweise ohne Daten)
2.5. Protokollinteraktionszusammenfassung (Protocol Interaction Summary)
Vollständiger Lebenszyklus
Phase 1: Initialisierung
Client ──SYN(Cookie-Anfrage)──> Server
Client <──SYN-ACK(Cookie)─── Server
Client ──ACK──────────────> Server
[Client speichert Cookie im Cache]
Phase 2: Fast Open (mehrfach)
Client ──SYN(Cookie+Daten)──> Server
Client <──SYN-ACK(Daten)───── Server
Client ──ACK──────────────> Server
[1 RTT eingespart]
Phase 3: Cookie-Aktualisierung (bei Bedarf)
Phase 1 wiederholen
Leistungskennzahlen
| Verbindungstyp | Beginn der Datenübertragung | Relative Leistung |
|---|---|---|
| Standard-TCP | 1,5 RTT | Referenz |
| TFO (erstmalig) | 1,5 RTT | Gleich wie Standard-TCP |
| TFO (Folgeverbindung) | 0,5 RTT | 66 % Verbesserung |
Kompatibilitätsmatrix
| Client | Server | Ergebnis |
|---|---|---|
| TFO unterstützt | TFO unterstützt | Fast Open erfolgreich |
| TFO unterstützt | TFO nicht unterstützt | Rückfall auf Standard-TCP |
| TFO nicht unterstützt | TFO unterstützt | Standard-TCP |
| TFO nicht unterstützt | TFO nicht unterstützt | Standard-TCP |
Nächster Abschnitt: 3. Protocol Details (Protokolldetails) beschreibt das TFO-Optionsformat, den Zustandsautomaten und Implementierungsdetails eingehend.