Nginx クイック スタート例の分析

なぜ nginx を使用するのでしょうか?

現在、nginx の主な競合相手は Apache ですが、ここでは、誰もが nginx の利点をよりよく理解できるように、編集者が 2 つを簡単に比較します。

1. Web サーバーとして:

Apache と比較して、nginx は使用するリソースが少なく、より多くの同時接続をサポートし、より高い効率を反映します。ホスティングプロバイダー。高い同時接続の場合、nginx は Apache サーバーの良い代替手段です: nginx は、米国の仮想ホスト ビジネスの上司によってよく選ばれるソフトウェア プラットフォームの 1 つであり、最大 50,000 の同時接続の応答をサポートできます。 nginx に感謝します。開発モデルとして epoll と kqueue を選択しました。

負荷分散サーバーとしての nginx: nginx は、内部で Rails および php プログラムを直接サポートして外部サービスを提供したり、http プロキシ サーバーとして外部サービスをサポートしたりできます。 nginx は C で書かれており、システム リソースのオーバーヘッドと CPU 使用効率は perlbal よりもはるかに優れています。

2. nginx の設定はシンプルですが、Apache は複雑です:

nginx は特に起動が簡単で、たとえ実行中でも中断することなくほぼ 7*24 実行できます。再起動の必要がなく、サービスを中断せずにソフトウェアのバージョンをアップグレードすることもできます。

nginx の静的処理パフォーマンスは、Apache の 3 倍以上です。Apache の php サポートは比較的シンプルです。nginx は他のバックエンドと併用する必要があります。Apache には nginx よりも多くのコンポーネントがあります。

3. 主要な違いは次のとおりです:

apache は同期マルチプロセス モデルであり、1 つの接続が 1 つのプロセスに対応しますが、nginx は非同期であり、複数の接続 (10,000レベル) ) はプロセスに対応できます。

4. 2 人の専門分野は次のとおりです:

nginx の利点は、少ない CPU メモリ使用量で静的リクエストを処理できることであり、Apache は動的リクエストの処理に適しています。通常、フロントエンドは圧力に抵抗するためにリバース プロキシとして nginx を使用し、動的リクエストを処理するために Apache がバックエンドとして機能します。

nginx の基本的な使用法

システム プラットフォーム: centos リリース 6.6 (最終) 64 ビット。

#1. コンパイル ツールとライブラリ ファイルをインストールします

##2. まず、pcre をインストールします

1. pcre の機能は、nginx が書き換え機能をサポートできるようにすることです。 pcre インストール パッケージをダウンロードします。ダウンロード アドレス:

2. インストール パッケージを解凍します:

3. インストール パッケージ ディレクトリを入力します

4. コンパイルしてインストールします

5. チェックを入れますpcre バージョン

3. nginx をインストールします

#1. nginx をダウンロードします。アドレス:

2. インストール パッケージを解凍します

3. 次のように入力します。インストール パッケージ ディレクトリ

4. コンパイルしてインストール

#5. nginx バージョンの確認

#この時点で、nginx のインストールは完了です。

4. nginx の設定

nginx を実行するためのユーザー www を作成します:

#nginx.conf を設定し、置き換えます/usr/local/webserver/nginx/conf/nginx.conf の内容は次のとおりです。

設定ファイル ngnix.conf コマンドが正しいことを確認してください:

5. nginx の起動

nginx 起動コマンドは次のとおりです:

6. サイトにアクセスします

ブラウザから設定されたサイト IP にアクセスします:

nginx の共通手順の説明

1. メインのグローバル設定

nginx は実行時に特定のビジネス機能と対話します。 (http サービスや電子メール サービス プロキシなど)、作業プロセスの数、実行中の ID など。

woker_processes 2
構成ファイルの最上位のメイン セクションで、ワーカー ロール内のワーカー プロセスの数、マスター プロセスが処理リクエストを受信して​​ワーカーに割り当てます。 。この値は、単純に cpu grep ^processor /proc/cpuinfo | wc -l のコア数に設定できます。これは auto 値でもあります。ssl と gzip がオンになっている場合は、同じか偶数に設定する必要があります。論理 CPU の数が 2 倍になり、I/O 操作が削減されます。 nginx サーバーに他のサービスがある場合は、それらを適切に減らすことを検討できます。

worker_cpu_affinity
も本編に書かれています。同時実行性が高い状況では、CPU スティッキーを設定することで、マルチ CPU コアの切り替えによって発生するレジスタなどのオンサイトの再構築によるパフォーマンスの損失が軽減されます。 worker_cpu_affinity 0001 0010 0100 1000; (クアッドコア) など。

worker_connections 2048
イベント セクションに書き込みます。各ワーカー プロセスが同時に処理 (開始) できる接続の最大数 (クライアントまたはバックエンド プロキシ サーバーとの接続の数を含む)。 nginx はリバース プロキシ サーバーとして機能します。計算式は次のとおりです: 最大接続数 = ワーカー プロセス * ワーカー コネクション / 4 したがって、ここでのクライアント接続の最大数は 1024 になります。ただし、後続の worker_rlimit_nofile を超えることはできません。 httpサーバーとしてnginxを使用する場合、計算式は2で割ります。

