次のインフラストラクチャがあります。
_80 -> Varnish -> Backend (NGINX, port 8080)
443 -> NGINX (SSL-Termination with HTTP/2 enabled) -> Varnish -> Backend (NGINX, port 8080)
_
Varnish(ポート80)の_HTTP/2
_パラメータを使用して、フロントエンド接続で_-p feature=+http2
_プロトコルを有効にできることは知っていますが、バックエンド接続はどうですか? _varnishlog -b
_は、すべてのバックエンド通信が_HTTP/1.0
_および_HTTP/1.1
_を使用して実行されることを示しています。
誰かがワニスとNGINXに関する一般的な慣行を教えてもらえれば幸いです。
HTTP/2
_を有効にすることは可能ですか?443 -> NGINX (SSL-Termination with HTTP/2 enabled) -> Varnish
通信に対して_-p feature=+http2
_パラメータを有効にしておくことはパフォーマンスに関して意味がありますか?バックエンド通信について(暗号化されていません):_HTTP/2
_がTLS暗号化にバインドされていることは知っていますが、聞いたことがないTweakがあるかもしれません。そのため、 100%確信してください。わかってくれてありがとう。
@マイケル・ハンプトンの答えはいくつかのポイントを欠いているので、ここに行きます:
Varnish is Hitch + VarnishコンボでHTTP/2を実行する1つのソフトウェアですが、ほとんどのブラウザーはHTTP/2が機能するためにTLS接続を必要とします。つまり、今日の基本要件であるHTTP/2にはTLS接続が必要です。
Varnish PlusはTLSをサポートしていますが、Varnishオープンソースはサポートしていません。
答えは:
-p feature=+http2
パラメータを443-> NGINX(HTTP/2が有効なSSL終了)に対して有効にしておくことは、パフォーマンスに関して意味があります。 NGINXは単純にHTTP/2をバックエンド(Varnish)と通信しないため、VarnishがHTTP/2をバックエンド(たとえば、NGINX + PHP-FPM)と通信しないのと同様です。以前のポイント)。それは言った:
-p feature=+http2
をHitch + Varnishのコンボに保つことは理にかなっています。-p feature=+http2
を保持することも意味があります[〜#〜] if [〜#〜] NGINXのストリームモジュールはALPNプロトコルネゴシエーションをサポートしていました。しかし、そうではありません。したがって、HTTP/2が正しく機能するようにTLSを適切に終了することはできません。Varnishはhttpsをまったくサポートしていません。それは決してありませんし、そうすることもありません。
Varnishが5.0で提供するいわゆるhttp2フロントエンドサポートは、実際にはVarnishにはまったくありません。代わりに、ヒッチと呼ばれる別のソフトウェアを使用します。これは、HTTP/2を使用してTLSを実際に終了し、プレーンHTTP接続をそのバックエンドであるVarnishフロントエンドに渡すプロキシサーバーです。
VarnishバックエンドはすべてHTTPのみです。
したがって、HTTP/2を使用すると、実際には次のようになります。
ヒッチ-ワニス-Nginx
この場合でも、ニスは問題を管理します。
一言で言えば、それはできません。