HTTPとサーバ技術の最新動向

2. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  名前: 奥一穂  ウェブ関連の基盤技術プログラマ ⁃ 主な業績（公開のもの） • Palmscape / Xiino (Palm OS向けウェブブラウザ) • Webブラウザプラグインを用いたサービス ⁃ Japanize, Mylingual, Pathtraq, ... • Q4M (MySQL用メッセージキュープラグイン) • Starlet (Perl用Webアプリケーションサーバ) • JSX (最適化コンパイラつきJavaScript方言) ⁃ M.I.T. TR100/2002, IPA未踏スーパークリエータ (2004), 日本/北東アジアOSS貢献者賞 (2015) 2HTTPとサーバ技術の最新動向

3. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 最近の仕事  H2O ⁃ ディー・エヌ・エーで開発しているウェブサーバ • 2014年12月: 初回リリース (0.9.0) • 2014年2月: 1.7.0リリース ⁃ HTTP/2対応 (おそらく世界最速) ⁃ その他、先進的な取り組み ⁃ オープンソース (MIT License)  標準化活動 ⁃ Cache Digests for HTTP/2 3HTTPとサーバ技術の最新動向

4. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 本日のテーマ: HTTPとサーバ技術の最新動向  目次: ⁃ サーバ技術の評価軸 ⁃ HTTP/2 • 誕生の背景と基礎 • レスポンスタイム最適化 ⁃ サーバプッシュ ⁃ HTTPS化とサーバ負荷 ⁃ Brotli ⁃ ウェブサーバ内でのスクリプト実行 4HTTPとサーバ技術の最新動向

7. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバ負荷の削減  例: HandlerSocket ⁃ DeNA樋口が開発 • MySQL Conference Community Awards 2011受賞 ⁃ MySQLサーバにKVSプロトコルを追加 ⁃ 単純なクエリにSQLを使わないことにより、大量の接続を高速に処理 ⁃ 効果: • スレーブ台数を削減（LANのデータ転送量も） • サーバが数千台規模だと、削減コスト>>開発費 7HTTPとサーバ技術の最新動向

18. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. HTTP/1.1は多重性がない 18HTTPとサーバ技術の最新動向 RTT request response request response client server … RTT  HTTP/1.1では、1RTTあたり1リクエスト/レスポンスしか送受信できない ⁃ RTT=ラウンドトリップタイム • レイテンシの大きさを表す値  緩和策:複数のTCP接続を使う ⁃ 同時6本が一般的 • 1RTTあたり6リクエスト!!! • それでも遅い

19. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. HTTP/1.1パイプラインの問題 19HTTPとサーバ技術の最新動向 RTT requests responses client server  仕様上、レスポンス受信前に次のリクエストを送信可能  問題: ⁃ 切断時に、レスポンス未受信のリクエストを再送信していいかわからない • サーバが同じリクエストを複数回処理する可能性 ⁃ 先行リクエストの処理に時間がかかると後続が詰まる (head-of-line blocking) ⁃ バグのあるサーバ実装が多い

26. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. バイナリプロトコルな理由  脆弱性を防ぐ ⁃ HTTP Request/Response Splitting Attack • HTTP/1.1のパーサによる解釈の差をつく攻撃  転送データ量の低減 ⁃ 細かな粒度でレスポンスの順序を変更したい • 転送単位が小さいなら、その単位毎につけるヘッダは小さくないといけない → バイナリにするしかない ⁃ ヘッダ圧縮 • 圧縮するんだから、どのみちバイナリ  全てのデータは、「フレーム」に分解して送受信 26HTTPとサーバ技術の最新動向

27. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 典型的な通信フロー（クライアントが送信） GET / HTTP/1.1 Host: example.com User-Agent: MySuperClient/1.0 （サーバが送信） HTTP/1.1 200 OK Date: Thu, 20 Aug 2015 06:48:36 GMT Server: Apache/2.2.29 (Unix) Last-Modified: Wed, 12 Mar 2014 05:03:17… ETag: "50b5e5-33a-4f461c1300f40" Content-Length: 826 Content-Type: text/html <html> … 27HTTPとサーバ技術の最新動向 HEADERSフレーム（クライアント送信）: :method: GET :scheme: https :authority: example.com :path: / user-agent: MySuperClient/1.0 HEADERSフレーム（サーバ送信）: :status: 200 date: Thu, 20 Aug 2015 06:48:36 GMT server: Apache/2.2.29 (Unix) last-Modified: Wed, 12 Mar 2014 05:03:… etag: "50b5e5-33a-4f461c1300f40" content-length: 826 content-type: text/html DATAフレーム（サーバ送信）: <html>…

29. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ヘッダ圧縮 (1)  HTTP/1.1のヘッダは大きい ⁃ リクエスト: • 最低でも300バイト程度 • Google Analytics使うとCookieで+200バイトなど ⁃ レスポンスも通常300バイト程度  100個レスポンスを受け取るなら、それだけで30KB ⁃ レイテンシがなくなるなら、ヘッダサイズも小さくしたい • 大量に304 Not Modifiedを返すこととかありますよね 29HTTPとサーバ技術の最新動向

32. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ヘッダ圧縮 (4)  / へのリクエスト 32HTTPとサーバ技術の最新動向 (圧縮前: 291バイト) :method: GET :scheme: https :authority: example.com :path: / user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/… accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: ja,en-US;q=0.7,en;q=0.3 accept-Encoding: gzip, deflate (圧縮後: 147バイト) 02 # :method: GET 07 # :scheme: https 41 88 2f 91 d3 5d 05 5c 87 a7 # :authority: example.com 04 # :path: / 7a bc d0 7f 66 a2 81 b0 da e0 53 ...(46 bytes) # user-agent: ... 53 b0 49 7c a5 89 d3 4d 1f 43 ae ...(50 bytes) # accept: ... 51 93 e8 3f a2 d4 b7 0d df 7d a0 ...(21 bytes) # accept-language: ... 10 # accept-encoding: ...

33. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ヘッダ圧縮 (5)  /banner.jpg へのリクエスト 33HTTPとサーバ技術の最新動向 (圧縮前: 300バイト) :method: GET :scheme: https :authority: example.com :path: /banner.jp user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/… accept: image/png,image/*;q=0.8,*/*;q=0.5 accept-language: ja,en-US;q=0.7,en;q=0.3 accept-encoding: gzip, deflate referer: https://example.com/ (圧縮後: 62バイト) 02 # :method: GET 07 # :scheme: https c1 # :authority: example.com 44 89 62 31 d5 51 6c 5f a5 73 7f # :path: /banner.jpg c1 # user-agent: … 53 9a 35 23 98 ac 57 54 df 46 a4 ...(28 bytes) # accept: ... c0 # accept-language: ... 10 # accept-encoding: ... 73 8f 9d 29 ad 17 18 60 be 47 4d ...(17 bytes) # referer: ...

34. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ヘッダ圧縮 (6)  /icon.png へのリクエスト 34HTTPとサーバ技術の最新動向 (圧縮前: 298バイト) :method: GET :scheme: https :authority: example.com :path: /icon.png user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/… accept: image/png,image/*;q=0.8,*/*;q=0.5 accept-language: ja,en-US;q=0.7,en;q=0.3 accept-encoding: gzip, deflate referer: https://example.com/ (圧縮後: 17バイト) 02 # :method: GET 07 # :scheme: https c4 # :authority: example.com 44 87 60 c4 3d 4b d7 54 df # :path: /icon.png c4 # user-agent: … c0 # accept: ... c2 # accept-language: ... 10 # accept-encoding: ... bf # referer: ...

35. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ヘッダ圧縮 (7)  最初のリクエストでもそこそこ圧縮される  画像等アセットへのリクエストが繰り返すとすごく縮む ⁃ レスポンスも同様 35HTTPとサーバ技術の最新動向リクエストパスヘッダサイズ（圧縮前，バイト）ヘッダサイズ（圧縮後，バイト）圧縮率 / 291 147 50.5% /banner.jpg 300 62 20.7% /icon.png 298 17 5.7%

36. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ここまでのまとめ  HTTP/2の基本 ⁃ 多重化によりレイテンシの影響を低減 ⁃ ヘッダ圧縮により通信量を低減  上記２点を体感できるデモ ⁃ https://www.symfony.fi/entry/compare- resource-loading-between-http-2-and-http-1-1 36HTTPとサーバ技術の最新動向

40. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. HTTP/2の規定する優先度制御  クライアントがリクエスト毎に優先度を指定する ⁃ ２種類の制御手法の組み合わせ • 重みづけ (weight) ⁃ 値に比例したバンド幅の配分 • 依存関係 (dependency) ⁃ 依存されているレスポンスを先に送信 ⁃ グループ化にも利用  サーバは指定された優先度を「参考にする」 40HTTPとサーバ技術の最新動向

41. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Firefoxの優先度制御 41HTTPとサーバ技術の最新動向 Root Leader G Follower G weight: 1 HTML weight: 32 Image weight: 22 Image weight: 22 Image weight: 22 CSS weight: 32 CSS weight: 32  各CSS, JSを、HTMLや画像より先に転送 ⁃ 正確には32倍速く転送  HTMLを画像よりも多少優先 JS weight: 32 JS weight: 32

42. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. H2Oの優先度制御実装  H2Oは ⁃ Webブラウザの指示に従い、バンド幅を配分 • 割当はHTTP/2の規定どおり ⁃ 優先度制御の粒度が細かい • 16KB単位でストリームを切り替え • 約64KB単位でバッファリング  全てのHTTP/2サーバが優先度制御を（正しく）実装しているわけではない 42HTTPとサーバ技術の最新動向

43. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバサイドの優先度制御実装  優れた優先度制御の要件: weighted fair queuing ⁃ 次に送信すべきストリームを、queueの中から • 重み (weight) に基づいて • 公平 (fair) に選択  H2Oのwfqは、リングバッファを使用したO(1)実装 ⁃ ツリーの深さに対しては高速なO(n) • タイトなループなので高速 ⁃ 高速な実装 → 細粒度で送信ストリームを切替可能  他のHTTP/2実装もwfqを採用へ ⁃ nghttp2, Apache (mod_h2), hyper, ... 43HTTPとサーバ技術の最新動向

44. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 優先度制御 (Chromeの場合) 44HTTPとサーバ技術の最新動向  重みづけのみを使用（依存関係は未使用）  HTTP/2で初期描画までの時間は劣化 0 0.5 1 1.5 2 2.5 3 Nginx (HTTP/1.1) Nginx (SPDY/3.1) H2O (HTTP/2) Chrome/43 Download Timing (unit: seconds, latency: 100ms) first paint load complete

45. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 優先度制御 (Chromeの場合) 45HTTPとサーバ技術の最新動向  重みはHTML>CSS>JS>画像  だが、画像のファイル数が多いと、画像がバンド幅の過半を使用してしまう Root HTML weight: 256 CSS weight: 220 JS weight: 183 Image weight: 110 Image weight: 110 Image weight: 110

46. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 優先度制御 (他のウェブブラウザの場合) 46HTTPとサーバ技術の最新動向  Edge – 優先度制御なし  Safari – 優先度制御なし  サーバ側でなんとかしないと… Root HTML weight: 16 CSS weight: 16 JS weight: 16 Image weight: 16 Image weight: 16 Image weight: 16

47. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. H2Oによる優先度の書き換え  クライアントが依存関係ツリーを構築しない場合に  レンダリングをブロックしそうな content-type のレスポンスを最優先で配信 47HTTPとサーバ技術の最新動向 Root HTML weight: 16 CSS weight: max JS weight: max Image weight: 16 Image weight: 16 Image weight: 16 (internal root)

48. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 優先度書き換えの効果  初期描画までの時間が大幅に改善 ⁃ 測定結果はChrome/43 48HTTPとサーバ技術の最新動向 0 0.5 1 1.5 2 2.5 3 Nginx (HTTP/1.1) Nginx (SPDY/3.1) H2O (HTTP/2) H2O+repriori ze (HTTP/2) Chrome/43 Download Timing (unit: seconds, latency: 100ms) first paint load complete

49. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 優先度制御まとめ  ユーザの体感速度を大幅に向上させる技術 ⁃ 初期描画までの時間が改善するため  クライアント側: ⁃ Firefox – すばらしい ⁃ 他のWebブラウザ – 要改善  サーバ側: ⁃ 実装状況がまちまち ⁃ H2OはFirefox以外のブラウザむけの最適化も実装 49HTTPとサーバ技術の最新動向

51. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュ  HTTP/2はRTTを隠蔽する技術  でも、1RTT（リクエストを投げてからレスポンスを受け取るまで）は絶対かかるよね？  それ、0RTTでできるよ！ ⁃ サーバが、クライアントの発行するリクエストを予測して、レスポンスをプッシュすればいい ※これ以外の目的でも使える技術ですが、今回はウェブブラウザのレスポンスタイムに絞った議論をします 51HTTPとサーバ技術の最新動向

52. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュ  例: RTT=50ms, アプリサーバの処理時間=200ms 52HTTPとサーバ技術の最新動向 req. processrequest push-asset HTML push-asset push-asset push-asset req. processrequest asset HTML asset asset asset req. 450ms(5RTT+processingme) 250ms(1RTT+processingme) without push with push

53. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュ  CDNによるウェブ高速化にも応用可能 ⁃ アプリサーバの応答を待つ間も回線を有効活用可能 ⁃ アプリ提供者は、その分、アプリサーバの設置拠点を減らすことが可能に 53HTTPとサーバ技術の最新動向 req. push-asset HTML push-asset push-asset push-asset client edge server (CDN) app. server req. HTML

55. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュと優先度制御  RFCどおり実装してあっても、あまり役に立たない ⁃ プッシュされるレスポンスは、プッシュを起動したレスポンスに依存する形でスケジュールされるから  画像をHTMLより優先してプッシュするわけにもいかない  H2Oは、プッシュのmime-typeを見て優先度を決定 ⁃ reprioritize-blocking-assetsと同様 ⁃ つまり、JSやCSSなら最優先で • 画像ならHTMLの後で 55HTTPとサーバ技術の最新動向 HTML weight: ?? CSS (pushed) weight: 16

56. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュの使い方 (1)  Link: rel=preload ヘッダ ⁃ アプリサーバが返す Link ヘッダを認識してプッシュ HTTP/1.1 200 OK Content-Type: text/html Link: </style.css>; rel=preload # このヘッダ!!! ⁃ H2O, nghttpx (nghttp2), mod_h2 (Apache) が対応 ⁃ 問題: アプリサーバが応答を返すまでプッシュ不可能 56HTTPとサーバ技術の最新動向

57. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュの使い方 (2)  H2O では、アプリサーバへリクエストを転送する前にプッシュを開始可能 # 1. mrubyハンドラでプッシュを開始 (Linkヘッダをセット) mruby.handler: | Proc.new do |env| [399, { "Link" => "</style.css>; rel=preload" }, []] end # 2. リバースプロキシハンドラがアプリサーバにリクエストを転送 proxy.reverse.url: http://app.example.com:8080/ 57HTTPとサーバ技術の最新動向

58. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバプッシュ vs. ブラウザキャッシュ  キャッシュ済のファイルはプッシュしたくない ⁃ バンド幅（と場合によっては時間）のムダ  キャッシュの有無を判断する方法は? ⁃ ブラウザキャッシュ内の状況を確認するためにリクエスト/レスポンスを送信してはいけない • そのために1RTTかかるとプッシュのメリットがなくなる 58HTTPとサーバ技術の最新動向

59. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. cache-aware server-push  H2O 1.5以降で実装 (experimental)  ブラウザキャッシュ内の CSS, JS を fingerprinting ⁃ Golomb coded sets (bloom filterの圧縮版) を使用  fingerprint を全てのリクエストに cookie として添付 ⁃ cookie サイズは100バイト程度 • さらに HPACK による圧縮が効く ⁃ ServiceWorker を使った実装も開発中 (jxck氏)  H2O は fingerprint を基に、ウェブアプリの要求するプッシュを実際に行うか判定 ⁃ プッシュした場合は fingerprint を更新 59HTTPとサーバ技術の最新動向

60. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. cache-aware server-push  cookieを使うアプローチの問題: ⁃ Webブラウザキャッシュに何が入ってるか、ブラウザ以外には正確には分からない ⁃ cookieは消される可能性／細かな更新が困難  理想的には、Webブラウザが fingerprint を送信すべき ↓  2014/10: 関係者と議論 @ http2/quic meetup  2015/01: インターネットドラフト(RFC化の提案)を提出 (共著者: Mark Nottingham) mod_h2 (Apache) がドラフトを実装 60HTTPとサーバ技術の最新動向

61. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. cache-aware server-push  fingerprint を含むリクエストの例 :method: GET :scheme: https :authority: example.com :path: / cache-digest: IdrjaOrSB4wfpbxdx5Q/ ⁃ この cache-digest ヘッダは、以下12の URL がキャッシュ済であることを示している https://example.com/assets/css/bootstrap.min.css, https://example.com/assets/css/font-awesome.css, https://example.com/assets/css/header.css, https://example.com/assets/css/magnific-popup.css, https://example.com/assets/css/main.css, https://example.com/assets/css/pinstrap.css, https://example.com/assets/css/pinterest.css, https://example.com/js/bootstrap.min.js, https://example.com/js/jquery-1.11.0.js, https://example.com/js/jquery-ui.min.js, https://example.com/js/jquery.magnific- popup.js, https://example.com/js/pinterest.js 61HTTPとサーバ技術の最新動向

66. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. リザンプションとは?  TLSのハンドシェイクは２種類: ⁃ フルハンドシェイク • サーバによる公開鍵署名演算が必要 ⁃ RSA 2048bitで署名する場合、約1ミリ秒/CPUコア • ちなみに ECDSA 256bitだと約10倍速い ⁃ 短縮ハンドシェイク (a.k.a. リザンプション) • 直前のフルハンドシェイクの結果を再利用＝軽い • フルハンドシェイクよりも1RTT速い  リザンプション: 2種類の方式 ⁃ Session Cache ⁃ Session Tickets 66HTTPとサーバ技術の最新動向

67. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Session Cache  正式名称 "Session Resumption" (TLS仕様の一部)  フルハンドシェイクの結果を、サーバとクライアントがそれぞれキャッシュ  長所: ⁃ 全ての主要なクライアントが対応 ⁃ forward secrecyが保証される • セッションキャッシュを正しく消していることが前提  短所: ⁃ サーバクラスタで使用する場合、キャッシュの同期が必要 67HTTPとサーバ技術の最新動向

68. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Session Tickets  TLSの「拡張」 (RFC 5077)  手法: ⁃ フルハンドシェイクの結果を、サーバが独自に暗号化＆署名して、クライアント側にticketとして送信 ⁃ クライアントは再接続の際にticketをサーバに提示 ⁃ サーバはticketの署名を検証し、ticketを復号して再接続に使用 68HTTPとサーバ技術の最新動向

69. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. TLS Session Tickets  長所: ⁃ サーバ間でのキャッシュ同期が不要  短所: ⁃ 未対応なクライアントの存在 • Safari (iOS 9), IE (Windows 8以前) ⁃ forward secrecyの確保が困難 • サーバがticket暗号化に使う鍵の定期更新が必須 ⁃ サーバによっては運用が煩雑に 69HTTPとサーバ技術の最新動向

70. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Webサーバの対応状況 Session Cache Session Tickets サーバ単独サーバ間同期サーバ単独サーバ間同期 Apache ○ ○ 手動更新手動更新 Nginx ○ × 手動更新手動更新 Varnish (hitch) ○ ○ 未対応 H2O ○ ○ 自動更新自動更新 70HTTPとサーバ技術の最新動向

71. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. HTTPS化によるオーバヘッドまとめ  HTTPS化と同時にHTTP/2化すれば良い ⁃ 利点: • ネットワークコストの削減 • 応答性の改善 ⁃ サーバコストは同等か減少（するだろう） • リザンプションの設定に注意  リザンプションが困難な場合の緩和策: ECDSA 71HTTPとサーバ技術の最新動向

73. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Brotli  Google が開発した新しい圧縮アリゴリズム ⁃ gzip(deflate)の置き換えが目的  「圧縮率がZopfliより20〜26%向上」 ⁃ Zopfli: 最強のgzipエンコーダ  FAQ ⁃ 具体的な圧縮率は? ⁃ 圧縮・展開の速度は? ⁃ ブラウザやサーバの対応状況は? 73HTTPとサーバ技術の最新動向

74. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Brotliの圧縮率と圧縮・展開速度 74HTTPとサーバ技術の最新動向  brotli:11の圧縮率は抜群 ⁃ 圧縮速度は超低速 ⁃ 事前圧縮に最適  brotli:1はdeflate:1より ⁃ 圧縮率が高く、速度は同等 ⁃ 実行時の圧縮に最適  展開速度はdeflateと同等 ref: http://www.gstatic.com/b/brotlidocs/brotli-2015-09-22.pdf 0 2 4 6 8 Canterbury HTML enwik8 圧縮率 0 50 100 150 200 Canterbury HTML enwik8 圧縮速度 (MB/s) brotli:1 brotli:11 deflate:1 deflate:9 zopfli

75. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. Brotliの対応状況  ウェブブラウザの対応状況 ⁃ Firefox 48 ⁃ Chrome 49 (予定) ⁃ ※ HTTPSのみ  ウェブサーバの対応状況 ⁃ Apache – 不明 ⁃ Nginx – Google がサードパーティモジュールを提供 ⁃ H2O – 1.8で対応予定 75HTTPとサーバ技術の最新動向

78. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ウェブサーバ設定の黒魔術: mod_rewrite  正規表現でURLを書き換え RewriteRule ^/abc/(.*)$ /new/$1 [R=301,L] RewriteRule ^/def/(.*).html$ /new2/$1.html [R=301,L] RewriteRule ^/ghi/(.*).(html|htm)$ /new3/$1.$2 [R=301,L] RewriteRule ^/jkl/(.*)$ http://www.example.com/$1 [R=301,L]  ルーティングに便利  例: URLをウェブアプリケーションにマッピング  例: クライアントによって異なるサイズの画像を返す  可読性／保守性が最悪  現場の声「mod_rewriteで書いた秘伝のタレがあるので Apache から離れられません」 78HTTPとサーバ技術の最新動向

79. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 上級黒魔術  ウェブサーバ内でのスクリプト実行  実装例: ⁃ Apache – mod_perl, … ⁃ nginx – lua, mruby, nginScript (JavaScript方言) ⁃ OpenRestry – lua ⁃ H2O - mruby 79HTTPとサーバ技術の最新動向

80. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ウェブサーバ内でのスクリプト実行  メリット: ⁃ 正規表現以上に複雑なルールが書ける ⁃ mod_rewriteよりも可読性が上がる ⁃ スクリプトの単体テストもできる ⁃ 外部サーバ（DB等）への問い合わせもできる  懸念材料: ⁃ 特定のウェブサーバへのベンダロックイン ⁃ 外部サーバへ問い合わせた際のパフォーマンス劣化 80HTTPとサーバ技術の最新動向

81. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ベンダロックインを避ける  ロックインが発生する理由: ⁃ ウェブサーバ毎にスクリプト言語やAPIが異なるから  ウェブアプリ記述に使われるスクリプト言語を使いたい ⁃ 具体例: ruby, JavaScript ⁃ 理由: • 学習コスト • 構成の柔軟性 ⁃ 同一コードを、アプリケーションサーバでも動かしたい  APIついても同様 81HTTPとサーバ技術の最新動向

82. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. H2Oの選択: mruby + Rack API  mruby: Rubyの組み込み向け実装  Rack API: Rubyの標準的なウェブアプリ用API  利用例: ⁃ share/h2o/mruby/htpasswd.rb • H2OのBasic認証の実装 ⁃ wfcache-mruby • WordPress Cacheへのインターフェイス ⁃ Rack APIを用いたRubyによる実装なので、Unicorn 等でも動作（多少の変更は必要） 82HTTPとサーバ技術の最新動向

84. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. コルーチンを用いた非同期化  手法: ⁃ サーバ内スクリプトをコルーチンで実行 ⁃ 外部への問い合わせ時にコルーチンを切り替え、問い合わせをサーバのイベントループで実行 ⁃ 結果が得られたら、再びコルーチンを切り替え、サーバ内スクリプトの実行を継続  採用実装: ⁃ OpenRestry – lua ⁃ H2O – mruby ⁃ nginx – nginScript (予定) 84HTTPとサーバ技術の最新動向

85. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. OpenRestryのコルーチン使用例  redis.client:get の呼出時に、コルーチンがイベントループに処理を渡す ⁃ プログラマは非同期であることを意識しなくていい local redis = require "redis" local client = redis.connect(REDIS_ADDR, REDIS_PORT) route = client:get(ngx.var.http_host) if route ~= nil then ngx.var.upstream = route else ngx.exit(ngx.HTTP_NOT_FOUND) end ref: http://blog.cybozu.io/entry/2016/02/16/080000 85HTTPとサーバ技術の最新動向

86. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 単純なコルーチン実装の問題  複数のサーバに同時問い合わせができない  並行問い合わせが必要なユースケース: ⁃ HTML内の特殊タグを認識して、ウェブサーバで別のコンテンツを差し込み (Edge-side Includes) <esi:include src="http://ad-server.local/..." />  解決策: 非同期処理をタスクとして抽象化 ⁃ H2Oのアプローチ 86HTTPとサーバ技術の最新動向

87. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. H2Oの非同期タスク  http_requestメソッドはタスクを返す  タスクはイベントループ側で非同期に実行される  join メソッドが呼ばれると、結果取得までコルーチンがスリープする  例: 広告を差し込んで返すコード app_req = http_request("http://example.com") ad_req = http_request("http://example.org") ad_html = (ad_req.join)[2].join status, headers, body = main_req.join body = [body.join.gsub(//, ad_html)] [status, headers, [body]] 87HTTPとサーバ技術の最新動向

88. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 非同期タスクを用いたESI実装 # HTML内の<ESI>タグを展開しつつ、届いたところからクライアントに送信 class ESIResponse def initialize(input) @parts = input.split /(<esi:include +src=".*?" */>)/ @parts.each_with_index do |part, index| @parts[index] = http_request("http://127.0.0.1:5000/#{$1}") if /^<esi:include +src=" *(.*?) *"/.match(part) end end def each(&block) @parts.each do |part if part.kind_of? String block.call(part) else part.join[2].each(&block) end end end end 88HTTPとサーバ技術の最新動向

89. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. サーバ内スクリプト実行まとめ  スクリプト言語を用いた実装へ移項することで ⁃ rewrite よりも可読性と保守性が高まる • 例: ユニットテストも書ける  標準化されたAPI仕様に依ることで ⁃ 特定サーバへのロックインを回避できる ⁃ 同一のスクリプトが、ウェブサーバ内でもアプリケーションサーバ内でも実行可能に  コルーチンや非同期タスクに対応した処理系であれば ⁃ 別サーバ問い合わせやコンテンツの差込など、複雑な処理も簡単に記述可能／高速に実行 89HTTPとサーバ技術の最新動向

91. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. まとめ  HTTPとサーバ技術は進化中 ⁃ 現在は、サーバによる差が大きい ⁃ 短期的な解に振り回されないこと  評価にあたっては、影響範囲に注意が必要 91HTTPとサーバ技術の最新動向サーバ負荷転送データ量応答性設定・運用コスト HTTP/2 ✓ ✓ ✓ サーバプッシュ ✓ HTTPS ✓ ✓ Brotli ✓ ✓ サーバ内スクリプト ✓ ✓

HTTPとサーバ技術の最新動向

Kazuho Oku

HTTPとサーバ技術の最新動向