HTTP/3(QUIC)対応してますか？～Citrix ADC(NetScaler)でHTTP/3化してみた～

2022年6月、IETFは"HTTP/3（Hyper Text Transport Protocol/3）"をRFC 9114として標準化しました。
そもそもHTTP/3とは何か、どのように対応すべきか、検討を始めている方もいらっしゃるのではないでしょうか。
本記事では、HTTP/3の概要とCitrix ADC（NetScaler）を用いて、HTTP/3に対応する方法をご紹介いたします。

HTTP/3は、Webサイトの表示を高速化する目的で、2022年6月にRFC9114として標準化されました。
＊HTTP/3のRFCは下記となっております。
RFC 9114 - HTTP/3 (ietf.org)

従来の通信規格（HTTP/1.1やHTTP/2）と比較した際、大きく異なるポイントとしては
TCPをベースとした"TCP+TLS"から、UDPをベースとした"UDP+QUIC"に変更されたという点になります。
UDPをベースにすることで、TCPの3-way handshakeによるオーバーヘッドや遅延を解消します。
QUICは、1つのQUICコネクション内で複数のストリーム処理を可能にすることで、通信の高速化を実現しています。
また、TLS1.3による通信の暗号化を前提としており、よりセキュリティの高い通信となっています。
＊QUIC（Quic UDP Internet Connections）とは、2013年にGoogleから発表され、2021年5月にRFC9000として標準化されました。

HTTP/3には様々な特長がありますが、本記事では２つの特長についてご紹介いたします。
①1-RTTによる通信の高速化
②QUICストリームによる再送制御
2つの特長について、詳しく見ていきましょう。

"TCP＋TLS"から"UDP＋QUIC"へ変更されたことにより、どのように通信が高速化されたのか見ていきましょう。

従来のTCP＋TLS通信では、3-way handshakeにてTCPコネクションを確立した後、TLS handshakeでTLSコネクションを確立します。
HTTP/3で利用される"UDP+QUIC"では、QUICコネクション確立と同時にTLSコネクションを確立する1-RTT（1 Round Trip Time）が採用されております。
これにより、HTTP/2よりも早くアプリケーションデータの転送が可能になり、Webサイトの読み込み速度が向上しました。

まずはじめに、従来のHTTPにおける再送制御の課題（HoL Blocking：Head-of-line blocking）について少し振り返りましょう。

■HTTP/1.1
HTTP/1.1では、Keep-aliveのサポートによって、TCPコネクションの持続が実現し、1つのコネクションの中に複数のrequest処理を行うことが可能になりました。
しかし、1つのrequestに対するresponseを受信した後に、次のrequestを送信できる仕組みの為、パケットの遅延や欠損が生じた場合、後続すべてのrequestが遅延いたします。
その結果、Webサイト全体のパフォーマンスが低下してしまう問題がありました。
 

■HTTP/2
この問題を解決するために、HTTP/2では、ストリームを用いたマルチプレキシングと呼ばれる機能が導入され、
複数のrequestとresponseを同時に処理することができるようになりました。
HTTP上におけるHoL Blocking問題が軽減され、Webサイトの読み込み速度が向上することが期待されました。
しかし、HTTP/2は1つのTCPコネクション上で複数のストリームを処理している為、1つのストリームのパケットに遅延や欠損が生じた場合、他ストリームの処理が遅延してしまう問題がありました。
結果として、HTTP/2では、HTTPのHoL Blocking問題は軽減できましたが、TCPのHoL Blocking問題は解消できませんでした。
 

■HTTP/3
この問題を解決するために、HTTP/3ではQUICストリームが登場しました。
QUICストリームは、1つのQUICコネクション内に複数のストリームを並列に処理することができ、それぞれのストリームは独立して処理されます。UDPベースで動作している為、TCPのHoL Blocking問題自体発生しません。
では、どのようにパケットの再送制御をしているのでしょうか。
フロー図を用いてご説明いたします。

