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

Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
HTTPとサーバ技術の最新動向
DeNA Co., Ltd.
Kazuho Oku
1

自己紹介
 名前: 奥一穂
 ウェブ関連の基盤技術プログラマ
⁃ 主な業績（公開のもの）
• 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とサーバ技術の最新動向

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

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

サーバ技術の評価軸

サーバ技術の評価軸
 サーバ負荷
 転送データ量
 応答性
 設定・運用コスト

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

転送データ量の削減
 主な受益者
⁃ 大規模事業者
⁃ モバイル回線のユーザ
 参考:
⁃ Amazon EC2のネットワーク価格: 〜$0.05/GB
• 10Gbps * 1 year = 40PB / year → 2.4億円 / 年

応答性
出典: http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html
 レスポンスタイム短縮 → 売上増加

HTTP/2の基本

誕生の背景

転送データ量は増大中
出典: http://httparchive.org/trends.php?s=All&minlabel=Aug+1+2011&maxlabel=Aug+1+2015#bytesTotal&reqTotal

バンド幅も増大中
 エンドユーザのバンド幅は年率50%で増加（ニールセン
の法則）
出典: http://www.nngroup.com/articles/law-of-bandwidth/

未来はバラ色？

ページロード時間はバンド幅に比例しない
出典: More Bandwidth Doesn't Matter - 2011 Mike Belshe (Google)
※実効バンド幅は1.6Mbps程度で頭打ちに

ページロードはレイテンシが小さいほど速い
出典: More Bandwidth Doesn't Matter - 2011 Mike Belshe (Google)

Why?

HTTP/1.1は多重性がない
RTT
request
response
request
response
client server
…
RTT
 HTTP/1.1では、1RTTあたり1リクエスト/レスポンスし
か送受信できない
⁃ RTT=ラウンドトリップタイム
• レイテンシの大きさを表す値
 緩和策:複数のTCP接続を使う
⁃ 同時6本が一般的
• 1RTTあたり6リクエスト!!!
• それでも遅い

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

レイテンシは今後も小さくならない
 光の速度はかわらない
⁃ アメリカまで光ファイバーで往復すれば80ミリ秒
 携帯回線はレイテンシが大きい
⁃ LTE ~ 50ms

やばい！ウェブが遅くなってきた！

どうしよう？

解決策：レイテンシに負けないプロトコルを作る

HTTP/2!

HTTP/2
 RFC 7540 (2015/5)
⁃ GoogleのSPDYプロトコルの実験を参考に規格化
 基本的な技術要素
⁃ バイナリプロトコル
⁃ 多重化
⁃ ヘッダ圧縮

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

典型的な通信フロー
（クライアントが送信）
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>
…
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>…

多重化
 同時に100以上のリクエストを発行可能
 任意のタイミングでリクエスト送信可能
 レスポンスの順序に制限なし
 レスポンスを織り交ぜ可能
⁃ DATAのstream IDを見よ
client server
…

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

ヘッダ圧縮 (2)
 HPACK (RFC 7541)として規定
 技術要素
⁃ 初見の文字列は、静的ハフマン圧縮
⁃ ２回目以降は、前回出現時からのオフセットで表現
⁃ 頻出文字列は、固定テーブルのインデックスで表現

ヘッダ圧縮 (3)
 想定例:
⁃ https://example.com/ にアクセス
⁃ 参照されている /banner.jpg と /icon.png をロード

ヘッダ圧縮 (4)
 / へのリクエスト
(圧縮前: 291バイト)
:method: GET
:scheme: https
: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: ...

ヘッダ圧縮 (5)
 /banner.jpg へのリクエスト
:method: GET
:scheme: https
:path: /banner.jp
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
referer: https://example.com/
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: ...
73 8f 9d 29 ad 17 18 60 be 47 4d ...(17 bytes) # referer: ...

ヘッダ圧縮 (6)
 /icon.png へのリクエスト
:method: GET
:scheme: https
:path: /icon.png
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
referer: https://example.com/
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: ...
bf # referer: ...

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

ここまでのまとめ
 HTTP/2の基本
