Tweet
Tweet

Slide 1

Slide 1 text

Webを速くする技術(HTTP編) HTTP/1.1→ HTTP/2 → QUIC @utushiiro

Slide 2

Slide 2 text

▷ Table of contents ○ HTTPとは ○ HTTP 1.1 ■ Keep-Alive ■ Pipelining ○ プロトコル以外の部分での高速化 ○ SPDY ○ HTTP 2 ○ QUIC

Slide 3

Slide 3 text

Hyper Text Transfer Protocol リソース(ファイル)の送受信に用いられる 通信プロトコル トランスポート層のプロトコルとしてはTCPを利用 主に Webブラウザ ⇔ Webサーバ GET index.html 1.1 ... 1.1 200 OK ...

Slide 4

Slide 4 text

▷ 1991年 HTTP/0.9 ▷ 1996年 HTTP/1.0 RFC 1945 ▷ 1999年 HTTP/1.1 RFC 2068 ▷ 2015年 HTTP/2 RFC 7045 HTTPの変遷

Slide 5

Slide 5 text

１つのリソースの取得毎に コネクションを確立する オーバーヘッド大きい HTTP/1.0までの問題点 HTTP Request HTTP Response コネクション確立処理 コネクション切断処理 HTTP Request HTTP Response

Slide 6

Slide 6 text

Keep-Alive (HTTP/1.1) リソースの取得毎にコネクションを確立する → オーバーヘッド大きい 複数のリソース取得のためにコネクションを 維持しておく仕組みとしてKeep-Aliveが実装 HTTP HeaderのConnectionヘッダを利用する 基本的に使われている機能

Slide 7

Slide 7 text

Keep-Alive (HTTP/1.1) HTTP Request HTTP Response HTTP Request HTTP Response 一連のリクエストの 最初と最後だけ

Slide 8

Slide 8 text

HTTP/1.1までの制約 1つのリクエストが完了(レスポンスを処理) するまで 原則次のリクエストを送れない つまり, 先頭が詰まると後続が止まってしまう これは HTTPのHead of Line Blockingと呼ばれる 以後 Head of Line Blocking → HoL Blocking

Slide 9

Slide 9 text

パケットロス HTTP/1.1までの制約 HTTP Request 1 HTTP Response 1 HTTP Request 2 やっと２個目を送れる 遅延

Slide 10

Slide 10 text

Pipelining (HTTP/1.1) 1つのリクエストが完了(レスポンスを処理) するまで 原則次のリクエストを送れない レスポンスを待たずにリクエストを送信する 仕組みとしてPipeliningが実装 ※これはリクエストを一つのコネクションで 　複数送信することを想定しているため 　Keep-Aliveが必要になる

Slide 11

Slide 11 text

Pipelining (HTTP/1.1) HTTP Request 1 HTTP Response 1 HTTP Request 2 HTTP Request 3 HTTP Response 2 HTTP Response 3

Slide 12

Slide 12 text

Pipelining (HTTP/1.1) ただし, クライアントからのリクエストの順序と サーバからのレスポンスの順序は 同期している必要がある なので, 結局先頭が詰まると後続も詰まる 大抵のブラウザでは使われていない機能

Slide 13

Slide 13 text

プロトコル以外の部分での高速化 ▷ CSSスプライト ▷ 画像のインライン化 ▷ Domain Sharding (後述) などなど 上記の手法のように プロトコル以外の部分で高速化を行っていた

Slide 14

Slide 14 text

Domain Sharding ブラウザは先述したHead of Line Blocking等 の影響を 小さくするために, 1ドメインに対して同時に複数のコネク ションを貼っている Domain Shardingはリソースを複数のドメインに分散させ て更に同時接続数を増やす方法 ※ 画像を別ドメインにするサイトが多いが 　 理由としてはこれ↑とセキュリティ向上 　

Slide 15

Slide 15 text

Webコンテンツのリッチ化 1999年にHTTP1.1仕様化されて10年 Webではコンテンツの容量が劇的に増加 Contents Delivery Network (CDN)の導入や 通信環境の改善はあるのものの (利用者が増えたこともあり)表示速度等が問題に Webの表示を高速化するにはどうすれば良いか？

Slide 16

Slide 16 text

Webコンテンツのリッチ化 ネットワークの回線帯域を増加させても 一定値を超えるとあまり速くならない コンテンツのデータをやり取りする際の サーバ・ホスト間やり取りの多さ(= RTT ✕ 回数)が 大きな影響を与えている 通信環境を改善するよりも プロトコルレベルでの改善が必要に

Slide 17

Slide 17 text

SPDY プロトコルレベルの改善としてGoogleが SPDY(スピーディー)を提唱 TLSの上にセッション層を追加する(置き換える) TLSの拡張仕様 Next Protocol Negotiation(※)を 利用するためHTTPSが必要 ※現在(HTTP2.0)では 　Application Layer Protocol Negotiation(ALPN) 詳細は省きます

Slide 18

Slide 18 text

HTTP/2 SPDYをベースにHTTP/2が策定(RFC 7540) 1. 優先度付全二重多重化通信 2. プロトコルのバイナリベース化 3. HTTPヘッダーの圧縮 4. フロー制御 1, 2, 3については後述. 4では主にHTTPのレイヤで, TCPのフロー制御の様なこ とをやるための枠組み(window size 制御)を仕様化して いる.

Slide 19

Slide 19 text

