入門 HTTP

自己紹介 @_honai

HTTP、使ってますか

HTTP: Hyper Text Transfer Protocol リクエスト レスポンス この画像が ほしいです どうぞ クライアント (スマホ、PC、サーバー) サーバー (サーバー) https://youtube.com/

HTTPの歴史 ← 現役！

Webアプリをつくる人にとってのHTTP

“再”入門 HTTP Webを支えるHTTPの進化を知ってほしい！

トークの内容

Host: www.example.com Accept: */* HTTPの基本要素 ― リクエスト GET /index.html HTTP/1.1 Host: www.example.com Accept: */* GET /index.html HTTP/1.1 メソッド パス フィールド名1 値1 ヘッダー フィールド名2 値2 メソッドいろいろ • GET • HEAD • POST • PUT • DELETE • CONNECT • OPTIONS

HTTPの基本要素 ― レスポンス HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 1256 Example Domain ... HTTP/1.1 200 OK ... ステータス ボディ 500 Internal Server Error 404 Not Found

HTTP/1.x TCPを使ったテキストベースのシンプルなプロトコル

HTTP/1.0 と HTTP/1.1 TCPのコネクション

HTTP/1.0 と HTTP/1.1 TCPのコネクション GET / HTTP/1.0 TCP 03 a7 1e 3c TCP 03 a7 1e 3c TCP 03 a7 1e 3c 0111 1011 1101 1011 0001 1001 1010 1010 0101 0000 0001 0101 文字列をエンコード

HTTP/1.0 と HTTP/1.1 TCPのコネクション HTTP/1.0 200 OK Content-Type: te… TCP 03 a7 1e 3c TCP 03 a7 1e 3c TCP 03 a7 1e 3c 0111 1011 1101 1011 0001 1001 1010 1010 0101 0000 0001 0101 バイナリをデコードするとレスポンスの文字列になる テキストベースのシンプルなプロトコル

HTTP/1.x の課題 ― 毎回接続すると時間がかかる 時間 接続処理 切断処理 TCP通信は接続/切断に1RTTかかる

HTTP/1.x の課題 ― 毎回接続すると時間がかかる 時間 接続処理 切断処理 リクエスト1 接続処理 切断処理 リクエスト2 接続処理 切断処理 リクエスト3 リクエスト毎に接続/切断するので遅い

Keep Alive 時間 接続処理 リクエスト1 リクエスト2 リクエスト3 TCPの接続をつなぎっぱなしにして高速化 (タイムアウト等で切断)

Keep Aliveの効果を見てみましょう // nginx.conf server_1 { listen 8001; keepalive_timeout 0; } server_2 { listen 8002; keepalive_timeout 65; } // index.html nginxでサーバーを2つ立てる iframeで両方を読み込む

No content

TLS と HTTP

TLS: Transport Layer Security TCP TLS HTTP TCP HTTP http:// https://

TLSとハンドシェイク TLSで通信するにはハンドシェイクが必要 TLS1.2 フルハンドシェイク 初回接続：2RTT（上図）、再接続：1RTT Client Hello Server Hello Certificate Server Key Exchange Client Key Exchange Change Cipher Spec Finished Change Cipher Spec Finished

TLS 1.3 ― 2018年にRFC 8446として公開 フルハンドシェイク: 1RTT HTTPのレイテンシ削減につながった 再接続: 0RTT

HTTP/2 仮想的に多重化されたバイナリベースのプロトコル

HTTP/1.x の課題 ― 輻輳制御の効率が悪い 引用した図を削除しています

HTTP/1.x の課題 ― HTTP HoLブロッキング リクエストA リクエストB リクエストC HoL (Head of Line) ブロッキング 待ち行列の先頭が後続を止める 1つの（重い）リクエストが 他のリクエストをブロックしてしまう

HTTP/2 ― バイナリベース TCP・TLSで接続 FRAME HTTP/2 Frame Layout FRAME FRAME FRAME FRAME FRAME HTTPをフレームに分解して送受信する 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 ― ストリームによる多重化 ストリームIDを振ることで 仮想的に通信路を多重化する ストリーム1 ストリーム1 ストリーム2 ストリーム2 ストリーム3 ストリーム3 TCP・TLSで接続 FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME FRAME

HTTP/2 ― 輻輳制御が効率的 1本のTCP接続で帯域を最大限に使える 引用した図を削除しています

HTTP/2 ― HTTP HoLブロッキングを解消 ストリーム1 ストリーム1 ストリーム2 ストリーム2 ストリーム3 ストリーム3 FRAME FRAME FRAME FRAME FRAME ストリームで並列化 非同期

