Использовать HTTP / 2.0 между обратным прокси-сервером nginx и внутренним веб-сервером
Я использую nginx в качестве обратного ssl-прокси перед внутренним веб-сервером, который может выполнять HTTP / 2.0.
Я заметил, что nginx передает запросы на внутренний сервер через HTTP / 1.1, а не через HTTP / 2.0. Можно ли указать nginx вместо этого использовать незашифрованное соединение HTTP / 2.0? Повысит ли это производительность?
Нашел следующее: https://trac.nginx.org/nginx/ticket/923
Нет планов по реализации поддержки HTTP / 2 в модуле прокси в обозримое будущее
Выдержка из письма, на которое есть ссылка в тикете:
Практически нет смысла реализовывать его, так как основной HTTP / 2 преимущество в том, что он позволяет мультиплексировать множество запросов в пределах одного одно соединение, таким образом [почти] сняв ограничение на количество одновременные запросы - и нет такого ограничения при разговоре с ваши собственные серверы. Более того, ситуация может даже ухудшиться, когда использование HTTP / 2 для бэкэндов из-за использования одного TCP-соединения вместо нескольких.
К сожалению, nginx не поддерживает прокси-сервер для внутреннего сервера http / 2, ссылка на который имеется в https://www.nginx.com/blog/http2-module-nginx/#QandA
Q: Будете ли вы поддерживать HTTP / 2 на восходящей стороне или только HTTP / 2 на стороне клиента?
A: На данный момент мы поддерживаем HTTP / 2 только на стороне клиента. Вы не можете настроить HTTP / 2 с помощью proxy_pass. [Редактор - В исходной версии этого сообщения это предложение было неправильно расшифровано как «Вы можете настроить HTTP / 2 с помощью proxy_pass». Приносим извинения за любую путаницу, которую это могло вызвать.]
Но в чем смысл HTTP / 2 на стороне сервера? Потому что, как вы можете видеть из тестов, HTTP / 2 не дает больших преимуществ для сетей с низкой задержкой, таких как восходящие соединения.
Кроме того, в NGINX у вас есть модуль keepalive, и вы можете настроить кеш keepalive. Основное преимущество HTTP / 2 в производительности заключается в устранении дополнительных подтверждений связи, но если вы делаете это уже с кешем поддержки активности, вам не нужен HTTP / 2 на восходящей стороне.
Начиная с версии 1.13.9 http2 поддерживается для серверных push-уведомлений.
Один из способов — определить список активов, которые вы хотели бы вернуть по запросу в определенное место, используя оператор http2_push.
Второй способ — позволить nginx перехватить ответ и отправить теги ссылок с атрибутом preload с помощью инструкции http2_push_preload.
Подробнее в сообщении в блоге, на которое @malix ссылается в комментариях к ОП
.