HTTP(S) 負荷分散のコンセプト

このドキュメントでは、HTTP または HTTPS の負荷分散を構成する際に理解しておく必要があるコンセプトについて説明します。

基礎知識

HTTP(S) ロードバランサは複数のコンポーネントで構成されています。次の図は、HTTP(S) ロードバランサ全体の構造を示しています。

コンテンツ ベースおよびクロスリージョンの負荷分散の図(クリックして拡大)
コンテンツ ベースおよびクロスリージョンの負荷分散の図(クリックして拡大)

以降のセクションでは、各種のロードバランサを構成するコンポーネントがそれぞれどのように連携しているかについて説明します。各コンポーネントの詳細については、以下のコンポーネントをご覧ください。

HTTP 負荷分散

HTTP ロードバランサ全体は次のように構成されます。

  1. 転送ルールによって受信リクエストがターゲット HTTP プロキシに振り向けられます。
  2. ターゲット HTTP プロキシによって、各リクエストが URL マップと照合され、各リクエストに適したバックエンド サービスが決定されます。
  3. バックエンド サービスによって、サービスに関連するバックエンドの処理能力、ゾーン、インスタンスの健全性に基づいて選ばれたバックエンドに、各リクエストが割り当てられます。各バックエンド インスタンスの健全性は、HTTP ヘルスチェック、HTTPS ヘルスチェック、または HTTP/2 ヘルスチェックによって検証されます。バックエンド サービスが HTTPS または HTTP/2 のヘルスチェックを使用するように構成されている場合、バックエンド インスタンスに送られる際にリクエストは暗号化されています。
  4. ロードバランサとインスタンス間のセッションでは、HTTP、HTTPS、あるいは HTTP/2 プロトコルが使用できます。HTTPS または HTTP/2 を使用する場合、バックエンド サービスの各インスタンスには SSL 証明書が必要です。

HTTPS 負荷分散

HTTPS ロードバランサの構造は、上述の HTTP ロードバランサと基本的には同じですが、次の点が異なります。

ロードバランサとのクライアント通信

  • クライアントは、HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
  • 最近のクライアントは、HTTPS を使用するとデフォルトで HTTP/2 になります。この制御は HTTPS ロードバランサではなくクライアント上で行われます。
  • ロードバランサ自体で構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、curl では --http1.1 パラメータを使用します。
  • HTTPS ロードバランサは、クライアント証明書ベースの認証(別名: 相互 TLS 認証)をサポートしていません。

オープンポート

HTTP(S) ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。リバース プロキシ機能は、Google Front Ends(GFE)が提供します。

ファイアウォール ルールの設定では、GFE からバックエンドへのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。

HTTP(S) ロードバランサには、同じアーキテクチャで実行される他の Google サービスをサポートしているオープンポートが多数あります。GCP の HTTP(S) ロードバランサの外部 IP アドレスに対してセキュリティ スキャンまたはポートスキャンを実行すると、他のポートも開いているように見えます。

このことは、HTTP(S) ロードバランサには影響しません。HTTP(S) ロードバランサの定義で使用される外部の転送ルールは、TCP ポート 80、8080、および 443 しか参照できず、トラフィックの TCP 宛先ポートが異なれば、ロードバランサのバックエンドに転送されることはないからです。

コンポーネント

HTTP(S) ロードバランサのコンポーネントは次のとおりです。

転送ルールとアドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシ、URL マップ、1 つ以上のバックエンド サービスからなる負荷分散構成にトラフィックをルーティングします。

各転送ルールでは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを指定します。DNS ベースの負荷分散は必要ありません。使用する IP アドレスを自分で指定することも、Google Cloud Load Balancing で割り当てられる IP アドレスを使用することもできます。

  • HTTP ロードバランサの転送ルールは、TCP ポート 80 と 8080 のみを参照できます。
  • HTTPS ロードバランサの転送ルールは、TCP ポート 443 のみを参照できます。

