HTTPを理解する
•
1 like•637 views
IIJ社内で行われている新人向けハンズオン勉強会「IIJ Bootcamp」で行われた "HTTP Overview" です。 HTTPの各バージョン(0.9、1.0、1.1、2、3)を紹介します。 ▼IIJ Bootcampについて IIJ Bootcampとは、様々な技術に触れることを目的としたIIJ社内で行われている新人向けハンズオン勉強会です。 https://iij.github.io/bootcamp/ 各技術が誕生した経緯・歴史、ほかの技術と比較といった知識を得るためのきっかけとして、さまざまな言語・フレームワーク・ツールに触れて実際に動かすハンズオンを行っています。 カリキュラムにはハンズオンだけでなく、「overview」として技術ジャンルの全体像や歴史などを紹介する回も設けています。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to HTTPを理解する
Similar to HTTPを理解する (20)
More from IIJ
More from IIJ (20)
HTTPを理解する
- 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 でプログラミング
- 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 がないとコネクションを継続
- 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 で持続しない
- 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
- 25. 25 HTTP/2
- 26. 26 HTTP/1.1 の問題点
- 27. 27 同期性 HTTP/1.1 は同期的なプロトコル サーバ： ある要求を処理した後、応答を返す クライアント：応答が返ってきたら、次の要求を出す Head-of-line ブロッキング ある要求への応答に時間がかかると、すべての処理が止まる
- 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による解決
- 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のフレームで分割