概要
インターネットに関する技術の標準化を司る、IETF(Internet Engineering Task Force)のWG(Working Group)において、HTTP-over-QUICが正式にHTTP/3という名前になることで合意が取れました。(ゆきさんからのご指摘内容を修正しました)
しかし、そもそもこのQUICやHTTP/3って何なんでしょうか？
Webに関わる僕たちエンジニアにとってどういう関わり方をするのか、考えてみました。
この記事は怪文書ですので、雑と書いてあるところは私見として軽く流してください。
追記
詳解HTTP/3を翻訳しました！雑に理解したあとはこの本を読んでみるといいと思います。
QUIC・HTTP/3ってなに？
QUIC
QUICは、Googleのエンジニアが提案した仕様が発端となって作られている、新しいトランスポート層のプロトコルです。
従来はgQUIC(Googleの仕様・実装)とIETF QUIC(IETFのQUIC仕様)の2つがあったのですが、今年の半ばにGoogleがIETFのQUICに仕様を統合する発表をしたため、gQUICの話は一旦無視して大丈夫です。(雑)
目的や機能は多岐にわたりますが、大きく分けて、以下のような特徴があります。
1. 暗号化ネイティブ
QUICでは、暗号化のためにTLS1.3を用いており、その仕様に含まれるものとなっています。
具体的には、TLSから認証部分と鍵の交換・提供アルゴリズムを提供してもらい、実際の暗号化はQUICのレイヤで制御しています。
従来のTLS1.2では暗号化チャネルの確立に3RTT(Round Trip Time)かかっていたのが、TLS1.3では0-1RTTで接続できるようになったため、オーバーヘッドが少ないかつより早い段階からの暗号化通信が可能となっています。
TLS1.3の0-RTTについては、このへんやこのへんが詳しいかと思います。
2. UDP上で動作
TCPには潜在的に以下のような問題を抱えています。
- 接続の確立に3-way handshakeを要するため、データの提供開始までのオーバーヘッドが非常に大きい
- データの再送処理・輻輳制御はあるものの、パケットが順番通りに届く必要があるためデータ転送の効率が悪い
- そもそもTCP自体が古い(雑)
QUICでは、その問題を解決するために、UDP上のQUICレイヤにて、輻輳・通信の多重化などの制御を行っています。言ってみれば、UDPの上でぼくのかんがえたさいきょうのあたらしいTCPを再実装しているようなものです(雑)
HTTP/3 is 何
HTTP/3は、HTTP-over-QUIC、つまり、QUICプロトコルの上でHTTP(HTTP/2 API)を動かすための仕様です。
僕も勘違いしてた時期があったのですが、QUICがHTTP/3なのではなく、IETF QUICは完全なトランスポートプロトコルとしての立ち位置を持つようで、HTTPレイヤはまた別に存在します。
が、実情として実装がより進んでいるgQUICにはHTTP/2のAPIが含まれていることや、実装の普及率を考えてHTTP/3≒QUICと考えても大きな乖離はなさそうです。(雑)
QUICのプロトコルオーバービューは下記画像のような形になっています。(Image credit)
HTTP/2には従来のHTTP/1.1の問題となっていたHoL Blockingを解消する重要な仕組みや、データ転送量を少しでも減らすための色々な仕組みが入っているため、ぜひ調べておくといいと思います。
TLS1.3、UDP+QUIC、HTTP/2による三段組の通信オーバーヘッドの改善が行われており、CDNなどで導入されればインターネット上のトラフィック全体に大きな変化があるのではないかと思います。(LINEやAkamaiなどが実績報告をしてる記事もあるのでご参考までに。)
もっと詳しく
まずは、詳解HTTP/3を読んで全体像を理解したらいいと思います。
そこから更に詳しく知りたい場合は、IETFのドラフトドキュメント読みましょう！
えいごむずかしいので日本語でお願いします
QUIC関連の情報を日本語で公開してくださっている方が何人かいらっしゃいます。そちらのツイッターやブログなどをフォローしてみると良いでしょう。
- ゆきさんのブログ: https://asnokaze.hatenablog.com/
- ゆきさんのツイッター: https://twitter.com/flano_yuki
- 大津さんのブログ: https://jovi0608.hatenablog.com/
- 大津さんのツイッター: https://twitter.com/jovi0608
- 大津さんのスライド: https://speakerdeck.com/shigeki
- tatsuhiro-tさんのQiita: https://qiita.com/tatsuhiro-t
- kazuhoさんのツイッター: https://twitter.com/kazuho
kazuhoさんのスライド: https://speakerdeck.com/kazuho
mozaic.fm: https://mozaic.fm/
HTTP/2勉強会のconnpass: https://http2study.connpass.com/
次世代Webカンファレンスのconnpass: https://nextwebconf.connpass.com/
Fukabori.fm #1: https://fukabori.fm/episode/1
露骨なブログ宣伝: https://inductor.hatenablog.com/
影響範囲は？
今すぐどうって話はありませんが、年末に受けてWGの動きも仕様策定に向け大幅に動いていくはずです。
おそらく、来年には正式な仕様として出てくるんじゃないでしょうか（雑）
アプリケーションを作る人達にとって直接大きく影響があるかどうかはわかりませんが
Web（HTTP/3)としての文脈においてはブラウザの対応状況が大きく関わってきます。
ネイティブアプリや、他プロトコルのQUIC対応については、各種OSのカーネルレベルでのモジュール対応が重要なのではと思っています。
カーネルレベルで依存しないようにUDPを使っているとの話がTwitter上であったので消します。
QUICの実装状況は？
Webサーバーの話です。
QUICにTLS1.3が必須要件となったため、Caddyの対応が遅れているようです。
自分の観測範囲ではこのへんをウォッチするようにしています。
https://github.com/mholt/caddy/issues/2080
https://github.com/h2o/h2o/pull/1846
さいごに
QUICはいいぞ。