Wie kann eine TCP-Fenstergröße größer sein als die maximale Größe eines Ethernet-Pakets?

Ich weiß, dass TCP-Fenstergrößen auf über 64 KB skaliert werden können, aber wenn ich mir ein Ethernet-Paket-Datagramm wie dieses ansehe:

Es sieht so aus, als ob ein Layer-2-Paket eine begrenzte Größe hat, um viel kleiner zu sein. Wie funktioniert ACKing auf der TCP-Ebene, wenn für eine einzelne TCP-Anforderung mehrere Netzwerkanforderungen an einem Empfänger zusammengestellt werden müssen?

Die TCP-Fenstergröße ist im Allgemeinen unabhängig von der maximalen Segmentgröße, die von der maximalen Übertragungseinheit abhängt, die wiederum von der maximalen Rahmengröße abhängt .

Fangen wir niedrig an.

Die maximale Rahmengröße ist der größte Rahmen, den ein Netzwerk (Segment) transportieren kann. Für Ethernet sind dies per Definition 1518 Byte.

Der Frame kapselt ein IP-Paket, sodass das größte Paket - die maximale Übertragungseinheit MTU - die maximale Frame-Größe abzüglich des Frame-Overheads ist. Für Ethernet sind das 1518 - 18 = 1500 Bytes.

Das IP-Paket kapselt ein TCP-Segment, sodass die maximale Segmentgröße MSS die MTU abzüglich des IP-Overheads abzüglich des TCP-Overheads ist (MSS enthält keinen TCP-Header). Für Ethernet und TCP über IPv4 ohne Optionen sind dies 1500 - 20 (IPv4-Overhead) - 20 (TCP-Overhead)) = 1460 Byte.

Jetzt ist TCP ein Transportprotokoll, das sich als Stream-Socket für die Anwendung darstellt. Das bedeutet, dass eine Anwendung einfach eine beliebige Datenmenge über diesen Socket übertragen kann. Dazu teilt TCP den Datenstrom in diese Segmente auf (0 bis MSS Bytes lang {1}), überträgt jedes Segment über IP und setzt sie am Ziel wieder zusammen.

TCP-Segmente werden vom Ziel bestätigt, um die Zustellung zu gewährleisten. Stellen Sie sich vor, der Quellknoten würde nur ein einzelnes Segment senden, auf die Bestätigung warten und dann das nächste Segment senden. Unabhängig von der tatsächlichen Bandbreite würde der Durchsatz dieser TCP-Verbindung durch die Umlaufzeit begrenzt (RTT, die Zeit, die ein Paket benötigt, um von der Quelle zum Ziel und wieder zurück zu gelangen).

Wenn Sie also eine 1-Gbit / s-Verbindung zwischen zwei Knoten mit einer RTT von 10 ms hätten, könnten Sie effektiv alle 10 ms oder 146 kB / s 1460 Bytes senden. Das ist nicht sehr befriedigend.

TCP verwendet daher ein Sendefenster - mehrere Segmente, die gleichzeitig "im Flug" sein können, gesendet werden und auf Bestätigung warten. Es wird auch als Schiebefenster bezeichnet, da es jedes Mal vorgerückt wird, wenn das Segment am Anfang des Fensters bestätigt wird, wodurch das Senden des nächsten Segments ausgelöst wird, zu dem das Fenster vorgerückt ist. Auf diese Weise spielt die Segmentgröße keine Rolle. Mit einem Fenster von traditionell 64 KiB können wir diese Menge während des Fluges haben und dementsprechend 64 KiB in jeweils 10 ms = 6,5 MB / s transportieren. Besser, aber für eine Gigabit-Verbindung immer noch nicht wirklich zufriedenstellend.

Modernes TCP verwendet die Option zur Fensterskalierung , mit der das Sendefenster exponentiell auf bis zu 2 GiB erhöht werden kann, um zukünftiges Wachstum zu erzielen.

Aber warum werden nicht alle Daten gleichzeitig gesendet und warum benötigen wir dieses Sendefenster? Wenn Sie alles so schnell senden, wie Sie - lokal - können, und (sehr wahrscheinlich) irgendwo auf dem Weg zum Ziel eine langsamere Verbindung besteht, müssen erhebliche Datenmengen in die Warteschlange gestellt werden. Kein Switch oder Router kann mehr als ein paar MB (wenn überhaupt) puffern, sodass der überschüssige Datenverkehr gelöscht werden müsste. Wenn die Bestätigung nicht erfolgt, muss sie erneut gesendet werden, und der Überschuss wird erneut gelöscht. Dies wäre äußerst ineffizient und würde das Netzwerk stark überlasten. TCP behandelt dieses Problem mit seiner Überlastungskontrolle und passt die Fenstergröße in einem komplexen Algorithmus an die effektive Bandbreite und die aktuelle Umlaufzeit an.

{1} Leere Segmente können verwendet werden, um Verbindungszeitüberschreitungen mithilfe der Keepalive- Option zu verhindern . Thx Deduplicator