HTTP2 時代の Web - web over http2
- 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
- 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
- 9. Local Activity Report @IETF89
- 10. RFC7540 10
- 11. 本当に出た 11
- 12. 今何がおこっているか？ 12
- 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
- 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
- 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/
- 30. HTTP2 30
- 31. HTTP2 31 ● バイナリフレーム ○ パースしやすい ○ サイズ効率が良い ○ データ分割しやすい ● セマンティクス維持 ○ 語彙は変わらない ○ 互換性
- 32. HTTP2 32 ● HPACK ○ Huffman 圧縮 ○ 頻出ヘッダを共有 ○ 送信済みデータを再利用 ● 圧縮率は実装次第 ● see also:http://bit.ly/1E8aHYL
- 34. HTTP2 34 ● コンテンツの優先度制御 ● 必要に応じたリソース分配 see also: http://bit.ly/1EFDnD7 1 : 2 : 3
- 36. Head of Line Blocking 回避 36 https://jxck.io/labs/hol/
- 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 (議論中) コンテンツ配信の枠を超え アプリケーションからより 積極的に使えるプロトコルに
- 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
- 57. ハイパージャイアントニーズ ● 戦ってるレベルが違う ○ 毎日が DOS ○ 1byte 減らすインパクトが違う ○ 効率が良くなると DC レベルでメリット ○ 知見もリソースも潤沢 ● そうじゃないと HTTP2 はいらない？ ○ 小さくても複雑なアプリ ○ 中くらいでもよく使われるサービス ○ HTTP/1.1 との戦いは Web 全体の課題 57 使わないといけなくはない 使ってはいけなくもない
- 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
- 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 良く知らない 導入しない 理解した 導入しない 良く知らない 導入する 理解した 導入する 戦略としてはあり (ただし留まり続けることが低コストである保証は無い)
- 74. まとめ ● 今何が起こっているか ○ HTTP2 RFC が発行された ○ HTTP2 実装が進んでいる ○ エコシステムの芽も見え始めた ● これからどうなっていくのか ○ HTTP/1.1 が消える事は無い ○ HTTPS 化は止まらなそう ○ Web はまだまだ進化しそう ○ HTTP2 はそのうちのひとつ ○ そして QUIC へ 74
- 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