Какие-нибудь HTTP прокси с явной, настраиваемой поддержкой буферизации запросов / ответов и отложенных соединений?

Question

При работе с мобильными клиентами очень часто возникают задержки во время передачи HTTP-запросов на несколько секунд. Если вы обслуживаете страницы или службы из предварительно настроенного Apache, дочерние процессы будут на несколько секунд привязаны к одному мобильному клиенту, даже если логика сервера приложений выполняется за 5 мс. Я ищу HTTP-сервер, балансировщик или прокси-сервер, который поддерживает следующее:

1. Приходит запрос к прокси. Прокси-сервер начинает буферизовать в RAM или на диске запрос, включая заголовки и тела POST / PUT. Прокси НЕ открывает соединение с внутренним сервером. Это, наверное, самая важная часть.

2. Прокси-сервер прекращает буферизацию запроса, когда:

   • Достигнут предел размера (скажем, 4 КБ) или
   • Запрос был получен полностью, заголовки и тело

3. Только теперь, с (частью) запросом в памяти, соединение с бэкэндом открывается, и запрос ретранслируется.

4. Бэкэнд отправляет ответ обратно. Снова прокси-сервер начинает немедленно буферизировать его (до более большого размера, скажем, 64 КБ.)

5. Поскольку прокси имеет достаточно большой буфер, ответ сервера полностью сохраняется на прокси-сервере в течение нескольких миллисекунд, и процесс / поток сервера может свободно обрабатывать больше запросов. Внутреннее соединение немедленно закрывается.

6. Прокси-сервер отправляет ответ мобильному клиенту, настолько быстрый или медленный, насколько это возможно, без подключения к серверу, связывающему ресурсы.

Я вполне уверен, что вы можете делать 4-6 со Squid, и nginx поддерживает 1-3 (и выглядит довольно уникальным в этом отношении). Мой вопрос: есть ли прокси-сервер, который сопрягает эти возможности буферизации и не-открытия-соединения-до-готовности? Может быть, есть немного Apache config-fu, который делает это поведение буферизации тривиальным? Кто-нибудь из них, что это не динозавр, как Squid, и который поддерживает стройную модель однопроцессного асинхронного выполнения на основе событий?

(Siderant: я бы использовал nginx, но он не поддерживает фрагментированные тела POST, что делает его бесполезным для доставки содержимого мобильным клиентам. Да, дешевые телефоны стоимостью 50 $ любят фрагментированные POST ... вздох)

Answer 1

А как насчет использования nginx и Squid (клиент - Squid - nginx - backend)? Когда возвращает данные из бэкэнда, Squid преобразует их из C-T-E: порция в обычный поток с установленным Content-Length, поэтому, возможно, он также может нормализовать POST.

Answer 2

Nginx может делать все, что вы хотите. Параметры конфигурации, которые вы ищете:

http://wiki.codemongers.com/NginxHttpCoreModule#client_body_buffer_size

и

http://wiki.codemongers.com/NginxHttpProxyModule#proxy_buffer_size

Answer 3

Fiddler , бесплатный инструмент от Telerik, выполняет, по крайней мере, некоторые вещи, которые вы ищете.

В частности, перейдите к Rules | Custom Rules..., и вы можете добавить произвольный код Javascript во всех точках во время соединения. Вы можете смоделировать некоторые вещи, которые вам нужны, с помощью sleep() вызовов.

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

Answer 4

Squid 2.7 может поддерживать 1-3 с патчем:

• http://www.squid -cache.org / Версии / v2 / HEAD / Изменения / 12402.patch

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

Разделенные на блоки POST являются проблемой для большинства серверов и посредников. Вы уверены, что вам нужна поддержка? Обычно клиенты должны повторить запрос, когда они получают 411.

Answer 5

К сожалению, я не знаю готового решения для этого. В худшем случае подумайте о том, чтобы разработать его самостоятельно, скажем, с использованием Java NIO - это не должно занять больше недели.