Slide 1

Slide 1 text

フロントエンドエンジニアも知っておきたい HTTP/3 で変わること フロントエンドカンファレンス沖縄 2023

Slide 2

Slide 2 text

名前: 吉田あひる (@strtyuu) 仕事: バックエンドエンジニア 所属: スターフェスティバル株式会社 自己紹介

Slide 3

Slide 3 text

HTTP/3

Slide 4

Slide 4 text

● 2022年6月に RFC 9114 として標準化された HTTP/2 に続くメジャーバー ジョン ● TCP の代わりに QUIC の上で動作する ● Q-Success によると 27%のサイトが HTTP/3 を利用している (2023年10 月時点) ○ https://w3techs.com/technologies/comparison/ce-http3 HTTP/3 とは?

Slide 5

Slide 5 text

QUIC とは? ● 2021年5月に RFC 9000 などで標準化された ● トランスポート層のプロトコルで、通信の信頼性や輻輳制御、暗号化など 様々な機能を提供する ● UDP をベースに作られているが、TCPと同じように信頼性がある

Slide 6

Slide 6 text

HTTP/2 と HTTP/3 の比較 機能 HTTP/2 HTTP/3 HTTP Semantics など HTTP/2 HTTP/3 多重化 HTTP/2 QUIC 暗号化 TLS QUIC(TLS 1.3) 信頼性/輻輳制御/etc TCP QUIC ポート番号 TCP UDP HTTP/2 の時と比べて、QUICだけで多くの仕事を担当するように

Slide 7

Slide 7 text

