HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）

Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。

2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。

本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです）

サーバプッシュの問題

次にサーバプッシュを見てみましょう。

HTTP/2のサーバプッシュは、クライアントが使うであろうレスポンスをサーバがプッシュするための仕組みです。

サーバがHTML生成に時間がかかるようなケースで、HTMLを生成している間にCSSを配信する、といったユースケースが想定されています。

ですがサーバプッシュにはいくつかの問題があります。

第一は、プッシュしたアセットは、クライアントがすでに持っているものかもしれないということです。その場合は帯域の無駄使いをしたことになってしまいます。

さらに、HTMLの生成を完了した後、アセット送信からHTML送信に切り替えるのは何も通信をしていない場合に比べてどうしても時間がかかります。これはOSやネットワーク上のルータなどのメモリ上に送信するパケットが滞留する結果です。

そのため、サーバプッシュは上手に使わないとかえってユーザー体験が悪化することになります。

Google Chromeでの調査結果を紹介したいと思います。2018年に発表された結果ですが、縦軸がページ表示までのミリ秒、横軸がパーセンタイル、青がサーバプッシュが有効な場合、赤がChromeのサーバプッシュ機能を無効化した場合の値です。

すべてのケースにおいて、なんと赤、つまりサーバプッシュを無効化した場合の方がユーザーの待ち時間が少なくなったということが分かります。

もちろんWebサイトによるのですが、平均してみるとサーバプッシュはユーザーにとって利益よりも害悪になることが多い、そういう風にいえるわけです。

結果として、Google Chromeではサーバプッシュへの対応をやめることにしました。

HTTP/2とgQUIC（Google版QUIC）、つまり未来のHTTP/3においてサーバプッシュはサポートしない、ということにしたのです。

もうこのままなのでしょうか。

103 Early Hints

実はサーバプッシュに代わって「103 Early Hints」というHTTP拡張が注目されています。

参考：Beyond Server Push: experimenting with the 103 Early Hints Status Code - Fastly blog

103 Early Hintsはレスポンスをプッシュする代わりに、クライアントが必要とするアセットのURLを送ります。

そのためにHTTPのインフォメーショナルレスポンスと呼ばれる100番台のレスポンスを使いますので、既存のHTTPプロトコルでそのまま動きます。

こちらが一般的なHTTPのフローです。

まず、クライアントがリクエストを投げて、それをエッジサーバがオリジンに送ります。

オリジンがHTMLを返してきて、それをクライアントが受けると、そのHTMLに含まれるリンクを解釈してCSSをリクエストします。

こちらが103 Early Hintsを使う場合のフローです。

エッジサーバがリクエストを受信すると、それをオリジンに転送する一方で、103という中間レスポンスをクライアントに返します。この103レスポンスにリンクヘッダが含まれていて、ブラウザはこのリンクを認識します。そして、リンクに含まれているURLがまだキャッシュされていなければそれをリクエストします。

やがてオリジンがエッジサーバにレスポンスを返してくると、エッジサーバはそのレスポンスをクライアントに転送します。

では、どうすればFastlyで103を送信できるのか。このようなVCL（新野注：VCLとはFastlyで採用されているキャッシュサーバのVarnishを制御するための言語）を書くことで可能です。

vcl_recvメソッドの中にURLを判断して、h2.early_hintsという先ほどのレスポンスを送る関数を呼び出すような形で書けばいいのですね。

このようにVCLで送信できるようになっています。

では103 Early Hintsが効果を発揮するのはどんな場合でしょうか。先ほどのダイアグラムを思い出していただければいいのですが、エッジからオリジンまでの距離が遠ければ、そのあいだにエッジとクライアントの間でアセットを大量に交換することができるでしょう。

また、オリジナルのHTMLの生成に時間がかかる場合も同様になると考えられます。

いずれにせよWebページがキャッシュ不可能な場合に効果があると考えられます。

実は103 Early Hintsの対応がGoogle Chromeで始まっています。こちらがそのアナウンスになりますが、英文なのでかいつまんで言うと、彼らはChromeで103 Early Hintsを受信した場合に、それからHTTPステータスの「200 OK」を受信するまでどのくらい時間がかかったか、その時間差を記録する機能を追加しました。

そしてその時間差を収集することで、もしChromeが103 Early Hintsに含まれるリンクをプリロードしたらどれくらいWeb表示のパフォーマンスが向上するかを推定しようとしています。

ですので、ここに書いたような条件にもしみなさんのWebサイトにあてはまる場合。103 Early Hintsに対応することで実験に参加していただいてもいいのではないかなと思います。

