読者です 読者をやめる 読者になる 読者になる

Nginx 1.9.4 HTTP/2 のconf パラメータ設定項目

Nginx 1.9.5でHTTP2がサポートされました。パラメータ自体は本記事から変わりません。(2015/09/23)


http2_max_field_sizeの挙動が変わったようです (2015/11/12)
http://hg.nginx.org/nginx/rev/1f26bf65b1bc


Nginx 1.9.4 + patch.http2-v5_1.9.4.txtで使えるhttp2のチュニーングパラメータ。

ココらへんも参考に


公式の資料を参考にしつつ、ちょっと調べてみたけど結構分からず...
http://nginx.org/patches/http2/README.txt

(間違ってる可能性があるので注意)

設定例

    http2_recv_buffer_size 256k;
    server {
        listen  8080 http2 ;

        http2_max_concurrent_streams 128;
        http2_streams_index_size     32;
        http2_idle_timeout           30s;
        http2_recv_timeout           3m;
        http2_chunk_size             8k;
        http2_max_field_size         4096;
        http2_max_header_size        16384;
        http2_pool_size              4096;

        location / {
          root /usr/share/www;
        }
    }

パラメータ

http2_recv_buffer_size
  • Workerごとの受信データのバッファサイズ(ngx_http_v2_read_handler中で使われる)
  • recvでソケットからデータを取り出す際のバッファのサイズである。
available = h2mcf->recv_buffer_size - 2 * NGX_HTTP_V2_STATE_BUFFER_SIZE;
do {
  ...
  n = c->recv(c, end, available);
  ...
} while (rev->ready);
  • デバッグログのログで、バッファに対して読み込んだデータ量が確認できる。
2015/09/26 20:53:08 [debug] 7154#0: *11 recv: fd:21 1448 of 262112                        
2015/09/26 20:53:08 [debug] 7154#0: *11 recv: fd:21 5792 of 262112
  • デフォルト値で十分大きいように思う。
http2_max_concurrent_streams
  • SETTINGSで送られるSETTINGS_MAX_CONCURRENT_STREAMS
  • ストリーム上限に達してる状態で、HEADERSフレームを受け取ると以下の様なエラーになる
2015/09/10 23:35:57 [info] 4069#0: *1 concurrent streams exceeded 0 while processing HTTP/2connection, client: x.x.x.x, server: 0.0.0.0:443
  • ブラウザ等のconcurrent_streams分はあっても良いと思う
  • サーバリソース足りないようなら減らしても良いかなと
http2_streams_index_size
  • ストリームIDからそのストリーム情報を引くためのstreams_index配列のサイズ

詳しくは別途記事を書きました「Nginxのhttp2_streams_index_sizeパラメータについて(2015/09/22)

http2_recv_timeout
  • フレームを処理するのに必要なデータが足りず、追加のデータが送られてくるまで待つ。その状態でhttp2_recv_timeout経つと、タイムアウトとなる。
2015/09/11 00:26:03 [info] 4735#0: *5 client timed out (110: Connection timed out) while processing HTTP/2 connection client: x.x.x.x, server: 0.0.0.0:443
  • サーバのコネクション数次第。とは言え、来るべきデータが来ない状態なので、正常な状態では無いと思う。少なくていいと思う。
http2_idle_timeout
  • http2のコネクションがアイドル状態。いかなるフレームも処理してない状態から、コネクションを切断するまでのタイムアウト時間。
  • keepalive handlerにうつってからコネクションが切断される
2015/09/11 00:31:55 [debug] 4835#0: *4 event timer: 3, old: 1441899119905, new: 1441899119946
2015/09/11 00:31:59 [debug] 4835#0: *4 event timer del: 3: 1441899119905
2015/09/11 00:31:59 [debug] 4835#0: *4 http2 keepalive handler
2015/09/11 00:31:59 [debug] 4835#0: *4 close http connection: 3
2015/09/11 00:31:59 [debug] 4835#0: *4 SSL_shutdown: 1
  • サーバのコネクション数次第。あとは、サイトの特性も
http2_chunk_size
  • DATAフレームのフレームサイズ。
  • 大きなファイルをHTTPレスポンスで返すときなどに、このサイズに分けられたDATAフレームになる
2015/09/11 02:51:14 [debug] 5907#0: *4 http2:13 create DATA frame 00000000027112E8: len:8192 flags:0
2015/09/11 02:51:14 [debug] 5907#0: *4 http2:13 create DATA frame 00000000027113F0: len:8192 flags:0
2015/09/11 02:51:14 [debug] 5907#0: *4 http2:13 create DATA frame 00000000027114F8: len:8192 flags:0
  • 小さい値だと送るDATAフレームの数が多くなりオーバヘッドが増える、大きい値だとHead-of-line_blockingによりプライオリティの処理を損なう可能性がある。
  • 値を大きくしても、SETTINGS_MAX_FRAME_SIZEのデフォルト値である16,384が使われる事が多い。
  • 個人的には16kを指定してもいいと思う(locationコンテキストでも使えるので、download系のpathだけとか)
http2_max_field_size
  • 一つのリクエストヘッダのサイズ上限
client exceeded http2_max_field_size limit
http2_max_header_size
  • リクエストヘッダ全体のサイズ上限
client exceeded http2_max_header_size limit
http2_pool_size
  • コネクション初期化時に確保されるメモリプールサイズ

各種フレームを生成する際にプールよりメモリを確保する

  • PINGフレームを受け取った際に、ACKを返すためのPINGフレームを生成する際
  • WINDOWS_UPDATEフレームを生成する際
  • RST_STREAMフレームを生成する際
  • GOAWAYフレームを生成する際
  • 個人的には、増やす必要はないと思う