HTTPを理解する

1. 1 HTTP を理解する 2022.8.1 14:00〜16:00 技術研究所山本和彦

2. 2 自己紹介山本和彦 IIJ 技術研究所プロトコルを実装して検証し標準化に貢献するメール、迷惑メール対策、DNS、HTTP/1.1、HTTP/2、TLS 1.3、 QUIC、HTTP/3 IIJエンジニアブログ「QUICをゆっくり解説」 Internet Infrastructure Review（IIR）Vol.52 「HaskellによるQUICの実装」ほとんど Haskell でプログラミング

3. 3 おしながき HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/3

4. 4 バージョン HTTP/0.9 標準化される前のHTTP HTTP/1.0 標準化されたHTTP HTTP/1.1 IPv4アドレスが足らなくなった時代のHTTP HTTP/2 多重化されたHTTP HTTP/3 QUICを利用したHTTP

5. 5 URL http://www.iij.ad.jp/dev/ どう解釈する？

6. 6 URLの解釈 http://www.iij.ad.jp/dev/ www.iij.ad.jp の TCP 80番ポートにアクセスして /dev/ を GET

7. 7 ちなみに URL の // の部分は失敗だと言われています

8. 8 HTTP/0.9 % gtelnet www.iij.ad.jp 80 GET /dev/↓ ワインライナー

9. 9 gtelnet がおかしくなったら？ Escape character is ’^]’. Control を押しながら ] を押せ

10. 10 HTTP/1.0 % gtelnet www.iij.ad.jp 80 GET /dev/ HTTP/1.0↓ ↓ GET の最後にバージョンなぜリターンは2回必要なのか？

11. 11 RFC Request For Comments インターネットのプロトコルを定める仕様書仕様書なのに「コメントください」とは？ HTTP/1.0 RFC 1945 (1996) HTTP/1.1 RFC 2068 (1997) RFC 2616 (1999) RFC 7230, 7231, 7232, 7233, 7234, 7235 (2014) RFC 9112 (2022)

12. 12 RFC 1945 HTTP-message = Simple-Request ; HTTP/0.9 messages | Full-Request ; HTTP/1.0 messages Simple-Request = "GET" SP Request-URI CRLF Full-Request = Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ] Request-Line = Method SP Request-URI SP HTTP-Version CRLF

13. 13 空行はヘッダ群の終わり

14. 14 HTTP/1.1 % gtelnet www.iij.ad.jp 80 GET /dev/ HTTP/1.1↓ Host: www.iij.ad.jp↓ Connection: close↓ ↓ Host: ヘッダが必須 Connection: close がないとコネクションを継続

15. 15 ヘッダヘッダキー：ヘッダ値メールのヘッダが参考にされた要求ヘッダクライアントが送るヘッダ応答ヘッダサーバが送るヘッダ

16. 16 要求ヘッダ Accept-Charset Host If-Modified-Since Referer Referrer ではない User-Agent Connection 例 Host: www.w3.org Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Referer: http://www.example.org/Overview.html

17. 17 HTTP/1.0 と HTTP/1.1 の違い Host: ヘッダ HTTP/1.1 で必須 1つのIPv4アドレスで、複数のドメインをホストサーバにドメイン名を教える役目 Connection: ヘッダ HTTP/1.0 のコネクションはデフォルトでは持続しない Connection: Keep-Alive で持続 HTTP/1.1 のコネクションはデフォルトで持続する Connection: close で持続しない

18. 18 メソッド GET リソースの取得 HEAD リソースの状態をチェック POST リソース自体のセマンティックスに応じた処理同じ結果にならないことがある PUT リソースの更新何度やっても同じ結果 DELETE リソースの削除 CONNECT HTTPS (TLS)でプロキシへ接続

19. 19 メソッドとCRUD Create POST Read GET POST -- URLパラメータの2000文字制限にひっかかる場合 Update PUT Delete DELETE

20. 20 HTTP/0.9 の応答 % gtelnet www.iij.ad.jp 80 GET /dev/↓ <html> <head>Hello</head> <body>Hello</body> </html> クイズ：応答データの大きさはどうやって分かる？

21. 21 HTTP/1.1 の応答 % gtelnet www.iij.ad.jp 80 GET /dev/ HTTP/1.1↓ Host: www.iij.ad.jp↓ ↓ HTTP/1.0 301 Moved Permanently Date: Thu, 29 Jul 2021 05:34:21 GMT Content-Length: 217 Content-Type: text/html; charset=iso-8859-1 ↓ <html><head> ... <<<コネクションは継続>>> クイズ：応答データの大きさはどうやって分かる？