ターゲット プロキシ

ターゲット プロキシは、クライアントからの HTTP(S) 接続を終端します。1 つ以上のグローバル転送ルールによってトラフィックがターゲット プロキシに振り向けられ、ターゲット プロキシは URL マップを参照してトラフィックをバックエンドにルーティングする方法を決定します。

プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。

  • Via: 1.1 google(リクエストとレスポンス)
  • X-Forwarded-Proto: [http | https](リクエストのみ)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP>(リクエストのみ)。リクエストが経由する中間経路で追加される IP アドレスのカンマ区切りのリスト。GCP 内で実行しているプロキシによって X-forwarded-For ヘッダーにデータが追加される場合は、使用するソフトウェアでそれらのプロキシの存在や数の管理が必要になります。ロードバランサでは、<immediate client IP> と <global forwarding rule external IP> のエントリのみが検証されます。リスト内のその他のエントリは検証なしで渡されます。エントリ <immediate client IP> は、ロードバランサに直接接続するクライアントです。エントリ <global forwarding rule external IP> は、ロードバランサの転送ルールの外部 IP アドレスです。これ以外にもエントリが存在する場合、リスト内の最初のエントリは元のクライアントのアドレスです。<immediate client IP> より前のエントリは、リクエストをロードバランサに転送したその他のプロキシを表します。
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(リクエストのみ)
    Stackdriver Trace のパラメータ。

デフォルトのヘッダーでニーズが満たされない場合は、カスタム リクエスト ヘッダーを作成できます。この機能について詳しくは、ユーザー定義のリクエスト ヘッダーの作成をご覧ください。

プロキシでは、リクエストまたはレスポンスのヘッダー名の大文字と小文字の区別の保持が保証されません。たとえば、Server: Apache/1.0 レスポンス ヘッダーは、クライアントで server: Apache/1.0 と表示される場合があります。

URL マップ

URL マップは、URL に基づいてリクエストが適切なバックエンド サービスにルーティングされる際に使用される一致パターンを定義します。デフォルトのバックエンド サービスは、指定されたホストまたはパスのマッチング ルールに一致しないリクエストを処理するように定義されています。クロスリージョン負荷分散の例など、URL ルールを定義せず、デフォルトのサービスのみに依存する状況もあります。コンテンツ ベースのトラフィック ルーティングでは、URL マップを使用して URL を調べることで、トラフィックを分割し、リクエストを各種のバックエンド セットに送信できます。

SSL 証明書

HTTPS 負荷分散を使用する場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。最大 15 件の SSL 証明書をインストールできます。HTTPS プロキシはこれらの証明書を使用して、ロードバランサとクライアントとの間の通信を認証します。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用できます。

HTTPS のロードバランサ用の SSL 証明書のインストールについて詳しくは、SSL 証明書をご覧ください。

ロードバランサからバックエンドの間で HTTPS または HTTP/2 を使用している場合は、各 VM インスタンスに SSL 証明書をインストールする必要があります。VM インスタンスに SSL 証明書をインストールするには、ご使用のアプリケーションのドキュメントに記載された指示に従ってください。これらの証明書は、自己署名にすることができます。

SSL ポリシー

SSL ポリシーを使用すると、HTTPS ロードバランサが HTTPS クライアントとネゴシエートする際に使用する SSL の機能を制御できます。

デフォルトでは、HTTPS 負荷分散は、優れたセキュリティと幅広い互換性を提供する一連の SSL 機能を使用します。アプリケーションの中には、HTTPS または SSL 接続に使用される SSL のバージョンおよび暗号をより詳細に管理しなければならないものがあります。ロードバランサがネゴシエートに使用する SSL 機能を制御する SSL ポリシーを定義し、ターゲット HTTPS プロキシに SSL ポリシーを関連付けることができます。

TLS の終端ロケーションに対する地理的制御