⁃ 多重化によりレイテンシの影響を低減
⁃ ヘッダ圧縮により通信量を低減
 上記２点を体感できるデモ
⁃ https://www.symfony.fi/entry/compare-
resource-loading-between-http-2-and-http-1-1

HTTP/2におけるレスポンスタイム最適化

HTTP/2のレスポンスタイムベンチマーク
 コンテンツ系ウェブサイトが表示されるまでの時間測定
 初期描画(first-paint)までの時間に大差、H2Oが最短

差が出た理由: 優先度制御

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

Firefoxの優先度制御
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

H2Oの優先度制御実装
 H2Oは
⁃ Webブラウザの指示に従い、バンド幅を配分
• 割当はHTTP/2の規定どおり
⁃ 優先度制御の粒度が細かい
• 16KB単位でストリームを切り替え
• 約64KB単位でバッファリング
 全てのHTTP/2サーバが優先度制御を（正しく）実装して
いるわけではない

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

優先度制御 (Chromeの場合)
 重みづけのみを使用（依存関係は未使用）
 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

優先度制御 (Chromeの場合)
 重みはHTML>CSS>JS>画像
 だが、画像のファイル数が多いと、画像がバンド幅の過
半を使用してしまう
Root
HTML
weight: 256
CSS
weight: 220
JS
weight: 183
Image
weight: 110
Image
weight: 110
Image
weight: 110

優先度制御 (他のウェブブラウザの場合)
 Edge – 優先度制御なし
 Safari – 優先度制御なし
 サーバ側でなんとかしないと…
Root
HTML
weight: 16
CSS
weight: 16
JS
weight: 16
Image
weight: 16
Image
weight: 16
Image
weight: 16

H2Oによる優先度の書き換え
 クライアントが依存関係ツリーを構築しない場合に
 レンダリングをブロックしそうな content-type のレス
ポンスを最優先で配信
Root
HTML
weight: 16
CSS
weight: max
JS
weight: max
Image
weight: 16
Image
weight: 16
Image
weight: 16
(internal root)

優先度書き換えの効果
 初期描画までの時間が大幅に改善
⁃ 測定結果はChrome/43
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

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

サーバプッシュ

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

 例: RTT=50ms, アプリサーバの処理時間=200ms
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

 CDNによるウェブ高速化にも応用可能
⁃ アプリサーバの応答を待つ間も回線を有効活用可能
⁃ アプリ提供者は、その分、アプリサーバの設置拠点を
減らすことが可能に
req.
push-asset
HTML
push-asset
push-asset
push-asset
client edge server (CDN) app. server
req.
HTML

 実用にむけた課題:
⁃ （クライアントに頼らない）優先度制御
⁃ プッシュの起動方法
⁃ ブラウザキャッシュとの兼ね合い

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

サーバプッシュの使い方 (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) が対応
⁃ 問題: アプリサーバが応答を返すまでプッシュ不可能

