Zusammenfassung

  • Das TCP-Fast-Open-Cookie wird vom Server erzeugt und ist an den Quell-IP-Kontext gebunden; es ist weder Benutzeridentität noch Anfrage-ID.
  • Gültiges TFO kann SYN-Daten vor Abschluss des Handshakes an die Anwendung liefern, während RFC 7413 das seltene Risiko doppelter Zustellung beibehält.
  • Ein Ausführungsnachweis verbindet Transportsequenzen, authentifizierten Akteur, Anfrageidentität, Deduplizierung, Commit und Antwort.

Der schnelle Pfad endete vor dem Geschäftsergebnis

Ein Client sendet eine Reservierung im SYN mit gespeichertem Cookie. Der Server prüft es, puffert die Daten, benachrichtigt die Anwendung und bestätigt SYN und Daten. Die nützliche Antwort erreicht den Client nicht; nach dem Fallback sendet er dieselbe logische Anfrage erneut.

Das Cookie sagt nicht, ob die zweite Ankunft die erste wiederholt. Das TCP-ACK sagt weder, dass ein Commit abgeschlossen wurde, noch dass die Autorisierung gelang oder die Antwort zugestellt wurde. Der Transport kann korrekt sein, obwohl das Geschäftsergebnis offen bleibt.

Was das Cookie authentifiziert

RFC 7413 beschreibt einen undurchsichtigen, serverseitig erzeugten Wert. Die vorgesehene Konstruktion authentifiziert die Quell-IP des SYN und verhindert eine Herstellung durch den Client. Der Server kann mehrere Cookies akzeptieren, eigene Daten kodieren und sie jederzeit verfallen lassen.

Das begrenzt Angriffe mit gefälschter Quelle, authentifiziert aber keine Person. IP-Adressen können geteilt, übersetzt oder neu vergeben werden. Ein gültiges Cookie bedeutet nur, dass der Server den IP-Kontext nach aktueller Richtlinie für Fast Open akzeptiert.

Die Anwendung muss TFO je Dienstport ausdrücklich aktivieren. Der Listener kann es abschalten oder bei Erreichen des Pending-Limits keine neuen Fast Opens annehmen. Cookieprüfung, Listener-Zulassung und Anwendungsautorisierung sind getrennt.

Frühe Daten: angenommen, verworfen oder erneut gesendet

Bei gültigem Cookie kann der Server SYN-Daten an die Anwendung geben und bestätigen. Bei ungültigem Cookie oder nicht verfügbarem TFO verwirft er die Daten und bestätigt nur den SYN; der Client sendet unbestätigte Bytes nach dem Handshake erneut.

Zwischensysteme können SYNs mit Nutzdaten oder unbekannten Optionen verwerfen. RFC 7413 empfiehlt nach einem Timeout den Rückfall auf ein gewöhnliches SYN, das weder Daten noch eine Fast-Open-Option trägt. Auch die gespeicherte MSS zählt, weil frühe Daten vor Bekanntgabe des aktuellen Werts gesendet werden; zu viele frühe Daten können eine erneute Übertragung erfordern.

Das ACK endet an der TCP-Grenze

RFC 9293 versieht jedes Oktett mit einer Sequenznummer und definiert kumulative Bestätigung als Empfang beim TCP-Peer. Das ist Transportnachweis, nicht Beleg für Identitätsprüfung, Autorisierung, dauerhafte Speicherung oder Anwendungsergebnis.

RFC 7413 warnt, dass SYN-Daten selten mehrfach an die Anwendung gelangen können. Frühe Operationen brauchen stabile Anfrage-ID, Deduplizierungsbereich, atomare Behandlung und abrufbares Ergebnis.

Quellen