Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Webを早くする技術(HTTP)
Search
Haru(utsushiiro)
July 31, 2017
Programming
1
520
Webを早くする技術(HTTP)
Haru(utsushiiro)
July 31, 2017
Tweet
Share
More Decks by Haru(utsushiiro)
See All by Haru(utsushiiro)
メールの仕組み
utsushiiro
4
820
TCPその他の機能と性能 + TCP Fast Open + TLS False Start
utsushiiro
1
650
Dynamic Routing Protocols
utsushiiro
0
90
TCP
utsushiiro
0
82
Other Decks in Programming
See All in Programming
Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow
cer
PRO
0
360
Compose 1.7のTextFieldはPOBox Plusで日本語変換できない
tomoya0x00
0
210
Macとオーディオ再生 2024/11/02
yusukeito
0
390
DevTools extensions で 独自の DevTool を開発する | FlutterKaigi 2024
kokiyoshida
0
140
EMになってからチームの成果を最大化するために取り組んだこと/ Maximize team performance as EM
nashiusagi
0
100
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
350
型付き API リクエストを実現するいくつかの手法とその選択 / Typed API Request
euxn23
8
2.4k
最新TCAキャッチアップ
0si43
0
220
Jakarta EE meets AI
ivargrimstad
0
280
初めてDefinitelyTypedにPRを出した話
syumai
0
440
ふかぼれ!CSSセレクターモジュール / Fukabore! CSS Selectors Module
petamoriken
0
150
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
130
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Navigating Team Friction
lara
183
14k
Site-Speed That Sticks
csswizardry
0
40
Why Our Code Smells
bkeepers
PRO
334
57k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Teambox: Starting and Learning
jrom
133
8.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
655
59k
It's Worth the Effort
3n
183
27k
How STYLIGHT went responsive
nonsquared
95
5.2k
The Language of Interfaces
destraynor
154
24k
Transcript
Webを速くする技術(HTTP編) HTTP/1.1→ HTTP/2 → QUIC @utushiiro
▷ Table of contents ◦ HTTPとは ◦ HTTP 1.1 ▪
Keep-Alive ▪ Pipelining ◦ プロトコル以外の部分での高速化 ◦ SPDY ◦ HTTP 2 ◦ QUIC
Hyper Text Transfer Protocol リソース(ファイル)の送受信に用いられる 通信プロトコル トランスポート層のプロトコルとしてはTCPを利用 主に Webブラウザ ⇔
Webサーバ GET index.html 1.1 ... 1.1 200 OK ...
▷ 1991年 HTTP/0.9 ▷ 1996年 HTTP/1.0 RFC 1945 ▷ 1999年
HTTP/1.1 RFC 2068 ▷ 2015年 HTTP/2 RFC 7045 HTTPの変遷
1つのリソースの取得毎に コネクションを確立する オーバーヘッド大きい HTTP/1.0までの問題点 HTTP Request HTTP Response コネクション確立処理 コネクション切断処理
HTTP Request HTTP Response
Keep-Alive (HTTP/1.1) リソースの取得毎にコネクションを確立する → オーバーヘッド大きい 複数のリソース取得のためにコネクションを 維持しておく仕組みとしてKeep-Aliveが実装 HTTP HeaderのConnectionヘッダを利用する 基本的に使われている機能
Keep-Alive (HTTP/1.1) HTTP Request HTTP Response HTTP Request HTTP Response
一連のリクエストの 最初と最後だけ
HTTP/1.1までの制約 1つのリクエストが完了(レスポンスを処理) するまで 原則次のリクエストを送れない つまり, 先頭が詰まると後続が止まってしまう これは HTTPのHead of Line
Blockingと呼ばれる 以後 Head of Line Blocking → HoL Blocking
パケットロス HTTP/1.1までの制約 HTTP Request 1 HTTP Response 1 HTTP Request
2 やっと2個目を送れる 遅延
Pipelining (HTTP/1.1) 1つのリクエストが完了(レスポンスを処理) するまで 原則次のリクエストを送れない レスポンスを待たずにリクエストを送信する 仕組みとしてPipeliningが実装 ※これはリクエストを一つのコネクションで 複数送信することを想定しているため Keep-Aliveが必要になる
Pipelining (HTTP/1.1) HTTP Request 1 HTTP Response 1 HTTP Request
2 HTTP Request 3 HTTP Response 2 HTTP Response 3
Pipelining (HTTP/1.1) ただし, クライアントからのリクエストの順序と サーバからのレスポンスの順序は 同期している必要がある なので, 結局先頭が詰まると後続も詰まる 大抵のブラウザでは使われていない機能
プロトコル以外の部分での高速化 ▷ CSSスプライト ▷ 画像のインライン化 ▷ Domain Sharding (後述) などなど
上記の手法のように プロトコル以外の部分で高速化を行っていた
Domain Sharding ブラウザは先述したHead of Line Blocking等 の影響を 小さくするために, 1ドメインに対して同時に複数のコネク ションを貼っている
Domain Shardingはリソースを複数のドメインに分散させ て更に同時接続数を増やす方法 ※ 画像を別ドメインにするサイトが多いが 理由としてはこれ↑とセキュリティ向上
Webコンテンツのリッチ化 1999年にHTTP1.1仕様化されて10年 Webではコンテンツの容量が劇的に増加 Contents Delivery Network (CDN)の導入や 通信環境の改善はあるのものの (利用者が増えたこともあり)表示速度等が問題に Webの表示を高速化するにはどうすれば良いか?
Webコンテンツのリッチ化 ネットワークの回線帯域を増加させても 一定値を超えるとあまり速くならない コンテンツのデータをやり取りする際の サーバ・ホスト間やり取りの多さ(= RTT ✕ 回数)が 大きな影響を与えている 通信環境を改善するよりも
プロトコルレベルでの改善が必要に
SPDY プロトコルレベルの改善としてGoogleが SPDY(スピーディー)を提唱 TLSの上にセッション層を追加する(置き換える) TLSの拡張仕様 Next Protocol Negotiation(※)を 利用するためHTTPSが必要 ※現在(HTTP2.0)では
Application Layer Protocol Negotiation(ALPN) 詳細は省きます
HTTP/2 SPDYをベースにHTTP/2が策定(RFC 7540) 1. 優先度付全二重多重化通信 2. プロトコルのバイナリベース化 3. HTTPヘッダーの圧縮 4.
フロー制御 1, 2, 3については後述. 4では主にHTTPのレイヤで, TCPのフロー制御の様なこ とをやるための枠組み(window size 制御)を仕様化して いる.
優先度付全二重多重化通信 (HTTP/2) まず 多重化 について, 1つのコネクションの上にストリーム(※)を 作って通信を行う このストリームは複数並列に扱えるため 前述したHead of
Line Blocking問題を解消する ※従来のRequest/Responseで行われる 一連のやり取りを行う仮想的な通信路
優先度付全二重多重化通信 (HTTP/2) それぞれ独立・並列 ストリーム 確立したコネクション
コネクションを使いまわすメリット Keep-alive や HTTP/2 のストリームは 一つのコネクション使いまわす 3 way handshake のオーバヘッドだけでなく
スロースタート等によるwindow sizeの調整に かかる時間のオーバヘッドも減らせる. また, 複数のコネクションを立てるのに比べて 効率的な輻輳制御が行われる(※). ※ 従来の複数では輻輳制御がそれぞれ独立して 行われるため, 帯域を効率的に使うのが難しい
優先度付全二重多重化通信 (HTTP/2) 次に 優先度 について, レンダリングする際にコンテンツの優先度を定めることに より, より効率的な配信を行う 従来はコードの配置場所を調整したりして ロードの順序を操作していた(
jsの位置とか) ※ただし, あくまで指標程度であり 必ずその順序になるとは限らない
優先度付全二重多重化通信 (HTTP/2) 次に 多重化 について, クライアント/サーバのどちらからも(※)ストリームを確立で き, いわゆるサーバプッシュができる ※従来はクライアントからのリクエストでないと セッションを開始できなかった
後に必要になるデータを予めキャッシュさせておく などの使用法がある
プロトコルのバイナリベース化 HTTP/1.1まではHTTPはテキストベース テキストベースだと ▷ 容量が大きい ▷ パースが煩雑 フレームと呼ばれるバイナリ形式のフォーマットを 採用して, 従来のRequest/Response,
Header等は すべてのこのフレームにマッピングされる
HTTPヘッダの圧縮 HTTP/1.1の頃は高速化の一つの手法として コンテンツデータの圧縮があった HTTP/2.0では, HTTPヘッダ部分を圧縮できる & 一度送信したヘッダは基本的に再度送信しなくて済む ようになっている(差分のみ送信) 現在ではHTTPヘッダで付加する情報が多いため これによる恩恵は大きい
HTTPヘッダの圧縮 SPDYの頃はデータと同様にGzip等で圧縮していたが CRIMEと呼ばれる脆弱性が発見された これはTLSで暗号化された通信上でも 圧縮されたヘッダデータを解読する手法(参考) そこでHTTP/2ではよりセキュアな圧縮方式としてHPACK が作られた(RFC 7541) ただし, 完全にCRIMEを防げるわけではない
TCPのHead of Line Blocking HTTP/2ではHTTPのHoL Blockingを防げる しかし, TCPのHoL Blockingは防げない ▷
TCPのHoL Blockingとは TCPでは先頭のパケットがロスすると 後続のパケットを処理することができない また, HTTP/2は1本のコネクション上で多重化する分 複数使っていた頃よりこれの影響が大きい恐れがある
QUIC 先述したTCP HoL Blockingの様な トランスポート層のプロトコルレベル(TCP)の 問題等を解決し, より効率的な通信を行うために GoogleのチームがUDPベースの新たなWeb向けのプ ロトコルを作成 Quick
UDP Internet Connections (QUIC)
なぜUDPベース? 長期的な目標はTCPやTLSの改善 しかし, TCP/TLSの改良(提案, 実装, 検証 … etc)には 時間がかかる UDPで理論を実践した後に,
有効な機能をTCP/TLSの 後続バージョンにフィードバックする (もちろん)UDPを用いるので先述した TCPのHoL Blockingは起きない(ようになってる)
QUICでやろうとしていること ▷ TCPやTLSの処理の効率化 ◦ 接続の確立時に必要なRTTを減らす (TFOやTLS False Startと同じ考え) ▷ パケット損失の影響を低減
◦ パケットレベルの前方誤り訂正 ◦ 暗号化のブロックやパケットの境界を整理 ▷ 再接続(接続の維持)の簡易化 ◦ 後述
再接続(接続の維持)の簡易化 モバイル端末ではWiFiとLTE(3G)を切り替えが起きえる が, この際に安定した接続を維持するのが難しい QUICでは接続を独自の識別子 Connection UUIDを 使用して, 回線の切り替えの際にも維持することで 以前の接続を引き継ぐ(再接続処理を簡易化)
TCPだとIP & portの4つ組で識別するので どれか変わるとが接続が切れる ( IP & portがそのまま識別子なので 同じようなことを同じレイヤでやることは難しい)
以上の話は HTTP/1.1 → QUICのざっくりとした流れ あくまで理論的(理想的?)な上辺のみを 扱ったので実際にはもっと泥臭い話が色々 実際の実践的な話は大規模インフラで 運用してる人のブログ・スライド等を読もう あとRFC
Credit ▷ Presentation template by SlidesCarnival