サーバプッシュの使い方 (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/

サーバプッシュ vs. ブラウザキャッシュ
 キャッシュ済のファイルはプッシュしたくない
⁃ バンド幅（と場合によっては時間）のムダ
 キャッシュの有無を判断する方法は?
⁃ ブラウザキャッシュ内の状況を確認するためにリクエ
スト/レスポンスを送信してはいけない
• そのために1RTTかかるとプッシュのメリットがなくなる

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 を更新

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

 fingerprint を含むリクエストの例
:method: GET
:scheme: https
: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とサーバ技術の最新動向

サーバプッシュまとめ
 ポテンシャルはあるが使いにくい（と思われてきた）
⁃ cache digest がそれらの問題を解決
⁃ 今後の期待:
• 仕様の標準化
• ウェブブラウザや、他のサーバでの実装

HTTPS化とサーバ負荷

ベンチマーク:静的ファイルの配信
 ベンチマーク環境: AWS c3.8xlarge (2台)
⁃ クライアントとサーバは、同一network placement
 ファイルサイズ: 612バイト (デスクリプタキャッシュ:on)

HTTPS/2 は HTTP/1 より高速
 主要ブラウザは HTTP/2 に HTTPS の場合のみ対応
 TLS の負荷は HTTPS に移行しない理由にならない
※リザンプションの設定を忘れないこと

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

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

Session Tickets
 TLSの「拡張」 (RFC 5077)
 手法:
⁃ フルハンドシェイクの結果を、サーバが独自に暗号化
＆署名して、クライアント側にticketとして送信
⁃ クライアントは再接続の際にticketをサーバに提示
⁃ サーバはticketの署名を検証し、ticketを復号して再
接続に使用

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

Webサーバの対応状況
Session Cache Session Tickets
サーバ単独サーバ間同期サーバ単独サーバ間同期
Apache ○ ○ 手動更新手動更新
Nginx ○ × 手動更新手動更新
Varnish (hitch) ○ ○ 未対応
H2O ○ ○ 自動更新自動更新

HTTPS化によるオーバヘッドまとめ
 HTTPS化と同時にHTTP/2化すれば良い
⁃ 利点:
• ネットワークコストの削減
• 応答性の改善
⁃ サーバコストは同等か減少（するだろう）
• リザンプションの設定に注意
 リザンプションが困難な場合の緩和策: ECDSA

Brotli

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

Brotliの圧縮率と圧縮・展開速度
 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

Brotliの対応状況
 ウェブブラウザの対応状況
⁃ Firefox 48
⁃ Chrome 49 (予定)
⁃ ※ HTTPSのみ
 ウェブサーバの対応状況
⁃ Apache – 不明
⁃ Nginx – Google がサードパーティモジュールを提供
⁃ H2O – 1.8で対応予定

Brotliまとめ
 Brotliは転送データ量削減に効果アリ
⁃ 事前圧縮と実行時圧縮のどちらにも適用可能
 ウェブブラウザの対応が見込まれる
⁃ ただしHTTPSのみ
 サーバ運営者は使わない理由がない

ウェブサーバ内でのスクリプト実行

ウェブサーバ設定の黒魔術: 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 から離れられません」

上級黒魔術
 ウェブサーバ内でのスクリプト実行
 実装例:
⁃ Apache – mod_perl, …
⁃ nginx – lua, mruby, nginScript (JavaScript方言)
⁃ OpenRestry – lua
⁃ H2O - mruby

ウェブサーバ内でのスクリプト実行
 メリット:
⁃ 正規表現以上に複雑なルールが書ける
⁃ mod_rewriteよりも可読性が上がる
⁃ スクリプトの単体テストもできる
⁃ 外部サーバ（DB等）への問い合わせもできる
 懸念材料:
⁃ 特定のウェブサーバへのベンダロックイン
⁃ 外部サーバへ問い合わせた際のパフォーマンス劣化

ベンダロックインを避ける
 ロックインが発生する理由:
⁃ ウェブサーバ毎にスクリプト言語やAPIが異なるから
 ウェブアプリ記述に使われるスクリプト言語を使いたい
⁃ 具体例: ruby, JavaScript
⁃ 理由:
• 学習コスト
• 構成の柔軟性
⁃ 同一コードを、アプリケーションサーバでも動かしたい
 APIついても同様

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
等でも動作（多少の変更は必要）

サーバ内スクリプトからの外部サーバアクセス
 多くのウェブサーバはイベントドリブンな実装
⁃ → サーバ内スクリプトから外部サーバへ問い合わせ
る間、イベントループをブロックできない
 サーバ内スクリプトで、非同期プログラムを書くの？

コルーチンを用いた非同期化
 手法:
⁃ サーバ内スクリプトをコルーチンで実行
⁃ 外部への問い合わせ時にコルーチンを切り替え、問い
合わせをサーバのイベントループで実行
⁃ 結果が得られたら、再びコルーチンを切り替え、サー
バ内スクリプトの実行を継続
 採用実装:
⁃ OpenRestry – lua
⁃ H2O – mruby
⁃ nginx – nginScript (予定)

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

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

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]]

非同期タスクを用いた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

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

まとめ

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

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

More Related Content

What's hot

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

More from Kazuho Oku

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