Was ist die Mindestgröße eines TCP-Pakets?

11

Ein Beitrag hier:

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

staes dass "Der kleinste Download, den Browser ausführen können, ist 1 KB."

Liegt dies an der Mindestgröße eines Pakets im Netzwerk? Wenn nicht, was ist der Grund dafür (wenn es tatsächlich wahr ist)?

— Andy Hume
quelle

2

Halten Sie sich an Standardbegriffe, wenn Sie Verwirrung vermeiden möchten. "Paket" ist ein Begriff auf IP-Ebene. Sie sagen "IP-Paket" oder "TCP-Paket", weder "Ethernet-Paket".

— vtest

Der von Ihnen zitierte Satz ("Der kleinste Download, den Browser ausführen können, ist 1 KByte.") Stimmt mit Sicherheit nicht - es gibt keine minimale Downloadgröße. und während es ist ein Minimum TCP / IP - Paketgröße (wie erläutert durch @ DMA57361), es ist sicherlich nicht 1 KB.

— Piskvor verließ das Gebäude

20

Paket ist hier ein mehrdeutiger Begriff, da es manchmal missbraucht wird, um auf verschiedene Elemente für Ihre Übertragung zu verweisen. Mal sehen, in was Ihre Daten eingepackt sind, und Sie werden sehen, was ich meine, und hoffentlich die Antwort erhalten, die Sie wollten:

Nehmen wir an, Sie senden 1 Byte Daten ¹ über das Internet im TCP / IP-Modell .

Die Daten beginnen auf Anwendungsebene und müssen in Headern für die unteren Ebenen verpackt werden, damit sie weitergegeben werden können.

Zuerst werden diese Daten in ein TCP-Segment eingeschlossen , das einen Header von 20 Bytes hinzufügt (Mindestgröße jetzt 21 Bytes).
Dies bringt uns auf die Transportebene.

Dies wird dann in ein IP-Paket eingeschlossen , das einen weiteren Header von 20 Bytes hinzufügt (Mindestgröße jetzt 41 Bytes).
Jetzt sind wir auf Internetebene.
Beachten Sie, dass dieser Wrapping jedes Mal geändert wird, wenn ein neuer Router Ihre Daten an ein neues Subnetz weiterleitet.

Dies ist in einen Link- Frame eines bestimmten Typs eingeschlossen, dessen Kopf- und Fußzeile je nach Art des verwendeten Frames und je nach Art des verwendeten Links unterschiedlich ist.
Dies ist auf Verbindungsebene.
Diese Umhüllung wird jedes Mal geändert, wenn die Einheit zwischen zwei Entitäten übertragen wird.

Schließlich ist die physische Übertragung (z. B. elektrische Signale über ein Kabel, Funkwellen usw.).

Hier sind einige informative Bilder, die auf der Wikipedia TCP / IP-Modellseite verfügbar sind , um visuell zu erklären, was passiert:

Datenkapselung mit UDP / IP

Verbindung über Schichten im TCP / IP-Modell

^{1. Ich denke, Sie können möglicherweise 0 Bytes senden ... haben das aber nicht überprüft. Tatsächlich habe ich auch nicht überprüft, ob 1 Byte erlaubt ist, aber hey.}

— DMA57361
quelle

4

Das ist falsch, es gibt keine Mindestgröße für einen Download. Sie können dies überprüfen, indem Sie eine winzige Datei auf Ihrem Webserver erstellen und mit drahteshark den Netzwerkverkehr überwachen, wenn Sie diese Datei herunterladen.

Die Mindestgröße eines Standard-Ethernet-Pakets beträgt 64 Byte.

— Shapr
quelle

3

Auf den ersten Blick ist der Blog-Beitrag, aus dem Sie zitieren, falsch. Es gibt keine "minimale Downloadgröße" für HTTP. (Und Ihre Theorie über minimale Paketgrößen ist ebenfalls falsch.)

