HTTP 1.1 Конвейерная обработка - PullRequest
Новая
       36

HTTP 1.1 Конвейерная обработка

6 голосов
/ 21 июля 2010

Мне нужно реализовать HTTP-клиент на Java, и для моих нужд, кажется, наиболее эффективный способ сделать это - реализовать HTTP-конвейер (согласно RFC2616 ).

Каккроме того, я хочу, чтобы конвейерная почта.(Также я не говорю о мультиплексировании. Я говорю о конвейерной обработке, т. Е. О множестве запросов по одному соединению до получения пакетных HTTP-запросов)

Я не смог найти стороннюю библиотеку, которая явно заявляет, что поддерживает конвейерную обработку,Но я мог бы использовать, например, Apache HTTPCore , чтобы создать такого клиента, или, если мне нужно, собрать его самому.

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

Итак, я должен попытаться реализовать такой клиент, или у меня будут большие проблемы из-за реализаций сервера (или прокси-серверов).Есть ли какие-либо ссылки, которые дают руководящие указания по этим вопросам?

Если это плохая идея, какой будет альтернативная модель программирования для повышения эффективности?Отдельные соединения TCP?

Ответы [ 3 ]

9 голосов
/ 21 июля 2010

POST не должен передаваться по конвейеру

8.1.2.2 Трубопровод

Клиент, который поддерживает постоянные Соединения МОГУТ "трубопровод" его запросы (т.е. отправка нескольких запросов не дожидаясь каждого ответа). сервер ДОЛЖЕН отправить свои ответы эти запросы в том же порядке, что запросы были получены.

Клиенты, которые предполагают постоянные соединения и трубопровод немедленно после установления соединения СЛЕДУЕТ будьте готовы повторить их соединение если первая конвейерная попытка не удалась. Если клиент делает такую ​​попытку, он ДОЛЖЕН НЕ конвейер, пока он не знает связь постоянна. Клиенты ДОЛЖНЫ также будьте готовы отправить их запросы, если сервер закрывает соединение перед отправкой всех соответствующие ответы.

Клиенты не должны передавать запросы используя неидемпотентные методы или неидемпотентные последовательности методов (см. раздел 9.1.2). В противном случае, преждевременное прекращение перевозки соединение может привести к неопределенности Результаты. Клиент, желающий отправить неидемпотентный запрос ДОЛЖЕН ждать отправить этот запрос, пока он не получил статус ответа для предыдущий запрос.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

8 голосов
/ 21 июля 2010

Я реализовал конвейерный HTTP-клиент. Основная концепция звучит легко, но обработка ошибок очень сложна. Увеличение производительности настолько незначительно, что мы давно отказались от концепций.

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

Вот лишь некоторые препятствия, которые я помню,

  1. Keepalive TCP не гарантирует постоянное соединение. Если у вас есть 3 запроса по соединению, сервер сбрасывает соединение после первого ответа. Вы должны повторить следующие два запроса.

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

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

0 голосов
/ 22 июля 2010

конвейерная обработка почти не имеет значения для http-серверов; они все равно обычно обрабатывают запросы в соединении последовательно - читают запрос, пишут ответ, затем читают следующий запрос ...

но клиент, скорее всего, улучшит пропускную способность за счет мультиплексирования. веб-сайты обычно имеют несколько компьютеров с несколькими процессорами, почему вы хотите добровольно ограничить свои запросы одной строкой? сегодня это больше о горизонтальной масштабируемости (параллельные запросы). конечно, лучше всего это сравнить.

...