Zusammenfassung

  • Beim Simultaneous Open starten beide Endpunkte einen aktiven OPEN für dasselbe Socket-Paar. Reine SYNs kreuzen sich, beide wechseln nach SYN-RECEIVED, und gekreuzte SYN-ACKs ergeben eine einzige Verbindung.
  • Ein vorher bestimmter Client ist nicht nötig. Jeder Endpunkt prüft lokal die aktuelle Initial Sequence Number des Gegenübers und erhält eine Bestätigung seiner eigenen.
  • Viele NATs erwarteten auf ein ausgehendes SYN zwingend ein eingehendes SYN-ACK. RFC 5382 musste verlangen, dass bei erlaubten Verbindungen auch das gültige eingehende SYN des gleichzeitigen Pfads erhalten bleibt.

Das Lehrbild machte aus Ablauf Rollen

SYN, SYN-ACK, ACK: Das Diagramm ist richtig, aber unvollständig. RFC 793 erklärte bereits, dass zwei Prozesse, die gleichzeitig aktiv zueinander öffnen, korrekt verbunden werden. Für asynchron arbeitende verteilte Komponenten war diese Freiheit ausdrücklich wichtig.

Client und Server beschreiben Anwendungen. Sie sind keine Titel, aus denen TCP-Wahrheit entsteht. Die Verbindung beruht auf einem Socket-Paar und zwei synchronisierten Sequenzräumen.

Simultaneous Open war daher kein späterer Notbehelf für eine Kollision. Es gehörte zum ursprünglichen Verbindungsaufbau. Das verbreitete Bild zeigte einen häufigen Pfad; spätere Zwischenboxen verwechselten ihn mit dem ganzen Zustandsautomaten.

Zwei SYNs, ein gemeinsamer Zustand

A wählt 100, B wählt 300. Beide senden SYN und gehen nach SYN-SENT. Empfängt A das nackte SYN von B, verwirft es dieses nicht wegen des eigenen Versuchs. A speichert 300, geht nach SYN-RECEIVED und sendet SYN-ACK mit ACK 301. B spiegelt den Vorgang und bestätigt 101.

Treffen die SYN-ACKs ein, kennt jede Seite den entfernten Startwert und weiß, dass der eigene angekommen ist. RFC 9293 bewahrt die korrigierte Folge: Auf beiden Seiten CLOSED → SYN-SENT → SYN-RECEIVED → ESTABLISHED.

Die Paketzeichnung sieht anders aus als beim aktiven/passiven Fall, die Beweisstruktur bleibt gleich. Beide Ursprünge werden angekündigt, empfangen und bestätigt.

Das Plus eins war der Beleg

Ein SYN belegt eine Position im Sequenzraum. Das SYN bei 300 wird deshalb mit 301 bestätigt. Das ACK sagt nicht bloß „Paket gesehen“, sondern dass der Empfänger über dieses sequenzierte Steuerelement hinausgelangt ist. Ein leeres ACK belegt selbst keinen Platz, sonst müssten ACKs ohne Ende bestätigt werden.

Die Senderäume bleiben getrennt. Symmetrische Initiative bedeutet keine gemeinsamen Nummern. RFC 6528 ergänzte später eine geheime Pseudozufallsfunktion über das Vier-Tupel, um ISNs schwerer vorhersagbar zu machen.

Damit braucht TCP keinen zentralen Schiedsrichter. Identität, erwartete Nummern und bestätigte Historie sind an jedem Endpunkt lokal prüfbar.

Zwei lokale Aufrufe ergaben nicht zwei Verbindungen

Weil beide Anwendungen aktiv connect auslösen, scheint ein doppeltes Ergebnis zunächst plausibel. RFC 1122 warnt genau davor: Gleichzeitige Versuche erzeugen eine Verbindung statt zweier, und diese absichtliche Entscheidung soll nicht „repariert“ werden.

Aus A-Sicht steht der lokale A-Socket dem entfernten B-Socket gegenüber; B sieht dasselbe Paar umgekehrt. Eine Verdoppelung erzeugte keine zusätzliche Wirklichkeit, sondern nur die Frage, welches Duplikat Daten tragen soll.

Lokale Verfahren und gemeinsamer Netzstatus sind verschieden. Zwei Anträge können in einem einzigen, synchronisierten Zusammenhang enden.

Derselbe Zustandsname brauchte Herkunft

SYN-RECEIVED kann auf einen passiven OPEN oder auf den Empfang eines SYN nach aktivem OPEN folgen. RFC 1122 und RFC 9293 verlangen, diese Herkunft zu speichern. Das Verhalten bei einem Reset und eine mögliche Rückkehr zu LISTEN hängen davon ab.

RFC 793 wusste außerdem, dass ein altes doppeltes SYN wie ein gleichzeitiger Neubeginn aussehen kann. TCP verbietet deshalb nicht den legitimen Pfad. Aktuelle Sequenzannahmen, Bestätigungen und Reset-Prüfung trennen die neue Inkarnation von altem Netzschutt.

Ein Zustand ist also mehr als sein Etikett. Wer die Eintrittsgeschichte löscht, verliert gerade im Fehlerfall die Entscheidungsgrundlage.

Das NAT lernte nur die häufigste Geschichte

Beim gewöhnlichen Client-Server-Verkehr erzeugt ein ausgehendes SYN eine Abbildung; anschließend kommt ein SYN-ACK zurück. Beim Simultaneous Open kommt ein weiteres SYN. RFC 5382 dokumentierte NATs, die es als unaufgefordert blockierten, sowie Geräte, die das folgende ausgehende SYN-ACK falsch übersetzten.

Die Endpunkte befolgten TCP. Die Box hatte nur einen populären Ablauf als vollständiges Protokoll implementiert. Das ist nicht dasselbe wie eine Sicherheitsrichtlinie, die die Verbindung ausdrücklich verweigert.

Ist eine Verbindung erlaubt, muss die Zustandsverfolgung ihre gültigen Übergänge verstehen. RFC 5382 verlangt deshalb für erlaubte Verbindungen alle gültigen TCP-Folgen einschließlich Simultaneous Open. Die Policy bleibt bestehen; die Interpretation darf sie nicht heimlich verengen.

Sechs Sekunden machten Unwissen messbar

Ein entferntes SYN kann das NAT erreichen, bevor das lokale SYN die Abbildung erzeugt. In diesem Augenblick wirkt es tatsächlich unaufgefordert. Ein sofortiger RST oder ICMP-Fehler liefert schnelle Gewissheit, beendet aber auch ein Rendezvous, dessen lokales SYN nur verspätet ist.

RFC 5382 verlangt mindestens sechs Sekunden Zurückhaltung. Erscheint das passende ausgehende SYN, wird das frühe Paket still verworfen und seine Wiederholung kann die nun vorhandene Abbildung nutzen. Andernfalls kann nach Maßgabe der Sicherheit ein Fehler folgen.

Die Frist ist kein Naturgesetz des TCP. Sie bepreist fehlendes Zukunftswissen: schneller Fehler gegen erhaltene Option, geringe Latenz gegen temporären Zustand. Die Spezifikation macht den Zielkonflikt sichtbar.

Peer-to-Peer nutzte die alte Symmetrie neu

Sind beide Enden hinter Übersetzern, kann keines zuverlässig passiv erreichbar sein. Beide können jedoch ausgehenden Zustand zum zuvor ausgetauschten Adress- und Portkandidaten schaffen. Stimmen Abbildungen und Timing, treffen sich die SYNs.

RFC 6544 definierte dafür S-O-Kandidaten in ICE TCP neben aktiven und passiven Kandidaten. Zugleich empfiehlt es mehrere Kandidatentypen und Relays, weil Betriebssysteme, NATs und Netze unterschiedlich sind.

Normkonformität ist nicht Reichweite. Simultaneous Open stellt den Endpunkten einen gültigen Mechanismus bereit; die gesamte Strecke entscheidet, ob er nutzbar bleibt.

Bestand hatte eine Symmetrie aus Beweisen

Der gemeinsame Kern ist klein: Socket-Paar bestimmen, zwei frische Ursprünge austauschen, beide bestätigen und nötige Herkunft bewahren. Darüber können Anwendungen aktiv, passiv, gleichzeitig oder über Relay arbeiten.

Das NAT-Problem war nicht zu viel Freiheit am Rand. Eine häufige Konvention wurde unbemerkt zum Zwang. RFC 5382 trennte die Ebenen wieder: Die Box darf entscheiden, was sie erlaubt; sie muss das erlaubte TCP aber vollständig lesen.

Als beide Enden zugleich anriefen, wählte TCP keinen Sieger. Es ließ beide Seiten Versand und Empfang beweisen. Eine Verbindung entstand aus verifizierbarem gemeinsamen Zustand, nicht aus vorab verliehenen Rollen.

Quellen und Beweisgrenzen

Grundlagen sind RFC 793, RFC 1122, RFC 5382, RFC 6528, RFC 6544 und RFC 9293. Sie liefern keine heutige Nutzungsquote und keine Vollerhebung von APIs oder NATs. Verlust und Wiederholung können die beobachtete Reihenfolge verändern.