Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hatena
October 18, 2023

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

Hatena

October 18, 2023
Tweet

More Decks by Hatena

Other Decks in Programming

Transcript

  1. HTTP
    #hatenaintern)*)+

    View full-size slide

  2. この講義では
    • ⽬的:
    Webの根幹を為すHTTPプロトコルを学び、以降の講義の理解
    を深められるようにする
    • そのために:
    • ⽤語‧知識の確認
    • RFCをベースに仕組みを理解していく

    View full-size slide

  3. この講義で取り扱うもの(順序は少し違う)
    • HTTP
    • URL
    • セマンティクス
    • 各世代のHTTPが解決したものと課題
    • TLS
    • HTTP/>, HTTP/A(QUIC)
    • 最近のネタ(時間が余ったら)

    View full-size slide

  4. HTTP
    Hypertext Transfer Protocol

    View full-size slide

  5. URL
    • Uniform Resource Locator
    • 詳細はかなり複雑:
    • 各パーツの名前は重要
    • オリジン
    ! 標準化団体周りも複雑
    WHATWG URL Living Standard
    RFC@ABC: Uniform Resource Identifier (URI): Generic Syntax

    View full-size slide

  6. URLの標準化は複雑

    View full-size slide

  7. HTTPのタイムライン
    • !""! HTTP/'.)
    • !""# HTTP/*.'
    • !""$ HTTP/!.!
    • *++" GoogleがSPDYを発表
    • *+!, GoogleがQUICを発表
    • *+!- SPDYを元にしたHTTP/*の標準化
    • *+!. HTTP-over-QUICをHTTP/,に改名
    • *+*! QUICの標準化
    • *+**/# HTTP/,の標準化

    View full-size slide

  8. HTTPのセマンティクス
    RFC %&&' HTTP Semantics
    HTTPのリクエストとレスポンスには何があるのか?
    それぞれは何を意味するのか?

    View full-size slide

  9. HTTPのセマンティクスの内容
    • メソッドとターゲット
    • ステータス
    • ヘッダー
    RFC &''( ではFieldの⼀種
    (RFC &''( Section 8)
    • ボディ
    RFC &''( ではContent
    HTTP/'.'はContentがMessage Body (RFC &''( Section F)

    View full-size slide

  10. NetcatでHTTP/+.+を話し0てみる
    ! 意味: あるプロトコルで通信する。通信プロトコルを実装している。あるプロトコルで通信可能である。同義語:
    喋る。 話す
    特に、⽣のパケットを読み取るような時にこの動詞が使われているイメージ。

    View full-size slide

  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

    View full-size slide

  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/<.<

    View full-size slide

  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 - サーバー : 選択したプロトコルを返す

    View full-size slide

  14. TLS ハンドシェイク
    1. クライアント→サーバに向けてClient
    Hello
    2. サーバ→クライアントにServer
    Hello
    3. 認証

    View full-size slide

  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や識別⼦を管理している団体

    View full-size slide

  16. おまけ:NetcatでHTTP//.1とHTTP/3./を話してみる

    View full-size slide

  17. HTTPメソッド
    GET
    POST
    PUT
    HEAD
    DELETE
    OPTIONS
    TRACE
    CONNECT
    PATCH

    View full-size slide

  18. ステータス⾏
    HTTP/1.1 000 Reason
    • 1xx Informational
    • 2xx Successful
    • 3xx Redirection
    • 4xx Client Error
    • 5xx Server Error

    View full-size slide

  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-<

    View full-size slide

  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

    View full-size slide

  21. 私的な独⾃ヘッダーの例
    curl -I https:!"mackerel.io

    View full-size slide

  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

    View full-size slide

  23. Content Negotiation Fields: ボディの圧縮
    Accept-Encoding: gzip, deflate
    Content-Encoding: gzip
    • gzip
    • compress
    • deflate
    • identity
    • br

    View full-size slide

  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は並⾏に送れない
    • 順番待ちのために他のレスポンスが遅延する

    View full-size slide

  25. HOLの例
    https://hatenablog.com

    View full-size slide

  26. RFC %&&&: HTTP Caching
    • ⽇時更新によるキャッシュ
    • Last-Modified, If-
    Modified-Since
    • Expires
    • ハッシュによるキャッシュ
    • ETag
    • 柔軟なキャッシュ
    • Cache-Control

    View full-size slide

  27. HTTP/%
    RFC %&&': HTTP/-

    View full-size slide

  28. HTTP/%
    変わらないこと
    • 基本的なセマンティクスは変わらない
    メソッドとパス、ステータス、ヘッダー、ボディのようなセマ
    ンティクスは、HTTP/F.Fと同様にRFCNFFOで定義
    • httpとhttpsの関係のようにURLを変えない

    View full-size slide

  29. HTTP/%
    通信の⾼速化のための⼯夫
    • 擬似ヘッダが導⼊される
    • バイナリでやりとりする
    • Keep-Aliveは必須
    • 単⼀TCPコネクションを仮想的に複数のストリームに分割
    • ストリームの中でフレームをやり取りする
    • ストリームの優先度や依存関係も表現できる
    • HTTPレベルのHoL Blockingの解決
    その他
    • サーバープッシュ

    View full-size slide

  30. バイナリでやりとりする
    バイナリの内容 : フレーム%
    HTTP Frame {
    Length (24),
    Type (8),
    Flags (8),
    Reserved (1),
    Stream Identifier (31),
    Frame Payload (Length),
    }
    ! RFC &''( ). HTTP Frames

    View full-size slide

  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),
    }

    View full-size slide

  32. HPACK
    RFC %&'( HPACK: Header Compression for HTTP/;
    • ハフマン符号
    • 符号化、複合化のために事前に計算してある
    • RFC <=>?: Appendix B
    • 静的テーブル
    • 62個事前定義されている
    • RFC <=>?: Appendix A
    • 動的テーブル
    • 1コネクション上で登場したHTTPヘッダーを登録する
    • インデックス番号は62から

    View full-size slide

  33. 疑似ヘッダー
    RFC %&&' (.'.&. Request Pseudo-Header Fields
    リクエスト
    • :method
    • :authority:
    • Hostの代替
    • RFC)**+ -./. Host and :authority
    • :scheme
    • :path
    レスポンス
    • :status

    View full-size slide

  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

    View full-size slide

  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),
    }

    View full-size slide

  36. HTTP/% まとめ
    • HTTP/&.&のセマンティクスを維持
    • ヘッダーも圧縮
    • ひとつのTCPコネクションを複数のストリームに分割
    • 複数のリソースを⼀度にやり取りできる
    • 複雑な制御ができる

    View full-size slide

  37. 課題: TCPレベルのHOL Blocking
    • HTTP/&はTCPセグメントロスに弱い
    • TCPセグメントロスに対してはTCPの機能で順序制御、再送制
    御される
    • 後続のTCPセグメントはロスしたセグメントの再送を待つ
    • これがフレームに影響を与える
    Head of Line Blocking - High Performance Web 789: - Qiita

    View full-size slide

  38. HTTP/%
    RFC %&&': HTTP/-

    View full-size slide

  39. HTTP/%
    • RFC &''' QUIC: A UDP-
    Based Multiplexed and
    Secure Transport
    • UDP上にTCPとTLSの機能
    を再現
    • RFC &LLM HTTP/P
    • HTTPセマンティクスを
    QUICトランスポート上で

    View full-size slide

  40. QUIC
    • RFC %&&& Version-
    Independent Properties of
    QUIC
    • RFC &''' QUIC: A UDP-
    Based Multiplexed and
    Secure Transport
    • RFC &''( Using TLS to
    Secure QUIC

    View full-size slide

  41. セキュアなQUIC
    • "-RTTハンドシェイクによる
    ⾼速化(Early Data)
    • PSK(事前共通鍵)
    • clientearlytraffic_secret
    で暗号化: 鍵の再利⽤で作
    る0-RTT⽤の鍵 RFC XYYZ:
    The Transport Layer
    Security (TLS) Protocol
    Version a.c

    View full-size slide

  42. RFC %&'( QPACK: Field Compression for HTTP/<
    • QPACK
    • 符号化など、基本はHPACKと同じ
    • 動的テーブルの扱い⽅の変更
    • HPACKのHOLブロッキングを解決
    • 静的テーブルの対応ヘッダ追加

    View full-size slide

  43. コネクションマイグレーション
    • 単⼀のネットワークパスに拘束されない
    • エンドポイントのアドレスやポートが変更されても接続を維持
    できる
    • コネクションIDを利⽤

    View full-size slide

  44. アドレスバリデーション
    • 送信元アドレスが正しいものか検証する
    • トラフィック増幅攻撃(アンプ攻撃)対策
    • 検証されていないアドレスに対しては送信データ量を制限する

    View full-size slide

  45. HTTP/%
    • UDP上にTCP+TLSを実現する
    • HTTPSによる通信が前提
    • 8-RTTによる効率化
    • NATリバインディングによるポート番号変更などが起きても接
    続が維持できる
    • アドレス検証によるアンプ攻撃対策

    View full-size slide

  46. おまけ: Reverse HTTP Transport 3
    • 提案段階の仕様
    • コネクション確⽴/TLSハン
    ドシェイクが逆向き
    • プロキシサーバーとオリジ
    ンサーバーで使う想定
    • オリジンがCDNに対して
    ! Reverse HTTP Transport
    逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

    View full-size slide

  47. おしまい

    View full-size slide