HTTPS ロードバランサは、クライアントとロードバランサ間のレイテンシを最小にするため、グローバルに分散されているロケーションで TLS を終端します。どこで TLS を終端するかを地理的に制御する必要がある場合は、GCP ネットワーク負荷分散を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。

バックエンド サービス

バックエンド サービスは、ロードバランサに構成情報を提供します。HTTP(S) ロードバランサには 1 つ以上のバックエンド サービスが必要です。複数のバックエンド サービスを設定することもできます。

ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。

各バックエンドは、1 つのインスタンス グループと、処理能力に関する追加のメタデータから構成されます。バックエンドの処理能力は、CPU または 1 秒あたりのリクエスト数(RPS)に基づいて設定できます。

HTTP(S) 負荷分散は Cloud Load Balancing のオートスケーラー をサポートします。これにより、バックエンド サービス内のインスタンス グループに対して自動スケーリングを実行できるようになります。詳しくは、HTTP 負荷分散の処理能力に基づくスケーリングをご覧ください。

バックエンド サービスで接続ドレインを有効にすると、トラフィックを処理しているインスタンスが停止されたり、手動で削除されたり、オートスケーラーによって削除されたりした場合に、ユーザーに対する中断を最小限に抑えることができます。接続ドレインについて詳しくは、接続ドレインの有効化のドキュメントをご覧ください。

ヘルスチェック

各バックエンド サービスでは、使用可能な各インスタンスに対してどのヘルスチェックが実行されるかも指定します。ヘルスチェック プローブが正常に機能するには、130.211.0.0/22 および 35.191.0.0/16 からのトラフィックがインスタンスに到達できるようにファイアウォール ルールを作成する必要があります。

ヘルスチェックについて詳しくは、ヘルスチェックのコンセプトヘルスチェックの作成をご覧ください。

バックエンドへのプロトコル

HTTP(S) ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。HTTP、HTTPS、HTTP/2 を選択できます。指定したプロトコルのみがロードバランサで使用されます。指定されたプロトコルでバックエンドへの接続をネゴシエートできない場合、ロードバランサは他のプロトコルへのフォールバックを行いません。

バックエンド VM に対して HTTP/2 を使用する場合は、HTTP/2 ヘルスチェックを使用します。

Google Cloud Platform アプリケーションでの gRPC の使用

gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。

  • 低レイテンシでスケーラビリティの高い分散システム
  • クラウド サーバーと通信するモバイル クライアントの開発
  • 正確かつ効率的で言語に依存しない新しいプロトコルの設計
  • 拡張、認証、ロギングを可能にする階層型の設計

Google Cloud Platform アプリケーションで gRPC を使用するには、HTTP/2 でエンドツーエンドにリクエストをプロキシする必要があります。これを HTTP(S) ロードバランサで行うには、次の手順に従います。

  1. HTTPS ロードバランサを構成します。
  2. ロードバランサからバックエンドへのプロトコルとして HTTP/2 を有効にします。

ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

ロードバランサは、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するように構成された HTTP(S) ロードバランサで、一部のクライアントと HTTPS をネゴシエートしたり安全でない HTTP リクエストを受け入れたりすることもあります。これらの HTTP または HTTPS のリクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

Google Kubernetes Engine Ingress で HTTP/2 を使用して HTTP(S) ロードバランサを構成する場合は、Ingress での HTTP/2 を使用した負荷分散をご覧ください。

Ingress で gRPC と HTTP/2 を使用することもできます。詳しくは、Ingress での HTTP/2 を使用した負荷分散をご覧ください。

HTTP/2 の問題のトラブルシューティングについては、バックエンドへの HTTP/2 の問題のトラブルシューティングをご覧ください。HTTP/2 の制限については、HTTP/2 に関する制限をご覧ください。

バックエンド バケット

バックエンド バケットは、受信トラフィックを Google Cloud Storage バケットに振り向けます。既存のロードバランサにバケットを追加する方法の例は、ロードバランサへの Cloud Storage バケットの追加をご覧ください。

