honai.me / slides

入門 HTTP

埋め込みコード (iframe)

入門 HTTP のスクリプト

  1. 入門 HTTP
  2. 自己紹介 @_honai
  3. HTTP、使ってますか
  4. HTTP: Hyper T ext ransfer Protocol この画像が ほしいです リクエスト レスポンス どうぞ クライアント サーバー (スマホ、PC、サーバー) (サーバー) https://youtube.com/
  5. HTTPの歴史 ← 現役！
  6. Webアプリをつくる人にとってのHTTP
  7. “再”入門 HTTP Webを支えるHTTPの進化を知ってほしい！
  8. トークの内容
  9. HTTPの基本要素 ― リクエスト GET /index.html HTTP/1.1 メソッドいろいろ Host: www.example.com • GET Accept: */* • HEAD • POST • PUT • DELETE GET /index.html HTTP/1.1 • CONNECT メソッド パス • OPTIONS Host: www.example.com フィールド名1 値1 Accept: */* ヘッダー フィールド名2 値2
  10. HTTPの基本要素 ― レスポンス HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 1256 <html> <head> <title>Example Domain</title> 500 Internal Server Error ... HTTP/1.1 200 OK ステータス <html> 404 Not Found <head> ボディ <title>...
  11. HTTP/1.x TCPを使ったテキストベースのシンプルなプロトコル
  12. HTTP/1.0 と HTTP/1.1 TCPのコネクション
  13. HTTP/1.0 と HTTP/1.1 TCP 03 a7 1e TCP 03 a7 1e TCP 03 a7 1e 3c TCPのコネクション 0111 1011 1101 1011 0001 1001 1010 1010 0101 0000 0001 0101 文字列をエンコード GET / HTTP/1.0
  14. HTTP/1.0 と HTTP/1.1 TCPのコネクション 03 a7 1eTCP 03 a7 1eTCP 03 a7 1TCPc 0111 1011 1101 1011 0001 1001 1010 1010 0101 0000 0001 0101 バイナリをデコードするとレスポンスの文字列になる HTTP/1.0 200 OK Content-Type: te… <html> テキストベースのシンプルなプロトコル
  15. HTTP/1.x の課題 ― 毎回接続すると時間がかかる 時間 接続処理 切断処理 TCP通信は接続/切断に1RTTかかる
  16. HTTP/1.x の課題 ― 毎回接続すると時間がかかる 時間 接続処理 リクエスト1 切断処理 接続処理 リクエスト2 切断処理 接続処理 リクエスト3 切断処理 リクエスト毎に接続/切断するので遅い
  17. Keep Alive 時間 接続処理 リクエスト1 リクエスト2 リクエスト3 (タイムアウト等で切断) TCPの接続をつなぎっぱなしにして高速化
  18. Keep Aliveの効果を見てみましょう // nginx.conf nginxでサーバーを2つ立てる server_1 { listen 8001; keepalive_timeout 0; } server_2 { listen 8002; keepalive_timeout 65; } iframeで両方を読み込む // index.html <iframe src="http://localhost:8001" /> <iframe src="http://localhost:8002" />
  20. TLS と HTTP
  21. TLS: T ransport Layer Security HTTP HTTP TLS TCP TCP http:// https://
  22. TLSとハンドシェイク TLS1.2 フルハンドシェイク Client Hello Server Hello Certificate Server Key Exchange Client Key Exchange Change Cipher Spec Finished Change Cipher Spec Finished 初回接続：2RTT（上図）、再接続：1RTT TLSで通信するにはハンドシェイクが必要
  23. TLS 1.3 ― 2018年にRFC 8446として公開 フルハンドシェイク: 1RTT 再接続: 0RTT HTTPのレイテンシ削減につながった
  24. HTTP/2 仮想的に多重化されたバイナリベースのプロトコル
  25. HTTP/1.x の課題 ― 輻輳制御の効率が悪い 引用した図を削除しています
  26. HTTP/1.x の課題 ― HTTP HoLブロッキング HoL (Head of Line) ブロッキング 待ち行列の先頭が後続を止める リクエストA リクエストB リクエストC 1つの（重い）リクエストが 他のリクエストをブロックしてしまう
  27. HTTP/2 ― バイナリベース FRAME FRAME FRAME TCP・TLSで接続 FRAME FRAME FRAME 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+ HTTP/2 Frame Layout HTTPをフレームに分解して送受信する
  28. HTTP/2 ― ストリームによる多重化 FRAME FRAME FRAME FRAME TCP・TLSで接続 FRAME FRAME FRAME FRAME ストリーム1 FRAME FRAME ストリーム1 FRAME ストリーム2 FRAME ストリーム2 FRAME FRAME ストリーム3 FRAME FRAME ストリーム3 ストリームIDを振ることで 仮想的に通信路を多重化する
  29. HTTP/2 ― 輻輳制御が効率的 引用した図を削除しています 1本のTCP接続で帯域を最大限に使える
  30. HTTP/2 ― HTTP HoLブロッキングを解消 ストリームで並列化 非同期 ストリーム1 ストリーム1 FRAMEFRAME FRAME ストリーム2 FRAME ストリーム2 ストリーム3 FRAME ストリーム3
  31. HTTP/2 ― HTTP HoLブロッキングを解消 ストリームで並列化 非同期 ストリーム1 ストリーム1 FRAMEFRAME FRAME ストリーム2 FRAME ストリーム2 ストリーム3 FRAME ストリーム3
  32. HTTP/2 ― HTTP HoLブロッキングを解消 ストリームで並列化 非同期 ストリーム1 FRAMEFRAME ストリーム1 FRAME ストリーム2 FRAME ストリーム2 ストリーム3 ストリーム3 FRAME リクエストは他のリクエストに ブロックされない
  33. HTTP/2 ― HTTPヘッダーの圧縮
  34. HTTP/2の課題 ― TCP HoLブロッキング アプリケーション OS （ブラウザ） (TCPソケット) FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME × FRAME FRAME ロスしたのは 青 のストリーム 再送 緑 や橙 のストリームには関係ないが TCPの実装上、青 が再送されるまで アプリケーションは処理できない TCPのパケットロス/再送が すべてのストリームをブロックしてしまう
  35. HTTP/2の課題 ― 接続までの時間 TCP接続処理 TCPとTLSのハンドシェイクで時間がかかる
  36. HTTP/2の課題 HTTPのレイヤーではどうにもならない！ Google 「TCPやめて新しいプロトコル作るわ」
  37. QUIC UDPベースの多重化されたセキュアな転送プロトコル
  38. ChromeでGoogleのサービスにアクセス
  39. QUIC: UDPベースの多重化されたセキュアな転送プロトコル HTTP/2 HTTP/2 * TLS QUIC 暗号化 TCP UDP IP IP HTTP/2 Google版QUIC + HTTP/2* * HTTP/2の機能抜粋版
  40. なぜUDPを使うか UDPacUDPacUDPac508 TCP UDP 通信の方向 双方向 相手に送るだけ 誤り/不達の検出 できる できない データの順序 保証される 保証されない 輻輳制御 ある ない 機能がシンプルな代わりに、（届けば） 到達速度がはやい UDPはTCPと同じよう普及している UDPを利用し、TCPよりも適したプロトコルを （ユーザー空間に）構築する
  41. QUIC: UDPベースの多重化されたセキュアな転送プロトコル FRAME FRAME FRAME FRAME QUIC QUIC QUIC QUIC UDP UDP UDP UDP FRAME FRAME FRAME FRAME QUIC QUIC QUIC QUIC UDP UDP UDP UDP QUIC QUIC コネクション コネクション FRAME ストリーム1 ストリーム1 FRAME FRAME FRAME ストリーム2 ストリーム2 FRAME FRAME ストリーム3 FRAME ストリーム3
  42. QUIC ― HoLブロッキングがない アプリケーション OS （ブラウザ） (UDPソケット) FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME × FRAME FRAME FRAME FRAME 再送 パケットロスが起きても 他のストリームの処理をブロックしない
  43. QUIC ― 0-RTT TCP+TLSの場合は、それぞれにハンドシェイクが必要 QUICはトランスポートとセキュリティを統合したプロトコルであり、 再接続の場合、真に0-RTTで暗号化されたデータを送信可能 最短 0-RTT でデータを送れる
  44. QUIC ― Connection Migration QUIC ID:abc UDP ID:abc QUIC 111.333.22.1:65432 UDP Internet QUIC ID:abc UDP 111.222.33.4:67890 QUIC ID:abc QUIC ID:abc コネクション コネクション ID:abc QUIC IPやポートが変わっても処理を継続できる
  45. HTTP/3 QUICを利用した新しいHTTP
  46. 2つのQUIC HTTP/3 HTTP/2 独自 QUIC 暗号化 QUIC TLS UDP UDP IP IP Google版QUIC + IETF版QUIC + HTTP/2 HTTP/3
  47. HTTP/3 ― QUICを利用した新しいHTTP HTTP/2 HTTP/3 バイナリフォーマット バイナリフォーマット ヘッダー圧縮（HPACK） ヘッダー圧縮（QPACK） サーバープッシュ サーバープッシュ ストリームによる多重化 QUIC ストリームによる多重化 暗号化、輻輳制御、その他 HTTP/2からQUICと重複する機能を除いたもの QUICとともにIETFで議論が進んでいる
  48. まとめ
  49. HTTPの歴史（再掲） 20年以上Webを支えているHTTP/1.1（もちろん現役） HTTPのセマンティックは1.x系から変わっていない
  50. HTTPの進化は「水面下」で Webを支えるHTTPのこれからに注目！
  51. 最後までご視聴ありがとうございました。 参考資料 質問：#CAMPHOR_Day, YouTubeコメント https://tools.ietf.org/html/draft-ietf-quic-http-27 https://tools.ietf.org/html/draft-ietf-quic-transport-27 https://tools.ietf.org/html/draft-ietf-quic-tls-27 https://tools.ietf.org/html/rfc7540 https://hpbn.co/ https://www.iij.ad.jp/dev/tech/techweek/pdf/151111_4.pdf https://docs.google.com/presentation/d/1OASDYIJlgSFg6hRkUjqdKfYTK1ZUk5VMGP3Iv2zQCI8