Nginx配置ガイド

Nginx配置ガイド
Nginxに対する学習は多くないですが、使うのがとても便利で、心の中がよく分かりません.本文は自分のnginx配置を共有して、その中のいくつかの配置項目を選んで説明します.
設定ファイル
inxプロファイルはデフォルトではhttpコンテキストの構成内容で、serverなどはしばしばサブファイルに分割され、includeによって導入される.以下は自分のnginx構成内容である.

user root;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 512;
    use epoll;
    accept_mutex on;
}

http {
    include /etc/nginx/mime.types; # mime type 
    default_type text/plain; # response  content-type
    charset utf8; #     

    server_tokens off;

    access_log /var/log/nginx/access.log main;
    log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" "$host"';

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_requests 1000000;
    keepalive_timeout 30s;

    lingering_close on;
    lingering_time 30s;
    lingering_timeout 5s;

    client_body_buffer_size 16k;
    client_max_body_size 10m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 4k;    

    client_header_timeout 15s;
    client_body_timeout 15s;
    send_timeout 15s;

    output_buffers 1 32k;
    postpone_output 1460;

    proxy_http_version 1.1;
    proxy_set_header Connection "";

    map $sent_http_content_type $expires {
        default off;
        text/html -1;
        text/plain max;
        text/css max;
        text/javascript max;
        application/javascript max;
        application/x-javascript max;
        application/json max;
    }

    proxy_cache_path /var/cache/nginx keys_zone=main_cache:4m levels=1:2 max_size=2G;

    limit_req_zone $binary_remote_addr zone=one:2m rate=5r/s;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    include /etc/nginx/default.conf;
}

この配置は自分でよく使います.たまに環境によって部分的に調整して、役割と目的の方面から部分的な内容を選んで説明します.
グローバル設定
1-4行は主にグローバル設定で、内容は比較的簡単で、自分のサーバーは長期にわたってrootユーザーだけを使用しているので、ここではいくつかのセキュリティリスクを無視して、rootユーザを使用して、ファイル権限によるアクセス異常を回避しています.
初心者がNgixをインストールして起動するときによくあるエラーは、403 Forbiddenであり、一般的にはinxがデフォルトでは、nginxというユーザをworkプロセスの所有者として使用しているため、登録されたユーザのホームディレクトリには権限が制限されており、workプロセスがユーザホームディレクトリの下のリソースにアクセスする権限がないため、403に戻る.
accept_mutex
inxは通常、複数のworkプロセスをmasterプロセスによって調整し、accept_mutexがオープンすると、workプロセスは順番に新しい接続を受信します.この時、各workプロセスに割り当てられた負荷は相対的に均衡しています.accept_をオフにすると、mutexは、新しい接続が到着すると、異なるworkプロセスが「争奪」の形で接続を獲得する必要がある.システムが正常な負荷の下で運行している場合、短い争奪は一部のシステムの資源の消耗が高すぎると浪費してしまうので、accept_を開くことを選択します.mutexはこのような浪費を避ける.
acceptを開いてもmutexは複数のworkerで得られた接続を相対的に均衡させることができますが、必ずしも利点ではありません.10のworkerが存在すると仮定して、100の接続要求がacceptを開いています.mutexの場合は各ワーカーに10個ずつ割り当てられますが、1分後に100個の接続要求が来ました.この時、一部のワーカーは早く自分の手元に10個の接続を処理しました.また、一部のワーカーは入手したのが面倒な仕事なので、まだ生きているうちに10個の接続を続けています.この100個を10個のワーカーに接続するのはちょっと無理です.一部のウォーカーの負荷が高すぎて他の問題を引き起こす可能性があります.このシーンは完全に自分の仮想です.この可能性があることを示すために、主観的には確率が非常に少ないと思います.
server_tokens
ふだんは珍しいですが、機能はとても簡単です.OfficeはレスポンスヘッドServerにinxバージョンの情報を隠しています.外部にもっと多くのinx関連情報を知られたくない時に使えます.
sendfile
通常は、クライアントに静的リソースを送信する場合、データをハードディスクからメモリに読み出して、writeを介してメモリからsocketに書き込む必要があります.このプロセスのデータの流れは、disk-kersnel buffer->user-kersnel socket buffer->プロトコルスタック->doneです.全体のプロセスは、4回のuser spaceとkersnel spaceコンテキスト切り替えと4回のデータコピーに関する.
sendfileシステムの呼び出しの目的は、ネットワークを介して2つのローカルファイル間で行われるデータ転送プロセスを簡略化することであり、そのデータの流れは、disk-kersnel buffer->プロトコルスタック->doneであり、全体のプロセスは2回のuser spaceとkersnel spaceのコンテキストの切り替えと2回のデータコピーだけであり、read/writeよりも半分のコンテキストの切り替えとデータのコピー回数が減少した.従って性能を向上させることができる.
inxでsendfileの構成オプションを開けば、sendfileシステムの呼び出しによる最適化を楽しむことができますが、この最適化は静的リソース処理のみに有効で、逆エージェントには機能しません.これはsendfileではデータソースのハンドルはファイルのハンドルだけであり、逆エージェントの両端はsocketのハンドルであり、sendfileを使用できなくなるためです.
sendfileシステムの呼び出しにより、データがuser spaceを通過しないため、nginxのoutput-filterと競合しています.例えば、同じコンテキストでgzipとsendfileを同時に開くと、sendfileが無効になります.
tcp_nopsh&tcp_nodelay
この二つのパラメータは特に内容が多くて、詳しく説明しません.簡単に言えば、tcp_を開けてください.nopshは、小さなパケットを一定のサイズに蓄積してからネットワークに送信するという意味で、tcp_を開きます.nodelayはどの小さいパケットも直接ネットワークに送信するという意味です.
この二つのパラメータは衝突したように見えますが、実は違っています.同時にsendfileを開けます.tcp_nopshとtcp_nodelayの場合、リソースに対してinx会を送信します.

