1. HTTP/2 時代の Web
Web over HTTP2
#yapcasia 2015 Jxck

2. ● id: Jxck
● github: Jxck
● twitter: @jxck_
● about: http://jxck.io
● blog: http://jxck.hatenablog.com
● podcast: http://mozaic.fm
● Love: music
Jack

3. 3
#http2study #wdpress vol.75#http2go (wip)
and more...
#mozaicfm ep2
http2 activity

4. 4

5. 5
http://http2.info

6. ● #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

7. ● #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

8. Implementations in Japan
nghttp2
C
iij-http2
node.js
http2-go
Go
sasazuka
node.js
haskell-http2
haskell
h2o
C

9. Local Activity Report @IETF89

10. RFC7540
10

11. 本当に出た
11

12. 今何がおこっているか？
12

13. 策定フェーズ
から
使うフェーズ
13

14. Position Matrix
14
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する

15. どう有るべきか？
15
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
積極的に使いこなして
行く？
使わない方がいい場合
がある？
気にせずとにかく入れる
べき？

16. 現状把握
16

17. コンテンツサイズ
17
http://httparchive.org/trends.php?s=All&minlabel=Dec+16+2010&maxlabel=Aug+1+2015#bytesTotal&reqTotal
1 ページ中のリクエスト数とレスポンスサイズ (2010/12 ~ 2015/8)
サイズもリクエスト数も増加の一途
=> サイズが増えるなら帯域が増えればいいのか？

18. 帯域 vs レイテシ
帯域 の増加よりも、 レイテシ の削減の方が効果が
大きい。
18
https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.g518e3c87f_2_0

19. 速くするために
● RTT (Round Trip Time) を減らす
○ 物理的に近くする
○ レスポンスを速くする
● RT (Round Trip) を減らす
○ アクセスする回数を減らす
○ キャッシュしてアクセスを減らす
○ なんとかしてアクセスしないで済ます
19

20. HTTP/1.1
20
advanced だから駆け足で

21. HTTP/1.*
21

22. HTTP/1.*
22
● Header
○ テキストベース
○ 圧縮不可
○ 毎回送る
○ 重複が多い(UA)
● Body
○ 何でも良い
○ 圧縮可能(gzip etc)

23. HTTP/1.*
23
● TCP を毎回確立
○ 毎回 3-W-H
○ 毎回 initial cwnd から

24. HTTP/1.*
24
● HTTP Head of Line Blocking
○ 一度に一つの HTTP リクエスト
○ 一つ詰まると後続がブロック

25. HTTP/1.*
25
● ブラウザは 6 本同時に接続
● 同時に 6 つのコンテンツを並行取得
1
2
3
4
5
6
1
2
3
4
5
6

26. シンプルな一方
高速化に限界が
26

27. 回避策
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. 回避策
28
● HTTP
○ Keep Alive
○ CSS Sprite
○ File Concat
○ Domain Sharding
● TCP
○ TCP Fast Open
○ InitCWND 10
○ TLS Session Ticket
○ TLS False Start
Bad
Hack
Kernel
level
http://www.oreilly.co.jp/books/9784873114460/
http://www.oreilly.co.jp/books/9784873113616/

29. HTTP/2
29
advanced だから駆け足で

30. HTTP2
30

31. HTTP2
31
● バイナリフレーム
○ パースしやすい
○ サイズ効率が良い
○ データ分割しやすい
● セマンティクス維持
○ 語彙は変わらない
○ 互換性

32. HTTP2
32
● HPACK
○ Huffman 圧縮
○ 頻出ヘッダを共有
○ 送信済みデータを再利用
● 圧縮率は実装次第
● see also:http://bit.ly/1E8aHYL

33. HTTP2
33
● 1 コネクションにストリームを多重化

34. HTTP2
34
● コンテンツの優先度制御
● 必要に応じたリソース分配
see also: http://bit.ly/1EFDnD7 1 : 2 : 3

35. 35http://www.slideshare.net/shigeki_ohtsu/http2-quic
コネクションを使い切る

36. Head of Line Blocking 回避
36
https://jxck.io/labs/hol/

37. プロトコルを改善し
最適化の余地が産まれた
37

38. Server Push
38
● 依存コンテンツを先に送ってキャッシュさせる
● リクエスト発生時キャッシュヒットする
● 1Req / 1RT の壁を超える

39. 積極的な Cache Contorl
● Browser Cache
○ 熾烈な奪い合い
○ 75% の人は 48h で領域を使い切る
○ see also: http://bit.ly/1HUy0Ex
● Push で積極的な Cache 管理
39https://github.com/h2o/h2o/issues/421

40. with Service Worker
40
● HTTP2 Push を Push API 受け取れる予定
● Fetch - Push が全て JS でコントロール可能
● HTTP2 + SW で積極的なミドルコントロール

41. Push が入ることの意味
41
● HTTP が Fetch と Push の両方をカバーした
● 双方向通信に必要な機能が揃った
● コンテンツ配信だけじゃもったいない
● 使用例
○ WebSocket over HTTP2 (策定中)
○ gRPC (push は未サポート?)
○ Servlet 4.0 (push の扱いを議論中)
○ Service Worker の Push API (議論中)
コンテンツ配信の枠を超え
アプリケーションからより
積極的に使えるプロトコルに

