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

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

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

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

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

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

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


http java pipelining rfc2616
person Cratylus    schedule 21.07.2010    source источник
comment
Не совсем то, что вам нужно, но serf - это библиотека C, которая реализует конвейерную обработку HTTP code.google.com/p / serf Однако я не уверен на 100%, поддерживает ли он конвейерные публикации.   -  person Rup    schedule 21.07.2010
comment
Спасибо, я должен сделать это на java   -  person Cratylus    schedule 21.07.2010
comment
@ user384706 Никогда не пробовал serf, но если действительно делает то, что вы хотите, а все остальное терпит неудачу, вы всегда можете попробовать JNI / JNA.   -  person luiscubal    schedule 21.07.2010
comment
@ luiscubal Спасибо, но моя проблема в том, что если я даже использовал serf с помощью JNI / JNA, конвейерная обработка правильно поддерживается серверами или прокси, или у меня будут проблемы? Например, я понимаю, что apache HTTPClient намеренно не поддерживает конвейерную обработку. Не удалось найти авторитетных ссылок или конкретных примеров того, что эта функция действительно используется для повышения производительности.   -  person Cratylus    schedule 21.07.2010
comment
Для справки: HTTP-клиент на основе Java, который поддерживает конвейерную обработку - stackoverflow.com/questions/2777005/   -  person Kevin Hakanson    schedule 21.07.2010

Ответы (3)


arrow_upward
8
arrow_downward

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

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

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

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

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

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

person ZZ Coder    schedule 21.07.2010
comment
@ZZ Coder Спасибо! В вашем клиенте вы также направляли POST-сообщения? Мой случай не нормальный. Я хочу конвейеризовать POST в реальном времени, которые запускают действия в колл-центре. Любая информация, которую вы можете вспомнить, особенно о поведении серверов / прокси, приветствуется! - person Cratylus; 21.07.2010
comment
да. Он обрабатывает POST. Нет никакой разницы, за исключением того, что вам нужно запомнить тело, если вы реализуете логику повтора. - person ZZ Coder; 21.07.2010
comment
@ZZ Coder - Относительно 1: в случае HTTP вы все равно должны реализовать логику повтора, и логика повтора для конвейерных соединений не сильно отличается (единственное, что в случае повтора после того, как конвейер сломался, вы должны дождитесь первого ответа, чтобы узнать, конвейерное соединение это или нет). И на большинстве серверов в наши дни конвейерная обработка включена по умолчанию, поэтому, за исключением очень плохих сетевых подключений, конвейерные потери, я думаю, не должны происходить часто. - person Evgeniy Berezovsky; 15.09.2011
comment
@ZZ Coder - Относительно 3: Можете ли вы пояснить, что в нем сложного? Звучит не слишком сложно. Кстати, есть HTTP-клиенты, у которых по умолчанию включена конвейерная обработка (msdn.microsoft.com/en-us/library/) - я думаю, их использование должно быть довольно простым. Тайм-аут - ›Повторить попытку, как 1.) - person Evgeniy Berezovsky; 15.09.2011

arrow_upward
10
arrow_downward

POST не должен быть конвейерным

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

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

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

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

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

person Arjan    schedule 21.07.2010
comment
Спасибо за ответ. Но НЕ ДОЛЖЕН означает: в определенных обстоятельствах могут существовать веские причины, когда конкретное поведение приемлемо или даже полезно для RFC 2119. Это один из таких случаев. Если в определении НЕ ДОЛЖНО быть подразумевается, я не понимаю - person Cratylus; 21.07.2010
comment
@ user384706 Если ваш запрос на самом деле идемпотентный, возможно, вы действительно выполняете PUT? - person Thomas Ahle; 15.04.2011
comment
@ user384706, значит паршивый сервер мог икать при конвейерной публикации. Но правда, это не ваша вина, но когда что-то не работает, все не работает. Кто бы ни виноват, это не имеет значения. - person Pacerier; 18.07.2012

arrow_upward
-1
arrow_downward

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

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

person irreputable    schedule 21.07.2010
comment
При конвейерной обработке, по крайней мере, по определению, взаимодействие не является последовательным, поскольку запросы поступают пакетами. А что, если есть ограничение на количество открытых подключений к одному серверу? - person Cratylus; 22.07.2010
comment
Все зависит от использования соединения с высокой задержкой (коммутируемого доступа); тем более когда это длинная толстая труба (спутник). Это позволяет избежать накладных расходов, связанных с несколькими TCP-соединениями, но сохраняет большинство преимуществ. - person lxgr; 26.01.2012