ファイアウォール ルール

130.211.0.0/2235.191.0.0/16 からのトラフィックがインスタンスに到達することを許可するファイアウォール ルールを作成する必要があります。これらは、ロードバランサがバックエンド インスタンスへの接続に使用する IP アドレス範囲です。このルールは、ロードバランサとヘルス チェッカーの両方からのトラフィックを許可します。このルールでは、グローバル転送ルールで使用するよう構成されているポート上のトラフィックを許可する必要があります。また、ヘルス チェッカーでも同じポートを使用するように構成することを推奨します。ヘルス チェッカーが異なるポートを使用している場合には、このポート用に別のファイアウォール ルールを作成する必要があります。

ファイアウォール ルールは、ネットワークのエッジではなく、インスタンス レベルでトラフィックのブロックまたは許可を行います。ロードバランサ自体へのトラフィックはブロックできません。

ある特定の時点での外部 IP アドレスを判別する必要がある場合は、Google Compute Engine のよくある質問の手順に従ってください。

リターンパス

GCP では、VPC ネットワークで定義されていない特殊なルートをヘルスチェックに使用します。この詳細については、ロードバランサのリターンパスをご覧ください。

負荷分散アルゴリズム

HTTP(S) 負荷分散には、インスタンスの負荷を調べる方法が 2 つ用意されています。バックエンド サービス リソース内の balancingMode プロパティによって、1 秒あたりのリクエスト数(RPS)と CPU 使用率のいずれかのモードが選択されます。いずれのモードでも最大値を指定できます。HTTP(S) ロードバランサは負荷が制限内にとどまるように調整しますが、フェイルオーバー イベントまたは負荷スパイク イベントの際には上限を超える短時間のバーストが発生する場合があります。

受信リクエストは、処理能力に余力がある場合はユーザーの最寄りのリージョンに送信されます。リージョン内の特定のバックエンドで複数のゾーンを構成する場合、アルゴリズムのデフォルトの動作では、各グループの処理能力に従って各ゾーンのインスタンス グループにトラフィックが分散されます。ゾーン内ではラウンドロビン アルゴリズムを使用して、リクエストがインスタンス間で均等に分散されます。ラウンドロビン配信は、セッション アフィニティを構成することでオーバーライドできます。ただし、セッション アフィニティは、これに加えて分散モードが [リクエスト数 / 秒](RPS)に設定されている場合に最も機能を発揮します。

負荷分散アルゴリズムの具体例については、HTTP(S) 負荷分散の仕組みをご覧ください。

セッション アフィニティ

セッション アフィニティでは、インスタンスが正常であり処理能力が足りている場合、同じクライアントからのすべてのリクエストが同じ仮想マシン インスタンスに送信されます。

GCP HTTP(S) 負荷分散には次の 2 種類のセッション アフィニティが用意されています。

WebSocket プロキシ サポート

HTTP(S) 負荷分散には WebSocket プロトコルのネイティブ サポートがあります。WebSocket を使用してクライアントと通信するバックエンドは、HTTP(S) ロードバランサをフロントエンドとして使用し、スケーリングと可用性を向上させることができます。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは RFC 6455 で定義され、クライアントとサーバー間で全二重の通信チャネルを提供します。このチャネルは HTTP(S) リクエストから開始します。

HTTP(S) 負荷分散で HTTP(S) クライアントからの WebSocket Upgrade リクエストが認識され、そのリクエストに続いてバックエンド インスタンスから Upgrade の正常終了のレスポンスが送られた場合、ロードバランサによって現在の接続の存続期間にわたり、双方向トラフィックがプロキシされます。バックエンドから Upgrade の正常終了のレスポンスが返されない場合、ロードバランサによって接続が閉じられます。

WebSocket 接続のタイムアウトは、ロードバランサの構成可能なレスポンス タイムアウトによって異なります。デフォルトは 30 秒です。このタイムアウトは、その接続が使用されているかどうかにかかわらず、すべての WebSocket 接続に適用されます。レスポンス タイムアウトとその構成方法について詳しくは、タイムアウトと再試行をご覧ください。

