http2 時代の web - web over http2
TRANSCRIPT
HTTP/2 時代の WebWeb over HTTP2#yapcasia 2015 Jxck
● id: Jxck● github: Jxck● twitter: @jxck_● about: http://jxck.io● blog: http://jxck.hatenablog.com● podcast: http://mozaic.fm● Love: music
Jack
3
#http2study #wdpress vol.75#http2go (wip)
and more...
#mozaicfm ep2
http2 activity
4
5
http://http2.info
● #1 2013/08/14● #2 2013/10/17● #3 2014/01/28● #4 2014/03/20● #5 2014/07/30● #6 2014/11/25
Meetup - #http2study
http://connpass.com/series/457/
● IETF briefing session● spec discuttion● implementation tips● project sharing● etc
● #1 2014/02/23● #2 2014/05/24● #3 2014/09/06● #4 2015/01/24
Hackathon● issuethon 2014/04/12
○ discuttion on http2 issues on ML & github
Implementations in Japan
nghttp2C
iij-http2node.js
http2-goGo
sasazukanode.js
haskell-http2haskell
h2oC
Local Activity Report @IETF89
RFC7540
10
本当に出た
11
今何がおこっているか？
12
策定フェーズ
から
使うフェーズ
13
Position Matrix
14
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
どう有るべきか？
15
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
積極的に使いこなして行く？
使わない方がいい場合がある？
気にせずとにかく入れるべき？
現状把握
16
コンテンツサイズ
17
http://httparchive.org/trends.php?s=All&minlabel=Dec+16+2010&maxlabel=Aug+1+2015#bytesTotal&reqTotal
1 ページ中のリクエスト数とレスポンスサイズ (2010/12 ~ 2015/8)
サイズもリクエスト数も増加の一途
=> サイズが増えるなら帯域が増えればいいのか？
帯域 vs レイテシ
帯域 の増加よりも、 レイテシ の削減の方が効果が
大きい。18
https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.g518e3c87f_2_0
速くするために
● RTT (Round Trip Time) を減らす
○ 物理的に近くする
○ レスポンスを速くする
● RT (Round Trip) を減らす
○ アクセスする回数を減らす
○ キャッシュしてアクセスを減らす
○ なんとかしてアクセスしないで済ます
19
HTTP/1.1
20
advanced だから駆け足で
HTTP/1.*
21
HTTP/1.*
22
● Header○ テキストベース○ 圧縮不可○ 毎回送る○ 重複が多い(UA)
● Body○ 何でも良い○ 圧縮可能(gzip etc)
HTTP/1.*
23
● TCP を毎回確立○ 毎回 3-W-H○ 毎回 initial cwnd から
HTTP/1.*
24
● HTTP Head of Line Blocking○ 一度に一つの HTTP リクエスト○ 一つ詰まると後続がブロック
HTTP/1.*
25
● ブラウザは 6 本同時に接続● 同時に 6 つのコンテンツを並行取得
123456
123456
シンプルな一方高速化に限界が
26
回避策
27
● HTTP○ Keep Alive○ CSS Sprite○ File Concat○ Domain Sharding
● TCP○ TCP Fast Open○ InitCWND 10○ TLS Session Ticket○ TLS False Start
http://www.oreilly.co.jp/books/9784873114460/http://www.oreilly.co.jp/books/9784873113616/
回避策
28
● HTTP○ Keep Alive○ CSS Sprite○ File Concat○ Domain Sharding
● TCP○ TCP Fast Open○ InitCWND 10○ TLS Session Ticket○ TLS False Start
Bad Hack
Kernellevel
http://www.oreilly.co.jp/books/9784873114460/http://www.oreilly.co.jp/books/9784873113616/
HTTP/2
29
advanced だから駆け足で
HTTP2
30
HTTP2
31
● バイナリフレーム○ パースしやすい○ サイズ効率が良い○ データ分割しやすい
● セマンティクス維持○ 語彙は変わらない○ 互換性
HTTP2
32
● HPACK○ Huffman 圧縮
○ 頻出ヘッダを共有
○ 送信済みデータを再利用
● 圧縮率は実装次第● see also:http://bit.ly/1E8aHYL
HTTP2
33
● 1 コネクションにストリームを多重化
HTTP2
34
● コンテンツの優先度制御● 必要に応じたリソース分配
see also: http://bit.ly/1EFDnD7 1 : 2 : 3
35http://www.slideshare.net/shigeki_ohtsu/http2-quic
コネクションを使い切る
Head of Line Blocking 回避
36https://jxck.io/labs/hol/
プロトコルを改善し最適化の余地が産まれた
37
Server Push
38
● 依存コンテンツを先に送ってキャッシュさせる
● リクエスト発生時キャッシュヒットする
● 1Req / 1RT の壁を超える
積極的な Cache Contorl● Browser Cache
○ 熾烈な奪い合い
○ 75% の人は 48h で領域を使い切る
○ see also: http://bit.ly/1HUy0Ex● Push で積極的な Cache 管理
39https://github.com/h2o/h2o/issues/421
with Service Worker
40
● HTTP2 Push を Push API 受け取れる予定
● Fetch - Push が全て JS でコントロール可能
● HTTP2 + SW で積極的なミドルコントロール
Push が入ることの意味
41
● HTTP が Fetch と Push の両方をカバーした
● 双方向通信に必要な機能が揃った
● コンテンツ配信だけじゃもったいない
● 使用例○ WebSocket over HTTP2 (策定中)○ gRPC (push は未サポート?)○ Servlet 4.0 (push の扱いを議論中)○ Service Worker の Push API (議論中)
コンテンツ配信の枠を超え
アプリケーションからより
積極的に使えるプロトコルに
Position Matrix (now)
42
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
HTTP2 は自分にとって必要か？
43
必要？
44
● HTTP よりも他にボトルネックあるし
● HTTP/1.1 に最適化して速度出てるし
● HTTPS にするのがなぁ。。
● Push って必要？
● インフラどうなるの？
● G と FB と Tw が必要としてるだけでしょ？
● そもそも実装が。。
● etc
Performance
45
Response Time の後の世界
46
FilmStrip
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
● 同じレンスポンスタイムでも、表示の最適化により
体感は変わる。
● 一枚の画像が、バックエンドのチューニングを台無
しにすることもある。
Res Time は全体の半分しか測れてない
● Response Time の後の世界○ Cache の最適化
○ Critical Rendering Path の最適化
○ SPA● 何を見るか
○ Speed Index○ Film Strip○ TTFB (time to first byte)○ First Paint○ RUM (real user monitoring)○ etc
47
see also: http://bit.ly/1fsJZhD http://bit.ly/1U1hWDx
Speed Indexhttp://bit.ly/1HMvBg6
HTTP/1.1 の呪縛
48
最適化
49
● HTTP/1.1 向けハック○ JS の concat○ CSS の concat○ 画像の Sprite○ Sprite のための CSS○ ドメイン分ける
○ etc
Bad Hack 無しの素直な作りでも遅くなら
なかったとしたら？http://www.oreilly.co.jp/books/9784873114460/http://www.oreilly.co.jp/books/9784873113616/
実装・インフラ
50
進む実装
51
● Nginx● Apache HTTPd● Apache Trafic Server● IIS● Akamai● H2O● nghttp2● etc
今は実装がこなれるまでの過渡期。各所で検証も進んでいる。
インフラ
● Load Balance どうするの？
● HTTPS の終端は？
● CDN は？
● 証明書管理は？
● etc
52see also: http://bit.ly/1PqYWNB
need more知見
HTTPS
53
様々な問題
● NSA: PRISM (広域盗聴)● AT&T: NSA への協力
TLS 推奨の流れ
● W3C○ End-to-End Encryption and the Web
● IETF○ Privacy Protected Security Considerations
● Google○ HTTPS as a ranking signal
● Mozilla○ Deprecating Non-Secure HTTP
● Let’s Encrypt (延期11月)○ https://letsencrypt.org/
54"Edward Snowden-2" by Laura Poitras / Praxis Films. Licensed under CC 表示 3.0 via ウィキメディア・コモンズ
Pervasive Surveillance
HTTPS は前提？
55
● HTTP2○ 仕様上は平文もあるが、ブラウザは実装してない。
● WebRTC○ HTTPS じゃないと getUserMedia が毎回要確認
● Service Worker○ HTTPS じゃないと登録できない
● HSTS○ HTTPS で接続させる
● Oppotunistic Encryption○ HTTP でも暗号化する
● Upgrade Insecure Request○ http:// を https:// に読み替えてリクエスト
see also: http://bit.ly/1Lq1fT9
HTTP2 はハイパージャイアント
のもの？
56
ハイパージャイアントニーズ
● 戦ってるレベルが違う○ 毎日が DOS○ 1byte 減らすインパクトが違う
○ 効率が良くなると DC レベルでメリット
○ 知見もリソースも潤沢
● そうじゃないと HTTP2 はいらない？○ 小さくても複雑なアプリ
○ 中くらいでもよく使われるサービス
○ HTTP/1.1 との戦いは Web 全体の課題
57
使わないといけなくはない使ってはいけなくもない
クライアントの普及
58
良く知らない導入しない
理解した導入しない
知らないうちに導入してる
理解した導入する
標準化の功。すでにクライアントの普及は始まってる。あとは、サービスが対応するかどうか次第。
カジュアルに使っちゃだめなの？
59
敷居は高いのか
● 突き詰めれば難しい
○ それは HTTP/1.1 も同じでは？
○ ノウハウがどこまで増えるか
● 敷居は仕様よりエコシステム
○ ツールなどの支援
○ フレームワークの抽象化
○ 気がついたら使ってた までの道のり
● HTTP/1.1 とのセマンティクス互換
○ 深入りしないなら入るのも抜けるのもできる
○ ミドルウェアの抽象化に任せていれば意識しない？61
広がるエコシステム
● servlet 4.0○ ミドルレイヤの仕様への導入: http://bit.ly/1PDc8iW
● HDFS○ ミドルウェアの通信プロトコルに: http://bit.ly/1hvxhR9
● grpc: ○ 汎用 RPC として: http://bit.ly/1MI5QjP
● F5-BigIP:○ gateway レベルで対応: http://bit.ly/1LmYxe4
● CURL:○ いつものツールが: http://bit.ly/1Eb19wi
62
これからどうなるか？
63
研究課題
● priority 最適化戦略
● hpack の圧縮戦略
● push による cache 管理戦略
● フレームワーク API (Push etc)● P2P など拡張仕様
64
HTTP3
65https://github.com/HTTPWorkshop/workshop/wiki/HTTP-Ideas
TCP の限界
● TCP レベルの Head of Line Blocking● 一本のコネクションに全て載せている
● パケットが一つ落ちると再送が発生
● コネクション全体が詰まる
66
TCP 自体は直せない
UDP それは最後の希望
67
● TCP 自体の問題
○ TCP 自体が持つ問題の解決は難しい
○ 別ポートプロトコルの普及は難しい
○ ミドルボックスを通れない
● UDP がある！！
○ UDP には良い意味で何も無い
○ そこに全て載せればいいのでは？
○ ポートも同じ、暗号化すればミドルボックスも通る
そして QUIC へ● Head of Line Block を解消
● 0RTT での接続確立
● TLS 1.3 ベース
● 輻輳制御も独自に実装
● UDP 上に実装することで迅速なデプロイ
● TCP の限界を突破
68
HTTP2 overQUIC over
UDP
Position Matrix
69
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
HTTP/1.1 は生き続けるので、これからも問題なく動く。
Position Matrix
70
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
戦略としてはあり(ただし留まり続けることが低コストである保証は無い)
Position Matrix
71
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
エコシステムの成熟次第でそうなる
かも
Position Matrix
72
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
既存課題の解決+
次のステージへ
Position Matrix
73
良く知らない導入しない
理解した導入しない
良く知らない導入する
理解した導入する
まずはここから
まとめ
● 今何が起こっているか
○ HTTP2 RFC が発行された
○ HTTP2 実装が進んでいる
○ エコシステムの芽も見え始めた
● これからどうなっていくのか
○ HTTP/1.1 が消える事は無い
○ HTTPS 化は止まらなそう
○ Web はまだまだ進化しそう
○ HTTP2 はそのうちのひとつ
○ そして QUIC へ74
Next Checkpoint
75
Nginx ! Nginx ! Nginx !
76
by the end of 2015!!すでに patch あり
http://nginx.org/patches/http2/
IETF at 横浜 (11月)
77
#http2study も日本でなにかやるかも
78
JOIN US !!
have a nice web :)
79
Jack