Конвейерная обработка HTTP 1.1
Я должен реализовать клиент HTTP в Java, и для моих потребностей кажется, что самый эффективный способ сделать это, HTTP-конвейер реализации (согласно RFC2616).
Как в стороне, я хочу конвейерно обработать СООБЩЕНИЯ. (Также я не говорю о мультиплексировании. Я говорю о конвейерной обработке т.е. многих запросах по одному соединению прежде, чем получить любой ответ - пакетная обработка Запросов HTTP),
Я не мог найти стороннюю библиотеку, которая явно заявляет, что поддерживает конвейерную обработку. Но я мог использовать, например, Apache HTTPCore для создания такого клиента, или если я имею к, создаю его один.
Проблема, которую я имею, состоит в том, если это - хорошая идея. Я не нашел авторитетных ссылок, что конвейерная обработка HTTP является чем-то большим чем теоретической моделью и правильно реализована серверами HTTP. Дополнительно все браузеры, которые поддерживают конвейерную обработку, имеют эту функцию прочь по умолчанию.
Так, должен я пытаться реализовать такой клиент, или я буду в большой проблеме из-за реализаций сервера (или прокси). Действительно ли там кто-либо - ссылка, которая дает инструкции по ним?
Если бы это - плохая идея, какова была бы альтернативная модель программирования для эффективности? Отдельные подключения TCP?
3 ответа
Я реализовал конвейерный HTTP-клиент. Основная концепция кажется простой, но обработка ошибок очень сложна. Прирост производительности настолько незначителен, что мы давно отказались от концепций.
На мой взгляд, это не имеет смысла для нормального использования. Это дает некоторые преимущества только тогда, когда запросы имеют логические связи. Например, у вас есть транзакция с 3 запросами, и вы можете отправить их все в пакете. Но обычно вы можете объединить их в один запрос, если они могут быть конвейерными.
Я могу вспомнить лишь некоторые препятствия:
Keepalive TCP не гарантирует постоянного соединения. Если у вас есть 3 запроса в соединении, сервер разрывает соединение после первого ответа. Вы должны повторить следующие два запроса.
Когда у вас несколько подключений, балансировка нагрузки также затруднена. Если нет незанятого соединения, вы можете либо использовать занятое соединение, либо создать новое.
Тайм-аут тоже сложен. Когда время ожидания одного запроса истекает, вы должны отбросить все после него, потому что они должны вернуться по порядку.
POST не должен быть конвейерным
8.1.2.2 Конвейерная обработка
Клиент, поддерживающий постоянный соединения МОГУТ "трубопровод" его запросы (т.е. отправить несколько запросов не дожидаясь каждого ответа). А сервер ДОЛЖЕН отправлять свои ответы на те запросы в том же порядке, что и запросы были получены.
Клиенты, предполагающие постоянное соединения и трубопровод сразу после установления соединения ДОЛЖЕН будьте готовы повторить попытку подключения если первая конвейерная попытка не удалась. Если клиент повторяет попытку, он ДОЛЖЕН НЕ конвейер, прежде чем он узнает соединение постоянное. Клиенты ДОЛЖНЫ также будьте готовы повторно отправить свои запрашивает, закрывает ли сервер соединение перед отправкой всех соответствующие отзывы.
Клиентам НЕ СЛЕДУЕТ передавать запросы по конвейеру с использованием неидемпотентных методов или неидемпотентные последовательности методов (см. раздел 9.1.2). В противном случае преждевременное прекращение перевозки соединение может привести к неопределенному Результаты. Клиент, желающий отправить неидемпотентный запрос ДОЛЖЕН подождать до отправьте этот запрос, пока он не будет получил статус ответа на предыдущий запрос.
конвейеризация почти не имеет значения для http-серверов; они обычно обрабатывают запросы в соединении последовательно - читают запрос, пишут ответ, затем читают следующий запрос...
но клиент, скорее всего, улучшит пропускную способность за счет мультиплексирования. на сайтах обычно используется несколько машин с несколькими процессорами, зачем вам добровольно ограничивать запросы одной строкой? сегодня речь идет скорее о горизонтальной масштабируемости (одновременные запросы). конечно, лучше всего использовать бенчмарки.