KUSANAGI 9 が対応した HTTP/3 とは

KUSANAGI 9 が対応した HTTP/3 とは

プライム・ストラテジーの開発チームは、新しいバージョンの「KUSANAGI 9.3.0」でHTTP/3に対応したことを発表しました。HTTP/3は最新のWebページ表示プロトコルで、以前のTCPプロトコルの不具合を克服し、通信速度の向上を目指しています。特にモバイル環境での閲覧において、無駄なトラフィックの減少やコネクション再確立の削減により、レスポンスの向上が期待できます。HTTP/3はUDPプロトコルをベースとしているため、適用にはセキュリティ上の解放が必要です。また、ChromeやFirefoxなどの主要ブラウザーはすでにHTTP/3に対応しています。

プライム・ストラテジー「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 を有効にしていますので、ぜひお試しください。

RFC 9114 HTTP/3

Series NavigationHTTPS暗号化通信のパズルの最後のピース >>

Webサイト運用の課題解決事例100選 プレゼント

Webサイト運用の課題を弊社プロダクトで解決したお客様にインタビュー取材を行い、100の事例を108ページに及ぶ事例集としてまとめました。

・100事例のWebサイト運用の課題と解決手法、解決後の直接、間接的効果がわかる

・情報通信、 IT、金融、メディア、官公庁、学校などの業種ごとに事例を確認できる

・特集では1社の事例を3ページに渡り背景からシステム構成まで詳解

KUSANAGI Tech Colmunを運営している
プライム・ストラテジーへのお問合せはこちらから。

資料請求

KUSANAGIマネージドサービスの課題解決事例集などの各種資料がダウンロードいただけます。

お見積り

「まずは概算が欲しい」「仕様に則った詳細見積もりが欲しい」など状況に応じてお見積り致します。

お問い合わせ

当社サービスの検討にあたってのご質問やご相談などからお気軽にご連絡ください。(フォーム、電話、メール)

お電話でのお問い合わせはこちら 03-6551-2996
受付時間:平日9:00 ~ 18:00