Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
HTTP/3 と QUIC について
Search
bokken
November 24, 2022
Programming
0
170
HTTP/3 と QUIC について
HTTP/3 の RFC が publish されたことに合わせて、HTTP/3 と QUIC について紹介します。
bokken
November 24, 2022
Tweet
Share
Other Decks in Programming
See All in Programming
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
140
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
340
童醫院敏捷轉型的實踐經驗
cclai999
0
180
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
2
250
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
100
Haskell でアルゴリズムを抽象化する / 関数型言語で競技プログラミング
naoya
17
4.9k
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
810
すべてのコンテキストを、 ユーザー価値に変える
applism118
2
720
Go1.25からのGOMAXPROCS
kuro_kurorrr
1
800
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
390
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
340
XP, Testing and ninja testing
m_seki
3
180
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
51
8.4k
KATA
mclloyd
29
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Six Lessons from altMBA
skipperchong
28
3.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
We Have a Design System, Now What?
morganepeng
53
7.7k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
Transcript
HTTP/3 and QPACK @bokken HTTP RFC Publication Study 1
About me • Name: bokken • Twitter: @bokken_ • GitHub:
@negibokken • Like: ◦ ブラウザ ▪ レンダリングエンジンからミニ自作ブラウザを作った ▪ Chromium Contributor として頑張りたい 2
もくじ (持ち時間10分) • HTTP/3 • QPACK 3
HTTP/3 4
HTTP/3 の歴史 • 2013 年: Google QUIC が提案される • 2016
年: IETF QUIC (HTTP over QUIC) draft ◦ IETF 有志でドラフト作成 ◦ このときは HTTP over QUIC • 2018 年: HTTP over QUIC から HTTP/3 draft に ◦ QUIC はアプリケーション層も含んでいたが HTTP/3 は違う ◦ HTTP/2 over QUIC ではない ◦ HTTP/2 よりも新しいものである • 2022 年6月6日: HTTP/3 RFC 🎉 5
HTTP/3 と HTTP/2, HTTP/1.1 の比較 6 ※図の引用元: https://twitter.com/programmingart/status/1533915149827964928 • IP
層は同じ • TCP ではなく UDP • QUIC 前提になっている • TLS は QUIC に組み込まれている • stream は QUIC が多重化
HTTP/3 概念図 7 • endpoint 間で connection を貼る • リクエストとレスポンスを双方向の
request stream で送受信(一回で close) • frame 単位で HTTP メッセージをやり取り • control stream で制御用 frame を送れる • push stream で Server Push ができる • encoder / decoder stream は QPACK 用
コネクションの確立 • Server が Alt-Svc ヘッダをレスポンスに付与して HTTP/3 対応を示す ◦ 例)
Alt-Svc: h3=":50781" (UDP 50781 番ポートで h3 を利用可能) ▪ HTTP/2 ALTSVC Frame, HTTPVSSVC でも指定可能 • クライアントは一度 HTTP/1.1 か HTTP/2 で通信 8
フレーム一覧 • 8 種類のフレームが存在し、送信可能な Stream が違う 9 HTTP ボディ用の Frame
HTTP ヘッダ用の Frame Server Push キャンセル用の Frame コネクション設定用の Frame サーバ Push 用の Frame コネクション切断用の Frame Push ID の上限を知らせる用の Frame 予約された Frame
HTTP Fields • HTTP/2 と同様に Pseudo-header fields を持っている (CONNECT 以外)
◦ request ▪ :method : HTTP メソッド ▪ :scheme : http や https などのスキーマ ▪ :authority : ホストとポート。Host ヘッダフィールドの代わりに使われるべき ▪ :path : パス ◦ response ▪ :status : ステータスコード 10
コネクションのクローズ 11 • Idle Connections ◦ 長い時間パケットを受信しない場合にクローズされる • Connection Shutdown
◦ 正常な流れのクローズ。 GOAWAY Frame を送ることによってクローズできる • Immediate Application Closure ◦ HTTP/3 の実装がなんらかの理由で接続終了を伝える • Transport Closure ◦ QUIC 側のエラーによってこれ以上通信できないときのエラー ※ HTTP/2 のときはパケロスでコネクションがうまく閉じられないことがあった
QPACK 12
QPACK 13 • HTTP/3 において Fields を圧縮する方法を定める仕様 • HTTP/2 では
Fields を圧縮するのは HPACK ◦ HTTP/3 で HPACK をそのまま使わないのは、 head of line blocking が発生するため ◦ HPACK はフレームの到着順序が保証されている前提 ◦ HTTP/3 では全 stream で見るとフレームの到着順は保証されない ▪ (stream 内では到着順は保証されている ) ◦ HPACK はそのまま使えないので QPACK が策定された
Fields を圧縮する方法 • HPACK でも利用していた下記を使う ◦ ハフマン符号化 ◦ リファレンステーブル ▪
静的テーブル ▪ 動的テーブル 14
ハフマン符号化 • 出現確率が高い文字順にデータ量が少ない符号を割り当てる ◦ QPACK の場合、ハフマン符号のテーブルは HPACK と同じものを利用 ◦ 大規模な
HTTP 通信の統計をもとに策定されたもの 15 ※Appendix B. Huffman Code より抜粋
ハフマン符号を使う際の注意点 • ハフマン符号を用いるからと言って必ず短くなるとは限らない • HEADERS フレームの H フラグでハフマン符号を使うか選ぶ 図: ビット長が長くなる記号の一例
図: Field Line のワイヤフレームの一例 16
静的テーブル | リファレンステーブル • QPACK の仕様であらかじめ規定されている field name と field
value の組 ◦ 実際のインターネット通信で利用頻度が多いヘッダをリストアップ ◦ 利用頻度が多い Index ほど小さい数字 図: Field Line のワイヤフレームの一例 17
動的テーブル | リファレンステーブル (1/2) • エンコード命令を使って動的にエントリを追加する ◦ HEADERS フレームで動的テーブルのエントリ追加しない ◦
encoder stream で別途命令を送信することで HEADERS フレームの到着順に依存しない 18
動的テーブルの具体例 | リファレンステーブル (2/2) 19 • encoder stream でエントリを追加 •
動的テーブル更新 • decoder が追加できたことを通知する • request stream で HEADERS frame を送る • decoder 側が処理できたことを示す Section Acknowledgement を返す • decoder 側が HTTP response を返す
まとめ 20 • HTTP/3 ◦ UDP ベースの QUIC を使う ◦
多数の stream と Frame を使う ◦ コネクションのクローズもきちんとされるようにクローズの仕組みを策定 • QPACK ◦ ハフマン符号とリファレンステーブルを使う点は HAPCK 同じ ◦ encoder / decoder stream を使って動的テーブルを管理し、フレーム到着順に依存しない HTTP_3_and_QPACK…
参考資料など • RFC 9114 - HTTP/3 • RFC 9204 -
QPACK: Field Compression for HTTP/3 • HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog • QUIC Tutorial • 『くいっく』HTTP/3編 (無料体験版有り) - 猫耳堂 - BOOTH • QUIC をゆっくり解説シリーズ | IIJ Engineers Blog • HTTP/3 explained 21 HTTP_3_and_QPACK…
補足: なぜ 4N なのか • QUIC の stream の ID
が client-initiated で双方向な stream は末尾が 0 ◦ 0x1 - 0x3 もそれぞれ決まっている • なので 0, 4, 8 と増えていく 22
ハフマン符号化 • 出現確率が高い文字順にデータ量が少ない符号を割り当てる 文字 回数 符号 A 3 10 B
2 110 C 1 111 D 4 0 例) AAABBCDDDD というデータを元にハフマン符号を作ると 1000001100000110000011000010100001010000111000100100010010001001000100 (80bit) →1010101101101110000 (19bit) 23