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 и бекендом - такого ограничения нет, следовательно и проблемы тоже.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru