> Вы просто перенесете то, что реализовано в ядре операционной системы > внутрь приложения. В случае 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 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
