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
