https://www.honai.me/slides/introducing-http/
1996年のHTTP/1.0制定から24年。Webは目まぐるしい進化を遂げましたが、それを支えた通信プロトコルであるHTTPのコンセプトは、実はあまり変わっていません。 HTTP/1.0から、現在標準化に向けて議論が進められているHTTP/3まで、どのように進化してきたのかでしょうか。 TLSやTCP/UDPなど関連する別レイヤーのプロトコルにも触れながら解説します。
入門 HTTP
View Slide
自己紹介@_honai
HTTP、使ってますか
HTTP: Hyper Text Transfer Protocolリクエストレスポンスこの画像がほしいですどうぞクライアント(スマホ、PC、サーバー)サーバー(サーバー)https://youtube.com/
HTTPの歴史← 現役！
Webアプリをつくる人にとってのHTTP
“再”入門 HTTPWebを支えるHTTPの進化を知ってほしい！
トークの内容
Host: www.example.comAccept: */*HTTPの基本要素 ― リクエストGET /index.html HTTP/1.1Host: www.example.comAccept: */*GET /index.html HTTP/1.1メソッド パスフィールド名1 値1ヘッダーフィールド名2 値2メソッドいろいろ• GET• HEAD• POST• PUT• DELETE• CONNECT• OPTIONS
HTTPの基本要素 ― レスポンスHTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Content-Length: 1256Example Domain...HTTP/1.1 200 OK...ステータスボディ500 Internal Server Error404 Not Found
HTTP/1.xTCPを使ったテキストベースのシンプルなプロトコル
HTTP/1.0 と HTTP/1.1TCPのコネクション
HTTP/1.0 と HTTP/1.1TCPのコネクションGET / HTTP/1.0TCP 03 a7 1e 3c TCP 03 a7 1e 3c TCP 03 a7 1e 3c0111 1011 11011011 0001 10011010 1010 01010000 0001 0101文字列をエンコード
HTTP/1.0 と HTTP/1.1TCPのコネクションHTTP/1.0 200 OKContent-Type: te…TCP03 a7 1e 3cTCP03 a7 1e 3cTCP03 a7 1e 3c0111 1011 11011011 0001 10011010 1010 01010000 0001 0101バイナリをデコードするとレスポンスの文字列になるテキストベースのシンプルなプロトコル
HTTP/1.x の課題 ― 毎回接続すると時間がかかる時間接続処理切断処理TCP通信は接続/切断に1RTTかかる
HTTP/1.x の課題 ― 毎回接続すると時間がかかる時間接続処理切断処理リクエスト1接続処理切断処理リクエスト2接続処理切断処理リクエスト3リクエスト毎に接続/切断するので遅い
Keep Alive時間接続処理リクエスト1リクエスト2リクエスト3TCPの接続をつなぎっぱなしにして高速化(タイムアウト等で切断)
Keep Aliveの効果を見てみましょう// nginx.confserver_1 {listen 8001;keepalive_timeout 0;}server_2 {listen 8002;keepalive_timeout 65;}// index.htmlnginxでサーバーを2つ立てるiframeで両方を読み込む
TLS と HTTP
TLS: Transport Layer SecurityTCPTLSHTTPTCPHTTPhttp:// https://
TLSとハンドシェイクTLSで通信するにはハンドシェイクが必要TLS1.2 フルハンドシェイク初回接続：2RTT（上図）、再接続：1RTTClient HelloServer HelloCertificateServer Key ExchangeClient Key ExchangeChange Cipher SpecFinishedChange Cipher SpecFinished
TLS 1.3 ― 2018年にRFC 8446として公開フルハンドシェイク: 1RTTHTTPのレイテンシ削減につながった再接続: 0RTT
HTTP/2仮想的に多重化されたバイナリベースのプロトコル
HTTP/1.x の課題 ― 輻輳制御の効率が悪い引用した図を削除しています
HTTP/1.x の課題 ― HTTP HoLブロッキングリクエストAリクエストBリクエストCHoL (Head of Line) ブロッキング待ち行列の先頭が後続を止める1つの（重い）リクエストが他のリクエストをブロックしてしまう
HTTP/2 ― バイナリベースTCP・TLSで接続FRAMEHTTP/2 Frame LayoutFRAME FRAMEFRAMEFRAMEFRAMEHTTPをフレームに分解して送受信する0 1 2 30 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 ストリーム3TCP・TLSで接続FRAME FRAME FRAMEFRAMEFRAMEFRAMEFRAMEFRAMEFRAMEFRAME FRAMEFRAMEFRAMEFRAMEFRAMEFRAME
HTTP/2 ― 輻輳制御が効率的1本のTCP接続で帯域を最大限に使える引用した図を削除しています
HTTP/2 ― HTTP HoLブロッキングを解消ストリーム1 ストリーム1ストリーム2 ストリーム2ストリーム3 ストリーム3FRAMEFRAMEFRAMEFRAME FRAMEストリームで並列化非同期
HTTP/2 ― HTTP HoLブロッキングを解消ストリーム1 ストリーム1ストリーム2 ストリーム2ストリーム3 ストリーム3FRAMEFRAMEFRAME FRAMEFRAMEストリームで並列化非同期
HTTP/2 ― HTTP HoLブロッキングを解消リクエストは他のリクエストにブロックされないストリーム1 ストリーム1ストリーム2 ストリーム2ストリーム3 ストリーム3FRAMEFRAME FRAMEFRAMEFRAMEストリームで並列化非同期
HTTP/2 ― HTTPヘッダーの圧縮
HTTP/2の課題 ― TCP HoLブロッキングTCPのパケットロス/再送がすべてのストリームをブロックしてしまうOSアプリケーション(TCPソケット)FRAMEFRAMEFRAMEFRAMEFRAMEFRAME×再送FRAMEFRAMEFRAMEFRAMEロスしたのは 青 のストリーム緑 や 橙 のストリームには関係ないがTCPの実装上、 青 が再送されるまでアプリケーションは処理できない（ブラウザ）
HTTP/2の課題 ― 接続までの時間TCPとTLSのハンドシェイクで時間がかかるTCP接続処理
HTTP/2の課題HTTPのレイヤーではどうにもならない！Google 「TCPやめて新しいプロトコル作るわ」
QUICUDPベースの多重化されたセキュアな転送プロトコル
ChromeでGoogleのサービスにアクセス
QUIC: UDPベースの多重化されたセキュアな転送プロトコルTCPTLSHTTP/2IPUDPIPHTTP/2 *独自暗号化QUICGoogle版QUIC +HTTP/2*HTTP/2* HTTP/2の機能抜粋版
なぜUDPを使うかTCP UDP通信の方向 双方向 相手に送るだけ誤り/不達の検出 できる できないデータの順序 保証される 保証されない輻輳制御 ある ないUDP 1ac508UDPを利用し、TCPよりも適したプロトコルを（ユーザー空間に）構築する機能がシンプルな代わりに、（届けば） 到達速度がはやいUDPはTCPと同じように普及しているUDP 1ac508 UDP 1ac508
QUIC: UDPベースの多重化されたセキュアな転送プロトコルFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICFRAMEUDPQUICQUICコネクションストリーム1ストリーム2ストリーム3QUICコネクションストリーム1ストリーム2ストリーム3FRAMEFRAME FRAMEFRAMEFRAMEFRAMEFRAME
QUIC ― HoLブロッキングがないパケットロスが起きても他のストリームの処理をブロックしないOSアプリケーション(UDPソケット)FRAMEFRAMEFRAMEFRAMEFRAMEFRAME×再送FRAMEFRAMEFRAMEFRAME（ブラウザ）FRAMEFRAME
QUIC ― 0-RTT最短 0-RTT でデータを送れるTCP+TLSの場合は、それぞれにハンドシェイクが必要QUICはトランスポートとセキュリティを統合したプロトコルであり、再接続の場合、真に0-RTTで暗号化されたデータを送信可能
QUIC ― Connection MigrationInternet111.333.22.1:65432111.222.33.4:67890UDPID:abcQUICUDPID:abcQUICUDPID:abc QUICコネクション コネクションID:abcQUIC ID:abcQUICID:abc QUICIPやポートが変わっても処理を継続できる
HTTP/3QUICを利用した新しいHTTP
2つのQUICUDPIPHTTP/2独自暗号化QUICGoogle版QUIC +HTTP/2IETF版QUIC +HTTP/3UDPIPHTTP/3TLSQUIC
HTTP/3 ― QUICを利用した新しいHTTPHTTP/2バイナリフォーマットヘッダー圧縮（HPACK）ストリームによる多重化サーバープッシュHTTP/3QUICバイナリフォーマットヘッダー圧縮（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-27https://tools.ietf.org/html/draft-ietf-quic-transport-27https://tools.ietf.org/html/draft-ietf-quic-tls-27https://tools.ietf.org/html/rfc7540https://hpbn.co/https://www.iij.ad.jp/dev/tech/techweek/pdf/151111_4.pdfhttps://docs.google.com/presentation/d/1OASDYIJlgSFg6hRkUjqdKfYTK1ZUk5VMGP3Iv2zQCI8最後までご視聴ありがとうございました。質問：#CAMPHOR_Day, YouTubeコメント
honai
spinscale
iwamot
kawaguti
bun913
dzeyelid
washizaki
alexanderbyndyu
matsujirushi
sinsoku
yumayabe
kadogen_0527
niryuu
roundedbygravity
smashingmag
vanstee
panda_program
sstephenson
bryan
jensimmons
rocio
paulrobertlloyd
holman
62gerente
hatefulcrawdad