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
510
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
640
Dynamic Routing Protocols
utsushiiro
0
88
TCP
utsushiiro
0
81
Other Decks in Programming
See All in Programming
Jakarta Concurrencyによる並行処理プログラミングの始め方 (JJUG CCC 2024 Fall)
tnagao7
1
240
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
9
1k
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
hatsu38
24
11k
Progressive Web Apps für Desktop und Mobile mit Angular (Hands-on)
christianliebel
PRO
0
110
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
8
440
GCCのプラグインを作る / I Made a GCC Plugin
shouth
1
150
飲食業界向けマルチプロダクトを実現させる開発体制とリアルな現状
hiroya0601
1
400
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
150
C#/.NETのこれまでのふりかえり
tomokusaba
1
160
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
210
Content Security Policy入門 セキュリティ設定と 違反レポートのはじめ方 / Introduction to Content Security Policy Getting Started with Security Configuration and Violation Reporting
uskey512
1
440
Golang と Erlang
taiyow
8
1.9k
Featured
See All Featured
BBQ
matthewcrist
85
9.3k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Docker and Python
trallard
40
3.1k
Navigating Team Friction
lara
183
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Into the Great Unknown - MozCon
thekraken
31
1.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
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