1 of 29

HTTP/3の今と将来

第71回 HTML5とか勉強会

@flano_yuki

マスコット: https://github.com/quicwg/wg-materials/blob/main/ietf103/http.pdf

2 of 29

HTTP/3の今と将来

第71回 HTML5とか勉強会

@flano_yuki

3 of 29

自己紹介

  • ゆき (@flano_yuki)
  • インフラエンジニア
  • 興味/趣味
    • Web技術
    • HTTP, QUIC, TLS, WebTransport
    • 標準化 (IETF, W3C)
  • ブログ

4 of 29

今日の参加者は？

  • フロントエンドエンジニア？
  • サーバアプリケーションエンジニア？
  • iOS, Androidアプリエンジニア?
  • ミドルウェア開発者？
  • ブラウザ開発者？CDN屋さん？プロトコルやさん？

​

�多くの人にHTTP/3の面白さをお伝えしたいです！�ネットワーク的な話もありますが�伝わるように気をつけて頑張ります！

5 of 29

HTTP/3のいま

  • 2022年 6月 HTTP/3はRFC 9114 として標準化された
  • すでに広く利用されている
    • ブラウザ: Chrome, Edge, Firefox, Safari
    • CDN/クラウド: GCP, Fastly, Cloudflare
    • 実装/ミドルウェア: 各種色々
  • おそらく、気づかないうちに皆さまもお使いになっています
    • 逆に言うと、カジュアルに有効にして利点を享受できる

Chromeのデベロッパーツール

6 of 29

https://blog.cloudflare.com/cloudflare-view-http3-usage/

7 of 29

HTTP/3について

セマンティクス, QUIC, 効率化の仕組み

8 of 29

HTTP/3とセマンティクス

HTTP/3はHTTPメッセージ(リクエスト/レスポンス)をより効率よく送信できる

  • HTTPのセマンティクス(メソッド・ヘッダステータスコード)はHTTPのバージョンで変わらない
  • HTTPメッセージをどのように送るかが�バージョンによって変わる�- HTTP/1.1: Ascii文字列�- HTTP/2: バイナリ(フレーム)�- HTTP/3: バイナリ(フレーム)

​

https://en.wikipedia.org/wiki/HTTP/3

9 of 29

