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

[S.A.N]

> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения.  В случае 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. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы
буферизирует чтобы отправить в том же порядки как пришли запросы.

2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах
Nginx

3. Если сделать свой велосипед, использовать $request_id для связи ответов и
запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке
указывать $request_id запроса на который он отвечает, Nginx клиенту отправит
ответы в той же последовательности как клиент прислал запросы.


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

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267088#msg-267088