Appendix B. Duplicates from Earlier Connection Incarnations (Duplikate aus früheren Verbindungsinkarnationen)

Appendix B: Duplicates from Earlier Connection Incarnations (Duplikate aus früheren Verbindungsinkarnationen)

Es sind zwei Fälle zu berücksichtigen: (1) ein System stürzt ab (und verliert den Verbindungszustand) und startet neu, und (2) dieselbe Verbindung wird geschlossen und ohne Verlust des Host-Zustands wieder geöffnet. Diese werden in den folgenden beiden Abschnitten beschrieben.

B.1 System Crash with Loss of State (Systemabsturz mit Zustandsverlust)

Die TCP-Ruhezeit von einem MSL beim Systemstart behandelt den Verlust des Verbindungszustands bei einem Systemabsturz/Neustart. Für eine Erklärung siehe zum Beispiel "When to Keep Quiet" in der TCP-Protokollspezifikation [Postel81]. Das hier erforderliche MSL hängt nicht von der Übertragungsgeschwindigkeit ab. Das aktuelle TCP-MSL von 2 Minuten scheint als operativer Kompromiss akzeptabel zu sein, da viele Hostsysteme nach einem Absturz so lange zum Booten benötigen.

Die Timestamp-Option kann jedoch verwendet werden, um die MSL-Anforderungen zu lockern (oder um zusätzliche Sicherheit gegen Datenbeschädigung zu bieten). Wenn Timestamps verwendet werden und wenn die Timestamp-Uhr garantiert über einen Systemabsturz/Neustart monoton sein kann, d.h. wenn der erste Wert der Timestamp-Uhr des Senders nach einem Absturz/Neustart garantiert größer als der letzte Wert vor dem Neustart sein kann, dann ist eine Ruhezeit unnötig.

Um vollständig auf die Ruhezeit zu verzichten, müsste die Hostuhr mit einer Zeitquelle synchronisiert werden, die über die Absturz-/Neustartperiode stabil ist, mit einer Genauigkeit von einem Timestamp-Uhr-Tick oder besser. Wir können von dieser strengen Anforderung zurücktreten, um von einer ungefähren Uhrsynchronisation zu profitieren. Angenommen, die Uhr wird immer innerhalb von N Timestamp-Uhr-Ticks neu synchronisiert und das Booten (bei Bedarf mit einer Ruhezeit erweitert) dauert mehr als N Ticks. Dies garantiert die Monotonie der Timestamps, die dann verwendet werden können, um alte Duplikate auch ohne ein erzwungenes MSL abzulehnen.

B.2 Closing and Reopening a Connection (Schließen und erneutes Öffnen einer Verbindung)

Wenn eine TCP-Verbindung geschlossen wird, bindet eine Verzögerung von 2*MSL im TIME-WAIT-Zustand das Socket-Paar für 4 Minuten (siehe Abschnitt 3.5 von [Postel81]). Auf TCP aufbauende Anwendungen, die eine Verbindung schließen und eine neue öffnen (z.B. eine FTP-Datenübertragungsverbindung im Stream-Modus), müssen jedes Mal ein neues Socket-Paar wählen. Die TIME-WAIT-Verzögerung dient zwei verschiedenen Zwecken:

(a) Implement the full-duplex reliable close handshake of TCP. (Implementierung des zuverlässigen Voll-Duplex-Schließ-Handshakes von TCP)

Die richtige Zeit, um den endgültigen Schließschritt zu verzögern, hängt nicht wirklich mit dem MSL zusammen; sie hängt stattdessen vom RTO für die FIN-Segmente und daher vom RTT des Pfades ab. (Man könnte argumentieren, dass die Seite, die ein FIN sendet, weiß, welchen Grad an Zuverlässigkeit sie benötigt, und daher sollte sie in der Lage sein, die Länge der TIME-WAIT-Verzögerung für den FIN-Empfänger zu bestimmen. Dies könnte mit einer geeigneten TCP-Option in FIN-Segmenten erreicht werden.)

Obwohl es keine formale Obergrenze für RTT gibt, macht die übliche Netzwerk-Engineering-Praxis ein RTT von mehr als 1 Minute sehr unwahrscheinlich. Somit funktioniert die 4-Minuten-Verzögerung im TIME-WAIT-Zustand zufriedenstellend, um einen zuverlässigen Voll-Duplex-TCP-Abschluss zu ermöglichen. Beachten Sie erneut, dass dies unabhängig von der MSL-Durchsetzung und der Netzwerkgeschwindigkeit ist.

Der TIME-WAIT-Zustand könnte ein indirektes Leistungsproblem verursachen, wenn eine Anwendung wiederholt eine Verbindung schließen und eine andere mit sehr hoher Frequenz öffnen müsste, da die Anzahl der verfügbaren TCP-Ports auf einem Host weniger als 2**16 beträgt. Hohe Netzwerkgeschwindigkeiten sind jedoch nicht der Hauptverursacher dieses Problems; das RTT ist der begrenzende Faktor dafür, wie schnell Verbindungen geöffnet und geschlossen werden können. Daher wird dieses Problem bei hohen Übertragungsgeschwindigkeiten nicht schlimmer.

(b) Allow old duplicate segments to expire. (Erlauben, dass alte duplizierte Segmente ablaufen)

Um diese Funktion des TIME-WAIT-Zustands zu ersetzen, müsste ein Mechanismus über Verbindungen hinweg funktionieren. PAWS ist streng innerhalb einer einzelnen Verbindung definiert; der letzte Timestamp TS.Recent wird im Verbindungssteuerungsblock gehalten und verworfen, wenn eine Verbindung geschlossen wird.

Ein zusätzlicher Mechanismus könnte dem TCP hinzugefügt werden, ein Pro-Host-Cache des letzten von einer beliebigen Verbindung empfangenen Timestamps. Dieser Wert könnte dann im PAWS-Mechanismus verwendet werden, um alte duplizierte Segmente aus früheren Inkarnationen der Verbindung abzulehnen, wenn garantiert werden kann, dass die Timestamp-Uhr mindestens einmal getickt hat, seit die alte Verbindung offen war. Dies würde erfordern, dass die TIME-WAIT-Verzögerung plus das RTT zusammen mindestens ein Tick der Timestamp-Uhr des Senders sein müssen. Eine solche Erweiterung ist nicht Teil des Vorschlags dieses RFC.

Beachten Sie, dass dies eine Variante des von Garlick, Rom und Postel [Garlick77] vorgeschlagenen Mechanismus ist, der erforderte, dass jeder Host Verbindungsaufzeichnungen mit den höchsten Sequenznummern auf jeder Verbindung führt. Bei Verwendung von Timestamps ist es stattdessen nur notwendig, eine Größe pro Remote-Host zu behalten, unabhängig von der Anzahl gleichzeitiger Verbindungen zu diesem Host.