はてなリモートインターンシップ2023 Web, HTTP 講義資料

https://hatena.co.jp/recruit/intern/2023

Transcript

1. HTTP #hatenaintern)*)+
2. この講義では • ⽬的: Webの根幹を為すHTTPプロトコルを学び、以降の講義の理解 を深められるようにする • そのために: • ⽤語‧知識の確認 • RFCをベースに仕組みを理解していく
3. この講義で取り扱うもの（順序は少し違う） • HTTP • URL • セマンティクス • 各世代のHTTPが解決したものと課題 • TLS • HTTP/>, HTTP/A(QUIC) • 最近のネタ（時間が余ったら）
4. HTTP Hypertext Transfer Protocol
5. URL • Uniform Resource Locator • 詳細はかなり複雑: • 各パーツの名前は重要 • オリジン ! 標準化団体周りも複雑 WHATWG URL Living Standard RFC@ABC: Uniform Resource Identifier (URI): Generic Syntax
6. URLの標準化は複雑
7. HTTPのタイムライン • !""! HTTP/'.) • !""# HTTP/*.' • !""$ HTTP/!.! • *++" GoogleがSPDYを発表 • *+!, GoogleがQUICを発表 • *+!- SPDYを元にしたHTTP/*の標準化 • *+!. HTTP-over-QUICをHTTP/,に改名 • *+*! QUICの標準化 • *+**/# HTTP/,の標準化
8. HTTPのセマンティクス RFC %&&' HTTP Semantics HTTPのリクエストとレスポンスには何があるのか？ それぞれは何を意味するのか？
9. HTTPのセマンティクスの内容 • メソッドとターゲット • ステータス • ヘッダー RFC &''( ではFieldの⼀種 (RFC &''( Section 8) • ボディ RFC &''( ではContent HTTP/'.'はContentがMessage Body (RFC &''( Section F)
10. NetcatでHTTP/+.+を話し0てみる ! 意味: あるプロトコルで通信する。通信プロトコルを実装している。あるプロトコルで通信可能である。同義語: 喋る。 話す 特に、⽣のパケットを読み取るような時にこの動詞が使われているイメージ。
11. HTTPのRFCs • RFC &''(: HTTP Semantics • RFC &''': HTTP Caching • RFC &''8: HTTP/'.' • RFC &'';: HTTP/8 • RFC &''<: HTTP/; • RFC &'=;: Expect-CT Extension for HTTP • RFC &8(<: QPACK: Field Compression for HTTP/; • RFC &8(J: Building Protocols with HTTP • RFC &8(&: The Proxy-Status HTTP Response Header Field • RFC &8'': The Cache-Status HTTP Response Header Field • RFC &8';: Targeted HTTP Cache Control • RFC &8'O: Extensible Prioritization Scheme for HTTP • RFC &88(: Bootstrapping WebSockets with HTTP/; • RFC &8;(: Oblivious DNS over HTTPS 参考: HTTP 関連 RFC が⼤量に出た話と 3 ⾏まとめ | blog.jxck.io
12. HTTP/%.% • RFC &'() Hypertext Transfer Protocol -- HTTP/<.< • Obsoleted by: B&C', B&C<, B&C&, B&CC, B&CE, B&CF • RFC &(<( Hypertext Transfer Protocol -- HTTP/<.< • Obsoleted by: B&C', B&C<, B&C&, B&CC, B&CE, B&CF • RFC B&C' Hypertext Transfer Protocol (HTTP/<.<): Message Syntax and Routing • Obsoleted by: !""#, N<<& • RFC B&C< Hypertext Transfer Protocol (HTTP/<.<): Semantics and Content • Obsoleted by: !""# • RFC B&C& Hypertext Transfer Protocol (HTTP/<.<): Conditional Requests • Obsoleted by: !""# • RFC B&CC Hypertext Transfer Protocol (HTTP/<.<): Range Requests • Obsoleted by: !""# • RFC B&CE Hypertext Transfer Protocol (HTTP/<.<): Caching • Obsoleted by: N<<< • RFC B&CF Hypertext Transfer Protocol (HTTP/<.<): Authentication • Obsoleted by: !""# • RFC N<<' HTTP Semantics • RFC N<<< HTTP Caching • RFC N<<& HTTP/<.<
13. TLS RFC %&&': The Transport Layer Security (TLS) Protocol Version >.@ • 暗号化通信プロトコル • HTTPプロトコルと併せて利⽤して ⼆者間のHTTPの内容を盗聴、改竄できないようにできる • httpsスキームはTLSで通信することができる • RFC \]]^ _.a.a • ALPN • RFC de^] Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension • TLSでHTTPを含むアプリケーション層のプロトコルを選択できる • Clinet Hello(TLSの最初の通信時) - クライアント: 利⽤可能なプロトコル⼀覧を渡す • Encrypted Extensions - サーバー : 選択したプロトコルを返す
14. TLS ハンドシェイク 1. クライアント→サーバに向けてClient Hello 2. サーバ→クライアントにServer Hello 3. 認証
15. TLSで接続してHTTPリクエスト • TLSで接続してHTTPリクエスト: 実際の画⾯でご紹介 echo -e "HEAD / HTTP/1.1\r\nHost: hatenablog.com \r\n" | openssl s_client -ign_eof -connect hatenablog.com:443 • ALPNで使えるプロトコルを送りサーバーがどれを選択するのか 確認してみる echo | openssl s_client -alpn h2,http/1.1 -connect hatenablog.com:443 • http/&.&はわかるが、h.は何？ ! Internet Assigned Numbers Authority: Webに関するIDや識別⼦を管理している団体
16. おまけ：NetcatでHTTP//.1とHTTP/3./を話してみる
17. HTTPメソッド GET POST PUT HEAD DELETE OPTIONS TRACE CONNECT PATCH
18. ステータス⾏ HTTP/1.1 000 Reason • 1xx Informational • 2xx Successful • 3xx Redirection • 4xx Client Error • 5xx Server Error
19. ヘッダー • Host: HTTP/+.+ における必須ヘッダー 7 • User-Agent?@ • sec-ch-ua: クライアントヒントL • Content Negotiation Fields: RFC T++U +V.7 ! https://wicg.github.io/ua-client-hints/ ! UAの誤判定の例: 2023年7⽉10⽇にリリースされた iOS=!.?.=(a) で⼀部Webサイトが⾒られなくなった問題など （ https://support.apple.com/ja-jp/HTe=fgef ） ! 歴史的経緯でブラウザ名が書かれているわけではなく、解析が複雑 https://www.rfc-editor.org/rfc/ rfcPQQR#section-QR.Q.! ! A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. https://www.rfc-editor.org/rfc/rfc4556.html#section-;.6-<
20. 例: http://www.example.com へのブラウザからのリ クエストとレスポンスヘッダ • リクエスト GET / HTTP/1.1 Accept: text/html,application/xhtml+xml,application/ xml;q=0.9,*/*;q=0.8 Upgrade-Insecure-Requests: 1 Host: www.example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15 Accept-Language: ja Accept-Encoding: gzip, deflate Connection: keep-alive • レスポンス HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Vary: Accept-Encoding Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT Age: 573292 Content-Encoding: gzip Expires: Fri, 26 Aug 2022 02:22:20 GMT Cache-Control: max-age=604800 Date: Fri, 19 Aug 2022 02:22:20 GMT Content-Length: 648 ETag: "3147526947" Accept-Ranges: bytes Server: ECS (oxr/8315) X-Cache: HIT
21. 私的な独⾃ヘッダーの例 curl -I https:!"mackerel.io
22. Content Negotiation Fields: ボディの形式 リクエストヘッダAcceptで要求する Content-Typeのセマンティクス • Content-Type: text/html → HTML • Content-Type: application/json → JSON • Content-Type: application/x-www-form-urlencoded application/x-www-form-urlencodedの形式: key=value&another_key=another_value
23. Content Negotiation Fields: ボディの圧縮 Accept-Encoding: gzip, deflate Content-Encoding: gzip • gzip • compress • deflate • identity • br
24. Connection: keep-alive, TCP, HoL • Connection: keep-alive • 連続したリクエストのときに接続を再利⽤する • TLSを有効化しているならば、TLSも使い回す • TCP: RFC KLKM Transmission Control Protocol (TCP) • 初出は1981年: RFCabM: TRANSMISSION CONTROL PROTOCOL • 接続確⽴に1.5-RTT(1往復半)（M-way handshaking） • TLSは1~2-RTTかかるが、TCPの最後の0.5-RTTと同時に TLSの最初の通信ができる • HTTPレベルの HOL(Head-of-Line) Blocking: • keep-aliveしてもTCPã本中のHTTPは並⾏に送れない • 順番待ちのために他のレスポンスが遅延する
25. HOLの例 https://hatenablog.com
26. RFC %&&&: HTTP Caching • ⽇時更新によるキャッシュ • Last-Modified, If- Modified-Since • Expires • ハッシュによるキャッシュ • ETag • 柔軟なキャッシュ • Cache-Control
27. HTTP/% RFC %&&': HTTP/-
28. HTTP/% 変わらないこと • 基本的なセマンティクスは変わらない メソッドとパス、ステータス、ヘッダー、ボディのようなセマ ンティクスは、HTTP/F.Fと同様にRFCNFFOで定義 • httpとhttpsの関係のようにURLを変えない
29. HTTP/% 通信の⾼速化のための⼯夫 • 擬似ヘッダが導⼊される • バイナリでやりとりする • Keep-Aliveは必須 • 単⼀TCPコネクションを仮想的に複数のストリームに分割 • ストリームの中でフレームをやり取りする • ストリームの優先度や依存関係も表現できる • HTTPレベルのHoL Blockingの解決 その他 • サーバープッシュ
30. バイナリでやりとりする バイナリの内容 : フレーム% HTTP Frame { Length (24), Type (8), Flags (8), Reserved (1), Stream Identifier (31), Frame Payload (Length), } ! RFC &''( ). HTTP Frames
31. HEADERSフレーム例（type=0x01） HEADERS Frame { Length (24), Type (8) = 0x01, Unused Flags (2), PRIORITY Flag (1), Unused Flag (1), PADDED Flag (1), END_HEADERS Flag (1), Unused Flag (1), END_STREAM Flag (1), Reserved (1), Stream Identifier (31), [Pad Length (8)], [Exclusive (1)], [Stream Dependency (31)], [Weight (8)], Field Block Fragment (!"), Padding (!"2040), }
32. HPACK RFC %&'( HPACK: Header Compression for HTTP/; • ハフマン符号 • 符号化、複合化のために事前に計算してある • RFC <=>?: Appendix B • 静的テーブル • 62個事前定義されている • RFC <=>?: Appendix A • 動的テーブル • 1コネクション上で登場したHTTPヘッダーを登録する • インデックス番号は62から
33. 疑似ヘッダー RFC %&&' (.'.&. Request Pseudo-Header Fields リクエスト • :method • :authority: • Hostの代替 • RFC)**+ -./. Host and :authority • :scheme • :path レスポンス • :status
34. HPACK 静的テーブルの中⾝ Index Header Name Header Value / :authority 0 :method GET 1 :method POST 2 :path / 3 :path /index.html 4 :scheme http 5 :scheme https 6 :status 200
35. おまけ: DATAフレーム（type=0x00） DATA Frame { Length (24), Type (8) = 0x00, Unused Flags (4), PADDED Flag (1), Unused Flags (2), END_STREAM Flag (1), Reserved (1), Stream Identifier (31), [Pad Length (8)], Data (!"), Padding (!"2040), }
36. HTTP/% まとめ • HTTP/&.&のセマンティクスを維持 • ヘッダーも圧縮 • ひとつのTCPコネクションを複数のストリームに分割 • 複数のリソースを⼀度にやり取りできる • 複雑な制御ができる
37. 課題: TCPレベルのHOL Blocking • HTTP/&はTCPセグメントロスに弱い • TCPセグメントロスに対してはTCPの機能で順序制御、再送制 御される • 後続のTCPセグメントはロスしたセグメントの再送を待つ • これがフレームに影響を与える Head of Line Blocking - High Performance Web 789: - Qiita
38. HTTP/% RFC %&&': HTTP/-
39. HTTP/% • RFC &''' QUIC: A UDP- Based Multiplexed and Secure Transport • UDP上にTCPとTLSの機能 を再現 • RFC &LLM HTTP/P • HTTPセマンティクスを QUICトランスポート上で
40. QUIC • RFC %&&& Version- Independent Properties of QUIC • RFC &''' QUIC: A UDP- Based Multiplexed and Secure Transport • RFC &''( Using TLS to Secure QUIC
41. セキュアなQUIC • "-RTTハンドシェイクによる ⾼速化(Early Data) • PSK(事前共通鍵) • clientearlytraffic_secret で暗号化: 鍵の再利⽤で作 る0-RTT⽤の鍵 RFC XYYZ: The Transport Layer Security (TLS) Protocol Version a.c
42. RFC %&'( QPACK: Field Compression for HTTP/< • QPACK • 符号化など、基本はHPACKと同じ • 動的テーブルの扱い⽅の変更 • HPACKのHOLブロッキングを解決 • 静的テーブルの対応ヘッダ追加
43. コネクションマイグレーション • 単⼀のネットワークパスに拘束されない • エンドポイントのアドレスやポートが変更されても接続を維持 できる • コネクションIDを利⽤
44. アドレスバリデーション • 送信元アドレスが正しいものか検証する • トラフィック増幅攻撃(アンプ攻撃)対策 • 検証されていないアドレスに対しては送信データ量を制限する
45. HTTP/% • UDP上にTCP+TLSを実現する • HTTPSによる通信が前提 • 8-RTTによる効率化 • NATリバインディングによるポート番号変更などが起きても接 続が維持できる • アドレス検証によるアンプ攻撃対策
46. おまけ: Reverse HTTP Transport 3 • 提案段階の仕様 • コネクション確⽴/TLSハン ドシェイクが逆向き • プロキシサーバーとオリジ ンサーバーで使う想定 • オリジンがCDNに対して ! Reverse HTTP Transport 逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
47. おしまい