HTTP2 時代の Web - web over http2

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

良く知らないで使うと失敗する？

割と単純に入れるだけで効果がある場合も

60also: http://bit.ly/1NLszIR

敷居は高いのか

● 突き詰めれば難しい

○ それは 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