=> 送受信を担うブラウザ・プロキシが対応すればその上で動くアプリケーションは意識する必要がない (URLも変わらず https://~)

ブラウザ

Webサーバ

Javascript

Web�アプリケーション

HTTP/3

HTTP/2

GETリクエスト�user-agent: hogehoge

accept-encoding: gzip, deflate

ステータス 200�set-cookie: key=value

server: web-server

10 of 29

HTTP/3とQUIC

HTTP/3は、下位層に “QUIC” というプロトコルを用いる。

QUICは2021年に標準化された新しいトランスポートプロトコル�TCPやTLSの機能を提供する

  • 必要なアプリケーションデータを届ける
    • ( 輻輳制御や再送制御、安全な切断
  • アプリケーションデータを暗号化

この新しいQUICというプロトコルを使い�HTTPメッセージのやり取りの効率を上げる

https://en.wikipedia.org/wiki/HTTP/3

11 of 29

QUIC の 名称

注意: Google QUICとIETF QUICは別物。互換性はない。�ただし、Google QUICは過去のもので、一般にIETF QUICが利用される

  • Google QUIC: HTTPの効率化を前提したアプリケーションレイヤも含むプロトコル (GCPだとQUICと言ってるがHTTP/3)
    • Quick UDP Internet Connectionsの略
  • IETF QUIC:トランスポートプロコルでHTTPに限られない
    • 「QUIC is a name, not an acronym」�

12 of 29

QUIC の 凄いところ

  • UDP上で動作する
    • TCP (通信の信頼性) + TLS(暗号化)の機能を提供する
    • (* 平文通信は行うことは出来ない
  • コネクションの確立が早い
    • 1-RTTハンドシェイク, 0-RTTハンドシェイク
  • コネクションマイグレーション
    • IP, Portが変わっても通信が切れない
  • 再送制御の効率化
  • セキュリティ関連 (アンプ攻撃対策), プライバシーへの考慮
  • ( 他にも色々

13 of 29

Head-of-Line-Blocking

  • HTTP/2では TCPのHead-of-Line-Blockingという課題があった
    • これは、パケットロスが発生した場合に、受信できている後続のパケットが待たされる現象
  • HTTP/3では、QUICを使うことで改善している
    • パケットロスが起こったとしても、受信できている後続のパケットの処理を極力進める

どういうことか見ていきましょう

HTTPでQUICを使うメリット (背景)

14 of 29

  • HTTP/2 (over TCP)では、HTTPメッセージを分割し�1つのTCPコネクション上で (並列的に) 効率よく送受信する。

Client

Server

HTTP/2の

送受信イメージ

TCP

フレーム

HTTP/2の通信の例 (背景)

画像Aのリクエスト

画像Bのリクエスト

画像Aのレスポンス

画像Bのレスポンス

* HTTP/2のメッセージはフレームと呼ばれ、一つ以上のフレームをTCPパケットに格納する

15 of 29

Client

Server

HTTP/2の場合

TCP

OS

App

OS

App

OSがパケットを回復するまで後続のパケットを処理できない

（赤の処理まで待たされる）

フレーム

データの処理順が守る

Head-of-line-blockingの例

このフレームを運ぶ�パケットがロスした

16 of 29

Client

Server

HTTP/3の場合

QUIC

OS

App

OS

App

UDPなので、Appにパケットが渡される。

青の処理はパケット再送までまつが、後続の赤の処理はできる

フレーム

Head-of-line-blockingの例

このフレームを運ぶ�パケットがロスした

届いたパケットから処理する

17 of 29

Priority

  • Webレンダリングするうえで、早く欲しいリソースとそうでないリソースがある
    • HTML, CSSは早く欲しい、画像はあとからでも(徐々に表示等もできる)
  • クライアントから欲しい順をサーバに伝える (Priority)

Client

Server

例1:

例2

リクエストヘッダで指定(rfc9218)

priorityヘッダ。例: priority = u=5, i

具体的にはリクエストヘッダで伝えられる。ブラウザがよしなにやる。�

（W3CのPriority Hintsの仕様でfetch API, DOMにfetchpriorityが付けられる?

例1: 赤と青のリソースを、同じ優先度でレスポンスしてほしい

例2: 赤を早くレスポンして欲しい

18 of 29

その他

  • QPACK ヘッダ圧縮 (RFC 9204 )
    • 事前に定義されているハフマン符号や�辞書データでHTTPヘッダ(フィールド)を圧縮する
    • HTTP/2でいうHPACKのHTTP/3版
    • （処理する順番が入れ替わっても大丈夫なように工夫されている

辞書データ(静的テーブルの例)

文字

bit表現

長さ

a

00011

5bit

q

1110110

7bit

@

1111111111010

13bit

出現頻度に合わせた�ハフマンコードの例

19 of 29

その他

  • サーバプッシュ
    • クライアントからのリクエストを待たずして�HTTPレスポンスを返す機能
    • HTTP/2同様、HTTP/3プロトコル上は機能を有しているが、実際に使うのは難しかったためChromeでは廃止
    • ステータスコード 103 Early Hintsで、早期レスポンスを返しPreloadさせる、というしくみに置き換わる

Link: <./styles.css>; rel=preload

103レスポンス

Client

Server

GET リクエスト

200レスポンス

100番台は200~500より前に追加で返せる

20 of 29

HTTP/3 (QUIC) の疎通性

  • HTTP/3 (QUIC) が疎通できなネットワークがあることが知られている
  • ブラウザは自動でHTTP/2にフォールバック。自前実装は注意

実際どれくらいなの？�というのは難しいところ

21 of 29

HTTP/3の将来

22 of 29

HTTP/3の将来

  • 近い未来
    • DNS HTTPSレコード対応
    • WebTransport
    • WebSocket over HTTP/3
    • gRPC over HTTP/3
    • QUICv2
  • 遠い未来
    • Media over QUIC (WebTransport)
    • Multipath QUIC
    • Multicast QUIC

23 of 29

DNS HTTPS レコード

今まで、HTTP/3で初めて接続する際は

  • HTTP/2で接続して、”alt-svc: h3” というレスポンスヘッダを受信すると�クライアントはサーバがHTTP/3に対応してることを知る
  • 改めてHTTP/3で通信する（次回からは最初からHTTP/3でつなぐ）

その手間なくサーバがHTTP/3に対応してることを知りたい。

�DNSレコードで取得できるようにする (HTTPS RR)

Chromeや、Safariが対応をしている

https://dns.google/query?name=google.com&rr_type=https

24 of 29

  • WebSocket的なHTTP上で双方向通信を実現する
    • サーバ・クライアント(ブラウザ)通信
    • + 再送を必要しないアプリケーションデータの送信
  • HTTP/3を利用する、フォールバック先としてHTTP/2も利用
  • 標準化
    • IETF
    • W3C
  • Chromeで実装が進められている
  • サーバ実装も幾つか

WebTransport

25 of 29

25

https://datatracker.ietf.org/meeting/106/materials/slides-106-webtrans-webtrans-bof-slides-03

(WebRTC)

26 of 29

​

  • ​

WebTransport (例)

https://www.w3.org/TR/webtransport/#examples

27 of 29

HTTP/3の将来

  • 近い未来
    • DNS HTTPSレコード対応
    • WebTransport
    • WebSocket over HTTP/3: Extend CONNECT対応必須。
    • gRPC over HTTP/3: MSが頑張ってる
    • QUICv2: そろそろ来る。ほぼ何も変わらない
  • 遠い未来
    • Media over QUIC (WebTransport)
    • Multipath QUIC
    • Multicast QUIC

28 of 29

HTTP/3の将来

  • 近い未来
    • DNS HTTPSレコード対応
    • WebTransport
    • WebSocket over HTTP/3
    • gRPC over HTTP/3
    • QUICv2
  • 遠い未来
    • Media over QUIC (WebTransport): Live動画用(Rush/Warp)
    • Multipath QUIC: MP-TCPのようにWi-FI + LTE両方使う
    • Multicast QUIC: 1:1ではなく、1:多でパケットを送信する

29 of 29

おわりに

今回のHTTP/3についての説明はまだまだほんの一部です

もっと話を聞きたい方はお気軽にお声がけください