プライム・ストラテジー「KUSANAGI」開発チームの石川です。
先日公開した KUSANAGI 9.3.0 が対応した HTTP/3 について紹介します。
HTTP/3 とは
HTTP (Hypertext Transfer Protocol) はWebページを見る際に用いられているプロトコルです。WebサーバとWebブラウザの間でHTMLコンテンツやCSS、JavaScript、画像といったデータをやりとりするために用いられています。このページを表示する際にもこのプロトコルが用いられています。
HTTPプロトコルは HTTP/1.0 、 HTTP/1.1 、HTTP/2 と進化を遂げてきましたが、その最新バージョンが HTTP/3 です。
この HTTP/3 は従来のHTTPプロトコル、および、その下層レイヤーであるTCPプロトコルにおける課題を解決するものとなっています。そのため、トランスポート層プロトコルとしてTCPプロトコルに換えてUDPプロトコルをベースにした QUIC を用いているのが特徴です。QUIC の詳細については解説しませんが、以前にASCII.jpに QUIC を解説した記事を執筆しているのでそちらを参照ください。
Googleが設計した次世代通信プロトコル「QUIC」とは？
ここでは HTTP/3 ではTCPプロトコルではなく、 QUIC というUDPプロトコルのようなものを代わりに使っている、と理解いただければOKです。
Head of Line ブロッキング
HTTP/3 が何を改善しようとしてるかを説明する上で、まずはHTTPプロトコルの課題を解説します。
HTTPプロトコルは1つのリクエストに対して、1つのレスポンスが返ってくるプロトコルです。例えば Chrome の DevTools のネットワークタブから、そのリクエストとレスポンスを見ることができます。
Webページが複雑化していくにつれて、HTTPプロトコルの問題が明らかとなっていきます。HTTPではリクエストとレスポントが1対1の対応をしているがゆえに、Head of Lineブロッキングという問題が発生します。
HTTP/1.1 までの場合
ここではシンプルにするために、WebブラウザとWebサーバの間で1つのコネクションしかないとします。
WebブラウザがHTMLを読み込み、続いてCSS、JavaScript、画像といった必要なリソースを続けてリクエストします。コネクションが1つしかないので、リソースは1つ1つのファイルのダウンロードが完了するまで次のリクエストを送信できません。順番待ちが発生することになります。
例えば、あるファイルのダウンロード中にエラーが発生して再送することなると、それが完了するまで次のファイルはリクエストすら開始できません。
(実際は複数のコネクションがあるので完全に逐次ダウンロードになるわけではありませんが、画像が多いページなどではコネクション数の上限に達してしまって順番待ちになることがありえます。)
HTTP/2 の場合
HTTP/2 ではHTTPパイプラインによってこの課題を解決しようとしました。
1つのコネクションの中で1つずつリクエストするのではなく、まとめてリクエストをして、順次レスポンスを受け取る方式です。画像のようにファイルサイズが大きいものは1回のデータ(チャンク)で全てを受け取れませんが、データが揃ったものか処理される(ブラウザ上では表示される)ことになります。
先の例のように、あるファイルのダウンロード中にエラーが発生してもそれだけを再送すればよく、他のダウンロード中のファイルは処理を継続できます。
しかし、HTTP/2 はTCPプロトコルの上で動作しています。HTTPパイプライン化されたリクエストとレスンポンスは、実際はTCPパケットの中に分割されてWebサーバからWebブラウザへ送信されることになります。そのため、TCPパケットのレイヤーでエラーが発生すると、抜け落ちたTCPパケットが再送されるまで受信済の(後続の)TCPパケットが処理されません。
これがTCPプロトコルをベースとしているHTTPプロトコルの弱点です。
HTTP/3 の場合
HTTP/3 では前述のとおりTCPプロトコルに換えて QUIC を用いることで、TCPプロトコルを使っているがゆえに起きていた課題を解決しました。
通信速度は速くなりましたが、スマートフォンのように一定ではない通信環境が増えて、通信のエラーはより発生し易くなっています。また、HTTPSが標準となったことにより、コネクションをはるためのオーバーヘッドの影響も顕著になってきていることも上げられます。現在のWeb利用状況で顕在化するようになったこれらの課題に対処するために HTTP/3 が産まれました。
HTTP/3 にすることで目に見えてにWebサイトが高速になるということは難しいと思います。しかし、通信状況やIPアドレスの変更が発生しやすいモバイル環境からの閲覧では、無駄なトラフィックの減少やコネクション再確立の削減によるレスンポンスの向上が期待できます。
なお QUIC はUDPプロトコルをベースとしているため、HTTP/3 を利用する上ではファイアウォールやクラウドのセキュリティグループなどで、UDPポート443を開放することが必要です。もしも、ファイアウォールなどでブロックされていてUDPプロトコルが通らない場合は、従来通りTCPプロトコル (HTTP/2) で接続します。
HTTP/3 の対応状況
ChromeやFirefoxといったメジャーなブラウザーは既に HTTP/3 に対応しています。
また Google.com はもちろんですが、CloudflareといったCDNも HTTP/3 に対応しており、ブラウザとWebサイトによっては気付かない内に HTTP/3 が既に使われていると思います。
これまで HTTP/3 に対応したWebサーバは LiteSpeed くらいだったのですが、Nginx 1.25で HTTP/3 に対応しました。これによってWebサイトの HTTP/3 対応も普及していくのではないかと考えています。
KUSANAGI 9 は Nginx 1.25 より HTTP/3 に対応したことに合わせて最新版より HTTP/3 を有効にしていますので、ぜひお試しください。
