nginx バージョンアップ動向（2014/01〜2014/12）

Nginx&バージョンアップ動向TAKAMURA'Narimichi'（@nari_ex）

2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 1

http://www.nari64.com/?page_id=36

このスライドの内容• バージョンアップ動向（ほとんどこれ）

• stable(ブランチと(mainline(ブランチの話（おまけ）


バージョンアップ動向• 一年分追いかけました（2014/01～2014/12）

• Change,.Feature,.Security.のみに注目（Bugfixは無視）

• 多すぎたので重要っぽいものを厳選

• ngx_http_mp4_module.は更新頻度が高いけど今回は取り上げてないです


Nginx&1.5.9（2014.01.22）• Feature

• limit_rate,が,SPDY,に対応

• コネクションごとの接続帯域をしぼる

• ssl_session_(ckets

• SSLセッションチケットに対応(RFC,5077)


SSL#が抱える問題• SSL$が抱える問題点

• 初回のハンドシェイク時の処理が重い→$二回目以降は省略したい

→"SSLセッションチケットの出番


SSL#セッションキャッシュ

1.初回接続

2.セッションIDをクライアントとサーバの両方に保存

3. 2回目以降はセッションIDを照合することで接続可能→ハンドシェイクを省略

問題点!"サーバ側でハンドシェイクのデータを共有する必要あり2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 6

SSL#セッションチケット

1.初回接続

2.サーバから暗号化されたセッションチケットをクライアントへ渡す。この内容は暗号化されているためサーバしか解読できない

3. 2回目以降は（クライアントから送られる）セッションチケットを確認することで接続可能

※!なお、セッションチケットを暗号化する鍵ファイルは予め共有2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 7

Nginx&1.5.10（2014-02-04）• Feature

• the)ngx_h.p_spdy_module)が)SPDY)3.1)をサポート

• 3.0)と比較すると)セッション単位のフロー制御ができるようになった


Nginx&1.5.11（2014-03-04）• Security

• ngx_h/p_spdy_module6モジュールの6SPDY6の実装における任意のコードを実行される脆弱性に対応

CVE$2014$0088


http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-002327.html

Nginx&1.5.12（2014-03-18）• Security

• SPDY-のバッファオーバーフロー問題の対策

• Feature

• Proxy&Protocol&に対応

• これに伴い関連する変数が新しく実装されたCVE$2014$01332015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 10

http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-001833.html

L4#ロードバランサの問題点• 接続元IPアドレスがわからない

• →%L7の場合はHTTPヘッダに%X+Forwarded+For%フィールドを追加すればよい

• L4%ではHTTPヘッダをいじれない


Proxy&Protocol

• クライアントの接続情報をTCPヘッダに付加する→&振り分け先のサーバが&Proxy&Protocol&に対応していれば接続元の情報が分かる


Proxy&Protocol&の設定例listen 80 proxy_protocol;

...

set_real_ip_from 172.31.0.0/20;real_ip_header proxy_protocol;

※!AWSのELBは2013年8月に対応2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 13

http://aws.typepad.com/aws_japan/2013/07/elastic-load-balancing-adds-support-for-proxy-protocol.html








Nginx&1.5.13（2014.04.08）• Change

• variables_hash_max_size(が(512(→(1024

• 変数を保持するハッシュテーブルの最大エントリのサイズ

• types_hash_bucket_size(が(32|64|128（プロセッサ依存）→(64

• types(ハッシュテーブルを保持するエントリのサイズ2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 14

Nginx&1.7.0&（2014-04-24）• Feature

• access_log)で)if)が利用可能に

• バックエンドのサーバを公開鍵認証で照合可能に

• バックエンドのサーバの照合時にSNIを利用可能に

• proxy_ssl_server_name on(


access_log)で)if)を使う例

静的ファイルへのアクセスログを省く設定map $uri $loggable { ~.*\.(gif|jpg|png|ico|js|css)$ 0; default 1; }access_log /var/log/nginx/access.log ltsv if=$loggable;


proxy_ssl_verify-の設定例proxy_ssl_verify on;proxy_ssl_verify_depth 3;proxy_ssl_trusted_certificate /etc/ssl/certs/hogehoge.pem;proxy_pass https://s3-ap-northeast-1.amazonaws.com/XXX/


Nginx&1.7.1&（2014-05-27）• Feature

• ログを!syslog!へ投げられるようになった

• 商用版（NGINX,Plus）では実装済みだった

• upstream_cookie_...,変数

• upstream!サーバによって送信されたクッキーを参照可能に


Nginx&1.7.2&（2014-06-17）• Feature

• upstream)ブロックで)hash)が利用可能に

• free)な共有メモリブロックをデフラグするようになった


今までの!upstream!振り分けの問題点• デフォルトでは"ip_hash"のみ

• アクセス元IPアドレスベース

• 柔軟な振り分けポリシーを設定するにはサードパーティモジュールが必要

→"hash$ディレクティブの実装により任意の変数を指定可能に！


upstream)ブロックで)hash)を用いる例

url$ベースで振り分けるupstream backend { hash $request_uri; server 192.168.0.1:8080; server 192.168.0.2:8080; }

