Microservices Engine:クラウドネイティブゲートウェイでの HTTP/3 の有効化

ステップ 1： EnableHttp3 パラメーターをオンにする

1. MSE コンソールにログインします。上部のナビゲーションバーで、リージョンを選択します。

2. 左側のナビゲーションウィンドウで、[クラウドネイティブゲートウェイ] > [ゲートウェイ] を選択します。[ゲートウェイ] ページで、対象のゲートウェイの名前をクリックします。

3. 左側のナビゲーションウィンドウで、パラメーターの設定 をクリックします。

4. Gateway Engine Parameters セクションで、[EnableHttp3] パラメーターを見つけ、Actions 列の Edit をクリックします。

   

5. Modify Parameters ダイアログボックスで、Value スイッチをオンにし、OK をクリックします。

ステップ 2： HTTPS リスナーの確認

ゲートウェイに関連付けられている Classic Load Balancer (CLB) インスタンスに、ポート 443 で正常なリスナーがあることを確認します。

1. ゲートウェイの [概要] ページで、CLB インスタンス名をクリックします。

2. CLB コンソールで、ポート 443 リスナーの [ヘルスチェックステータス] が正常であることを確認します。

ステップ 3： バックエンドサービスとルーティングルールの追加

1. HTTP/1.1 をサポートするバックエンドサービスを追加します。詳細については、「サービスの追加」および「サービスソースの追加」をご参照ください。

2. サービスにルーティングルールを追加します。たとえば、quic という名前のルーティングルールを追加します。詳細については、「ルーティングルールの作成」をご参照ください。

ステップ 4： HTTP/3 接続のテスト

cURL コマンドを実行して、ゲートウェイ経由で HTTP/3 リクエストを送信します。

curl --http3 https://api.alibaba-inc.com/quic \
  --resolve api.alibaba-inc.com:443:<IP address of the CLB instance> -k

api.alibaba-inc.com をご利用のドメイン名に、/quic をルーティングルールで定義したパスに、<IP address of the CLB instance> を実際の CLB の IP アドレスに置き換えます。

docker run --rm ymuski/curl-http3 \
  curl --http3 https://api.alibaba-inc.com/quic \
  --resolve api.alibaba-inc.com:443:<IP address of the CLB instance> -k

ステップ 1： EnableHttp3 パラメーターをオンにする

コンソールでの方法のステップ 1 と同じ手順に従って、EnableHttp3 パラメーターをオンにします。

ステップ 2： MSE Ingress Controller のインストールと関連付け

1. ご利用の Container Service for Kubernetes (ACK) クラスターに MSE Ingress Controller をインストールします。詳細については、「MSE Ingress Controller コンポーネントの管理」をご参照ください。

2. ゲートウェイを MSE Ingress Controller に関連付けます。詳細については、「MseIngressConfig の設定」をご参照ください。

ステップ 3： HTTPS Secret と Ingress の作成

次のマニフェストを適用して、ご利用の ACK クラスターに TLS Secret と Ingress ルーティングルールを作成します。

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: <base64-encoded-certificate>    # Base64 エンコードされた TLS 証明書
  tls.key: <base64-encoded-private-key>     # Base64 エンコードされた秘密鍵
type: kubernetes.io/tls
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
  annotations:
    # バックエンドサービスが HTTP/2 を使用する場合は HTTP2 に設定
    nginx.ingress.kubernetes.io/backend-protocol: HTTP
spec:
  tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls
  rules:
  - host: https-example.foo.com
    http:
      paths:
      - path: /quic
        pathType: Prefix
        backend:
          service:
            name: service1             # ご利用のバックエンドサービス名
            port:
              number: 80

プレースホルダーの値を置き換えます。

ステップ 4： HTTP/3 接続のテスト

cURL コマンドを実行して、Ingress 経由で HTTP/3 が機能することを確認します。

curl --http3 https://https-example.foo.com/quic \
  --resolve https-example.foo.com:443:<IP address of the CLB instance> -k

接続が成功すると、応答には HTTP/3 サポートを通知する alt-svc ヘッダーが含まれます。

HTTP/1.1 の制限事項

HTTP/1.1 は、スペースで区切られたテキストとしてメッセージを転送します。多重化レイヤーがないため、ブラウザは複数の TCP 接続を開いて並列リクエストを処理しますが、これは輻輳制御とネットワーク効率を損ないます。詳細については、「RFC 9112」をご参照ください。

HTTP/2 の改善点と残された課題

HTTP/2 は、トランスポートレイヤーを変更せずにレイテンシを削減するために、バイナリフレーミングと多重化を追加します。ただし、HTTP/2 は TCP 上で実行されるため、1 つのパケットが失われると、回復が完了するまで接続内のすべてのストリームがブロックされます (head-of-line ブロッキング)。詳細については、「RFC 9113」をご参照ください。

HTTP/3 によるこれらの問題の解決方法

HTTP/3 (以前は HTTP-over-QUIC と呼ばれていました) は、TCP を、もともと Google によって開発された UDP ベースのプロトコルである QUIC に置き換えます。IETF は 2018 年に HTTP-over-QUIC を HTTP/3 に改名し、2022 年 6 月 6 日に RFC 9114 で提案標準として公開しました。

QUIC は各ストリームに独自のフロー制御を提供するため、1 つのストリームでパケットが失われても他のストリームはブロックされません。HTTP/3 はまた、HTTP/2 に比べて輻輳制御とヘッダ圧縮を改善します。

HTTP/3 は、Cloudflare、Google Chrome、および Firefox Nightly でサポートされています。詳細な概要については、「HTTP/3 from A to Z: core concepts」をご参照ください。