高性能Webサーバを構築するNginxのインストールと構成(2.9)
6800 ワード
前述したように、nginxプロファイル(nginx.conf)の実行、パフォーマンスの最適化、および関連デバッグに関するいくつかの構成構文について説明します.このセクションでは、基本的なWebの構成方法、および関連する構成項目の定義、仮想ホストの移動、およびリクエストの配布に関する構文構成について説明します.
一.HTTPコアモジュールを使用して静的Webサーバを構成する方法
静的Webサーバの主な機能はngx_http_core_moduleモジュール(HTTPフレームワークの主要メンバー)は実装され、もちろん、完全な静的Webサーバには他のHTTPモジュールによって実装される多くの機能があります.このセクションでは、基本機能を含む静的Webサーバの構成方法について説明します.
以下に示すように、基本httpの構成
以上が簡単な静的web構成の説明の参考になります.
すべてのHTTP構成項目はhttpブロック、serverブロック、locationブロック、upstreamブロックまたはifブロックなどに直属しなければならない(HTTP構成項目は当然すべてhttp{}ブロック内でなければならないが、ここでの「直属于」は構成項目が直接属する大かっこに対応する構成ブロックを指す)とともに、各構成項目の機能を記述する際に、上記のどのブロックに存在できるかを説明する一部のコンフィギュレーション・アイテムは任意にブロックに表示され、一部のコンフィギュレーション・アイテムは特定のブロックにのみ表示されるためです.
Nginxは完全な静的Webサーバを構成するために非常に多くの機能を提供しています.以下、これらの構成項目を以下の8種類に分けて詳しく説明します.仮想ホストと要求の配布、ファイルパスの定義、メモリとディスクリソースの割り当て、ネットワーク接続の設定、MIMEタイプの設定、クライアント要求の制限、ファイル操作の最適化、クライアント要求に対する特殊な処理.この区分は、これらの構成項目を機能的に理解するのに役立つだけです.次に、構成の説明を説明します.
1.1仮想ホストと要求の配布構成項目説明
IPアドレスの数が限られているため、複数のホストドメイン名が同じIPアドレスに対応している場合が多く、nginx.confではserver_name(対応するユーザ要求のホストドメイン名)は、serverブロックによって仮想ホストを定義し、各serverブロックは、対応するホストドメイン名要求のみを処理する仮想ホストである.これにより、1台のサーバ上のNginxは、異なるホストドメイン名にアクセスするHTTPリクエストを異なる方法で処理できます.
[1]リスニングポート
構文:listen address:port[default(deprecated in 0.8.21)|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv 6 only=[on|off]|ssl];
デフォルト:listen 80;
ブロックの構成:server
Listenパラメータは、Nginxサービスがポートをどのように傍受するかを決定します.Listenの後、IPアドレス、ポート、ホスト名のみを追加できます.たとえば、次のような柔軟性があります.
サーバがIPv 6アドレスを使用している場合は、次のように使用できます.
アドレスとポートの後に、次のような他のパラメータを追加することもできます.
次にlistenが使用できるパラメータの意味を説明します.
default:存在するserverブロックをWebサービス全体のデフォルトserverブロックとします.このパラメータが設定されていない場合、nginx.confで見つかった最初のserverブロックがデフォルトのserverブロックとして使用されます.デフォルトの仮想ホストが必要なのはなぜですか?1つのリクエストがプロファイル内のすべてのホストドメイン名に一致しない場合、デフォルトの仮想ホストが選択されます.
default_server:同じです.
backlog=num:TCPにおけるbacklogキューのサイズを表します.デフォルトは�C 1で、設定しないことを示します.TCPが3回の握手を確立する過程で、プロセスはまだリスニングハンドルの処理を開始していないので、backlogキューはこれらの新しい接続を配置します.しかし、backlogキューがいっぱいで、新しいクライアントが3回の握手でTCP接続を確立しようとした場合、クライアントは接続を確立できません.
rcvbuf=size:リスニングハンドルのSO_を設定するRCVBUFパラメータ.
sndbuf=size:リスニングハンドルのSO_を設定するSNDBUFパラメータ.
accept_filter:acceptフィルタを設定し、FreeBSDオペレーティングシステムにのみ役立ちます.
deferred:このパラメータを設定した後、ユーザーが接続要求を開始し、TCPの3回の握手を完了した場合、カーネルも今回の接続のためにworkerプロセスをスケジューリングすることはなく、ユーザーが本当に要求データを送信した場合(カーネルがNICで要求データパケットを受信した場合)だけ、カーネルはworkerプロセスを起動してこの接続を処理します.このパラメータは、大きな同時性の場合に適用され、workerプロセスの負担を軽減します.リクエストデータが来ると、workerプロセスはこの接続の処理を開始します.deferred構成は、上記のアプリケーションシーンが自分のビジネスニーズに合っていることを確認する場合にのみ使用できます.
bind:現在のポート/アドレスペア、例えば127.0.0.1:8000をバインドします.1つのポートに対して複数のアドレスを同時にリスニングする場合にのみ有効です.
ssl:現在傍受されているポートで確立された接続は、SSLプロトコルに基づいている必要があります.
[2] ホスト名
構文:server_name name [...];
デフォルト:server_name "";
ブロックの構成:server
説明:
server_nameの後にserver_などの複数のホスト名を付けることができます.name www.testweb.com、download.testweb.com;.
HTTPリクエストの処理を開始すると、Nginxはヘッダのホストと、各サーバのserver_を取り出します.nameは、どのサーバブロックがこのリクエストを処理するかを決定するためにマッチングされる.1つのHostと複数のserverブロックのserver_nameが一致すると,マッチング優先度に基づいて実際に処理されるserverブロックが選択される.server_nameとHostのマッチングの優先度は次のとおりです.
1)まず、すべての文字列が完全に一致するserver_を選択します.www.testweb.comなどのname.
2)次にワイルドカードの先頭にあるserver_を選択名前、例えば*.testweb.com.
3)ワイルドカードの後ろにあるserver_を再度選択www.testweb.*などのname.
4)正規表現で一致するserver_を最後に選択name、例えば~^.testweb.com$です.
実際、このルールは7.7節で紹介されたワイルドカード付きハッシュリストの実現根拠であり、ホストがすべてのserver_とnameが一致しない場合、処理するserverブロックは以下の順序で選択されます.
5)listenコンフィギュレーションアイテムの後に[default|default_server]を追加するserverブロックを優先的に選択します.
6)listenポートに一致する最初のserverブロックが見つかりました.
[3] リダイレクトホスト名の処理
構文:server_name_in_redirect on | off;
デフォルト:server_name_in_redirect on;
構成ブロック:http、server、またはlocation
この構成はserver_と連携する必要があります.name使用.onを使用して開くと、リダイレクト要求時にserver_が使用されることを示します.nameで構成された最初のホスト名は、元のリクエストのホストヘッダに代わり、offクローズを使用すると、リダイレクトリクエスト時にリクエスト自体のホストヘッダが使用されることを示します.
[4]locationの使い方
構文:location 【 =|^~|~*|~|@]|/uri/{ ... 】
ブロックの構成:server
locationでは、ユーザー要求のURIに基づいて上記の/uri式をマッチングしようとします.マッチング可能であれば、location{}ブロックの構成を選択してユーザー要求を処理します.もちろん、マッチング方法は多様ですが、locationのマッチングルールについて説明します.locationの参考例は次のとおりです.
location ~*/js/.*/\.js
locationパラメータの説明
パラメータ値
意味を表す
=
パラメータのuriと完全に一致するようにURIを文字列として表す、すなわち正確に一致する
^~
URIのマッチングを表す場合はその前半をuriパラメータとマッチングするだけでよい
~
URIに一致するときにアルファベットの大文字と小文字の問題に注意することを表します.
~*
URIに一致するときにアルファベットの大文字と小文字の問題を無視することを示します.
!~
大文字と小文字の区別が一致しないことを示します
!~*
大文字と小文字を区別しない一致を表す
@
Nginxサービス内部リクエスト間のリダイレクトのみに使用されることを示し、@付きlocationはユーザーリクエストを直接処理しません.
locationのマッチング優先度
(location=)>(locationフルパス)>(location^~パス)>(location~,~*正規順)>(location部分開始パス)>(/)
nginx locationオプションの構成については、後述しますが、ここでは一般的な構成パラメータについて概説します.次のセクションでは、nginxのファイルパスの定義について説明します.
一.HTTPコアモジュールを使用して静的Webサーバを構成する方法
静的Webサーバの主な機能はngx_http_core_moduleモジュール(HTTPフレームワークの主要メンバー)は実装され、もちろん、完全な静的Webサーバには他のHTTPモジュールによって実装される多くの機能があります.このセクションでは、基本機能を含む静的Webサーバの構成方法について説明します.
以下に示すように、基本httpの構成
http {
gzip on;
upstream {
…
}
server {
listen localhost:80;
…
location /webstatic {
if … {
…
}
root /opt/webresource;
…
}
location ~* .(jpg|jpeg|png|jpe|gif)$ {
…
}
}
server {
…
}
}以上が簡単な静的web構成の説明の参考になります.
すべてのHTTP構成項目はhttpブロック、serverブロック、locationブロック、upstreamブロックまたはifブロックなどに直属しなければならない(HTTP構成項目は当然すべてhttp{}ブロック内でなければならないが、ここでの「直属于」は構成項目が直接属する大かっこに対応する構成ブロックを指す)とともに、各構成項目の機能を記述する際に、上記のどのブロックに存在できるかを説明する一部のコンフィギュレーション・アイテムは任意にブロックに表示され、一部のコンフィギュレーション・アイテムは特定のブロックにのみ表示されるためです.
Nginxは完全な静的Webサーバを構成するために非常に多くの機能を提供しています.以下、これらの構成項目を以下の8種類に分けて詳しく説明します.仮想ホストと要求の配布、ファイルパスの定義、メモリとディスクリソースの割り当て、ネットワーク接続の設定、MIMEタイプの設定、クライアント要求の制限、ファイル操作の最適化、クライアント要求に対する特殊な処理.この区分は、これらの構成項目を機能的に理解するのに役立つだけです.次に、構成の説明を説明します.
1.1仮想ホストと要求の配布構成項目説明
IPアドレスの数が限られているため、複数のホストドメイン名が同じIPアドレスに対応している場合が多く、nginx.confではserver_name(対応するユーザ要求のホストドメイン名)は、serverブロックによって仮想ホストを定義し、各serverブロックは、対応するホストドメイン名要求のみを処理する仮想ホストである.これにより、1台のサーバ上のNginxは、異なるホストドメイン名にアクセスするHTTPリクエストを異なる方法で処理できます.
[1]リスニングポート
構文:listen address:port[default(deprecated in 0.8.21)|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv 6 only=[on|off]|ssl];
デフォルト:listen 80;
ブロックの構成:server
Listenパラメータは、Nginxサービスがポートをどのように傍受するかを決定します.Listenの後、IPアドレス、ポート、ホスト名のみを追加できます.たとえば、次のような柔軟性があります.
listen 127.0.0.1:8000;
listen 127.0.0.1; # ： ， 80
listen 8000;
listen *:8000;
listen localhost:8000;サーバがIPv 6アドレスを使用している場合は、次のように使用できます.
listen [::]:8000;
listen [fe80::1];
listen [:::a8c9:1234]:80;アドレスとポートの後に、次のような他のパラメータを追加することもできます.
listen 443 default_server ssl;
listen 127.0.0.1 default_server accept_filter=dataready backlog=1024;次にlistenが使用できるパラメータの意味を説明します.
default:存在するserverブロックをWebサービス全体のデフォルトserverブロックとします.このパラメータが設定されていない場合、nginx.confで見つかった最初のserverブロックがデフォルトのserverブロックとして使用されます.デフォルトの仮想ホストが必要なのはなぜですか?1つのリクエストがプロファイル内のすべてのホストドメイン名に一致しない場合、デフォルトの仮想ホストが選択されます.
default_server:同じです.
backlog=num:TCPにおけるbacklogキューのサイズを表します.デフォルトは�C 1で、設定しないことを示します.TCPが3回の握手を確立する過程で、プロセスはまだリスニングハンドルの処理を開始していないので、backlogキューはこれらの新しい接続を配置します.しかし、backlogキューがいっぱいで、新しいクライアントが3回の握手でTCP接続を確立しようとした場合、クライアントは接続を確立できません.
rcvbuf=size:リスニングハンドルのSO_を設定するRCVBUFパラメータ.
sndbuf=size:リスニングハンドルのSO_を設定するSNDBUFパラメータ.
accept_filter:acceptフィルタを設定し、FreeBSDオペレーティングシステムにのみ役立ちます.
deferred:このパラメータを設定した後、ユーザーが接続要求を開始し、TCPの3回の握手を完了した場合、カーネルも今回の接続のためにworkerプロセスをスケジューリングすることはなく、ユーザーが本当に要求データを送信した場合(カーネルがNICで要求データパケットを受信した場合)だけ、カーネルはworkerプロセスを起動してこの接続を処理します.このパラメータは、大きな同時性の場合に適用され、workerプロセスの負担を軽減します.リクエストデータが来ると、workerプロセスはこの接続の処理を開始します.deferred構成は、上記のアプリケーションシーンが自分のビジネスニーズに合っていることを確認する場合にのみ使用できます.
bind:現在のポート/アドレスペア、例えば127.0.0.1:8000をバインドします.1つのポートに対して複数のアドレスを同時にリスニングする場合にのみ有効です.
ssl:現在傍受されているポートで確立された接続は、SSLプロトコルに基づいている必要があります.
[2] ホスト名
構文:server_name name [...];
デフォルト:server_name "";
ブロックの構成:server
説明:
server_nameの後にserver_などの複数のホスト名を付けることができます.name www.testweb.com、download.testweb.com;.
HTTPリクエストの処理を開始すると、Nginxはヘッダのホストと、各サーバのserver_を取り出します.nameは、どのサーバブロックがこのリクエストを処理するかを決定するためにマッチングされる.1つのHostと複数のserverブロックのserver_nameが一致すると,マッチング優先度に基づいて実際に処理されるserverブロックが選択される.server_nameとHostのマッチングの優先度は次のとおりです.
1)まず、すべての文字列が完全に一致するserver_を選択します.www.testweb.comなどのname.
2)次にワイルドカードの先頭にあるserver_を選択名前、例えば*.testweb.com.
3)ワイルドカードの後ろにあるserver_を再度選択www.testweb.*などのname.
4)正規表現で一致するserver_を最後に選択name、例えば~^.testweb.com$です.
実際、このルールは7.7節で紹介されたワイルドカード付きハッシュリストの実現根拠であり、ホストがすべてのserver_とnameが一致しない場合、処理するserverブロックは以下の順序で選択されます.
5)listenコンフィギュレーションアイテムの後に[default|default_server]を追加するserverブロックを優先的に選択します.
6)listenポートに一致する最初のserverブロックが見つかりました.
[3] リダイレクトホスト名の処理
構文:server_name_in_redirect on | off;
デフォルト:server_name_in_redirect on;
構成ブロック:http、server、またはlocation
この構成はserver_と連携する必要があります.name使用.onを使用して開くと、リダイレクト要求時にserver_が使用されることを示します.nameで構成された最初のホスト名は、元のリクエストのホストヘッダに代わり、offクローズを使用すると、リダイレクトリクエスト時にリクエスト自体のホストヘッダが使用されることを示します.
[4]locationの使い方
構文:location 【 =|^~|~*|~|@]|/uri/{ ... 】
ブロックの構成:server
locationでは、ユーザー要求のURIに基づいて上記の/uri式をマッチングしようとします.マッチング可能であれば、location{}ブロックの構成を選択してユーザー要求を処理します.もちろん、マッチング方法は多様ですが、locationのマッチングルールについて説明します.locationの参考例は次のとおりです.
location = / {
# / ，
[ configuration A ]
}location / {
# / ，
#
[ configuration B ]
}location /documents/ {
# /documents/ ， ，
# ，
[ configuration C ]
}location ~ /documents/Abc {
# /documents/ ， ，
# ，
[ configuration CC ]
}location ^~ /images/ {
# /images/ ， ， ， 。
[ configuration D ]
}location ~* \.(gif|jpg|jpeg)$ {
# gif,jpg jpeg
# ， /images/ config D ， ^~
[ configuration E ]
}location /images/ {
# /images/， ， ^~
[ configuration F ]
}location /images/abc {
# /images/abc， ， ^~
# F G
[ configuration G ]
}location ~ /images/abc/ {
# config D ： config G ， ， ，
[ configuration H ]
}location ~*/js/.*/\.js
locationパラメータの説明
パラメータ値
意味を表す
=
パラメータのuriと完全に一致するようにURIを文字列として表す、すなわち正確に一致する
^~
URIのマッチングを表す場合はその前半をuriパラメータとマッチングするだけでよい
~
URIに一致するときにアルファベットの大文字と小文字の問題に注意することを表します.
~*
URIに一致するときにアルファベットの大文字と小文字の問題を無視することを示します.
!~
大文字と小文字の区別が一致しないことを示します
!~*
大文字と小文字を区別しない一致を表す
@
Nginxサービス内部リクエスト間のリダイレクトのみに使用されることを示し、@付きlocationはユーザーリクエストを直接処理しません.
locationのマッチング優先度
(location=)>(locationフルパス)>(location^~パス)>(location~,~*正規順)>(location部分開始パス)>(/)
nginx locationオプションの構成については、後述しますが、ここでは一般的な構成パラメータについて概説します.次のセクションでは、nginxのファイルパスの定義について説明します.