Nginxの基本概念とは何ですか

Nginx とは何ですか?

Nginx はもともと、C10k の問題を解決する Web サーバーとして作成されました。 Web サーバーとして、驚異的な速度でデータを提供できます。しかし、Nginx は単なる Web サーバーではなく、Unicorn や Puma などの低速な上流サーバーと簡単に統合するためのリバース プロキシとして使用することもできます。トラフィックの適切な分散 (ロード バランサー)、メディアのストリーミング、画像の動的サイズ変更、コンテンツのキャッシュなどを行うことができます。基本的な nginx アーキテクチャは、マスター プロセスとそのワーカー プロセスで構成されます。マスターは構成ファイルを読み取り、ワーカー プロセスを維持し、ワーカーが実際にリクエストを処理します。

基本コマンド

nginx を開始するには、次のように入力します:

[sudo] nginx

nginx インスタンスが実行されているとき、管理するには次のように対応するシグナルを送信できます。それ:

[sudo] nginx -s signal

利用可能なシグナル:

• stop – クイック シャットダウン

• ##quit – 正常なシャットダウン (ワーカーを待ちます)処理を完了するためのスレッド)

• reload – 構成ファイルを再ロードします

• reopen – ログ ファイルを再度開きます

コマンドとコンテキスト

nginx 構成ファイル。デフォルトの場所には次のものが含まれます:

• /etc/nginx /nginx .conf、

• ##/usr/local/etc/nginx/nginx.conf

  、または

• /usr/local/nginx/conf/nginx.conf

設定ファイルは次の部分で構成されます:

ディレクティブ– オプション。名前とパラメータを含み、セミコロンで終わる

• gzip on;

コンテキスト– チャンクでディレクティブを宣言できます– プログラミング言語のスコープと同様です

• worker_processes 2; # 全局上下文指令http {              # http 上下文   gzip on;        # http 上下文中的指令 server {          # server 上下文   listen 80;      # server 上下文中的指令 }
  }

命令タイプ

同じ命令を使用して異なる継承モデルで動作する場合は、注意が必要です。ディレクティブには 3 種類あり、それぞれに独自の継承モデルがあります。

通常のディレクティブ

各コンテキストで一意の値を持ちます。また、現在のコンテキストで定義できるのは 1 回だけです。子コンテキストでの親の値のオーバーライドは、現在の子コンテキストでのみ有効です。

gzip on;
gzip off; # 非法，不能在同一个上下文中指定同一普通指令2次server {
 location /downloads {
   gzip off;
 }

 location /assets {
   # gzip is on here }
}

配列ディレクティブ

同じコンテキストに複数のディレクティブを追加すると、完全にカバーされるのではなく、複数の値が追加されます。子コンテキストでディレクティブを定義すると、親コンテキストの値がオーバーライドされます。

error_log /var/log/nginx/error.log;
error_log /var/log/nginx/error_notive.log notice;
error_log /var/log/nginx/error_debug.log debug;

server {
 location /downloads {
   # 下面的配置会覆盖父级上下文中的指令   error_log /var/log/nginx/error_downloads.log;
 }
}

行動指示

行動とは、物事を変えるための指示です。モジュールのニーズに応じて、モジュールが継承する動作は異なる場合があります。たとえば、次の条件に一致する限り、書き換えコマンドが実行されます:

server {
 rewrite ^ /foobar;

 location /foobar {
   rewrite ^ /foo;
   rewrite ^ /bar;
 }
}

ユーザーが /sample を取得しようとしている場合:

サーバーの書き換えが実行されます、/sample rewrite to /foobar
location /foobar は、
location に一致する最初のリライトによって実行され、/foobar から/foo
location の 2 番目の書き換え実行では、/foo から /bar への書き換え
return ディレクティブは異なる動作を提供します:

server {
 location / {
   return 200;
   return 404;
 }
}

上記の場合はすぐに200を返します。

リクエストの処理

Nginx 内では、複数の仮想サーバーを指定でき、各仮想サーバーはサーバー コンテキストで記述されます。{}

server {
 listen      *:80 default_server;
 server_name netguru.co;

 return 200 "Hello from netguru.co";
}

server {
 listen      *:80;
 server_name foo.co;

 return 200 "Hello from foo.co";
}

server {
 listen      *:81;
 server_name bar.co;

 return 200 "Hello from bar.co";
}

これにより、受信リクエストの処理方法が Nginx に指示されます。特定の IP ポートの組み合わせをチェックするとき、Nginx はまず、どの仮想ホストに listen ディレクティブが設定されているかをテストします。

次に、server_name ディレクティブの値により、Host ヘッダー (ホスト ドメイン名が格納されている) が検出されます。

Nginx は次の順序で仮想ホストを選択します:

sever_name ディレクティブに一致する IP ポート ホスト
default_server タグ IP ポート ホスト
最初に IP ポート ホストを定義します
一致するものがない場合は、接続を拒否します。
たとえば、次の例:

Request to foo.co:80     => "Hello from foo.co"Request to www.foo.co:80 => "Hello from netguru.co"Request to bar.co:80     => "Hello from netguru.co"Request to bar.co:81     => "Hello from bar.co"Request to foo.co:81     => "Hello from bar.co"

server_name ディレクティブserver_name ディレクティブは複数のディレクティブを受け入れます。値 。ワイルドカード マッチングや正規表現も処理します。