Dies ist jedoch ein Körnchen Wahrheit. Wenn die Größe der heruntergeladenen Datei klein genug ist, passt die HTTP-Antwortnachricht (bestehend aus der Datei und den HTTP-Antwortheadern) in ein einzelnes Netzwerkpaket. In diesem Fall wird der Browser die Datei wahrscheinlich schneller abrufen, als wenn zwei oder mehr Pakete zum Senden der Antwort erforderlich waren.

(Mit einem Paket in der Antwort besteht eine geringere Wahrscheinlichkeit, dass ein Paket verworfen wird und erneut gesendet werden muss, und eine größere Wahrscheinlichkeit, dass das TCP / IP-Flusssteuerungsfenster keine zusätzlichen Umlaufverzögerungen für die Paketbestätigung hinzufügt. )

Die typische maximale Größe eines gesendeten / empfangenen Pakets (MTU) beträgt 1500 Byte für Ethernet. Wenn Sie den IP- und TCP-Overhead und die Größe eines typischen HTTP-Antwortheaders berücksichtigen, bleiben möglicherweise ~ 1 KB für Dateidaten im ersten Paket einer Antwort übrig. Daher das Korn der Wahrheit im Kommentar des Bloggers.

— Stephen C.
quelle

Das wäre richtig - wenn Sie nur dieses eine Bild herunterladen würden und nicht beispielsweise eine Webseite und die zugehörigen Ressourcen (Bilder, JS, CSS) - in diesem Fall verwenden Sie Keepalives und Pipelining für mehrere Ressourcen, also TCP Overhead und Paketgröße sind viel weniger relevant. Sie haben in diesem speziellen Fall Recht (nur ein Bild herunterladen), aber wie oft passiert das? Es scheint, dass der Blogger 1999 feststeckte, als jede HTTP-Anfrage eine eigene TCP-Verbindung benötigte.

— Piskvor verließ das Gebäude

2

Es ist schlimmer als du denkst.

Das langsame Laden der Seite ist darauf zurückzuführen, dass der Browser Probleme hat, das 1x1-Pixel 800000-mal zu rendern (z. B. für ein Browserfenster, das auf 1000x800 eingestellt ist). Vor vielen Jahren, vielleicht 1999, las ich irgendwo einen Artikel, in dem 16x16 als das 'schnellste' x kleinste zum Kacheln vorgeschrieben war. Natürlich kann das Rendern jetzt anders sein.

Wenn Sie den Blog-Beitrag lesen, geht es bei der Beschwerde tatsächlich um langsames Laden von Seiten. Nicht langsam herunterladen. Es hat nichts mit Paketen zu tun, obwohl es eine interessante Diskussion war.

Vielleicht sollte die Frage umformuliert werden.

— Mockman
quelle

In diesem Fall habe ich den Blog-Beitrag möglicherweise völlig falsch verstanden - ich habe gedacht, dass der Kern in diesem Satz liegt: "Der kleinste Download, den Browser ausführen können, ist 1 KByte [und passen Sie daher Ihre Bildgröße auf 1 KByte an]" Ich habe gelesen als "... weil Sie sowieso 1 KByte übertragen, egal dass Ihr Bild nur 50 Byte groß ist" (was ein offensichtlicher Unsinn ist). Das Problem hierbei kann darin bestehen, " size" sowohl für Pixelabmessungen als auch für die Byteanzahl zu verwenden und diese zusammenzuführen. Ihre Erklärung ist sinnvoll, aber für die Anzahl der Bytes des Bildes irrelevant (im Gegensatz zu den Aussagen des Blogs).

— Piskvor verließ das Gebäude

Nach dem erneuten Lesen des Blogposts scheint er vom Kurs abzuweichen, da der dritte Absatz inkohärent ist.

— Mockman

Nach dem erneuten Lesen Ihres Kommentars ... Sein beabsichtigter Punkt ist es, das im ersten Absatz angesprochene Problem anzusprechen. Er schreibt dieses Problem jedoch fälschlicherweise den Paketgrößen zu und gibt den Rest des Beitrags dafür aus. Meine Antwort erklärte den Grund für das langsame Laden der Seite. Wie andere betont haben, sind Paketmerkmale nicht die Ursache.

— Mockman