worker_rlimit_nofile 10240
本文に書き込みます。デフォルトは設定なしで、オペレーティング システムの最大制限である 65535 に制限できます。

epoll を使用します
イベント セクションに書き込みます。 Linux オペレーティング システムでは、nginx はデフォルトで epoll イベント モデルを使用するため、nginx は Linux オペレーティング システムで非常に効率的です。同時に、nginx は、openbsd または freebsd オペレーティング システム上の epoll と同様の効率的なイベント モデル kqueue を使用します。 select は、オペレーティング システムがこれらの効率的なモデルをサポートしていない場合にのみ使用してください。

2. http サーバー

http サービスの提供に関連するいくつかの設定パラメータ。例: キープアライブを使用するかどうか、圧縮に gzip を使用するかどうかなど。

sendfile on
効率的なファイル転送モードをオンにします。sendfile 命令は、nginx がファイルを出力するために sendfile 関数を呼び出し、ユーザー空間からカーネル空間へのコンテキストの切り替えを減らすかどうかを指定します。通常のアプリケーションではオンに設定し、ダウンロードなどのディスク IO 負荷の高いアプリケーションで使用する場合はオフに設定すると、ディスクとネットワークの I/O 処理速度のバランスをとり、システムの負荷を軽減できます。

keepalive_timeout 65 : 長い接続タイムアウト (秒単位) このパラメータは非常に機密であり、ブラウザの種類、バックエンド サーバーのタイムアウト設定、およびオペレーティング システムの設定に関係します。システムごとに個別に設定できる記事です。長時間の接続で多数の小さなファイルが要求される場合、接続を再確立するコストを削減できますが、大きなファイルをアップロードする場合は、65 秒以内にアップロードを完了できないと失敗します。セットアップ時間が長すぎてユーザー数が多い場合、長時間接続を維持すると多くのリソースが占有されます。

send_timeout: クライアントに応答するためのタイムアウト期間を指定するために使用されます。このタイムアウトは 2 つの接続アクティビティの間の時間に制限されており、クライアントでアクティビティがないままこの時間を超えると、nginx は接続を閉じます。

client_max_body_size 10m
クライアントが要求できる単一ファイルの最大バイト数。より大きなファイルをアップロードする場合は、その制限値を設定してください。

client_body_buffer_size 128k
バッファ プロキシがクライアント リクエストをバッファリングする最大バイト数

Module http_proxy :

このモジュールは、キャッシュ機能を含む、リバース プロキシ サーバーとして nginx の機能を実装します (記事も参照)

proxy_connect_timeout 60
nginx はバックエンド サーバーへの接続タイムアウト (プロキシ)接続タイムアウト)

proxy_read_timeout 60
接続が成功した後、バックエンド サーバーへの 2 つの正常な応答操作の間のタイムアウト (エージェント受信タイムアウト)

proxy_buffer_size 4k
proxy バックエンド リアルサーバーからユーザー ヘッダー情報を読み取って保存するサーバー (nginx) のバッファ サイズです。デフォルトのサイズは proxy_buffers と同じです。実際には、このコマンドの値をより小さく設定できます

proxy_buffers 4 32k
proxy_buffers バッファー、nginx は単一接続のバックエンド リアルサーバーからの応答をキャッシュします。平均 Web ページが 32k 未満の場合は、次のように設定します。

proxy_busy_buffers_size 64k
高負荷時のバッファサイズ (proxy_buffers*2)

proxy_max_temp_file_size
proxy_buffers がバックエンドサーバーの応答内容を収容できない場合、その一部がハードディスク上の一時ファイルに保存されます。この値は、一時ファイルの最大サイズを設定するために使用されます。デフォルトは 1024m で、proxy_cache とは関係ありません。これより大きい値は上流サーバーから返されます。無効にするには 0 に設定します。

proxy_temp_file_write_size 64k
一時ファイルに応答するためにキャッシュがサーバーによってプロキシされる場合、このオプションは毎回書き込まれる一時ファイルのサイズを制限します。 proxy_temp_path (コンパイル中に指定可能) に書き込むディレクトリ。

proxy_pass、proxy_redirect 場所のセクションを参照してください。

モジュール http_gzip:

gzip on: gzip 圧縮出力をオンにして、ネットワーク送信を削減します。

1. gzip_min_length 1k: 圧縮が許可されるページの最小バイト数を設定します。ページのバイト数はヘッダーのコンテンツ長から取得されます。デフォルト値は 20 です。バイト数は 1k 以上に設定することをお勧めしますが、1k 未満の場合は圧縮がさらに進む可能性があります。

2. gzip_buffers 4 16k: gzip 圧縮結果データ ストリームを保存するために複数のキャッシュ ユニットを取得するようにシステムを設定します。 4 16k は、16k 単位でメモリを申請することを意味します。これは、16k 単位でインストールされる元のデータの 4 倍のサイズです。

