Верна ли моя оценка минимального полезного объёма данных для быстрой передачи через HTTP?
Пытаюсь прикинуть разумный минимальный полезный размер в байтах для HTTP-запроса исходя из того, что HTTP-запрос ходит поверх TCP-пакетов.
Следовательно — быстрая передача — это чтобы 1 HTTP_запрос умещался в 1 TCP-пакет.
TCP-пакет с одной стороны должен быть меньше 65кБайт (лимит IP-фрейма), а с другой стороны размер TCP-пакета — это TCP-ЗАГОЛОВОК (20...60байт) + TCP-ТЕЛО любой длины, но в сумме не больше MTU.
Значени MTU, как я понимаю, могут быть на маршруте разными, но по RFC 879 минимальный размер 576 байт.
Поэтому получается, что минимальны размер полезных данных в HTTP-запросе равен 576 байт минус 60 байт на заголовок TCP-пакета, минус длина HTTP-заголовка.
А т.к. минимальный HTTP-заголовок, по моим очень субъективным ощущениям, в среднем около 300-400 байт, то получается, что на полезные данные остается около 100-200 байт.
Спасибо за ваше внимание к вопросу. Причина почти академическа — спор с моим товарищем на тему — до какого предела есть смысл уменьшать полезный объем сообщения в HTTP-запросах. Я субъективно исходил из предположения, что образно говоря «пол-килобайта» и «10 байт» придут за примерно одно время. Но хотелось вычислить примерную оценку такого «минимального объема», после которого бесмысллено что-то уменьшать.
В чем ошибочность постулата, что HTTP-запрос из 1 TCP-пакета дойдет быстрее, чем из большее их колличества? (Про накопление малых фреймов/окон в буффере я в курсе. Я не нашел данных о типичных размерах такого буффера)
во-первых это не постулат, а ваше предположение. почувствуйте разницу.
во-вторых как вы уже поняли, маленький размер запроса не гарантирует того, что он будет передан за один сетевой кадр. типичного размера буфера для всех типов соединений нет. поведение отправки определяется алгоритмом Нагла, а MSS в разных ОС уже определяется по типу соединения и его MTU. для сокета с низкой задержкой алгоритм Нагла следует отключить.
в-третьих TCP-соединение не берётся из ниоткуда. оно начинается с тройного рукопожатия — соответственно это два пустых пакета туда и один обратно. совсем другое дело если сервер поддерживает Keepalive и соединение уже было установлено.
этого всего я в ваших рассуждениях не увидел о быстрой передаче не увидел
Спасибо за комментарии. Причина вопроса — мой спор с товарищем на тему — до какого предела есть смысл уменьшать полезный объем сообщения в HTTP-запросах. Я субъективно исходил из предположения, что образно говоря «пол-килобайта» и «10 байт» придут за примерно одно время. Но хотелось вычислить примерную оценку такого «минимального объема».
> лимит IP-фрейма
фреймами оперирует протокол канального уровня, ip — сетевой, tcp — транспортный.
так что выражение ip-фрейм некорректно.
> но в сумме не больше MTU
MTU понятие канального уровня, так что как минимум хидер IP нужно включить.
Ну а вообще есть понятие MSS (Maximum Segment Size):
MSS = MTU — sizeof(TCPHDR) — sizeof(IPHDR)
> А т.к. минимальный HTTP-заголовок, по моим очень субъективным ощущениям, в среднем около 300-400 байт
значительно меньше.