42. Position Matrix (now)
42
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する

43. HTTP2 は自分にとって
必要か？
43

44. 必要？
44
● HTTP よりも他にボトルネックあるし
● HTTP/1.1 に最適化して速度出てるし
● HTTPS にするのがなぁ。。
● Push って必要？
● インフラどうなるの？
● G と FB と Tw が必要としてるだけでしょ？
● そもそも実装が。。
● etc

45. Performance
45

46. Response Time の後の世界
46
FilmStrip
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
● 同じレンスポンスタイムでも、表示の最適化により
体感は変わる。
● 一枚の画像が、バックエンドのチューニングを台無
しにすることもある。

47. 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 Index
http://bit.ly/1HMvBg6

48. HTTP/1.1 の呪縛
48

49. 最適化
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. 実装・インフラ
50

51. 進む実装
51
● Nginx
● Apache HTTPd
● Apache Trafic Server
● IIS
● Akamai
● H2O
● nghttp2
● etc
今は実装がこなれるまでの過渡期。
各所で検証も進んでいる。

52. インフラ
● Load Balance どうするの？
● HTTPS の終端は？
● CDN は？
● 証明書管理は？
● etc
52see also: http://bit.ly/1PqYWNB
need more
知見

53. HTTPS
53

54. 様々な問題
● 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

55. 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

56. HTTP2 は
ハイパージャイアント
のもの？
56

57. ハイパージャイアントニーズ
● 戦ってるレベルが違う
○ 毎日が DOS
○ 1byte 減らすインパクトが違う
○ 効率が良くなると DC レベルでメリット
○ 知見もリソースも潤沢
● そうじゃないと HTTP2 はいらない？
○ 小さくても複雑なアプリ
○ 中くらいでもよく使われるサービス
○ HTTP/1.1 との戦いは Web 全体の課題
57
使わないといけなくはない
使ってはいけなくもない

58. クライアントの普及
58
良く知らない
導入しない
理解した
導入しない
知らないうちに
導入してる
理解した
導入する
標準化の功。
すでにクライアントの普及は
始まってる。
あとは、サービスが対応する
かどうか次第。

59. カジュアルに使っちゃだめ
なの？
59

60. 良く知らないで使うと失敗する？
割と単純に入れるだけで効果がある場合も
60also: http://bit.ly/1NLszIR

61. 敷居は高いのか
● 突き詰めれば難しい
○ それは HTTP/1.1 も同じでは？
○ ノウハウがどこまで増えるか
● 敷居は仕様よりエコシステム
○ ツールなどの支援
○ フレームワークの抽象化
○ 気がついたら使ってた までの道のり
● HTTP/1.1 とのセマンティクス互換
○ 深入りしないなら入るのも抜けるのもできる
○ ミドルウェアの抽象化に任せていれば意識しない？
61

62. 広がるエコシステム
● 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. これからどうなるか？
63

64. 研究課題
● priority 最適化戦略
● hpack の圧縮戦略
● push による cache 管理戦略
● フレームワーク API (Push etc)
● P2P など拡張仕様
64

65. HTTP3
65
https://github.com/HTTPWorkshop/workshop/wiki/HTTP-Ideas

66. TCP の限界
● TCP レベルの Head of Line Blocking
● 一本のコネクションに全て載せている
● パケットが一つ落ちると再送が発生
● コネクション全体が詰まる
66
TCP 自体は直せない

67. UDP それは最後の希望
67
● TCP 自体の問題
○ TCP 自体が持つ問題の解決は難しい
○ 別ポートプロトコルの普及は難しい
○ ミドルボックスを通れない
● UDP がある！！
○ UDP には良い意味で何も無い
○ そこに全て載せればいいのでは？
○ ポートも同じ、暗号化すればミドルボックスも通る

68. そして QUIC へ
● Head of Line Block を解消
● 0RTT での接続確立
● TLS 1.3 ベース
● 輻輳制御も独自に実装
● UDP 上に実装することで迅速なデプロイ
● TCP の限界を突破
68
HTTP2 over
QUIC over
UDP

69. Position Matrix
69
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
HTTP/1.1 は生き続けるので、
これからも問題なく動く。

70. Position Matrix
70
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
戦略としてはあり
(ただし留まり続けることが低コストである保証は無い)

71. Position Matrix
71
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
エコシステムの成
熟次第でそうなる
かも

72. Position Matrix
72
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
既存課題の解決
+
次のステージへ

73. Position Matrix
73
良く知らない
導入しない
理解した
導入しない
良く知らない
導入する
理解した
導入する
まずはここから

74. まとめ
● 今何が起こっているか
○ HTTP2 RFC が発行された
○ HTTP2 実装が進んでいる
○ エコシステムの芽も見え始めた
● これからどうなっていくのか
○ HTTP/1.1 が消える事は無い
○ HTTPS 化は止まらなそう
○ Web はまだまだ進化しそう
○ HTTP2 はそのうちのひとつ
○ そして QUIC へ
74

75. Next Checkpoint
75

76. Nginx ! Nginx ! Nginx !
76
by the end of 2015!!
すでに patch あり
http://nginx.org/patches/http2/

77. IETF at 横浜 (11月)
77
#http2study も日本でなにかやるかも

78. 78
JOIN US !!

79. have a nice web :)
79

80. Jack