location / { proxy_pass http://backend;}


Nginx&1.7.3&（2014.07.08）• Feature

• SSL証明書のパスワードをファイルから読み取り可能に

• HTTP-ETag-に関する機能追加

• >-weak-en4ty-tags-are-now-preserved-on-response-modifica4ons,-and-strong-ones-are-changed-to-weak.

• >-cache-revalida4on-now-uses-IfENoneEMatch-header-if-possible.


Nginx&1.7.4&（2014-08-05）• Security

• POODLE/脆弱性対応

• Feature

• 16進数の大文字を含んだURIのエスケープが可能に

• BoringSSL、LibreSSL+を用いてビルド可能に


新しい!SSL!ライブラリの話• OpenSSL(の(Heartbleed(脆弱性を受けて、独自にフォークをして開発されはじめた

• Boringssl:(Google(がフォーク

• Libressl:(OpenBSDの開発者がフォークNginx&2.7.4&で上記ライブラリを利用してビルド可能になった


Nginx&1.7.5&（2014.09.16）&その1

• Security

• Virtual-Host-Confusion-攻撃を実行される脆弱性に対応

• Change

• stub_status-が引数なしになった

• stub_status on;-ではなく-stub_status;


Nginx&1.7.5&（2014.09.16）&その3

• Feature

• add_header'ディレクティブで'always'パラメタが利用可能に


add_header'に'always'が使えるとなにがいいのか• 通常（always'を付与しない）の場合、特定のレスポンスコードの場合にのみヘッダの追加が有効になる。

• →'200,'201,'204,'206,'301,'302,'303,'304,'307

→"always"パラメタを付与することでステータスコードに関係なくヘッダの追加が可能


Nginx&1.7.6&（2014.09.30）• Change

• "limit_zone"0ディレクティブの廃止

• 保持する共有メモリ領域のパラメタ指定

• limit_conn_zone,,limit_req_zone,にて複数の,key,を指定可能に

• 今までは1つしか指定できなかった2015/01/19'社内プロダクト勉強会'('TAKAMURA'Narimichi（topotal） 29

limitconnzone,*limitreqzone

リクエスト数やコネクション数を制限する機能複数条件を指定して接続制限をかけられるようになったlimit_conn_zone $binary_remote_addr zone=perip:10m;limit_conn_zone $server_name zone=perserver:10m;

server { ... limit_conn perip 10; limit_conn perserver 100;}


Nginx&1.7.7&（2014-10-28）その1

• Change

• Vary+ヘッダがある場合も、バックエンドのレスポンスをキャッシュするようになった


Nginx&1.7.7&（2014-10-28）その2

• Feature

• (proxy|fastcgi|scgi|uwsgi)_force_ranges

• バックエンドのサーバからのキャッシュおよびキャッシュされていない応答の両方において、byte8rangeのサポートを有効にする


Nginx&1.7.8&（2014.12.02）&その1

• Change

• log_format*ディレクティブが*h,p*ブロックでのみ利用可能に

• (proxy|fastcgi|scgi|uwsgi)_cache_lock_age:ディレクティブ

• ロックが解放され、（おそらく別の上位サーバへ試行し）キャッシュを再作成しようとする


Nginx&1.7.8&（2014.12.02）&その2

• Feature

• ssl_cer,ficate,/ssl_cer,ficate_key,/ssl_password_file/が/proxy,/

uwsgi/に対応

• tcp_nodelay/が/SPDY/に対応

• Keepalive/時に/TCP_NODELAY/フラグを立てるかどうか


Nginx&1.7.8&（2014.12.02）&その3（時間あれば）• Change

• proxy_cache_/meout3後は、キャッシュが作成されなくなった

• 再作成したいなら*cachelock_age3を使えという意図っぽい

• proxy_cache_min_uses3利用時に生じるケース3


Nginx&1.7.9&（2014.12.23）&その1

• Feature

• (proxy|fastcgi|scgi|uwsgi)_cache7変数

• expires7変数

• autoindex_format.ディレクティブ

• html7だけではなく、xml7や7json7を選べるようになった


autoindex*とは• みなさんご存知のこれです（下記は"html"形式）

• この情報が"json"や"xml"で返せるようになった


stable'ブランチと'mainline'ブランチ


mainline'が'1.6'にならなかった件


ブランチの遷移図


答え• stable(のバージョンが(1.4(から(1.6(になった

• mainline（1.5）がフォークされたもの

• 1.4(はすでに(EOL(

• このタイミングで(mailine(は(1.7(となった


どっちがいいんだろう...

作者曰く、大概の場合は!mainline!を使うべしIn#general,#you#should#deploy#the#NGINX#mainline#branch#at#all#

9mes.#

→"なんでか調べた


stable'と'mainline'の違い• stable(は新機能が入らない

• stable(はバグが少ないという意味ではない

• mainline(はバグ修正がすべて行われる

• stable(は深刻なバグに関する修正のみが行われる参考:"NGINX"1.6"and"1.7"released


http://nginx.com/blog/nginx-1-6-1-7-released/

mainline'ではなく'stable'を用いたほうがよいケース

以下の場合は!stable!を用いたほうがよい• サードパーティモジュールとの互換性が気になる場合

• 新機能のリリースで紛れ込んだバグを回避したい参考:"NGINX"1.6"and"1.7"released


http://nginx.com/blog/nginx-1-6-1-7-released/

感想• Apache(にはあって(Nginx(にない機能が少なくなってきた

• 便利な変数が増えてるので(lua(を用いていろいろ応用できそう

• パラメタ調整が勝手に行われたりするので、バージョンアップだけでやや性能が上がりそう

• 副作用に要注意


nginx バージョンアップ動向（2014/01〜2014/12）

Technology