TCP-Fenstersonde

Question 1

Ich gehe davon aus, dass der Grund dafür darin liegt, dass die Fensterprüfmeldungen ein Oktett an Daten enthalten.

Nur um das klarzustellen: Es gibt kein spezielles Paketformat, keinen Header oder andere Kennung für ein Fensterprüfpaket. TCP sendet einfach ein Standard-TCP-Paket, wenn es ein Fenster prüfen muss. Es beschränkt die Benutzer-/Anwendungsdaten in diesem TCP-Paket einfach auf ein einziges Oktett.

Ich habe im Standard keine Angabe gesehen, dass Prüfpakete ein Oktett neuer Daten enthalten müssen.

Sie haben gerade die Aussage im Standard zitiert, dass Testpakete mindestens ein Oktett neuer Daten enthalten müssen, nicht wahr? Wenn Sie weitere Aussagen wünschen, finden Sie Aussagen in RFC 793 und RFC 1122, die Sie daran erinnern, dass Bestätigungen ohne neue Anwendungsdaten nicht zuverlässig übertragen werden (mit der Implikation, dass Sie einige neue Daten übertragen müssen, um wissen zu können, ob sie durchgekommen sind).

Gibt es verschiedene Möglichkeiten, die Fenstergröße zu prüfen?

Man könnte sich vorstellen, dass die Autoren des TCP-Standards andere Möglichkeiten hätten finden können, aber die von Ihnen zitierte Methode ist die einzige, die sie im Standard vorgesehen haben.

Wenn dies die einzige Möglichkeit ist, frage ich mich, warum das erneute Senden eines alten Segments (mit einer alten Sequenznummer) nicht ausreicht.

Es geht nicht darum, ob es ausreicht, sondern was der beste Weg ist. Wenn Sie keine weiteren Daten zu senden haben, müssen Sie das Fenster nicht testen. Wenn SieTunweitere Daten zu übermitteln haben, nutzen Sie dochDasum das Fenster zu prüfen, anstatt Bandbreite für zuvor gesendete (und vermutlich bestätigte) Daten zu verschwenden?

Muss der Empfänger nur Daten bestätigen, die sich zu einem bestimmten Zeitpunkt innerhalb des Fensters befinden (d. h. alte Daten werden nicht unbedingt bestätigt)

Der Empfänger sollte nur die zuletzt empfangenen Daten bestätigen, d. h. die Daten, die mit allen seit dem Beginn empfangenen Daten zusammenhängen (mit zusammenhängend meine ich, dass er, wenn er eine Lücke aufweist, weil er ein oder mehrere Pakete verpasst hat, aber ein späteres Paket erhalten hat, dieses spätere Paket nicht bestätigen kann; er muss weiterhin die letzte Sequenznummer vor der ersten Lücke bestätigen).

Benachrichtigt der Empfänger den Absender im Allgemeinen, wenn sein Fenster größer wird?

Ja, im Allgemeinen benachrichtigt der Empfänger den Absender mit jeder Bestätigung über Aktualisierungen der Fenstergröße.

Außerdem schlagen die Autoren unter „Vorschläge zur Fensterverwaltung“ auf S. 43 von RFC 793 vor, dass TCP-Empfänger „eine weitere Bestätigung mit neuen Fensterinformationen senden, wenn das Fenster größer ist“. Dieses RFC ist älter als RFC 2119, das die Terminologiestandards MAY/SHOULD/MUST definierte, aber dieser Vorschlag scheint gemäß den Richtlinien zu den Anforderungsebenen von RFC 2119 als SOLLTE betrachtet zu werden.

Muss es das tun (ich verstehe, dass die Bestätigung verloren gehen kann, sodass der Absender möglicherweise trotzdem nachforschen muss)?

Mir ist kein RFC bekannt, das RFC 793 aktualisiert und dieses Verhalten zu einem MUSS machen würde.

Werden Testpakete nur gesendet, wenn das Fenster = 0 ist, oder können sie auch schon vorher gesendet werden?

Wenn das Fenster nicht Null wäre, würde ein TCP-Segment mit einem Datenbyte nicht wirklich als Probe betrachtet werden. Wenn ich beispielsweise eine Telnet-Verbindung hätte, die einzelne Tastenanschläge an den Remote-Host sendet, könnte jeder Tastenanschlag als TCP-Segment mit einem Datenbyte gesendet werden. Diese können in einem Fall wie Telnet problemlos gesendet werden, selbst wenn das Fenster größer als 0 oder 1 ist, aber sie würden nicht als Probe betrachtet werden.

Answer

Ich gehe davon aus, dass der Grund dafür darin liegt, dass die Fensterprüfmeldungen ein Oktett an Daten enthalten.

Nur um das klarzustellen: Es gibt kein spezielles Paketformat, keinen Header oder andere Kennung für ein Fensterprüfpaket. TCP sendet einfach ein Standard-TCP-Paket, wenn es ein Fenster prüfen muss. Es beschränkt die Benutzer-/Anwendungsdaten in diesem TCP-Paket einfach auf ein einziges Oktett.

Ich habe im Standard keine Angabe gesehen, dass Prüfpakete ein Oktett neuer Daten enthalten müssen.

Sie haben gerade die Aussage im Standard zitiert, dass Testpakete mindestens ein Oktett neuer Daten enthalten müssen, nicht wahr? Wenn Sie weitere Aussagen wünschen, finden Sie Aussagen in RFC 793 und RFC 1122, die Sie daran erinnern, dass Bestätigungen ohne neue Anwendungsdaten nicht zuverlässig übertragen werden (mit der Implikation, dass Sie einige neue Daten übertragen müssen, um wissen zu können, ob sie durchgekommen sind).

