Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

[Валентин Бартенев]

On Tuesday 24 May 2016 08:34:57 S.A.N wrote:
> > Вы просто перенесете то, что реализовано в ядре операционной системы
> > внутрь приложения.  В случае HTTP/2 у вас будет на каждый отдельный
> > запрос свой внутренний идентификатор со своими накладными расходами,
> > который точно также будет "простаивать" пока запрос обрабатывается.
> > 
> > У вас уже есть мультиплексирование на уровне TCP/IP.
> > 
> > HTTP/2 - это коробочка в коробочке.
> 
> 
> Провел простые тесты, получил интересные результаты.
> 
> Браузер делает три аякс запроса
> 
> GET /one HTTP/1.1
> GET /two HTTP/1.1
> GET /three HTTP/1.1
> 
> Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном
> конекте.
> Nginx отправляет все эти три запроса в одном конекте на бекенд.
> 
> Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит
> очередь HTTP запросов, допустим время ответа у нас такое:
> 
> GET /one HTTP/1.1 -- 500ms
> GET /two HTTP/1.1 -- 20ms
> GET /three HTTP/1.1 -- 10ms
> 
> Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос,
> не дожидаясь обработки первого медленного запроса.
> 
> Есть три варианта как это сделать:
> 
> 1. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы
> буферизирует чтобы отправить в том же порядки как пришли запросы.
> 

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

Если бы следующий запрос пришел до того, как на первый был получен ответ,
то он бы был отправлен на бекенд в другом соединении.

Т.е. никакой проблемы между nginx и бекендом нет.


> 2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах
> Nginx
> 
> 3. Если сделать свой велосипед, использовать $request_id для связи ответов и
> запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке
> указывать $request_id запроса на который он отвечает, Nginx клиенту отправит
> ответы в той же последовательности как клиент прислал запросы.
> 
> 
> Я не люблю велосипеды ($request_id) но если Nginx не планирует
> мультиплескирования (НТТР/2 или FastCGI) в апстримах, возможно это неплохой
> компромис, как вы считаете?
> 
[..]

Вы пытаетесь решить несуществующую проблему, см. выше.

Проблема в общении браузера и сервера, которую решает мультиплексирование,
заключается исключительно в том, что браузер жестко ограничен в количестве TCP
соединений.

Между nginx и бекендом - такого ограничения нет, следовательно и проблемы тоже.

--
Валентин Бартенев