HTTP/3は実際に速いのか？

さて、HTTP/3の話題に戻りましょう。いろいろやっていることはお分かりいただけたと思いますが、みなさんの関心はHTTP/3が実際に速いかどうかだと思います。

まず、Googleさんの公開しているデータを見てみましょう。これは2017年、昔のGoogle版のQUICを実装した、GoogleのサーバとGoogleのクライアントを使った場合のパフォーマンスです（水色のマーカーが韓国、青のマーカーが米国、黄色のマーカーがインド）。

韓国ではYouTubeが固まるケースが10％減少したことが分かり、アメリカだと13％で検索の遅延も減っています。インドではさらに顕著な効果が出ていて20％を超えていたりします。

ネットワークの品質が低いほど、QUIC導入の効果が大きいようです。

ではFastlyの実装の場合はどうでしょう。こちらはFastlyで使っているHTTPサーバのH2Oで2020年9月にとったベンチマークです。

まずTTFB（新野注：Time to first byte：ブラウザがHTTPリクエストをしてから最初の1バイトを受け取るまでの期間）の値を見てみましょう。

ここからのグラフでは、HTTP/2の50パーセンタイルの値を1として、所要時間の相対値を示しています。ですのでバーが短い方が速いことを示しています。

QUICはTCP+TLSに比べてハンドシェイク時間が短くなっていると説明しましたが、実際にTTFBが7割程度に短縮されたことが分かります。

次にFullyLoadedのグラフを見てみましょう。このネットワークは遅延が20ms、バンド幅が1Mbpsです。現在、こういう状況の回線がどれだけあるかは分かりませんが、昔の専用線T1をイメージしていただければいいと思います。

このようなネットワークでは、HTTP/1.1、HTTP/2、HTTP/3はほぼ同じ結果になります。バンド幅がボトルネックになるからですね。

HTTP/3はHTTP/2より1％程度遅いのですが、これはUDPパケット化によるオーバーヘッドによるものです。しかし実際にこのオーバーヘッドが問題になるかというとそういうことはなくて、実際のネットワークは1Mbpsより太いことが多いからですね。

例えばこれは10Mbpsでのグラフですが、このような環境ではHTTP/3がHTTP/2よりも3％程度速いというベンチマーク結果が得られています。

そしてレイテンシが100msのように大きくなると、HTTP/3はHTTP/2よりも10％程度高速になります。

これはランダムなパケットロスを5％人工的に注入したネットワークです。これはもちろん現実のネットワークに即したものではありませんが、こうした極端に悪いネットワーク環境ではHTTP/3はHTTP/2よりも速いことが分かります。

HTTP/1.1のように同時に6本の接続を使うというチートをする場合にはなかなか及びませんけれども、開発途中のHTTP/3のほうがHTTP/2よりもこれだけ優秀になっているということをご理解いただければと思います。

FastlyにおけるHTTP/3の現状

最後にFastlyにおけるHTTP/3の現状について紹介させてください。

Fastly自身のWebサイトはすでにHTTP/3に対応済みです。お使いのWebブラウザがChromeであれば、もうすでにHTTP/3で通信しているかもしれません。

また、まもなくLimited Availabilityのアナウンスもできる見込みです。

パフォーマンス測定の結果はさきほど紹介したようにすでに良いものになっていますが、引き続きパフォーマンス向上に取り組んでいきます。

そこには実装アルゴリズムの改良や通信プロトコルの拡張を行うことも含まれています。

まとめ

最後にまとめたいと思います。

お話してきたようにHTTP/3は標準化の段階を経て実用化の段階に入りつつあります。

FastlyではHTTP/3への移行に取り組むとともに、さまざまな側面からWebの高速化に取り組み続けたいと思っています。

具体的には先ほど申し上げましたが、実装アルゴリズムの改良、標準プロトコル策定もありますし、他のベンダさんと協力してさまざまな高速化に取り組んでいけたらなと考えています。

ご静聴ありがとうございました。

関連記事

• レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
• リクエストを待たずに送信を開始する「サーバプッシュ」～奥一穂氏による「HTTPとサーバ技術の最新動向」（中編）。Developers Summit 2016
• HTTPS化もHTTP/2にすれば負荷を下げられる～奥一穂氏による「HTTPとサーバ技術の最新動向」（後編）。Developers Summit 2016
• 「HTTP/3」がHTTP-over-QUICの新名称に。IETFのQUICワーキンググループとHTTPワーキンググループで合意
• QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に

2021年5月、QUICがRFC 9000としてインターネット標準となりました。

• HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として