入門 HTTP ― CAMPHOR- Day 2020 / Introducing HTTP

入門 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 <html> <head> <title>Example Domain</title> ... HTTP/1.1 200 OK <html> <head> <title>... ステータスボディ 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… <html>
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 <iframe src="http://localhost:8001" /> <iframe src="http://localhost:8002" /> nginxでサーバーを2つ立てる iframeで両方を読み込む

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ヘッダーの圧縮

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コメント

入門 HTTP ― CAMPHOR- Day 2020 / Introducing HTTP

入門 HTTP ― CAMPHOR- Day 2020 / Introducing HTTP

More Decks by Honai

Other Decks in Technology

Featured

Transcript