Fenstergröße und ACK-Nummer

Kopieren und Einfügen von den Folien meines Dozenten:

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

Daraus ergibt sich, dass die Fenstergröße angibt, wie viele Bytes der Empfänger vor dem Senden einer Bestätigung sammeln wird.

Aber das sehe ich in diesem Wireshark-Capture nicht:

Wie Sie auf dem Screenshot sehen können (von einer TCP-Dateiübertragung), bestätigt der Server etwa alle ~ 1400 Bytes (unter Berücksichtigung der ACK-Nummer), zeigt aber gleichzeitig eine Fenstergröße von 100'000 + Bytes an?

Nach dem, was ich aus den Folien meines Dozenten verstehe, sollte der Server alle 100'000 + Bytes bestätigen? Warum ACKing er viel öfter als das?

Ich unterrichte TCP und stoße oft auf Leute, denen falsch beigebracht wurde, dass die ACK nur gesendet wird, wenn die Fenstergröße erreicht ist. Das ist nicht wahr. (Um wirklich transparent zu sein, habe ich dies auch falsch gelehrt, bevor ich es auch besser wusste, also verstehe ich den Fehler vollständig).

HINWEIS: Ich werde Empfänger / Absender verwenden, um dies zu beschreiben. Beachten Sie jedoch, dass TCP bidirektional ist und beide Parteien eine Fenstergröße beibehalten.

Die Fenstergröße (die der Empfänger festlegt) ist eine feste Grenze für die Anzahl der Bytes, die der Absender senden kann, ohne gezwungen zu sein, anzuhalten, um auf eine Bestätigung zu warten.

Die Fenstergröße bestimmt nicht , wie oft der Empfänger Bestätigungen senden soll. Ursprünglich forderte das TCP-Protokoll , dass nach dem Empfang jedes Segments eine Bestätigung gesendet wird. Später wurde TCP optimiert , damit der Empfänger ACKs überspringen und für jedes zweite Paket (oder mehr) eine ACK-Bestätigung senden kann.

Das Ziel von TCP ist es dann, dass der Absender kontinuierlich Pakete ohne Verzögerung oder Unterbrechung sendet, da er kontinuierlich Bestätigungen empfängt, so dass die Anzahl der "Bytes während der Übertragung" immer geringer als die Fenstergröße ist. Wenn der Absender zu irgendeinem Zeitpunkt eine Anzahl von Bytes gesendet hat, die der Fenstergröße entspricht, ohne eine Bestätigung zu erhalten, muss er das Senden unterbrechen und warten.

Das Wichtigste dabei ist die Hin- und Rückfahrt. Wenn Sie TCP in einem Wireshark studieren, sehen Sie häufig nur die Perspektive einer Partei in der TCP-Konversation, was es schwierig macht, den Effekt der RTT abzuleiten oder wirklich zu "sehen". Schauen Sie sich diese beiden Aufnahmen an, um die Wirkung von RTT zu veranschaulichen . Beide erfassen dieselbe Konversation, einen 2-MB-Dateidownload über HTTP, aber einer aus Sicht des Clients und der andere aus Sicht des Servers .

Hinweis: es einfacher TCP zu analysieren , wenn Sie schalen aus der Wireshark - Funktion „ Allow subdissector wieder zusammenzusetzen TCP - Streams “

Beachten Sie bei der serverseitigen Erfassung (wer der Absender der Datei ist), dass der Server 8 Pakete in voller Größe hintereinander sendet (Paketnummer 6-13), bevor er die erste Bestätigung in Paket Nr. 14 erhält. Wenn Sie einen Drilldown durchführen Beachten Sie, dass die Bestätigung des Kunden für das in Paket Nr. 7 gesendete Segment gilt. Die vom Paket in Paket 20 gesendete ACK stammt aus dem in Paket 9 gesendeten Segment.

Sehen Sie, wie der Client tatsächlich jedes andere Paket bestätigt. Aber es scheint fast so, als würde es sie "spät" anerkennen. Tatsächlich ist dies jedoch nur der Effekt der Round Trip Time. Der Absender kann 7 ~ Segmente in der Zeit senden, die das erste Segment benötigt, um den Client zu erreichen, und die ACK des Clients, um den Server zu erreichen. Wenn Sie sich die Erfassung aus der Sicht des Kunden ansehen, sieht sie sehr "sauber" aus, dh, jedes zweite empfangene Paket sendet eine ACK aus.

Beachten Sie auch, was bei Paket Nr. 23 passiert. Der Server hat alles gesendet, was er kann, da die "Bytes während der Übertragung" die Fenstergröße erreichen und daher gezwungen sind, das Senden zu beenden. Bis der nächste ACK eintrifft. Da kommen die ACKs in jedes andere Segment. Mit jedem ACK kann der Absender erneut zwei neue Segmente senden, bevor das Fenster wieder voll ist und der Server erneut zum Anhalten gezwungen wird. Dies geschieht bis zu Paket Nr. 51, wenn der Client (Empfänger) die Fenstergröße erheblich erhöht, sodass der Server (Absender) wieder ungehemmt Daten übertragen kann ... zumindest bis Paket Nr. 175, wenn das neue Fenster voll ist.

Die Fenstergröße wird verwendet, um eine Überlastung des Empfängers zu verhindern (im Gegensatz zum Überlastungsfenster, das versucht, eine Überlastung im Netzwerk zu verhindern).

Die Funktionalität ist relativ einfach: Der Empfänger informiert den Absender über seine Fenstergröße, die normalerweise die verfügbare Puffergröße darstellt. Daher sollte diese Anzahl jedes Mal verringert werden, wenn ein neues Paket beim Empfänger ankommt, und jedes Mal erhöht werden, wenn ein Paket beim Empfänger verarbeitet wird.

Auf der Senderseite, versucht der Absender sicherstellen, dass zu einem bestimmten Zeitpunkt er / sie nicht hat im Transit mehr Bytes als die letzten beworbenen Fenster erhalten und damit die Wahrscheinlichkeit von Überflutung des Empfängers senken.

Anhand Ihrer Wireshark-Ausgabe können wir nun erkennen, dass Ihre Fenstergröße relativ groß ist und Ihre Übertragungen daher nicht gedrosselt werden und Sie für jedes gesendete Paket eine ACK erhalten (wie es im allgemeinen Szenario der Fall sein sollte, in dem keine ACK-Aggregation verwendet wird). . Derzeit beträgt die am häufigsten verwendete maximale Größe für Ethernet-Frames 1500 Byte. Wenn Sie alle Header entfernen, sehen Sie, dass die verbleibenden Bytes tatsächlich die Anzahl sind, um die Ihre ACKs erhöht werden.