22. 22 応答ステータス 1xx -- 情報 100 Continue 2xx -- 成功 200 OK 201 Created 206 Partial Content 3xx -- 向け直し 301 Moved Permanently 4xx -- クライアントエラー 400 Bad Request 404 Not Found 405 Method Not Allowed 5xx -- サーバーエラー 500 Internal Server Error

23. 23 応答ヘッダ Server Last-Modified Content-Length Content-Encoding Content-Range Content-Type Date 例 HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif

24. 24 HTTP/1.1 でのストリーミング応答データの大きさが、あらかじめ分からない Transfer-Encoding: chunked 7rn Mozillarn 9rn Developerrn 7rn Networkrn 0rn rn

25. 25 HTTP/2

26. 26 HTTP/1.1 の問題点

27. 27 同期性 HTTP/1.1 は同期的なプロトコルサーバ：ある要求を処理した後、応答を返すクライアント：応答が返ってきたら、次の要求を出す Head-of-line ブロッキングある要求への応答に時間がかかると、すべての処理が止まる

28. 28 低い並列性 1つのコネクション上では高々1つの仕事要求が1つ、応答が1つ、なにもない要求応答パイプラインイングは事実上使われてない同時コネクションの数はドメインごとに6つ

29. 29 ドメインシャーディングドメインを増やして並列性を上げるコンテンツが分散し、管理が困難になる

30. 30 非効率なヘッダ帯域の浪費要求ヘッダの長さの平均は800バイト似通った要求ヘッダが毎回送られる GET /roversync/ HTTP/1.1 Host: rover.ebay.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Referer: http://www.ebay.com/ Cookie: ebay=%5Esbf%3D%23%5E; dp1=bpbf/%2380000000000055 276504d^u1p/QEBfX0BAX19AQA**5276504d^; cssg=c67883f113a 0a56964e646c6ffaa1abe; s=CgAD4ACBQlm5NYzY3ODgzZjExM2EwY TU2OTY0ZTY0NmM2ZmZhYTFhYmUBSgAYUJZuTTUwOTUxY2NkLjAuMS4z LjE1MS4zLjAuMeN+7JE*; nonsession=CgAFMABhSdlBNNTA5NTFjY 2QuMC4xLjEuMTQ5LjMuMC4xAMoAIFn7Hk1jNjc4ODNmMTEzYTBhNTY5 NjRlNjQ2YzZmZmFhMWFjMQDLAAFQlSPVMX8u5Z8*

31. 31 HTTP/2 2012年9月からIETFで標準化がスタート 4つの提案の中からGoogleのSPDYがベースに選ばれた 3年間の議論 2015年5月にRFCになった RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2) RFC 7541: HPACK: Header Compression for HTTP/2 2022年に改訂 RFC 9113: HTTP/2 特徴 HTTP ヘッダなどの意味は変わらないトランスポートのみが変更され効率的になった

32. 32 HTTP/2による解決

33. 33 フレームの非同期性と高い並列性高い並列性利用されるコネクションは1つ複数のフレームが多重化される非同期性準備ができた応答から返してよい

34. 34 HTTP/3

35. 35 HTTP/2 の問題点

36. 36 TCP の HoL ブロッキング

37. 37 HTTP/3 による解決

38. 38 QUIC 2016年6月からIETF で標準化がスタート Google の QUIC がベース 5年間の議論 2021年5月にRFCになった RFC 8999: Version-Independent Properties of QUIC RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport RFC 9001: Using TLS to Secure QUIC RFC 9002: QUIC Loss Detection and Congestion Control HTTP/3 RFC 9114: HTTP/3 RFC 9204: QPACK: Field Compression for HTTP/3

39. 39 QUICのプロトコル階層

40. 40 QUIC や QPACK がどのように HoLを解決したかは「QUICをゆっくり解説」を読んでください。

41. 41 最近のRFC構成 RFC9110: HTTP Semantics HTTPのバージョンに依存しないヘッダなどの意味 RFC9111: HTTP Caching RFC9112: HTTP/1.1 ヘッダはテキストそのまま本文は、コンテンツそのままか、チャンクなど RFC9113: HTTP/2 ヘッダは HPACK を使ったバイナリ本文はフレームで分割 RFC9114: HTTP/3 ヘッダは QPACK を使ったバイナリ本文はQUICのフレームで分割

HTTPを理解する

You are reading a preview.

Check these out next

HTTPを理解する

More Related Content

More from IIJ (20)

Recently uploaded (20)