Successfully reported this slideshow.
Your SlideShare is downloading. ×

HTTPを理解する

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
監視 Overview
監視 Overview
Loading in …3
×

Check these out next

1 of 41 Ad

HTTPを理解する

Download to read offline

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」として技術ジャンルの全体像や歴史などを紹介する回も設けています。

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」として技術ジャンルの全体像や歴史などを紹介する回も設けています。

Advertisement
Advertisement

More Related Content

More from IIJ (20)

Recently uploaded (20)

Advertisement

HTTPを理解する

  1. 1. 1 HTTP を理解する 2022.8.1 14:00〜16:00 技術研究所 山本和彦
  2. 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. 3 おしながき HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/3
  4. 4. 4 バージョン HTTP/0.9 標準化される前のHTTP HTTP/1.0 標準化されたHTTP HTTP/1.1 IPv4アドレスが足らなくなった時代のHTTP HTTP/2 多重化されたHTTP HTTP/3 QUICを利用したHTTP
  5. 5. 5 URL http://www.iij.ad.jp/dev/ どう解釈する?
  6. 6. 6 URLの解釈 http://www.iij.ad.jp/dev/ www.iij.ad.jp の TCP 80番ポートにアクセスして /dev/ を GET
  7. 7. 7 ちなみに URL の // の部分は 失敗だと言われています
  8. 8. 8 HTTP/0.9 % gtelnet www.iij.ad.jp 80 GET /dev/↓ ワインライナー
  9. 9. 9 gtelnet がおかしくなったら? Escape character is ’^]’. Control を押しながら ] を押せ
  10. 10. 10 HTTP/1.0 % gtelnet www.iij.ad.jp 80 GET /dev/ HTTP/1.0↓ ↓ GET の最後にバージョン なぜリターンは2回必要なのか?
  11. 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. 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. 13 空行はヘッダ群の終わり
  14. 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. 15 ヘッダ ヘッダキー: ヘッダ値 メールのヘッダが参考にされた 要求ヘッダ クライアントが送るヘッダ 応答ヘッダ サーバが送るヘッダ
  16. 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. 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. 18 メソッド GET リソースの取得 HEAD リソースの状態をチェック POST リソース自体のセマンティックスに応じた処理 同じ結果にならないことがある PUT リソースの更新 何度やっても同じ結果 DELETE リソースの削除 CONNECT HTTPS (TLS)でプロキシへ接続
  19. 19. 19 メソッドとCRUD Create POST Read GET POST -- URLパラメータの2000文字制限にひっかかる場合 Update PUT Delete DELETE
  20. 20. 20 HTTP/0.9 の応答 % gtelnet www.iij.ad.jp 80 GET /dev/↓ <html> <head>Hello</head> <body>Hello</body> </html> クイズ:応答データの大きさはどうやって分かる?
  21. 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. 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. 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. 24 HTTP/1.1 でのストリーミング 応答データの大きさが、あらかじめ分からない Transfer-Encoding: chunked 7rn Mozillarn 9rn Developerrn 7rn Networkrn 0rn rn
  25. 25. 25 HTTP/2
  26. 26. 26 HTTP/1.1 の問題点
  27. 27. 27 同期性 HTTP/1.1 は同期的なプロトコル サーバ: ある要求を処理した後、応答を返す クライアント:応答が返ってきたら、次の要求を出す Head-of-line ブロッキング ある要求への応答に時間がかかると、すべての処理が止まる
  28. 28. 28 低い並列性 1つのコネクション上では高々1つの仕事 要求が1つ、応答が1つ、なにもない 要求応答パイプラインイングは事実上使われてない 同時コネクションの数はドメインごとに6つ
  29. 29. 29 ドメインシャーディング ドメインを増やして並列性を上げる コンテンツが分散し、管理が困難になる
  30. 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. 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. 32 HTTP/2による解決
  33. 33. 33 フレームの非同期性と高い並列性 高い並列性 利用されるコネクションは1つ 複数のフレームが多重化される 非同期性 準備ができた応答から返してよい
  34. 34. 34 HTTP/3
  35. 35. 35 HTTP/2 の問題点
  36. 36. 36 TCP の HoL ブロッキング
  37. 37. 37 HTTP/3 による解決
  38. 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. 39 QUICのプロトコル階層
  40. 40. 40 QUIC や QPACK がどのように HoLを解決したかは 「QUICをゆっくり解説」 を読んでください。
  41. 41. 41 最近のRFC構成 RFC9110: HTTP Semantics HTTPのバージョンに依存しないヘッダなどの意味 RFC9111: HTTP Caching RFC9112: HTTP/1.1 ヘッダはテキストそのまま 本文は、コンテンツそのままか、チャンクなど RFC9113: HTTP/2 ヘッダは HPACK を使ったバイナリ 本文はフレームで分割 RFC9114: HTTP/3 ヘッダは QPACK を使ったバイナリ 本文はQUICのフレームで分割

×