server_name netguru.co www.netguru.co; # exact matchserver_name *.netguru.co;              # wildcard matchingserver_name netguru.*;                 # wildcard matchingserver_name  ~^[0-9]*\.netguru\.co$;   # regexp matching

曖昧さがある場合、nginx は次のコマンドを使用します:

正確な名前
最長のワイルドカード 名前「*.example.org」のようにアスタリスクで始まります。
最長のワイルドカード名は、「mail.**」のようにアスタリスクで終わります。
最初に正規表現と一致します (構成ファイルの順序)
Nginx は、特定の名前、アスタリスクで始まるワイルドカード、およびアスタリスクで終わるワイルドカードを保存するための 3 つのハッシュ テーブルを保存します。結果がどのテーブルにもない場合、正規表現テストは順番に実行されます。

server_name .netguru.co;

は

server_name  netguru.co  www.netguru.co  *.netguru.co;

の略語であることを覚えておく価値があります。

listen 127.0.0.1:80;
listen 127.0.0.1;    # by default port :80 is usedlisten *:81;
listen 81;           # by default all ips are usedlisten [::]:80;      # IPv6 addresseslisten [::1];        # IPv6 addresses

は少し異なり、.netguru.co は 2 番目のテーブルに格納されます。これは、明示的に宣言されているよりも少し遅いことを意味します。

listen コマンド

在很多情况下，能够找到 listen 指令，接受IP:端口值

listen 127.0.0.1:80;
listen 127.0.0.1;    # by default port :80 is usedlisten *:81;
listen 81;           # by default all ips are usedlisten [::]:80;      # IPv6 addresseslisten [::1];        # IPv6 addresses

然而，还可以指定 UNIX-domain 套接字。

listen unix:/var/run/nginx.sock;

你甚至可以使用主机名

listen localhost:80;
listen netguru.co:80;

但请慎用，由于主机可能无法启动 nginx，导致无法绑定在特定的 TCP Socket。

最后，如果指令不存在，则使用 *:80。

最小化配置

有了这些知识 – 我们应该能够创建并理解运行 nginx 所需的最低配置。

# /etc/nginx/nginx.confevents {}                   # events context needs to be defined to consider config validhttp {
server {
   listen 80;
   server_name  netguru.co  www.netguru.co  *.netguru.co;

   return 200 "Hello";
 }
}

root, location, 和 try_files 指令

root 指令

root 指令设置请求的根目录，允许 nginx 将传入请求映射到文件系统。

server {
 listen 80;
 server_name netguru.co;
 root /var/www/netguru.co;
}

根据给定的请求，指定 nginx 服务器允许的内容

netguru.co:80/index.html     # returns /var/www/netguru.co/index.htmlnetguru.co:80/foo/index.html # returns /var/www/netguru.co/foo/index.html

location 指令

location指令根据请求的 URI 来设置配置。location [modifier] path

location /foo/ {
 # ...}

如果没有指定修饰符，则路径被视为前缀，其后可以跟随任何东西。

以上例子将匹配

/foo
/fooo
/foo123
/foo/bar/index.html
...

此外，在给定的上下文中可以使用多个 location 指令。

server {
 listen 80;
 server_name netguru.co;
 root /var/www/netguru.co;

 location / {
   return 200 "root";
 }

 location /foo/ {
   return 200 "foo";
 }
}
netguru.co:80   /       # => "root"netguru.co:80   /foo    # => "foo"netguru.co:80   /foo123 # => "foo"netguru.co:80   /bar    # => "root"

Nginx还有一些修饰符可以用于连接location。因为每个修饰符都有自己的优先级，所以它们会影响 location 模块在使用时的行为。

=           - Exact match
^~          - Preferential match
~ && ~*     - Regex match
no modifier - Prefix match

Nginx 会先检查精确匹配。如果找不到，我们会找优先级最高的。如果之前的匹配尝试失败，正则表达式会按照出现的顺序逐个进行测试。至少，最后一个前缀匹配将被使用。

location /match {
 return 200 'Prefix match: matches everything that starting with /match';
}

location ~* /match[0-9] {
 return 200 'Case insensitive regex match';
}

location ~ /MATCH[0-9] {
 return 200 'Case sensitive regex match';
}

location ^~ /match0 {
 return 200 'Preferential match';
}

location = /match {
 return 200 'Exact match';
}
/match/    # => 'Exact match'/match0    # => 'Preferential match'/match2    # => 'Case insensitive regex match'/MATCH1    # => 'Case sensitive regex match'/match-abc # => 'Prefix match: matches everything that starting with /match'

try_files 指令

尝试不同的路径，找到一个路径就返回。

try_files $uri index.html =404;

所以对于 /foo.html 请求，它将尝试按以下顺序返回文件：

1. $uri ( /foo.html )

2. index.html

3. 如果什么都没找到则返回 404

有趣的是，如果我们在服务器上下文中定义 try_files，然后定义匹配的所有请求的 location —— try_files 将不会执行。

这是因为在服务器上下文中定义的 try_files 是它的 pseudo-location，这是最不可能的位置。因此，location/的定义将比pseudo-location更为明确。

server {
 try_files $uri /index.html =404;

 location / {
 }
}

因此，你应该避免在 server 上下文中出现 try_files:

server {
 location / {
   try_files $uri /index.html =404;
 }
}

以上がNginxの基本概念とは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。