Gibt es verschiedene Möglichkeiten, die Fenstergröße zu prüfen?

Man könnte sich vorstellen, dass die Autoren des TCP-Standards andere Möglichkeiten hätten finden können, aber die von Ihnen zitierte Methode ist die einzige, die sie im Standard vorgesehen haben.

Wenn dies die einzige Möglichkeit ist, frage ich mich, warum das erneute Senden eines alten Segments (mit einer alten Sequenznummer) nicht ausreicht.

Es geht nicht darum, ob es ausreicht, sondern was der beste Weg ist. Wenn Sie keine weiteren Daten zu senden haben, müssen Sie das Fenster nicht testen. Wenn SieTunweitere Daten zu übermitteln haben, nutzen Sie dochDasum das Fenster zu prüfen, anstatt Bandbreite für zuvor gesendete (und vermutlich bestätigte) Daten zu verschwenden?

Muss der Empfänger nur Daten bestätigen, die sich zu einem bestimmten Zeitpunkt innerhalb des Fensters befinden (d. h. alte Daten werden nicht unbedingt bestätigt)

Der Empfänger sollte nur die zuletzt empfangenen Daten bestätigen, d. h. die Daten, die mit allen seit dem Beginn empfangenen Daten zusammenhängen (mit zusammenhängend meine ich, dass er, wenn er eine Lücke aufweist, weil er ein oder mehrere Pakete verpasst hat, aber ein späteres Paket erhalten hat, dieses spätere Paket nicht bestätigen kann; er muss weiterhin die letzte Sequenznummer vor der ersten Lücke bestätigen).

Benachrichtigt der Empfänger den Absender im Allgemeinen, wenn sein Fenster größer wird?

Ja, im Allgemeinen benachrichtigt der Empfänger den Absender mit jeder Bestätigung über Aktualisierungen der Fenstergröße.

Außerdem schlagen die Autoren unter „Vorschläge zur Fensterverwaltung“ auf S. 43 von RFC 793 vor, dass TCP-Empfänger „eine weitere Bestätigung mit neuen Fensterinformationen senden, wenn das Fenster größer ist“. Dieses RFC ist älter als RFC 2119, das die Terminologiestandards MAY/SHOULD/MUST definierte, aber dieser Vorschlag scheint gemäß den Richtlinien zu den Anforderungsebenen von RFC 2119 als SOLLTE betrachtet zu werden.

Muss es das tun (ich verstehe, dass die Bestätigung verloren gehen kann, sodass der Absender möglicherweise trotzdem nachforschen muss)?

Mir ist kein RFC bekannt, das RFC 793 aktualisiert und dieses Verhalten zu einem MUSS machen würde.

Werden Testpakete nur gesendet, wenn das Fenster = 0 ist, oder können sie auch schon vorher gesendet werden?

Wenn das Fenster nicht Null wäre, würde ein TCP-Segment mit einem Datenbyte nicht wirklich als Probe betrachtet werden. Wenn ich beispielsweise eine Telnet-Verbindung hätte, die einzelne Tastenanschläge an den Remote-Host sendet, könnte jeder Tastenanschlag als TCP-Segment mit einem Datenbyte gesendet werden. Diese können in einem Fall wie Telnet problemlos gesendet werden, selbst wenn das Fenster größer als 0 oder 1 ist, aber sie würden nicht als Probe betrachtet werden.

Question 2

Dies baut aufSpiffs Antwort, aber mit mehr Ergänzungen, als in einen Kommentar passen würden. Beachten Sie, dass im August 2022RFC9293ersetzte schließlich die ursprüngliche TCP-Spezifikation und enthält die gesamte MUST/SHOULD/MAY-Sprache.

F1. Ich habe im Standard nicht gesehen, dass Testpakete ein Oktett neuer Daten enthalten müssen.

Die folgende Anforderung, die nicht auf ein Oktett beschränkt ist, war in der ursprünglichen TCP-Spezifikation enthaltenRFC793und wurde wortwörtlich in RFC9293 kopiert:

When the receiving TCP peer has a zero window and a segment arrives, it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).

F2. Ich frage mich, warum das erneute Senden eines alten Segments nicht ausreicht.

Dies ist nicht die effizienteste Methode (wenn das Fenster groß genug wird, muss das Oktett trotzdem verworfen werden). Aber es würde funktionieren, da die Spezifikationen zur TCP-Überlastungskontrolle immer etwas wieRFC5681jetzt heißt es:

A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-
order segment arrives.

F3. Benachrichtigt der Empfänger den Absender im Allgemeinen, wenn sein Fenster größer wird?

Ich nehme an, Sie meinen, dass das Fenster des Empfängers wächst, weil die empfangende Anwendung einige Daten aus dem Empfangspuffer verbraucht. Dann glaube ich, dass es in den Spezifikationen keine Anforderung gibt, eine ACK zu senden, um dies mitzuteilen. Daher ist die Fenstersonde erforderlich, um eine ACK auszulösen.

F4. Werden Testpakete nur gesendet, wenn Fenster = 0

Ja, per Definition. Denn wenn ein Paket mit einem Oktett gesendet würde, bevor Fenster = 0 ist, wäre es nur ein normales Paket, das zufällig ein Oktett groß ist.

Answer