Jaki jest minimalny rozmiar pakietu TCP


11

Post tutaj:

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

stwierdza, że ​​„Najmniejsze pobieranie, jakie przeglądarki mogą wykonać, to 1 KB bajtów”.

Czy wynika to z minimalnego rozmiaru pakietu w sieci? Jeśli nie, jaki jest tego powód (jeśli to rzeczywiście prawda)?


2
Trzymaj się standardowych warunków, jeśli chcesz uniknąć nieporozumień. „Pakiet” to termin na poziomie IP. Mówisz „pakiet IP”, „pakiet TCP”, ani „pakiet Ethernet”.
vtest

Zdanie, które cytujesz („Najmniejsze pobieranie, jakie przeglądarki mogą wykonać, to 1 K bajtów.”) Z pewnością nie jest prawdziwe - nie ma minimalnego rozmiaru; i choć nie jest rozmiar minimalny pakiet TCP / IP (jak wyjaśnił @ DMA57361), to z pewnością nie jest 1KB.
Piskvor opuścił budynek

Odpowiedzi:


20

Pakiet jest tu dwuznacznym terminem, ponieważ czasami jest niewłaściwie używany w odniesieniu do różnych elementów transmisji. Zobaczmy, w co są zapakowane twoje dane, a zobaczysz, o co mi chodzi, i mam nadzieję, że uzyskasz odpowiedź, której chciałeś:


Załóżmy, że wysyłasz 1 bajt danych 1 przez Internet, w modelu TCP / IP .

Do danych rozpoczyna się na poziomie aplikacji i musi być zawinięta w nagłówkach na niższych poziomach tak, że może być poprowadzony wokół.

Najpierw dane są pakowane w segment TCP , który dodaje nagłówek 20 bajtów (minimalny rozmiar to teraz 21 bajtów).
To stawia nas na poziomie transportu.

Jest to następnie pakowane w pakiet IP , który dodaje kolejny nagłówek 20 bajtów (minimalny rozmiar to teraz 41 bajtów).
Teraz jesteśmy na poziomie Internetu.
Pamiętaj, że to zawijanie jest zmieniane za każdym razem, gdy nowy router przesyła dane do nowej podsieci.

Jest on zawinięty w ramkę pewnego rodzaju - którego rozmiar nagłówka i stopki różni się w zależności od rodzaju użytej ramki, która zależy od rodzaju użytego łącza.
To jest na poziomie łącza.
To opakowanie jest zmieniane za każdym razem, gdy urządzenie jest przesyłane między dwoma podmiotami.

Wreszcie jest fizyczna transmisja (np. Sygnały elektryczne w kablu, fale radiowe itp.).

Oto kilka obrazków informacyjnych dostępnych na stronie modelowej TCP / IP Wikipedii, które pomagają wizualnie wyjaśnić, co się dzieje:


Hermetyzacja danych przy użyciu UDP / IP


Połączenie przez warstwy w modelu TCP / IP


1. Myślę, że możesz wysłać 0 bajtów ... ale tego nie sprawdziłeś. W rzeczywistości nie sprawdziłem, czy 1 bajt jest dozwolony, ale hej.


4

To nieprawda, nie ma minimalnego rozmiaru do pobrania. Możesz to zweryfikować, tworząc mały plik na swoim serwerze internetowym i używając Wireshark do obserwowania ruchu sieciowego podczas pobierania tego pliku.

Minimalny rozmiar standardowego pakietu Ethernet to 64 bajty.


3

Na pierwszy rzut oka zamieszczony przez Ciebie blog jest nieprawidłowy. Nie ma „minimalnego rozmiaru pobierania” dla HTTP. (A twoja teoria o minimalnych rozmiarach pakietów również jest nieprawidłowa.)

Jest w tym jednak ziarno prawdy. Oznacza to, że jeśli rozmiar pobieranego pliku jest wystarczająco mały, komunikat odpowiedzi HTTP (składający się z pliku i nagłówków odpowiedzi HTTP) zmieści się w jednym pakiecie sieciowym. Jeśli tak się stanie, przeglądarka prawdopodobnie pobierze plik szybciej niż w przypadku wysłania odpowiedzi przez dwa lub więcej pakietów.

(W odpowiedzi na jeden pakiet istnieje mniejsze prawdopodobieństwo, że pakiet zostanie odrzucony i konieczne będzie jego ponowne wysłanie, a większa szansa, że ​​okno kontroli przepływu TCP / IP nie doda dodatkowych opóźnień w obie strony dla potwierdzenia pakietu. )

Typowy maksymalny rozmiar wysyłanego / odbieranego pakietu (MTU) wynosi 1500 bajtów dla sieci Ethernet. Jeśli weźmiesz pod uwagę koszty ogólne IP i TCP oraz rozmiar typowego nagłówka odpowiedzi HTTP, możesz zostawić ~ 1 KB na dane pliku w pierwszym pakiecie odpowiedzi. Stąd ziarno prawdy w komentarzu blogera.


Byłoby to poprawne - gdybyś pobierał tylko ten jeden obraz, a nie, powiedzmy, stronę internetową i powiązane z nim zasoby (obrazy, JS, CSS) - w takim przypadku i tak używasz keepalives i potokowania dla wielu zasobów, więc TCP narzut i rozmiar pakietu są znacznie mniej istotne. Masz rację w tym konkretnym przypadku (pobieranie tylko jednego obrazu), ale jak często to się zdarza? Wygląda na to, że blogger utknął w 1999 r., Gdzie każde żądanie HTTP wymagało własnego połączenia TCP.
Piskvor opuścił budynek

2

Gorzej niż myślisz.

Powolne ładowanie strony jest spowodowane tym, że przeglądarka ma problemy z renderowaniem piksela 1x1 800000 razy (np. Dla okna przeglądarki ustawionego na 1000x800). Wiele lat temu, być może w 1999 roku, przeczytałem gdzieś artykuł, w którym przepisano 16x16 jako „najszybszy” x najmniejszy do układania płytek. Oczywiście rendering może być teraz inny.

Jeśli czytasz post na blogu, skarga dotyczy w rzeczywistości powolnego ładowania strony. Nie powolne pobieranie. Nie ma to nic wspólnego z pakietami, chociaż była to interesująca dyskusja.

Być może więc pytanie należy przeformułować.


W takim przypadku mogłem całkowicie nie rozumieć posta na blogu - myślałem, że rdzeń znajduje się w tym zdaniu: „Najmniejsze pobieranie, jakie można zrobić w przeglądarkach, to 1 KB [i dlatego dostosuj rozmiar obrazu do 1 KB]”, co Przeczytałem jako „... ponieważ i tak przesyłasz 1K bajtów, bez względu na to, że twój obraz ma tylko 50 bajtów” (co jest oczywistym nonsensem). Problemem może być użycie „ size” zarówno do wymiarów pikseli, jak i do zliczania bajtów i ich łączenie. Twoje wyjaśnienie ma sens, ale nie ma znaczenia liczba bajtów obrazu (w przeciwieństwie do tego, co mówi blog).
Piskvor opuścił budynek

Po ponownym przeczytaniu posta na blogu wydaje się, że zboczył z kursu, ponieważ trzeci akapit jest niespójny.
mockman

Po ponownym przeczytaniu komentarza ... Jego celem jest rozwiązanie problemu poruszonego w pierwszym akapicie. Jednak błędnie przypisuje ten problem rozmiarom pakietów i spędza na nim resztę wiadomości. Moja odpowiedź wyjaśniła powód wolnego ładowania strony. Jak zauważyli inni, charakterystyka pakietów nie jest przyczyną.
mockman
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.