は、パケットがお客様に送信される前に満杯となった

であることを保証する.

最後のパケットに対して、tcp_nopushは削除され、TCPの即時送信が許可され、200 msの遅延がない

keepalive_requests
このパラメータは、単一のkeepalive接続を制御するために用いられ、requestの最大数を送信することができ、デフォルトでは100であり、一つのkeepalive接続が100個以上の要求を送信すると、サービス端末は接続を切断する.全体的なrequest数を制限するシーンは、単一のkeepalive接続で必要とされるとは考えられないので、この設定は制限がないことを示す大きな値を設定します.
リングリング＊
設定中の3つの値は、実際にはデフォルトの値です.設定において、遅延クローズという特性を明示的に表現するために、HTTP接続をオフにしようとすると、すぐにTCP接続をオフにするのではなく、書き込みを停止してから30 sまたは5 s連続してデータを受信してからTCP接続を完全にオフにします.
postpone_out put
クライアントのデータ転送を遅延させ、少なくとも指定されたサイズのバイトのデータをinxに送信させる場合には、nginxレベルでTCP_CORKと同様に最適化された送信を開始します.
map$sent_http_コンテント.type$expires
mapコマンドは、一つの変数値をマッチ規則に従って他の変数にマッピングすることができ、ここでは応答content-typeに対して異なる失効値をマッピングし、serverでは以下のように使用する.

server {
    listen 80;
    server_name cdn.amsimple.com;

    gzip_comp_level 9;
    expires $expires;

    location / {
        root /root/amsimple/release/static;
    }
}

proxycacheパス
プロキシキャッシュパーティションを宣言して、逆プロキシの上流の戻り結果をキャッシュします.詳細な説明はこのブログを参照してもいいです.serverでの使用:

server {
    # ...
    location ~* \.html$ {
        root /root/amsimple/release/static/html;
        try_files /$uri /$uri/index.html @amsimple;
    } 

    location @amsimple {
        proxy_cache main_cache;
        proxy_cache_valid 200 1h;

        proxy_cache_lock on;
        proxy_cache_use_stale updating;

        proxy_pass http://amsimple;
    }
}

上記の構成は.拡張子の応答に対してキャッシュ処理を行いましたが、アップストリームではリソース生成のためのオーバーヘッドが比較的高いです.これまでの内容は常に変化しておらず、1時間のキャッシュタイムは許容できます.
limit_req_.zone
IP制限要求周波数により、前の文章で詳細に説明しましたが、ここで省略します.
締め括りをつける
本来は自分のnginx配置を共有するつもりですが、文章を書く過程で知識だけでなく、以前の誤りも発見されました.

sendfile、tcp_nopsh、tcp_nodelayは共存できますが、もっと具体的な詳細は分かりません.推測tcp_nopushはsendfileに対してだけ有効で、tcp_nodelay対write呼び出し有効

postpone_out putは1460を制限しますが、その内部の詳細はどうですか?sendfileはこの特性と関係がないですか?

この二つの疑惑はGoogleを通じていい答えが見つからないので、真大神さんの指導が必要です.
ブログの記事