3. gzip_http_version 1.0: http プロトコルのバージョンを識別するために使用されます。初期のブラウザは gzip 圧縮をサポートしておらず、文字化けが発生する可能性があるため、このオプションは以前のバージョンをサポートするために追加されました。 nginx のリバースプロキシを使用し、gzip 圧縮を有効にしたい場合は、最終通信が http/1.0 であるため、1.0 に設定してください。

4. gzip_comp_level 6: gzip 圧縮率、1 は圧縮率が最も小さく、処理速度が最も速く、9 は圧縮率が最も大きいが、処理速度が最も遅い (送信は速いが、より多くの CPU を消費する)

5. gzip_types: 圧縮する MIME タイプに一致します。指定の有無にかかわらず、"text/html" タイプは常に圧縮されます。

6. gzip_proxied any: nginx がリバース プロキシとして使用されている場合に有効になり、バックエンド サーバーから返された結果の圧縮を有効にするか無効にするかを決定します。バックエンドサーバーは、「via」ヘッダーを含むメッセージを返す必要があります。

7. gzip_vary on: http ヘッダーに関連しています。Vary: accept-encoding が応答ヘッダーに追加され、フロントエンド キャッシュ サーバーが gzip 圧縮されたページをキャッシュできるようになります。たとえば、Squid Cache nginx 圧縮データを使用します。

3. サーバー仮想ホスト

http サービスは複数の仮想ホストをサポートします。各仮想ホストには対応するサーバー構成項目があり、これには仮想ホストに関連する構成が含まれます。メール サービスにプロキシを提供する場合、複数のサーバーを作成することもできます。各サーバーは、リスニング アドレスまたはポートによって区別されます。

listen
リスニング ポートはデフォルトで 80 です。1024 未満の場合は、root として起動する必要があります。 listen *:80、listen 127.0.0.1:80 などの形式にすることができます。

server_name
localhost、www.example.com などのサーバー名は、正規表現で照合できます。

モジュール http_stream

このモジュールは、単純なスケジューリング アルゴリズムを使用して、クライアント IP からバックエンド サーバーへのロード バランシングを実現します。アップストリームの後にロード バランサの名前が続き、バックエンド サーバーの名前が続きます。 -end realserver はホスト: ポートのオプションです。メソッドは {} で構成されます。 1 つのバックエンドのみがプロキシされる場合は、それを proxy_pass に直接記述することもできます。

4. location

http サービスにおいて、特定の URL に対応する一連の設定項目。

root /var/www/html
サーバーのデフォルトの Web サイトのルート ディレクトリの場所を定義します。 locationurl がサブディレクトリまたはファイルと一致する場合、root は効果がなく、通常はserver ディレクティブまたは / の下に配置されます。

indexindex.jspindex.htmlindex.htm
パスの下にデフォルトのアクセスファイル名を定義します。通常はルートが続きます

proxy_pass http:/backend
リクエストは次のとおりです。バックエンド定義にリダイレクトされます。サーバー リスト、つまりリバース プロキシは、上流のロード バランサーに対応します。 http://ip:port を proxy_pass することもできます。

proxy_redirect オフ;
proxy_set_header ホスト $host;
proxy_set_header x-real-ip $remote_addr;
proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;

とりあえずこの4つを設定しましたが、さらに掘り下げるとそれぞれ非常に複雑な内容になるので、これもまた別の記事で解説します。

位置一致ルールの記述に関しては、特に重要かつ基本的な事項であるため、nginx 設定の位置の概要の記事を参照して、ルールの記述を書き直してください;

5。その他

5.1 アクセス制御許可/拒否

nginxのアクセス制御モジュールはデフォルトでインストールされており、記述方法も非常に簡単です。複数の許可と拒否、各 IP または IP セグメントへの特定のアクセスを許可または禁止すると、ルールのいずれか 1 つが満たされると照合が停止されます。例:

また、一般的に httpd-devel ツールの htpasswd を使用して、アクセスされるパスのログイン パスワードを設定します。

これにより、デフォルトで crypt によって暗号化されたパスワード ファイルが生成されます。上記の nginx-status の 2 行のコメントを開き、nginx を再起動して有効にします。

5.2 ディレクトリのリスト autoindex

nginx では、デフォルトではディレクトリ全体のリストを許可しません。この機能が必要な場合は、nginx.conf ファイルを開いて、location、server、または http セクションに autoindex on; を追加します。他の 2 つのパラメータを追加することをお勧めします:

1. autoindex_exact_size off ; デフォルト オンの場合、ファイルの正確なサイズがバイト単位で表示されます。 off に変更すると、ファイルのおおよそのサイズが表示されます。単位は kb または mb または gb autoindex_localtime on;

2. デフォルトは off、表示されるファイル時間は gmt time です。 。 on に変更すると、表示されるファイル時間はファイルのサーバー時間

以上がNginx クイック スタート例の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。