Node.jsサーバーがnginxプロキシの背後で実行されています。 node.jsは、ポート3000でHTTP 1.1(SSLなし)サーバーを実行しています。両方とも同じサーバーで実行されています。
最近、SSL(h2)でHTTP2を使用するようにnginxをセットアップしました。 HTTP2は実際に有効になっており、機能しているようです。
ただし、プロキシ接続(nginx <-> node.js)がHTTP 1.1を使用しているという事実がパフォーマンスに影響するかどうかを知りたいです。つまり、内部接続がHTTP 1.1であるため、速度の点でHTTP2の利点がありませんか?
一般に、HTTP/2の最大の直接的な利点は、 多重化 によって提供される速度の向上です。これは、高遅延(つまり、往復速度が遅い)によって妨げられることが多いブラウザ接続に対してです。これらは、複数の接続の必要性(および費用)も削減します。これは、HTTP/1.1で同様のパフォーマンスの利点を達成しようとする回避策です。
内部接続(たとえば、リバースプロキシとして機能するWebサーバーとバックエンドアプリサーバーの間)の場合、レイテンシは通常非常に低いため、HTTP/2の速度の利点は無視できます。また、通常、各アプリサーバーは既に個別の接続になっているため、ここでもメリットはありません。
そのため、エッジでHTTP/2をサポートするだけで、パフォーマンス上のメリットのほとんどが得られます。これは非常に一般的な設定です。HTTPSが完全に通過するのではなく、リバースプロキシ/ロードバランサーで終了することが多い方法に似ています。
ただし、HTTP/2をすべてサポートすることには潜在的な利点があります。たとえば、アプリケーションからサーバープッシュをすべて許可することができます。また、HTTP/2とヘッダー圧縮のバイナリの性質により、その最後のホップのパケットサイズが小さくなることによる潜在的な利点もあります。ただし、遅延と同様に、帯域幅は通常内部接続の問題ではないため、この重要性は議論の余地があります。最後に、あるプロキシを別のプロトコルに変換する必要がないため、リバースプロキシはHTTP/2接続をHTTP/2接続に接続するよりもHTTP/1.1接続に接続する方が作業が少ないと主張する人もいますが、それらは別個の接続であるため、目立っています(TCPパススループロキシ)として機能している場合を除く)。したがって、エンドツーエンドHTTP/2の主な理由は、エンドツーエンドサーバープッシュ、ただし それでも、複数の接続でプッシュを管理する際の複雑さのために、HTTPリンクヘッダーと103-アーリーヒントを使用する方が適切です 。
現時点では、サーバーはまだサポートを追加しており、サーバープッシュの使用率は低いですが(ベストプラクティスを定義するために実験中です)、エンドポイントでHTTP/2のみを使用することをお勧めします。また、Nginxは執筆時点でProxyPass接続用のHTTP/2をサポートしていません(Apacheはサポートしています)。また、 これを追加する予定はありません を持ち、 HTTP/2接続により、速度が低下する可能性があります(強調機能):
HTTP/2プロキシのサポートは近い将来に予定されていますか?
短い答え:
いいえ、計画はありません。
長い答え:
HTTP/2の主な利点は、1つの接続内で多くの要求を多重化できることです。したがって、[ほぼ]同時要求の数の制限がなくなります。独自のバックエンド。 さらに、HTTP/2をバックエンドに使用すると、単一のTCP複数の接続ではなく接続が使用されるため、状況はさらに悪化する可能性があります。
一方、アップストリームモジュールの単一の接続内でHTTP/2プロトコルとリクエストの多重化を実装するには、アップストリームモジュールを大幅に変更する必要があります。
上記により、少なくとも近い将来、アップストリームモジュールにHTTP/2サポートを実装する計画はありません。 HTTP/2を介してバックエンドと通信する必要があるとまだ考えている場合は、パッチを提供してください。
最後に、ブラウザはHTTP/2(h2)にHTTPSを必要としますが、ほとんどのサーバーはそうではないため、HTTP上のこの最終ホップ(h2c)をサポートできることに注意してください。したがって、Node部分にない場合が多いため)エンドツーエンド暗号化は必要ありません。ただし、バックエンドサーバーがこの接続にもHTTPSを使用するフロントエンドサーバーは、トラフィックがセキュリティで保護されていないネットワーク(インターネットを介したCDNからOriginサーバーへ)を通過する場合におそらく考慮すべきものです。
NGINXはHTTP2/Pushをサポートするようになりました...
ここでは、favicon.ico、minified.css、minified.js、register.svg、purchase_litecoin.svgを静的サブドメインからもプッシュしています。サブドメインからプッシュできることに気づくまでに時間がかかりました。
location / {
http2_Push_preload on;
add_header Link "<//static.yourdomain.io/css/minified.css>; as=style; rel=preload";
add_header Link "<//static.yourdomain.io/js/minified.js>; as=script; rel=preload";
add_header Link "<//static.yourdomain.io/favicon.ico>; as=image; rel=preload";
add_header Link "<//static.yourdomain.io/images/register.svg>; as=image; rel=preload";
add_header Link "<//static.yourdomain.io/images/purchase_litecoin.svg>; as=image; rel=preload";
proxy_hide_header X-Frame-Options;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_Host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://app_service;
}
NGINXは、クライアントとしてHTTP/2をサポートしていません。それらは同じサーバー上で実行されており、遅延や帯域幅の制限がないため、いずれにしても大きな違いが生じるとは思いません。 nginxとnode.jsの間でキープアライブを使用していることを確認します。
Nginxは、ノードバックエンドへの複数の同時リクエストを作成することにより、ブラウザがHTTP/2で多重化するリクエストと一致するため、一般にパフォーマンスを失うことはありません。 (HTTP/2の主要なパフォーマンス改善の1つは、ブラウザーが同じ接続で複数の同時要求を行えるようにすることです。一方、HTTP 1.1では、接続ごとに1つの同時要求のみが可能です。ブラウザーも接続数を制限します。)
サービスをHTTP2互換にするのが都合の悪いときに誰かがこれに関する解決策を探している場合に備えて。 HTTP1サービスをHTTP2サービスに変換するために使用できる基本的なNGINX構成を次に示します。
server {
listen [::]:443 ssl http2;
listen 443 ssl http2;
server_name localhost;
ssl on;
ssl_certificate /Users/xxx/ssl/myssl.crt;
ssl_certificate_key /Users/xxx/ssl/myssl.key;
location / {
proxy_pass http://localhost:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $Host;
}
}