HTTP/2 ― HTTP HoLブロッキングを解消 ストリーム1 ストリーム1 ストリーム2 ストリーム2 ストリーム3 ストリーム3 FRAME FRAME FRAME FRAME FRAME ストリームで並列化 非同期

HTTP/2 ― HTTP HoLブロッキングを解消 リクエストは他のリクエストに ブロックされない ストリーム1 ストリーム1 ストリーム2 ストリーム2 ストリーム3 ストリーム3 FRAME FRAME FRAME FRAME FRAME ストリームで並列化 非同期

HTTP/2 ― HTTPヘッダーの圧縮

HTTP/2の課題 ― TCP HoLブロッキング TCPのパケットロス/再送が すべてのストリームをブロックしてしまう OS アプリケーション (TCPソケット) FRAME FRAME FRAME FRAME FRAME FRAME × 再送 FRAME FRAME FRAME FRAME ロスしたのは 青 のストリーム 緑 や 橙 のストリームには関係ないが TCPの実装上、 青 が再送されるまで アプリケーションは処理できない （ブラウザ）

HTTP/2の課題 ― 接続までの時間 TCPとTLSのハンドシェイクで時間がかかる TCP接続処理

HTTP/2の課題 HTTPのレイヤーではどうにもならない！ Google 「TCPやめて新しいプロトコル作るわ」

QUIC UDPベースの多重化されたセキュアな転送プロトコル

ChromeでGoogleのサービスにアクセス

QUIC: UDPベースの多重化されたセキュアな転送プロトコル TCP TLS HTTP/2 IP UDP IP HTTP/2 * 独自 暗号化 QUIC Google版QUIC + HTTP/2* HTTP/2 * HTTP/2の機能抜粋版

なぜUDPを使うか TCP UDP 通信の方向 双方向 相手に送るだけ 誤り/不達の検出 できる できない データの順序 保証される 保証されない 輻輳制御 ある ない UDP 1ac508 UDPを利用し、TCPよりも適したプロトコルを （ユーザー空間に）構築する 機能がシンプルな代わりに、（届けば） 到達速度がはやい UDPはTCPと同じように普及している UDP 1ac508 UDP 1ac508

QUIC: UDPベースの多重化されたセキュアな転送プロトコル FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC FRAME UDP QUIC QUIC コネクション ストリーム1 ストリーム2 ストリーム3 QUIC コネクション ストリーム1 ストリーム2 ストリーム3 FRAME FRAME FRAME FRAME FRAME FRAME FRAME

QUIC ― HoLブロッキングがない パケットロスが起きても 他のストリームの処理をブロックしない OS アプリケーション (UDPソケット) FRAME FRAME FRAME FRAME FRAME FRAME × 再送 FRAME FRAME FRAME FRAME （ブラウザ） FRAME FRAME

QUIC ― 0-RTT 最短 0-RTT でデータを送れる TCP+TLSの場合は、それぞれにハンドシェイクが必要 QUICはトランスポートとセキュリティを統合したプロトコルであり、 再接続の場合、真に0-RTTで暗号化されたデータを送信可能

QUIC ― Connection Migration Internet 111.333.22.1:65432 111.222.33.4:67890 UDP ID:abc QUIC UDP ID:abc QUIC UDP ID:abc QUIC コネクション コネクション ID:abc QUIC ID:abc QUIC ID:abc QUIC IPやポートが変わっても処理を継続できる

HTTP/3 QUICを利用した新しいHTTP

2つのQUIC UDP IP HTTP/2 独自 暗号化 QUIC Google版QUIC + HTTP/2 IETF版QUIC + HTTP/3 UDP IP HTTP/3 TLS QUIC

HTTP/3 ― QUICを利用した新しいHTTP HTTP/2 バイナリフォーマット ヘッダー圧縮（HPACK） ストリームによる多重化 サーバープッシュ HTTP/3 QUIC バイナリフォーマット ヘッダー圧縮（QPACK） サーバープッシュ ストリームによる多重化 暗号化、輻輳制御、その他 HTTP/2からQUICと重複する機能を除いたもの QUICとともにIETFで議論が進んでいる

まとめ

HTTPの歴史（再掲） 20年以上Webを支えているHTTP/1.1（もちろん現役） HTTPのセマンティックは1.x系から変わっていない

HTTPの進化は「水面下」で Webを支えるHTTPのこれからに注目！

参考資料 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 最後までご視聴ありがとうございました。 質問：#CAMPHOR_Day, YouTubeコメント