優先度付全二重多重化通信 (HTTP/2) まず 多重化 について, 1つのコネクションの上にストリーム(※)を 作って通信を行う このストリームは複数並列に扱えるため 前述したHead of Line Blocking問題を解消する ※従来のRequest/Responseで行われる 　一連のやり取りを行う仮想的な通信路

Slide 20

Slide 20 text

優先度付全二重多重化通信 (HTTP/2) それぞれ独立・並列 ストリーム 確立したコネクション

Slide 21

Slide 21 text

コネクションを使いまわすメリット Keep-alive や HTTP/2 のストリームは 一つのコネクション使いまわす 3 way handshake のオーバヘッドだけでなく スロースタート等によるwindow sizeの調整に かかる時間のオーバヘッドも減らせる. また, 複数のコネクションを立てるのに比べて 効率的な輻輳制御が行われる(※). ※ 従来の複数では輻輳制御がそれぞれ独立して 　 行われるため, 帯域を効率的に使うのが難しい

Slide 22

Slide 22 text

優先度付全二重多重化通信 (HTTP/2) 次に 優先度 について, レンダリングする際にコンテンツの優先度を定めることに より, より効率的な配信を行う 従来はコードの配置場所を調整したりして ロードの順序を操作していた( jsの位置とか) ※ただし, あくまで指標程度であり 　必ずその順序になるとは限らない

Slide 23

Slide 23 text

優先度付全二重多重化通信 (HTTP/2) 次に 多重化 について, クライアント/サーバのどちらからも(※)ストリームを確立で き, いわゆるサーバプッシュができる ※従来はクライアントからのリクエストでないと 　セッションを開始できなかった 後に必要になるデータを予めキャッシュさせておく などの使用法がある

Slide 24

Slide 24 text

プロトコルのバイナリベース化 HTTP/1.1まではHTTPはテキストベース テキストベースだと ▷ 容量が大きい ▷ パースが煩雑 フレームと呼ばれるバイナリ形式のフォーマットを 採用して, 従来のRequest/Response, Header等は すべてのこのフレームにマッピングされる

Slide 25

Slide 25 text

HTTPヘッダの圧縮 HTTP/1.1の頃は高速化の一つの手法として コンテンツデータの圧縮があった HTTP/2.0では, HTTPヘッダ部分を圧縮できる & 一度送信したヘッダは基本的に再度送信しなくて済む ようになっている(差分のみ送信) 現在ではHTTPヘッダで付加する情報が多いため これによる恩恵は大きい

Slide 26

Slide 26 text

HTTPヘッダの圧縮 SPDYの頃はデータと同様にGzip等で圧縮していたが CRIMEと呼ばれる脆弱性が発見された これはTLSで暗号化された通信上でも 圧縮されたヘッダデータを解読する手法(参考) そこでHTTP/2ではよりセキュアな圧縮方式としてHPACK が作られた(RFC 7541) ただし, 完全にCRIMEを防げるわけではない

Slide 27

Slide 27 text

TCPのHead of Line Blocking HTTP/2ではHTTPのHoL Blockingを防げる しかし, TCPのHoL Blockingは防げない ▷ TCPのHoL Blockingとは TCPでは先頭のパケットがロスすると 後続のパケットを処理することができない また, HTTP/2は1本のコネクション上で多重化する分 複数使っていた頃よりこれの影響が大きい恐れがある

Slide 28

Slide 28 text

QUIC 先述したTCP HoL Blockingの様な トランスポート層のプロトコルレベル(TCP)の 問題等を解決し, より効率的な通信を行うために GoogleのチームがUDPベースの新たなWeb向けのプ ロトコルを作成 Quick UDP Internet Connections (QUIC)

Slide 29

Slide 29 text

なぜUDPベース？ 長期的な目標はTCPやTLSの改善 しかし, TCP/TLSの改良(提案, 実装, 検証 … etc)には 時間がかかる UDPで理論を実践した後に, 有効な機能をTCP/TLSの 後続バージョンにフィードバックする (もちろん)UDPを用いるので先述した TCPのHoL Blockingは起きない(ようになってる)

Slide 30

Slide 30 text

QUICでやろうとしていること ▷ TCPやTLSの処理の効率化 ○ 接続の確立時に必要なRTTを減らす (TFOやTLS False Startと同じ考え) ▷ パケット損失の影響を低減 ○ パケットレベルの前方誤り訂正 ○ 暗号化のブロックやパケットの境界を整理 ▷ 再接続(接続の維持)の簡易化 ○ 後述

Slide 31

Slide 31 text

再接続(接続の維持)の簡易化 モバイル端末ではWiFiとLTE(3G)を切り替えが起きえる が, この際に安定した接続を維持するのが難しい QUICでは接続を独自の識別子 Connection UUIDを 使用して, 回線の切り替えの際にも維持することで 以前の接続を引き継ぐ(再接続処理を簡易化) TCPだとIP & portの4つ組で識別するので どれか変わるとが接続が切れる ( IP & portがそのまま識別子なので 同じようなことを同じレイヤでやることは難しい)

Slide 32

Slide 32 text

以上の話は HTTP/1.1 → QUICのざっくりとした流れ あくまで理論的(理想的？)な上辺のみを 扱ったので実際にはもっと泥臭い話が色々 実際の実践的な話は大規模インフラで 運用してる人のブログ・スライド等を読もう あとRFC

Slide 33

Slide 33 text

Credit ▷ Presentation template by SlidesCarnival