HTTP(S) ロードバランサに対してクライアント IP アフィニティまたは生成された Cookie セッション アフィニティのいずれかを構成している場合は、インスタンスが連続的にヘルスチェックに合格し、その処理能力に余裕ある限り、特定クライアントからのすべての WebSocket 接続が同じバックエンド インスタンスに送信されます。

WebSocket プロトコルは Ingress によってサポートされています。

HTTPS 負荷分散の QUIC プロトコルのサポート

HTTPS 負荷分散では、ロードバランサとクライアントの間の接続で QUIC プロトコルがサポートされます。QUIC は、TCP と同様の輻輳制御および SSL/TLS と同等のセキュリティを HTTP/2 に提供するトランスポート レイヤ プロトコルであり、パフォーマンスが向上しています。QUIC では、クライアント接続の開始が迅速になり、多重化されたストリームにおけるヘッドオブライン ブロッキングがなくなり、クライアントの IP アドレスが変更されたときの接続の移行がサポートされます。

QUIC は、クライアントとロードバランサ間の接続に影響し、ロードバランサとバックエンド間の接続には影響しません。

ターゲット プロキシの QUIC オーバーライド設定では、次のいずれかを有効にすることができます。

  • 可能であれば、ロードバランサに対して QUIC をネゴシエートする。または
  • ロードバランサに対して常に QUIC を無効にする。

QUIC オーバーライドを指定しない場合、QUIC がいつ使用されるかを Google が管理できます。オーバーライドが指定されていないと、Google は QUIC を有効にしません。QUIC サポートの有効化と無効化については、ターゲット プロキシをご覧ください。また、Google Cloud Platform Console を使用した HTTPS ロードバランサの作成時に QUIC を有効化することも、Google Cloud Platform Console を使用してロードバランサの構成を編集するときに無効化することもできます。

QUIC のネゴシエートの仕組み

QUIC を有効にすると、ロードバランサはその QUIC 機能をクライアントにアドバタイズでき、QUIC をサポートするクライアントは HTTPS ロードバランサとの QUIC 接続の確立を試行できるようになります。適切に実装されたクライアントは、QUIC 接続を確立できない場合は常に HTTPS または HTTP/2 にフォールバックします。このフォールバックにより、ロードバランサで QUIC を有効または無効にしても、ロードバランサのクライアントへの接続機能は中断されません。

HTTPS ロードバランサで QUIC が有効になっているときに、クライアントが QUIC をネゴシエートせずに HTTPS または HTTP/2 にフォールバックすることがあります。次のような場合です。

  • HTTPS ロードバランサによってサポートされている QUIC バージョンと互換性のないバージョンの QUIC をクライアントがサポートしている場合
  • QUIC が機能できない方法で、UDP トラフィックがブロックされているかレート制限されていると、ロードバランサで検出された場合
  • バグ、脆弱性、その他の問題に対応して HTTPS ロードバランサで QUIC が一時的に無効になっている場合

このような状況のために接続が HTTPS または HTTP/2 にフォールバックした場合は、ロードバランサの障害としてカウントされません。

QUIC を有効にする前に、上記の動作がワークロードに対して許容できることを確認してください。

インターフェース

HTTP(S) 負荷分散サービスは、次のインターフェースを通じて構成および更新できます。

  • gcloud コマンドライン ツール: Cloud SDK に含まれているコマンドライン ツール。HTTP(S) 負荷分散のドキュメントでは、タスクの実行時にこのツールをよく利用します。このツールの完全な概要については、gcloud ツールガイドをご覧ください。負荷分散に関連するコマンドは、gcloud compute コマンド グループに含まれます。

    すべての gcloud コマンドでは、--help フラグを使用して詳細なヘルプを表示できます。

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console: 負荷分散タスクは、Google Cloud Platform Console から実行できます。

  • REST API: 負荷分散タスクはすべて、Google Cloud Load Balancing API を使用して実行できます。API リファレンス ドキュメントでは、使用できるリソースとメソッドについて説明しています。

