QUIC (Quick UDP Internet Connections) プロトコルは、特にネットワーク状態が悪い場合や、Wi-Fi とモバイルネットワークを頻繁に切り替えるシナリオにおいて、クライアントのアクセス速度を向上させます。再接続を必要とせずに多重化を可能にし、リソースへのアクセス効率を高め、データ伝送を保護します。
QUIC プロトコル
QUIC は、Quick UDP Internet Connections プロトコルとしても知られており、SSL と同等のセキュリティを提供し、多重化などの利点があります。ネットワーク状態が悪い環境でも良好なパフォーマンスを発揮し、大幅なパケット損失やネットワーク遅延が発生した場合でも、実用的なサービスを提供できます。QUIC プロトコルは、オペレーティングシステムやカーネルのサポートを必要とせずに、アプリケーション層でさまざまな輻輳制御アルゴリズムを実装できます。これにより、従来の TCP プロトコルと比較して柔軟な変更が可能なため、TCP の最適化がボトルネックになっているサービスに適しています。
ショートビデオやライブストリーミングなどの新しいサービスの急速な成長に伴い、メディア伝送には高帯域幅と低レイテンシーの両方が求められるようになりました。QUIC プロトコルは、ネットワークやビデオバッファリングの問題を効果的に解決し、オーディオ/ビデオ リソースへのアクセスを改善し、データ伝送のセキュリティを確保できます。
サポートされるQUICプロトコルタイプ
Application Load Balancer (ALB) は gQUIC と iQUIC をサポートしています。HTTP/3 プロトコルは iQUIC 上に構築されたアプリケーション層プロトコルです。iQUIC を利用して、多重化、輻輳制御、損失検出、再送などの機能を実装しています。HTTP/3 プロトコルは、クライアント接続をより高速に確立し、多重化ストリームにおけるヘッドオブラインブロッキングを解消します。
ALB は、gQUIC バージョン Q46、Q43、Q39、および HTTP/3 バージョン h3 をサポートしています。
HTTP/3 ネゴシエーション
[QUIC アップデート]を有効にすると、ALB は HTTP/3 と gQUIC プロトコルをクライアントにアドバタイズします。HTTP/3 をサポートするクライアントが最初に ALB に接続できるように、HTTP/3 のアドバタイズを優先します。
クライアントは、HTTP/3 接続の確立に失敗した場合、常に HTTPS または HTTP/2 へフォールバックします。
HTTP/3 をサポートするクライアントは、HTTP/3 関連のキャッシュ Cookie を使用します。
QUIC アップグレードを有効または無効にしても、クライアントの ALB への接続には影響しません。
このサポートは、Alt-Svc HTTP レスポンスヘッダーでアドバタイズされます。alt-svc ヘッダーの値は次のとおりです:
Alt-Svc : h3=":$quic_port"; ma=3600,quic=":$quic_port"; v="46,43,39"; ma=3600QUIC アップグレードが有効な場合でも、特定の状況では、クライアントは HTTP/3 をネゴシエートする代わりに HTTPS または HTTP/2 にフォールバックすることがあります。次のような状況が該当します:
クライアントがサポートする HTTP/3 バージョンが、ALB がサポートする HTTP/3 バージョンと互換性がない場合。
ALB が UDP トラフィックのブロックまたはレート制限を検出し、HTTP/3 が機能しない場合。
クライアントが HTTP/3 をまったくサポートしておらず、HTTP/3 接続のネゴシエーションを試みない場合。
クライアント要件
Google Chrome を使用する場合、Google Chrome は ALB に対して直接 QUIC リクエストを開始できます。
Google Chrome を使用して QUIC にアクセスするには、特定の Chrome バージョンを使用する必要があります。
ALB がサポートする最新の gQUIC プロトコルバージョンは Q46 で、これは Google Chrome 74 から 81 に対応します。
ALB がサポートする最新の HTTP/3 プロトコルバージョンは h3 で、これは Google Chrome 87 以降に対応します。
カスタム開発されたアプリケーションなど、他のクライアントを使用する場合、クライアントは QUIC プロトコルをサポートするネットワークライブラリ (例:lsquic-client、Cronet、ngtcp2、quiche) を統合する必要があります。
ユースケース
Google Chrome を使用して ALB インスタンスにアクセスすると、ALB はリスナーに紐づく証明書のドメイン名 example.com に基づいて、リクエストをバックエンドサーバーにルーティングします。主なユースケースは次の 2 つです:
HTTPS リスナーと QUIC リスナーの両方が設定されている場合、ALB は QUIC リスナーを優先します。この場合、Google Chrome で証明書に紐づくドメイン名
example.comを入力すると、ALB インスタンスは設定済みの QUIC リスナーを介して、クライアントリクエストをデフォルトのサーバーグループ RS1 に転送します。QUIC リスナーが利用できない場合、接続は自動的に関連付けられた HTTPS リスナーにフォールバックします。この場合、Google Chrome で証明書に紐づくドメイン名
example.comを入力すると、ALB インスタンスは設定済みの HTTPS リスナーを介して、クライアントリクエストをデフォルトのサーバーグループ RS1 に転送します。
前提条件
ALB インスタンスを作成済みであること。詳細については、「ALB インスタンスの作成と管理」をご参照ください。
RS1 という名前のサーバーグループを作成済みであること。詳細については、「サーバーグループの作成と管理」をご参照ください。
ECS01 インスタンスを RS1 サーバーグループに追加し、ECS01 インスタンスに Nginx ビデオサービスをデプロイ済みであること。
ALB インスタンスに SSL サーバー証明書をデプロイ済みであること。証明書はドメイン名
example.comにバインドされています。
ステップ 1:QUIC リスナーの作成
- ALBコンソールにログインします。
上部メニューで、ALB インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、目的のインスタンスを見つけ、インスタンス ID をクリックします。 リスナー タブで、リスナーの作成 をクリックします。
リスナーの設定 ウィザードで、次のパラメーターを指定し、次へ をクリックします。
このトピックでは、関連するパラメーターのみを説明します。その他のパラメーターについては、デフォルト値を使用できます。詳細については、「QUIC リスナーの追加」をご参照ください。
リスナー設定
説明
[リスナープロトコルの選択]
リスナーのプロトコルを選択します。
この例では、**[QUIC]** を選択します。
[リスナーポート]
リクエストを受信してバックエンドサーバーに転送するためのポートを指定します。
ポート番号は 1 から 65535 の間でなければなりません。
説明同じ ALB インスタンス内では、同じプロトコルのリスナーポートは一意である必要があります。HTTP リスナーポートと HTTPS リスナーポートを同じにすることはできません。
SSL 証明書の設定 ウィザードで、サーバー証明書を選択し、次へ をクリックします。
サーバーグループの選択 ウィザードで、サーバー を選択し、次にサーバーグループを選択してバックエンドサーバー情報を表示し、次へ をクリックします。
設定の確認 ウィザードで、設定情報を確認し、送信 をクリックします。
ステップ 2:HTTPS リスナーの作成
HTTPS リスナーを作成する際に、QUIC アップグレードを有効にし、作成した QUIC リスナーと関連付けます。
インスタンス ページで、ステップ 1 で QUIC リスナーを作成したインスタンスを見つけ、インスタンス ID をクリックします。
インスタンスの詳細 タブで、リスナー タブをクリックし、リスナーの作成 をクリックします。
リスナーの設定 ウィザードで、以下のパラメーターを指定し、次へ をクリックします。
このトピックでは、関連するパラメーターのみを説明します。その他のパラメーターについては、デフォルト値を使用できます。詳細については、「HTTPS リスナーの追加」をご参照ください。
リスナー設定
説明
[リスナープロトコルの選択]
リスナーのプロトコルを選択します。
この例では、**[HTTPS]** を選択します。
[リスナーポート]
リクエストを受信してバックエンドサーバーに転送するために使用するリスナーポートを入力します。通常、HTTP にはポート 80、HTTPS にはポート 443 が使用されます。
ポート番号は 1 から 65535 の間でなければなりません。
この例では、443 を入力します。
説明リスナーポートは、同じロードバランサーインスタンス内で一意である必要があります。
[詳細設定]
変更 をクリックして、詳細設定を展開します。
[QUIC アップデート]
QUIC アップグレードを有効にするかどうかを選択します。
この例では、QUIC アップグレードを有効にし、関連付けられた QUIC リスナー ドロップダウンリストから作成した QUIC リスナーを選択します。
SSL 証明書の設定 ウィザードで、サーバー証明書を選択し、次へ をクリックします。
サーバーグループの選択 ウィザードで、サーバー を選択し、サーバーグループを選択してバックエンドサーバー情報を表示してから、次へ をクリックします。
設定の確認 ページで、設定情報を確認し、送信 をクリックします。
ステップ 3:ドメイン名の名前解決設定
example.com を ALB インスタンスのパブリックドメイン名にマッピングするために、CNAME レコードを作成します。
ALB コンソールにログインします。
上部メニューで、リージョンを選択します。
対象の ALB インスタンスを見つけ、その DNS 名をコピーします。
次の手順に従って、CNAME レコードを追加します:
説明ドメイン名が Alibaba Cloud に登録されていない場合は、まず Alibaba Cloud DNS コンソールに追加してから、名前解決設定を行う必要があります。詳細については、「ドメイン名管理」をご参照ください。ドメイン名が Alibaba Cloud に登録されている場合は、次の手順に進みます。
Alibaba Cloud DNS コンソールにログインします。
インターネットの権威ある DNS 解決 ページで、目的のドメイン名を見つけ、Actions 列の 解決設定 をクリックします。
解決設定 ページで、Add Record をクリックします。
Add Record パネルで、次のパラメーターを指定し、OK をクリックします。
パラメーター
説明
[Record Type]
ドロップダウンリストから **[CNAME]** を選択します。
[Hostname]
レコードのホスト名。例:www
[Query Source]
デフォルトを選択します。
[Record Value]
コピーした ALB インスタンスの DNS 名を貼り付けます。
TTL
TTL (Time to Live)。DNS レコードが DNS サーバーにキャッシュされる時間を指定します。この例では、デフォルト値を使用します。
説明新しい CNAME レコードはほぼ即時に有効になります。変更されたレコードが反映されるまでの時間は、以前のレコードの TTL に依存し、デフォルトでは 10 分です。
レコードの追加時に競合が発生した場合は、別のホスト名を使用してください。詳細については、「DNS レコード競合ルール」をご参照ください。
ステップ 4:結果の検証
ここでは、Windows クライアントを例に説明します。ブラウザで example.com を入力して ALB インスタンスにアクセスしてください。この例では、サーバーグループ RS1 のバックエンドサーバーである ECS01 に Nginx ビデオサービスがデプロイされています。
HTTPS リスナーと QUIC リスナーの両方が設定されている場合、ブラウザで証明書に紐づくドメイン名
example.comを入力し、F12キーを押します。現在のウェブページの プロトコルが HTTP/3 であり、リクエストに 93 ms かかったことがわかります。QUIC リスナーが利用できない場合、ブラウザで証明書に紐づくドメイン名
example.comを入力し、F12キーを押します。現在のウェブページの プロトコルが HTTP/2 であり、リクエストに 148 ms かかったことがわかります。
この結果から、ALB を介して HTTP/3 を使用すると、バックエンドサーバー上のビデオコンテンツへのアクセス速度が向上することがわかります。