Zusammenfassung

  • RFC 1644 verglich beim TCP Accelerated Open den CC des ersten SYN mit dem zuletzt für den Client gespeicherten Wert. Ein höherer Wert erlaubte die Datenübergabe vor Abschluss des gewöhnlichen Drei-Wege-Handshakes.
  • CC.NEW erklärte die bisherige Kontinuität nach Neustart, Zählerumlauf oder fehlender Historie für ungültig und erzwang den normalen Handshake. CC.ECHO band das SYN/ACK an den Öffnungswert des Clients.
  • Der Mechanismus grenzte alte Transportduplikate ab, nicht Identität oder Anwendungs-Commit. RFC 6247 stufte T/TCP später wegen fehlender breiter Nutzung und gemeldeter Sicherheitsprobleme als Historic ein.

Der Cache öffnete das Tor

RFC 1644 beschrieb eine experimentelle Erweiterung für kurze Anfrage-Antwort-Folgen. Der Client legte Nutzdaten und einen 32-Bit-Verbindungszähler in das erste SYN. Der Server hielt je Clienthost den letzten gültigen Wert fest.

War der neue Wert größer, bestand das SYN den TAO-Test. Der Server aktualisierte den Cache und gab die Daten an den Benutzerprozess. Bei gleichem oder kleinerem Wert ließ sich ein altes Duplikat nicht von Umordnung unterscheiden; dann galt der normale Handshake.

Der Vergleich bestätigte nur eine lokale Reihenfolge. Er setzte einen monotonen Zähler, einen passenden Cachelebenszyklus und die richtige Zuordnung zum Client voraus. Weder die Person hinter dem Host noch die spätere Wirkung des Programms wurde dadurch belegt.

CC.NEW machte verlorene Kontinuität sichtbar. Nach einem Neustart oder möglichem Umlauf löschte der Server seinen Eintrag und verlangte 3WHS. CC.ECHO spiegelte im SYN/ACK den Öffnungswert, sodass der Client die Antwort zuordnen konnte. Eine kryptografische Identität entstand daraus nicht.

Transportgarantie und Geschäftsabschluss

RFC 1644 begrenzte „transaction“ ausdrücklich auf die Transportfolge und schloss Anwendungssemantik wie Mehrphasen-Commit aus. Auch der minimale Ablauf bestand aus drei Segmenten.

Nach der Übergabe kann die Anwendung beim Parsen, Autorisieren oder dauerhaften Schreiben scheitern. Sie kann einen nachgelagerten Auftrag auslösen und anschließend die Antwort verlieren. Für einen Client ohne Antwort unterscheidet CC nicht zwischen Nichtzustellung, Ablehnung und erfolgreicher Ausführung mit verlorenem Beleg.

Irreversible Vorgänge brauchen deshalb eine stabile Operations-ID, dauerhafte Deduplizierung und einen Ergebnisbeleg in der Anwendungsschicht. Ein Transportcache kann keine Zahlung oder Konfigurationsänderung quittieren.

Der historische Status ist Teil der Aussage. RFC 6247 verschob RFC 1644 nach Historic, weil keine weite Verbreitung eingetreten war und Sicherheitsprobleme gemeldet wurden. Die heutige TCP-Grundlage ist RFC 9293. Daraus folgt keine Aussage über heutige Implementierungen oder Middleboxes.

Auch TIME-WAIT blieb bedingt

Für kurze Verbindungen half CC, neue Inkarnationen von alten Segmenten zu unterscheiden und TIME-WAIT zu verkürzen. Bei Laufzeiten über der maximalen Segmentlebensdauer war weiterhin die normale Verzögerung erforderlich. Fielen die Transaktionsannahmen weg, sollte T/TCP in gewöhnliches TCP übergehen.

Ein Cachetreffer, eine Transportübergabe und ein dauerhafter Anwendungserfolg sind drei verschiedene Belege.

Quellen und Grenzen

Die Quellen beweisen weder aktuelle Bereitstellung noch authentisierte Identität oder exakt einmalige Geschäftsausführung.