Назад | Перейти на главную страницу

Когда браузер отправляет полезные данные HTTP отдельно от HTTP-запроса?

При каких обстоятельствах вы ожидаете, что веб-браузер разделит HTTP-запрос на два IP-пакета, даже если сумма размеров пакетов все еще меньше максимального размера сегмента? Я бы предположил, что это всегда будет отправляться одним пакетом, но мой опыт показывает иное.

Используя Microsoft Network Monitor для анализа HTTP-трафика, я иногда вижу запрос, который разделен на два IP-пакета, как показано ниже.

HTTP:Request, POST /foobar.htm (PacketID=55178, TotalLength=528)
  POST /foobar.htm HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  ...etc...

HTTP:HTTP Payload, URL: /foo.htm (PacketID=55179, TotalLength=98)
  param1=foo&param2=bar&param3=foo+bar

Пока что я видел это только на клиентах Windows XP, но не на всех клиентах XP. А в затронутых системах IE8 и Firefox демонстрируют одинаковое поведение двух пакетов.

Некоторый контекст: недавно мы начали использовать сторонний программный пакет, который предоставляет веб-приложение в нашей интрасети. Но вместо использования настоящего веб-сервера, такого как IIS или Apache, программное обеспечение внутренне реализует собственный HTTP-сервер.

Поскольку сервер использует простую реализацию HTTP, он проверяет только первый пакет HTTP-запроса и пропускает аргументы, отправленные во втором пакете. Это приводит к сбою запроса.

windows ip http tcp

Это случайно и непредсказуемо, и если вам не все равно, вы делаете что-то ужасно неправильно.

Поскольку сервер использует простую реализацию HTTP, он проверяет только первый пакет HTTP-запроса и пропускает аргументы, отправленные во втором пакете. Это приводит к сбою запроса.

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

Если вы действительно имеете в виду, что HTTP-сервер просматривает пакеты, то он должен восстановить поток данных TCP, а затем следовать протоколу HTTP. Конец HTTP-запроса отмечен двумя <CRLF> в потоке байтов TCP. Любой другой метод определения конца HTTP-запроса не работает.

Поскольку первый пакет не содержит последовательности завершения запроса HTTP, он явно не может содержать весь запрос.

HTTP-сервер должен соответствовать спецификации HTTP, в противном случае это не HTTP-сервер. Спецификация HTTP только указывает, какие байты идут в поток данных TCP. В нем ничего не говорится о сегментации, что хорошо, потому что на практике приложения не могут это контролировать. Он определяет, как определяется конец запроса, и код, который не соответствует этой спецификации, не HTTP-сервер. Он реализует протокол, подобный HTTP, который может быть совместим или несовместим с HTTP.

Как создаются POST, о которых идет речь - те, которые проливаются, сделаны через XMLHTTPRequest, то есть AJAX?

POST AJAX отправляют заголовки и тело как минимум как два отдельных TCP-пакета.

Несколько лет назад в сети разработчиков Yahoo есть сообщение об этом в блоге.