TLS サポート

デフォルトでは、HTTPS ターゲット プロキシは、クライアントの SSL リクエストを終端するときに TLS 1.0、1.1、1.2 のみを受け入れます。SSL ポリシーを使用してこのデフォルトの動作を変更し、ロードバランサがクライアントと SSL をネゴシエートする方法を制御できます。

ロードバランサが HTTPS をバックエンド サービス プロトコルとして使用する場合は、TLS 1.0、1.1、または 1.2 をバックエンドにネゴシエートできます。

タイムアウトと再試行

HTTP(S) 負荷分散には次の 2 種類のタイムアウトがあります。

  • 構成可能な HTTP レスポンス タイムアウトは、ロードバランサがバックエンドから完全な HTTP レスポンスが返されるのを待ち受ける時間です。HTTP のアイドル(キープアライブ)タイムアウトではありません。デフォルト値は 30 秒です。次の状況では、このタイムアウトを長くすることを検討してください。

    • バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合、または
    • 接続が WebSocket にアップグレードされた場合。

    GCP HTTP(S) ロードバランサを介して送信される WebSocket トラフィックのバックエンド サービス タイムアウトは、WebSocket 接続がアイドルであるかどうかにかかわらず、オープンとして保持できる時間の上限と解釈されます。詳しくは、バックエンド サービスの設定をご覧ください。

  • TCP セッション タイムアウト。この値は 10 分(600 秒)に固定されています。このセッション タイムアウトはキープアライブ タイムアウトまたはアイドル タイムアウトと呼ばれることもあります。バックエンド サービスの設定の変更では、セッション タイムアウトの値は構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアでキープアライブ タイムアウトを 600 秒より長い時間に設定する必要があります。このタイムアウトは WebSocket には適用されません

次の表は、一般的なウェブサーバー ソフトウェアの、キープアライブ タイムアウトを変更するために必要な変更を示します。

ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

HTTP(S) 負荷分散は、レスポンス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。失敗した POST リクエストは再試行されません。再試行回数は 2 回に制限されています。再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。詳しくは、ロギングをご覧ください。

不正なリクエストとレスポンスの処理

HTTP(S) ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に HTTP/1.1 に準拠するためという理由もあれば、バックエンド間での予期しないデータのやり取りを避けるという理由もあります。

ロードバランサは、HTTP/1.1 への準拠のために以下をブロックします。

  • 要求の最初の行を解析することができない。
  • ヘッダーに : 区切り文字がない。
  • ヘッダーまたは最初の行に無効な文字が含まれている。
  • コンテンツの長さが有効な数値でない、または、複数のコンテンツ長ヘッダーがある。
  • 複数の転送エンコーディング キーがある、または、認識されない転送エンコーティング値がある。
  • チャンク化されていない本文があり、コンテンツの長さが指定されていない。
  • 本文のチャンクが解析できない。これは、いくつかのデータがバックエンドに到達する唯一のケースです。ロードバランサは、解析不能なチャンクを受信すると、クライアントとバックエンドへの接続を閉じます。

次のいずれかが該当する場合、ロードバランサはリクエストをブロックします。

  • リクエスト URL とヘッダーの組み合わせが 15 KB より長い。
  • リクエスト メソッドは本文を許可しないが、リクエストに本文がある。
  • リクエストに Upgrade ヘッダーが含まれており、WebSocket 接続の有効化に Upgrade ヘッダーが使用されない。
  • HTTP のバージョンが不明。

ロードバランサは、次のいずれかに該当する場合、バックエンドからのレスポンスをブロックします。

  • レスポンス ヘッダーの合計サイズが約 128 KB を超えている。
  • HTTP のバージョンが不明。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...