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