Каков минимальный размер пакета TCP


11

Пост здесь:

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

утверждает, что «Наименьшая загрузка, которую могут сделать браузеры, составляет 1 КБ».

Это связано с минимальным размером пакета в сети? Если нет, то какова причина этого (если это действительно так)?


2
Придерживайтесь стандартных условий, если вы хотите избежать путаницы. «Пакет» - это термин уровня IP. Вы говорите «IP-пакет», ни «TCP-пакет», ни «Ethernet-пакет».
vtest

Предложение, которое вы цитируете («Наименьшая загрузка, которую могут сделать браузеры, составляет 1 Кбайт.»), Безусловно, не соответствует действительности - минимальный размер загрузки отсутствует; и в то время это минимум TCP / IP размер пакета (как объяснено @ DMA57361), это, конечно , не 1KB.
Писквор покинул здание

Ответы:


20

Здесь термин « пакет» является двусмысленным, поскольку иногда он неправильно используется для обозначения различных элементов вашей передачи. Давайте посмотрим, во что обернуты ваши данные, и вы поймете, что я имею в виду, и, надеюсь, получите ответ, который вы хотели:


Предположим, вы отправляете 1 байт данных 1 через Интернет в модели TCP / IP .

В данных начинается на уровне приложений и должен быть обернут в заголовках для более низких уровней , так что он может быть передан вокруг.

Сначала эти данные помещаются в сегмент TCP , который добавляет заголовок из 20 байтов (минимальный размер теперь 21 байт).
Это ставит нас на транспортный уровень.

Затем он оборачивается в IP-пакет , который добавляет еще один заголовок размером 20 байт (минимальный размер теперь составляет 41 байт).
Теперь мы на уровне интернета.
Обратите внимание, что эта упаковка меняется каждый раз, когда новый маршрутизатор пересылает ваши данные в новую подсеть.

Он заключен в фрейм ссылки какого-либо типа, размер заголовка и нижнего колонтитула которого зависит от типа используемого фрейма, который зависит от типа используемой ссылки.
Это на уровне ссылки.
Эта упаковка изменяется каждый раз, когда блок передается между двумя объектами.

Наконец, физическая передача (например, электрические сигналы по кабелю, радиоволны и т. Д.).

Вот некоторые информативные изображения, доступные со страницы модели TCP / IP Википедии, которые помогают визуально объяснить, что происходит:


Инкапсуляция данных с использованием UDP / IP


Соединение через слои в модели TCP / IP


1. Я думаю, вы могли бы отправить 0 байтов ... но не проверяли это. На самом деле я не проверял, разрешен ли 1 байт, но эй.


4

Это неверно, нет минимального размера для загрузки. Вы можете убедиться в этом, создав крошечный файл на своем веб-сервере и используя wireshark для отслеживания сетевого трафика при загрузке этого файла.

Минимальный размер стандартного пакета Ethernet составляет 64 байта.


3

На первый взгляд, запись в блоге, с которой вы цитируете, неверна. Не существует «минимального размера загрузки» для HTTP. (И ваша теория о минимальных размерах пакетов также неверна.)

Однако в этом есть доля правды. Иными словами, если размер загружаемого файла достаточно мал, ответное сообщение HTTP (состоящее из файла и заголовков ответа HTTP) поместится в одном сетевом пакете. Если это произойдет, браузер, скорее всего, получит файл быстрее, чем если бы для отправки ответа потребовалось два или более пакетов.

(С одним пакетом в ответе меньше вероятность того, что пакет будет отброшен и его необходимо отправить повторно, и больше вероятность того, что окно управления потоком TCP / IP не добавит дополнительных задержек приема-передачи для подтверждения пакета. )

Типичный максимальный размер отправляемого / получаемого пакета (MTU) составляет 1500 байтов для Ethernet. Когда вы учитываете издержки IP и TCP и размер типичного заголовка ответа HTTP, это может оставить ~ 1K для файловых данных в первом пакете ответа. Отсюда и доля правды в комментарии блоггера.


Это было бы правильно - если вы загружали только это одно изображение, а не, скажем, веб-страницу и связанные с ней ресурсы (изображения, JS, CSS) - в этом случае вы все равно используете keepalive и конвейерную обработку для нескольких ресурсов, поэтому TCP издержки и размер пакета гораздо менее актуальны. Вы правы в данном конкретном случае (скачиваете только одно изображение), но как часто это происходит? Кажется, что блоггер застрял в 1999 году, где для каждого HTTP-запроса требовалось собственное TCP-соединение.
Писквор покинул здание

2

Это хуже, чем ты думаешь.

Медленная загрузка страницы вызвана тем, что в браузере возникают проблемы при рендеринге пикселя 1x1 800000 раз (например, для окна браузера, установленного на 1000x800). Много лет назад, возможно, в 1999 году, я где-то читал статью, в которой предписывалось, что 16x16 является «самым быстрым» x наименьшим для черепицы. Конечно, сейчас рендеринг может быть другим.

Если вы читаете сообщение в блоге, жалоба на самом деле о медленной загрузке страницы. Не медленная загрузка. Это не имеет ничего общего с пакетами, хотя это было интересное обсуждение.

Так что, возможно, вопрос должен быть переформулирован.


В этом случае я, возможно, неправильно понял сообщение в блоге - я подумал, что ядро ​​в этом предложении: «Наименьшая загрузка, которую могут сделать браузеры, составляет 1 КБ [и, следовательно, отрегулируйте размер изображения до 1 КБ]», что Я читал как «... потому что вы все равно передаете 1 Кбайт, независимо от того, что ваше изображение составляет всего 50 байт» (что является очевидной чепухой). Проблема здесь может заключаться в использовании " size" как для измерений в пикселях, так и для подсчета байтов, и их совмещения. Ваше объяснение имеет смысл, но не имеет значения для количества байтов изображения (вопреки тому, что говорится в блоге).
Писквор покинул здание

Перечитав сообщение в блоге, он, кажется, отклоняется от курса, поскольку третий абзац бессвязен.
издатель

Перечитав ваш комментарий ... Он намеревается решить проблему, поднятую во вступительном абзаце. Однако он ошибочно приписывает эту проблему размеру пакета и тратит на него оставшуюся часть сообщения. Мой ответ объяснил причину медленной загрузки страницы. Как уже отмечали другие, характеристики пакета не являются причиной.
Mockman
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.