nginxリバースプロキシとバックエンドウェブサーバー間でHTTP / 2.0を使用する

HTTP / 2.0を実行できるバックエンドWebサーバーの前で、nginxをreverse-ssl-proxyとして使用します。

nginxがHTTP / 2.0ではなくHTTP / 1.1を介してバックエンドサーバーにリクエストをプロキシすることに気付きました。代わりに、暗号化されていないHTTP / 2.0接続を使用するようにnginxに指示することはできますか？これによりパフォーマンスが向上しますか？

nginx reverse-proxy http2

— S1lentSt0rm
ソース

http2の仕様では暗号化は必要ないとされていますが、nginxは現在、SSLなしのhttp2をサポートしていません。

— マルコ

https：//アドレスを指定した場合、HTTP / 2.0を使用しますか？それでは、HTTP / 1.1を使用したほうが良いと思います。トラフィックを2回暗号化するのは理にかなっておらず、SSLを使用したHTTP / 2.0のパフォーマンスは、おそらくSSLを使用しないHTTP / 1.1ほど良くないでしょうか？つまり、そのようなことでreverse-ssl-proxyが役に立たなくなります;）

— S1lentSt0rm

フロントマシンとバックエンドサーバーが同じマシン上にある場合、それらの間のトラフィックを暗号化しても、実際には問題ではありません。パフォーマンスに関しては、http2は暗号化されていても、http1.1よりもかなり高速です。それが違いを生むかどうかを試すことなく言うことはできません。

— マルコ

nginx.com/blog/nginx-1-13-9-http2-server-push

— malix

回答:

これを見つけました：https : //trac.nginx.org/nginx/ticket/923

近い将来、プロキシモジュールにHTTP / 2サポートを実装する計画はありません。

チケットで参照されるメールからの抜粋：

HTTP / 2の主な利点は、単一の接続内で多くの要求を多重化できることです。したがって、[ほぼ]同時要求の数の制限がなくなります。独自のバックエンド。さらに、HTTP / 2をバックエンドに使用すると、複数の接続ではなく単一のTCP接続が使用されるため、状況がさらに悪化する場合があります。

— S1lentSt0rm
ソース

これは、バックエンドサーバーが直接アクセスされた場合にバックエンドサーバーがサポートしていても、nginxでプロキシしている場合、HTTP / 2サーバープッシュを使用できないことを意味するようです。

— -thomasrutter

HTTP / 2が私を助けてくれるので、遅い接続を介してローカルでないサイトにnginxリバースプロキシを使用します。nginx開発者がユースケースを考慮していないのは残念です:

— 。– markshep

悲しいことにnginxはhttps://www.nginx.com/blog/http2-module-nginx/#QandAから参照されるhttp / 2バックエンドサーバーへのプロキシをサポートしていません

Q：アップストリーム側でもHTTP / 2をサポートしますか、それともクライアント側でHTTP / 2のみをサポートしますか？

A：現時点では、クライアント側でのみHTTP / 2をサポートしています。proxy_passでHTTP / 2を構成することはできません。[編集者–この投稿の元のバージョンでは、この文は「proxy_passでHTTP / 2を設定できます」と誤って転記されていました。これにより生じた混乱についておWeび申し上げます。

しかし、バックエンド側のHTTP / 2のポイントは何ですか？ベンチマークからわかるように、アップストリーム接続などの低遅延ネットワークのHTTP / 2にはあまりメリットがないためです。

また、NGINXにはキープアライブモジュールがあり、キープアライブキャッシュを構成できます。HTTP / 2の主なパフォーマンス上の利点は、追加のハンドシェイクを排除することですが、すでにキープアライブキャッシュを使用してこれを行う場合、アップストリーム側でHTTP / 2は必要ありません。

— タンシンファ
ソース