Download as PDF, PPTX
More Related Content
Similar to HTTP2 時代の Web - web over http2
HTTP2 時代の Web - web over http2
- 1. HTTP/2 時代の Web Webover 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.
- 5.
- 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.
- 9. Local Activity Report@IETF89
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 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 (RoundTrip Time) を減らす ○ 物理的に近くする ○ レスポンスを速くする ● RT (Round Trip) を減らす ○ アクセスする回数を減らす ○ キャッシュしてアクセスを減らす ○ なんとかしてアクセスしないで済ます 19
- 20.
- 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 Headof Line Blocking ○ 一度に一つの HTTP リクエスト ○ 一つ詰まると後続がブロック
- 25. HTTP/1.* 25 ● ブラウザは 6本同時に接続 ● 同時に 6 つのコンテンツを並行取得 1 2 3 4 5 6 1 2 3 4 5 6
- 26.
- 27. 回避策 27 ● HTTP ○ KeepAlive ○ 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 ○ KeepAlive ○ 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.
- 30.
- 31. HTTP2 31 ● バイナリフレーム ○ パースしやすい ○サイズ効率が良い ○ データ分割しやすい ● セマンティクス維持 ○ 語彙は変わらない ○ 互換性
- 32. HTTP2 32 ● HPACK ○ Huffman圧縮 ○ 頻出ヘッダを共有 ○ 送信済みデータを再利用 ● 圧縮率は実装次第 ● see also:http://bit.ly/1E8aHYL
- 33.
- 34. HTTP2 34 ● コンテンツの優先度制御 ● 必要に応じたリソース分配 seealso: http://bit.ly/1EFDnD7 1 : 2 : 3
- 35.
- 36. Head of LineBlocking 回避 36 https://jxck.io/labs/hol/
- 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.
- 43.
- 44. 必要？ 44 ● HTTP よりも他にボトルネックあるし ●HTTP/1.1 に最適化して速度出てるし ● HTTPS にするのがなぁ。。 ● Push って必要？ ● インフラどうなるの？ ● G と FB と Tw が必要としてるだけでしょ？ ● そもそも実装が。。 ● etc
- 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.
- 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.
- 51. 進む実装 51 ● Nginx ● ApacheHTTPd ● Apache Trafic Server ● IIS ● Akamai ● H2O ● nghttp2 ● etc 今は実装がこなれるまでの過渡期。 各所で検証も進んでいる。
- 52. インフラ ● Load Balanceどうするの？ ● HTTPS の終端は？ ● CDN は？ ● 証明書管理は？ ● etc 52see also: http://bit.ly/1PqYWNB need more 知見
- 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.
- 57. ハイパージャイアントニーズ ● 戦ってるレベルが違う ○ 毎日がDOS ○ 1byte 減らすインパクトが違う ○ 効率が良くなると DC レベルでメリット ○ 知見もリソースも潤沢 ● そうじゃないと HTTP2 はいらない？ ○ 小さくても複雑なアプリ ○ 中くらいでもよく使われるサービス ○ HTTP/1.1 との戦いは Web 全体の課題 57 使わないといけなくはない 使ってはいけなくもない
- 58.
- 59.
- 60.
- 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.
- 64. 研究課題 ● priority 最適化戦略 ●hpack の圧縮戦略 ● push による cache 管理戦略 ● フレームワーク API (Push etc) ● P2P など拡張仕様 64
- 65.
- 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.
- 70.
- 71.
- 72.
- 73.
- 74. まとめ ● 今何が起こっているか ○ HTTP2RFC が発行された ○ HTTP2 実装が進んでいる ○ エコシステムの芽も見え始めた ● これからどうなっていくのか ○ HTTP/1.1 が消える事は無い ○ HTTPS 化は止まらなそう ○ Web はまだまだ進化しそう ○ HTTP2 はそのうちのひとつ ○ そして QUIC へ 74
- 75.
- 76. Nginx ! Nginx! Nginx ! 76 by the end of 2015!! すでに patch あり http://nginx.org/patches/http2/
- 77. IETF at 横浜(11月) 77 #http2study も日本でなにかやるかも
- 78.
- 79. have a niceweb :) 79
- 80.