web-dev-qa-db-ja.com

Varnish 5.0はバックエンド接続でHTTP / 2をサポートしていますか?

次のインフラストラクチャがあります。

_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%確信してください。わかってくれてありがとう。

2
manifestor

@マイケル・ハンプトンの答えはいくつかのポイントを欠いているので、ここに行きます:

Varnish is Hitch + VarnishコンボでHTTP/2を実行する1つのソフトウェアですが、ほとんどのブラウザーはHTTP/2が機能するためにTLS接続を必要とします。つまり、今日の基本要件であるHTTP/2にはTLS接続が必要です。

Varnish PlusはTLSをサポートしていますが、Varnishオープンソースはサポートしていません。

答えは:

  • いいえ、バックエンド接続でHTTP/2を有効にすることはできません
  • notはパフォーマンスに関してそうするのに意味があります。 HTTP/2の主な利点は、リクエストの多重化です。 VarnishがHTML/2を介してHTMLを解析し、バックエンドからすべてのアセットを並行してリクエストできなかった場合を除き、必要ありません/不可能です。 Varnishをブラウザにしたいと思う人はいません。
  • いいえ、それはnot-p feature=+http2パラメータを443-> NGINX(HTTP/2が有効なSSL終了)に対して有効にしておくことは、パフォーマンスに関して意味があります。 NGINXは単純にHTTP/2をバックエンド(Varnish)と通信しないため、VarnishがHTTP/2をバックエンド(たとえば、NGINX + PHP-FPM)と通信しないのと同様です。以前のポイント)。

それは言った:

  • -p feature=+http2をHitch + Varnishのコンボに保つことは理にかなっています。
  • NGINX(ストリーム)+ Varnishコンボで-p feature=+http2を保持することも意味があります[〜#〜] if [〜#〜] NGINXのストリームモジュールはALPNプロトコルネゴシエーションをサポートしていました。しかし、そうではありません。したがって、HTTP/2が正しく機能するようにTLSを適切に終了することはできません。
4

Varnishはhttpsをまったくサポートしていません。それは決してありませんし、そうすることもありません。

Varnishが5.0で提供するいわゆるhttp2フロントエンドサポートは、実際にはVarnishにはまったくありません。代わりに、ヒッチと呼ばれる別のソフトウェアを使用します。これは、HTTP/2を使用してTLSを実際に終了し、プレーンHTTP接続をそのバックエンドであるVarnishフロントエンドに渡すプロキシサーバーです。

VarnishバックエンドはすべてHTTPのみです。

したがって、HTTP/2を使用すると、実際には次のようになります。

ヒッチ-ワニス-Nginx

この場合でも、ニスは問題を管理します。


一言で言えば、それはできません。

3
Michael Hampton