Zum Hauptinhalt springen

1. Introduction (Einführung)

1.1. Motivation​

Die traditionelle TCP-Verbindungsherstellung erfordert einen Drei-Wege-Handshake (Three-Way Handshake), der mindestens eine vollständige Umlaufzeit (Round-Trip Time, RTT) Latenz einführt, bevor die Datenübertragung beginnen kann. Für viele moderne Anwendungen, insbesondere Webdienste und mobile Anwendungen, stellt diese Latenz einen erheblichen Leistungsengpass dar.

Latenzproblem in typischen Szenarien​

Im traditionellen TCP MUSS ein Client:

  1. Ein SYN-Paket senden
  2. Auf die SYN-ACK-Antwort des Servers warten
  3. Eine ACK-Bestätigung senden
  4. Erst dann Anwendungsdaten senden

Das bedeutet, dass die Übertragung von Anwendungsdaten mindestens 1,5 RTT erfordert (vorausgesetzt, der Server antwortet sofort nach Empfang des ACK).

Herausforderungen bei HTTP-Kurzzeitverbindungen​

Für das HTTP-Anfrage-Antwort-Muster gilt:

  • Jede neue Verbindung erfordert einen vollständigen Drei-Wege-Handshake
  • Bei Kurzzeitverbindungen (z. B. einzelne API-Aufrufe) macht die Handshake-Latenz einen großen Anteil der Gesamtzeit aus
  • Dieses Problem ist in Hochlatenz-Netzwerken (wie Mobilfunknetzen) noch ausgeprägter

Beispiel-Latenzberechnung:

  • 50 ms RTT-Netzwerk: Handshake-Latenz = 50 ms
  • 200 ms RTT-Netzwerk (transkontinental): Handshake-Latenz = 200 ms

Bei API-Aufrufen, die kleine Datenmengen zurückgeben, kann die Handshake-Latenz die eigentliche Datenübertragungszeit übersteigen.

1.2. Schlüsselkonzepte (Key Concepts)​

TCP Fast Open (TFO) löst dieses Problem, indem es den Datenaustausch während des TCP-Handshakes ermöglicht.

Ein TFO-Cookie ist ein verschlüsseltes Token zur Validierung der Client-Identität:

  1. Cookie-Anfragephase:

    • Der Client fordert beim ersten Verbindungsaufbau ein TFO-Cookie an
    • Der Server generiert und gibt ein Cookie zurück (verschlüsselt auf Basis der Client-IP-Adresse)
    • Der Client speichert das Cookie für die spätere Verwendung im Cache

  2. Fast-Open-Phase:

    • Der Client fügt Cookie und Anwendungsdaten in das SYN-Paket ein
    • Der Server validiert die Gültigkeit des Cookies
    • Bei erfolgreicher Validierung akzeptiert der Server die SYN-Daten und kann sofort antworten

Leistungsverbesserung​

Zeitplan der Datenübertragung mit TFO:

  1. Erstverbindung: Client sendet SYN (fordert Cookie an)
  2. Folgeverbindungen: Client sendet SYN + Cookie + Daten → Server verarbeitet sofort

Latenzreduzierung: Einsparung von 1 vollständigen RTT

Sicherheitsdesign​

Der TFO-Cookie-Mechanismus bietet folgende Sicherheitsschutzmaßnahmen:

  • Anti-Amplifikation: Begrenzt die Größe von SYN-Datenpaketen
  • Anti-Ressourcenerschöpfung: Cookie-Validierung stellt die Client-Identität sicher
  • Rückwärtskompatibilität: Server, die TFO nicht unterstützen, ignorieren die Option

Terminologie​

Gemäß RFC 2119 haben Schlüsselwörter in diesem Dokument folgende Bedeutungen:

  • MUSS (MUST): Absolute Anforderung
  • SOLLTE (SHOULD): Dringend empfohlen, kann aber unter bestimmten Umständen ignoriert werden
  • KANN (MAY): Vollständig optionale Funktion

Anwendungsfälle (Use Cases)​

TFO eignet sich besonders für:

  • Web-Browsing: HTTP/HTTPS-Anfragen
  • API-Aufrufe: RESTful API, RPC
  • Mobile Anwendungen: Häufige Kurzzeitverbindungsanfragen
  • IoT-Geräte: Periodische Datenmeldungen

Einschränkungen und Überlegungen​

Bei der Verwendung von TFO ist zu beachten:

  • SYN-Daten können erneut übertragen werden (Idempotenzanforderung)
  • Einige Netzwerkgeräte können TCP-Optionen beeinträchtigen
  • Cookies haben Ablaufzeiten und müssen regelmäßig erneuert werden

Nächster Abschnitt: 2. Protocol Overview (Protokollübersicht) beschreibt den TFO-Arbeitsablauf und die Nachrichtenaustauschsmuster im Detail.

Letztes Update am