QUICは、ストリーム毎に独自のパケット番号を持ち、パケットの順序を維持するために使用されます。
例として、上図では1つのrequestに対し、3つのresponseを返す通信としております。
（各ストリームそれぞれのパケット番号を①～③としています。）
上図（右）のようにストリームID:1のパケット番号②が欠損した場合、Clientはパケット番号の①、③を受信しますが、パケット番号の②が受信できなかった為、欠損と判断することができます。
これにより、Clientは再送requestを送信し、Serverは再送する必要のあるデータに対して、新しいパケット番号を付与して送信することで、再送処理をすることができます。
また、各ストリームは独立して動作している為、他ストリームにも影響を与えずに安定した通信を実現することができます。

HTTP/3の特長についてご紹介してきましたが、実際にHTTP/3の通信に対応するにはどのようにしたら良いでしょうか。
本記事では、Citrix ADC（NetScaler）にてAlt-Svcヘッダーを付与し、HTTP/3化した結果をご紹介いたします。

本構成では、ClientからからServerに対し、HTTPの画像コンテンツを取得いたします。
今回使用した機器構成、OSについては下記の通りです。

■Client
Windows11のFirefoxを使用
IPアドレス：192.168.21.10/24
request：GET /index.html
※TLS1.3はWindows 11、またはWindows Server 2022以降にて対応している為、使用するVersionには注意が必要
参考リンク
Windows 11の TLS 暗号スイート - Win32 apps | Microsoft Learn

■Load Balancer
MPX9100 NS13.1 build 24.38
VIP：192.168.21.23/24
※NS13.0 より HTTP/3をsupport

■Server
CentOS Linux release 7.9.2009 (Core) ：HTTP/1.1で2台稼働中
IPアドレス：192.168.22.1-2/24
Server内に"index.html"ファイルを用意、"index.html"には画像を4つ読み込むよう記載

では、実際の通信を確認してみましょう。

①ClientからHTTP/1.1でrequestを送信
はじめに、ClientからCitrix ADC（NetScaler）の持つVIPにrequestを送信します。
Clientから最初の通信はHTTP/1.1となってしまいますので、この時点はHTTP/3の通信が実現できていません。

②Citrix ADC（NetScaler）からAlt-SveヘッダーでHTTP/3を指定してClientにresponse
ここで登場するのが、Alt-Svc（HTTP Alternative Services）です。
Alt-Svcとは、HTTPのresponseヘッダーの1つであり、代替サービス（Alternative Services）としてプロトコル/ホスト/ポート等を組み合わせることで定義され、アクセスした接続先とは異なる接続先を提供したい場合に利用されます。
※参考
Citrix ADC（NetScaler）にて付与したAlt-Svcの中身は下記となります。
【Alt-Svc:"h3=\":443\"; ma=3600; persist=1"】
　 "h3=\":443\"：プロトコルをHTTP/3、ポート番号を443に指定
　 ma=3600：1時間後にキャッシュが失効
　 persist=1：Clientのネットワークの変更があった場合にもAlt-svcの内容を維持

③ClientからHTTP/3でrequestを送信
　ClientにてAlt-Svcが付与されたresponseを受け取り、HTTP/3でrequestを送信

■ブラウザーのリロードを実施
ClientのWebブラウザーにキャッシュが残っていれば、最初からHTTP/3でrequestを送信いたします。
そのため、リロード後でも①の通信（"index.html"の参照）からHTTP/3が使用されます。

Citrix ADC（NetScaler）であれば、既存Serverの設定変更をすることなく、HTTP/3化を実現できます。

本記事では、HTTP/3の概要とCitrix ADC（NetScaler）を用いたHTTP/3の実現方法をご紹介いたしました。
ご興味ある方は、是非下記のフォームよりお問い合わせください。

テキスト

木村詩織

入社3年目のNWエンジニア
Citrix ADC(NetScaler)のプリセールス/デリバリーを担当