● TCP の Head of Line Blocking の解消 ● 接続確立までの時間の短縮 ● 優先度制御の改善 (正確には HTTP/3 から独立した機能 ● 通信経路が切り替わる時に切断されなくなる ● パケットロス時の通信が効率化 ● トランスポート層の通信も暗号化されるようになる ● 通信の暗号化が必須に ● etc HTTP/3 で何が変わるのか?

Slide 8

Slide 8 text

不安定な通信環境下での 通信速度が改善

Slide 9

Slide 9 text

HTTP/1.1 Persistent Connection HTTP/1.1 までの時代は、TCP コネ クション上で通信を直列に並べて処 理していた。

Slide 10

Slide 10 text

HTTP/2 Multiplexing 通信の多重化を行えるようにするこ とで複数の通信をまとめて行うように なり、通信効率を大きく改善

Slide 11

Slide 11 text

TCP の Head-of-Line-Blocking 問題 1/4 TCP はコネクション内でパケットの順序が割り振られて おり、送信者が送った順番でパケットを 処理する必要がある。

Slide 12

Slide 12 text

TCP の Head-of-Line-Blocking 問題 2/4 パケットロスなどが発生すると再送されるまでの間 後続のパケットを処理できなくなる

Slide 13

Slide 13 text

TCP の Head-of-Line-Blocking 問題 3/4 HTTP/2 では 複数の通信のパケットがごちゃまぜに並んでいるため同じコネクションを使って いる通信全てで順序を共有している状態 になる

Slide 14

Slide 14 text

TCP の Head-of-Line-Blocking 問題 4/4 パケットロスが発生すると 、再送されるまでのあいだ同じコネクションを使っている 他の通信 のパケットも待ちの状態 になる。

Slide 15

Slide 15 text

● 不安定な通信環境だと通信速度に悪影響がある ○ レンダリングブロックの時間の増加など ● パケットロスが多い場合、複数のコネクションを使う HTTP/1.x の方がパ フォーマンスが高い場合も TCP の Head-of-Line-Blocking の何が問題なのか?

Slide 16

Slide 16 text

QUIC による Head-of-Line-Blocking 問題の解消 QUIC ではストリーム(通信)単位で順序の保証をしているため、パケットロス が発生しても他のストリームに影響が出なくなる

Slide 17

Slide 17 text

HTTP/3 がストリーム単位で信頼性を担保できる理由 機能 HTTP/2 HTTP/3 HTTP Semantics など HTTP/2 HTTP/3 多重化 HTTP/2 QUIC 暗号化 TLS QUIC(TLS 1.3) 信頼性/輻輳制御/etc TCP QUIC ポート番号 TCP UDP HTTP/2 と違い、HTTP/3 はストリームの管理と信頼性の担保を QUIC がまとめて担当 しているため、ストリーム単位の信頼性の担保が可能になっている

Slide 18

Slide 18 text

● 不安定な通信環境の通信速度が改善 ○ 通信面のアクセシビリティが向上すると言えそう ○ 海外との通信や通信環境の悪い国へサービス提供するときとかにメ リットが大きそう HTTP/3 でどう変わるのか?

Slide 19

Slide 19 text

コネクション確立までの 時間の短縮

Slide 20

Slide 20 text

これまで(TCP + TLS) のコネクション確立 TCP と TLS それぞれでハンドシェイ クが必要な状態

Slide 21

Slide 21 text

HTTP/3 (QUIC) の コネクション確立 TLS が QUIC に内包されているた め、コネクション確立と暗号化のため のやりとりが同時に行える ように

Slide 22

Slide 22 text

● TTFB(Time To First Byte) が2~3割ほど改善する ○ https://www.publickey1.jp/blog/21/http3web_tcptlshttp2http3fast ly_1.html ○ https://tech.loveholidays.com/making-loveholidays-18-faster-with- http-3-1860879528a7 HTTP/3 でどう変わるのか?

Slide 23

Slide 23 text

HTTP/3 以外の改善

Slide 24

Slide 24 text

● サーバーがHTMLを生成している間に preload してほしいリソース情報だけ 先にレスポンスを返してしまおうというやつ ○ HTML のレスポンスよりも前にリソースの取得を始めることが可能に ● RFC 8297 にて提案中で Experimental のステータス ○ なので、ブラウザの対応状況はまだ中途半端 ○ Cloudflare など既に対応している CDN もある ● レンダリングブロックの大幅な削減が期待できる 103 Early Hints

Slide 25

Slide 25 text

● レンダリングに影響のないリソースを後回しにして、必要なやつを優先して ダウンロードするための仕組み ● 2022年6月にRFC 9218 にて標準化 ○ 元々は HTTP/3 の仕様として議論されていたが、途中で独立し HTTP/2 に対しても使 用可能に ● HTTP/2 の複雑すぎた優先度制御の代わりとなる ○ 8段階の優先順位とincrementalフラグがあるだけの単純な仕様 ● HTML の Attribute などを考慮しつつブラウザが勝手に順位づけしてくれる 模様 ○ 非アクティブになったタブのリソースは優先度下げるとかもやってくれる ● レンダリングブロックの大幅な削減が期待できる 優先度制御 - Extensible Prioritization Scheme for HTTP

Slide 26

Slide 26 text

まとめ

Slide 27

Slide 27 text

● HTTP/3 は TCP の代わりに QUIC を採用したことで様々な問題が解決され た ○ 不安定な通信環境下の速度が改善 ○ コネクション確立までの時間が短縮し TTFBが改善する ○ Wi-Fi回線からモバイル回線に切り替わるときなどに通信が継続できるように ● より通信速度を速く!というよりは通信環境が悪い人たちの体験向上という 側面が大きそう ● HTTP/3 から独立した仕様も同時に色々と標準化された ● 他にも色々と改善されているので、興味のある人は調べてみてください まとめ

Slide 28

Slide 28 text

● https://ja.wikipedia.org/wiki/HTTP/3 ● https://ja.wikipedia.org/wiki/QUIC ● https://togetter.com/li/1723153 ● https://www.publickey1.jp/blog/21/http3web_tcptlshttp2http3fastly.html ● https://vimeo.com/485450984 ● https://gihyo.jp/list/group/HTTP-3%E5%85%A5%E9%96%80#rt:/admin/serial/01/http3/0002 ● http://blog.kazuhooku.com/2019/07/http-ietf-105.html ● https://asnokaze.hatenablog.com/entry/2019/09/16/021413 ● https://asnokaze.hatenablog.com/entry/2019/11/07/020354 ● https://calendar.perfplanet.com/2022/http-3-prioritization-demystified/ ● http://blog.kazuhooku.com/2018/04/http2.html ● https://http3-explained.haxx.se/ja ● https://http2-explained.haxx.se/ja ● https://rebuild.fm/154/ ● https://developer.mozilla.org/ja/docs/Web/HTTP/Connection_management_in_HTTP_1.x ● https://eng-blog.iij.ad.jp/archives/tag/about-quic ● https://tech.loveholidays.com/making-loveholidays-18-faster-with-http-3-1860879528a7 参考資料

Slide 29

Slide 29 text

● https://developer.mozilla.org/ja/docs/Web/HTTP/Status/103 ● https://www.youtube.com/watch?v=_hfG0HCufbs ● https://web.dev/articles/fetch-priority?hl=ja ● https://blog.cloudflare.com/better-http-3-prioritization-for-a-faster-web/ ● https://blog.cloudflare.com/early-hints/ ● https://www.cloudflare.com/ja-jp/learning/ssl/what-happens-in-a-tls-handshake/ 参考資料