日本経済新聞社のAdvent Calendarの 17 日目の記事です。
日本経済新聞社の電子版アプリは今年、一部APIで現在HTTP/3での通信ができるようになりました。
今回はHTTP/3の簡単な説明と、日経電子版へのアクセスログをもとにHTTP/3がどの程度利用されているか紹介しようと思います。
HTTP/3とは
HTTP/3は今年の6月に正式にRFC9114として勧告されたWeb通信Protocolの最新版です。 HTTP/2の改良版にあたり、通信のボトルネックを減らして効率の良い通信を可能にする技術です。
HTTP/3はトランスポートのプロトコルにQUIC(RFC9000)を採用した点が特徴です。 通信にはTCPではなくUDPを利用しており、TCPが行っていた再送制御やTLS暗号化処理はQUICが行います。
通信速度の改善ポイントとしては、接続確立時のハンドシェイク数の減少、ヘッドオブラインブロッキングの解消、優先度制御の再設計などがあります。 TCPでは接続に3way handshakeが必要なため、1往復半の通信が必要です。更にTLS通信を行うためには鍵のやり取りでより多くの往復やり取りが必要となります。このためクライアントの接続先となるサーバが物理的に遠い場所にある場合や、通信エラーの発生しやすい状況での通信は接続に時間がかかる問題がありました。
TFO(TCP Fast Open, RFC7413)など、TCPでも3way handshakeを減らす技術はあります。しかしFirewallやルータなどの中間装置によりデータを削除されて接続できないといった問題(Ossification、硬直化と呼ばれます）があり、あまり利用されていませんでした。
HTTP/3のQUICでは、TLS暗号化を含めて1往復で初回のhandshakeができるようになっています。 中間装置が中身を見られないような仕組みにすることで、TFOで起きた問題も回避しています。
そのほか、HTTP/2で導入された多重化なども用いることで高速化を行っています。
HTTP/3の詳細はRFC9114を参照して下さい。
HTTP/3の利用状況
このHTTP/3は世界でどの程度利用されているのでしょうか。
W3Techs によると、2022年12月時点で全Webサイトの25.2%で利用されているようです。
※ https://w3techs.com/technologies/details/ce-http3 より
大規模なサイトでは
- google.com
- youtube.com
- facebook.com
- instagram.com
などで利用されているようです。 bbc.com などのニュースサイトでも最近はHTTP/3となっています。
日本経済新聞社におけるHTTP/3
日本経済新聞社ではFastlyやCloudFrontなどのCDN(Content Delivery Network)を利用しています。 これらのCDNを通した場合、クライアントに対してHTTP/3での接続環境は容易に提供可能です。
日本経済新聞社では現在、一部のAPIやサイトでHTTP/3のテストをしています。 この hack.nikkei.com も HTTP/3 が有効になっています。
HTTP/3を有効にするには
HTTP/3を有効にするには、おおまかに以下の3つが必要です。
- HTTPサーバをHTTP/3へ対応させる
- CDNの場合、オプション有効化やCNAMEをHTTP/3対応のエンドポイントへ切り替えることでできる
- サーバのUDPポート(主に443)を開ける
- (CDN利用の場合は不要)
- クライアントにHTTP/3対応であることを伝える
- CDNによってはオプション有効化で同時に設定されることもある
HTTP/3はUDPを利用するようになるため、3点目の手順でクライアントへ明示的にHTTP/3対応であることを伝える必要があります。
この方法は2つ用意されています。
- HTTPヘッダで伝える
- DNSレコードで伝える
この点について少し詳しく見ていきましょう。
HTTPヘッダで伝える
1つ目の方法はHTTPヘッダで伝える方法です。 alt-svcヘッダをHTTPレスポンスに加えることでサーバがHTTP/3対応であることを伝えます。
オリジンサーバでヘッダを足すと前段のLBやキャッシュサーバが誤解する可能性もあるため、実際にHTTP/3を返すエッジで付与してあげるのが良いでしょう。
CDNでは以下の挙動になっています。
- Fastly
- VCLに
h3.alt_svc();を書くことで、自動で以下のヘッダが追加される alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
- VCLに
- Cloudfront
- HTTP/3オプションを有効にすると自動で以下のヘッダが追加される
alt-svc: h3=":443"; ma=86400
クライアントは初回HTTP/2で接続します。 そこでこのヘッダを見て「このサーバはHTTP/3対応だ」という情報を記憶し、次にHTTP/3での通信を試行します。
DNSレコードで伝える
HTTPヘッダのalt-svcはシンプルですが、一度は従来のHTTPでの通信が必要となります。 そのためHTTP/3のメリットである初回接続の遅さを減らす効果を最大限享受することはできません。
この問題を解消するため、DNSで情報を伝える仕様が検討されています。 https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/
DNSのHTTPSレコード(type65)でAlt-svc情報を伝えることで、h3に対応していることをブラウザに伝達できます。
実際にCloudflareではHTTPSレコードが既に利用されており、 Chrome等も対応しているため意外と利用されているようです。
ただし、AWSのRoute53をはじめとして多くのDNSサーバではまだこのtype65をサポートしていません。 またクライアント側のHTTP/3ブラウザについても、すべてがHTTPSレコードに対応しているわけではないため、こちらだけを利用するのはまだ限られています。
注意点
HTTP/3を有効にするにあたり、私が気にしていたポイントです。
ファイアウォール
クライアントはUDPでの接続試行を行います。そのため企業内など外への通信を絞っているところでは、従来のTCP:443と異なる通信としてブロックし、HTTP/3接続できない可能性があります。
接続試行
UDPでの接続に失敗したとしてもブラウザ側でのフォールバックは行われますが、ここは結構複雑です。 例えばdualstackで動かしている場合、
- IPv4+IPv6 egghappy eyeballs
- HTTP/1.1, 2.0, 3.0 の切替処理(とくにHTTP/2.0までとHTTP/3.0)
というパターンで、クライアントは一度に4つの接続を試す可能性があります。
このような接続試行の動きを理解しておかないと、接続できなかったときの原因調査が難しくなります。 クライアントが期待通りにフォールバックしてくれるか心配だったため、今回は一度に全部を移行はせず、少しずつ様子を見ながら切り替えました。
アクセス状況
アプリAPIをHTTP/3対応に切り替えた後のアクセス状況を紹介します。
アプリはiOS, Androidとありますが、現在クライアントの実装の関係上 iOSのみがHTTP/3に対応しています。
iOSからのAPIアクセスにおけるHTTP/3割合などを見ていきましょう。
iOS16, iOS15で比較
iOS16は約50%、iOS15は約35%がHTTP/3です。
通信路別で比較
iOS16に絞った上で、通信路別にHTTP/3比率を見てみます。 通信路(ISP, FastlyからみたAS番号)によるHTTP/3割合に大きな違いは見られません。
IPv4, IPv6で比較
IPv4, IPv6とHTTP/3の割合に相関は見られませんでした。
ちなみに、IPv6からのアクセス割合は2022現在 50% 程度で推移しています。
速度比較
サーバサイドログのみからではHTTP/3とHTTP/2に速度の違いは見られませんでした。 レスポンス時間全体に対してRTTの時間はそこまで大きくないのだと思います。 一方で、通信が安定していない状況や、最寄りのCDNエッジから距離があるケースに絞るなどすると もう少し効果が見られるかもしれません。
その他、データから分かること
iOS16においてHTTP/3の割合が突然大きく変動したことがあります。 当初、iOS16からのHTTP/3比率は8割ほどありましたが、 9/28 頃に大きく下がっています。 この日に特にデプロイはアプリ・サーバで実施していないため、ブラウザ等がABテスト的に割合をコントロールしている可能性もありそうです。
終わりに
今回は、HTTP/3の簡単な説明と、ログをもとにHTTP/3でのアクセス割合を紹介しました。 残念ながら、数値から通信速度の改善は見られませんでしたが、大きな問題もでていないので HTTP/3有効化は進めていこうと考えています。
明日は 18 日目、「Atlas 開発チームに join して半年後に自走するまでの取り組み」です。お楽しみに！
