ホームページ 運用・保守 Nginx Nginxサーバーでのロケーション構成例の分析

Nginxサーバーでのロケーション構成例の分析

May 24, 2023 pm 02:05 PM
nginx location

まず最初に、Nginx Wiki の例を使用して、一般的な Location の種類と一致ルールを紹介します。

4 番目の "~" 接頭辞は、規則的な一致が必要な場所。nginx には、URL を解析するときに、これら 5 つの異なるタイプの場所に対して異なる優先順位ルールがあります。一般的なルールは次のとおりです:

1. 文字列が「=」というプレフィックスが付いた場所と一致する場合、

2. 文字列が残りの非正規および非特殊な場所と一致する場合、一致する場合は、接頭辞「^~」の付いた場所に到達したら停止します。

3、通常のマッチング。マッチング順序は、構成ファイル内に出現する場所の順序です。通常の場所が一致した場合は、停止してこの場所の構成を使用します。それ以外の場合は、手順 2 で取得した文字列が最も一致する場所の構成を使用します。

たとえば、次のリクエストの場合:

1, / -> 最初の場所と完全に一致し、一致は停止します。構成 a

2, /some/other/url - を使用します。 > まず、文字列のプレフィックス部分が 2 番目の位置と一致し、次に通常のマッチングが実行されます。当然一致しないため、2 番目の位置の設定はconfigurationb
3, /images /1.jpg -> まず、 、プレフィックス 文字列の一部が 2 番目の場所と一致しましたが、その後 3 番目の場所のプレフィックスが一致しました。この時点では、これが構成ファイル内でこの URL に一致する最大の文字列であり、その場所には「^~」プレフィックスが付いていました。 . の場合、通常のマッチングは実行されなくなり、最終的に設定 c
4 が使用されます (/some/other/path/to/1.jpg -> まず、プレフィックス部分の同じ文字列が 2 番目の場所と一致し、通常のマッチングが成功したら、設定 d

を使用します。nginx の URL マッチング ルールは、実際には少し不適切です。ほとんどの場合、URL は最初に文字列マッチングを実行し、次に通常のマッチングを実行する必要があります。マッチングですが、実際には、最初に通常のマッチングを実行し、一致しない場合は文字列マッチングを実行します。これにより、多くの場合、文字列マッチングを実行する時間を節約できます。とにかく、nginx ソース コードの実装を見てみましょう。位置一致プロセスを紹介する前に、まず nginx での位置の構成を紹介しましょう。実際、設定解析段階で、nginx は位置一致する文字列を通常の一致する場所。場所は、http コア モジュールの loc 設定の ngx_http_core_loc_conf_t 構造体の次の 2 つのフィールドに保存されます:

location = / { 
 # matches the query / only. 
 [ configuration a ]  
} 
location / { 
 # matches any query, since all queries begin with /, but regular 
 # expressions and any longer conventional blocks will be 
 # matched first. 
 [ configuration b ]  
} 
location ^~ /images/ { 
 # matches any query beginning with /images/ and halts searching, 
 # so regular expressions will not be checked. 
 [ configuration c ]  
} 
location ~* \.(gif|jpg|jpeg)$ { 
 # matches any request ending in gif, jpg, or jpeg. however, all 
 # requests to the /images/ directory will be handled by 
 # configuration c.   
 [ configuration d ]  
} 
 
location @named { 
 # such locations are not used during normal processing of requests,  
 # they are intended only to process internally redirected requests (for example error_page, try_files). 
 [ configuration e ]  
}
ログイン後にコピー

これら 2 つのフィールドの型から、文字列によって一致する場所が次のとおりであることがわかります。

ngx_http_location_tree_node_t  *static_locations; 
(ngx_pcre) 
ngx_http_core_loc_conf_t    **regex_locations; 
if
ログイン後にコピー

構成が読み取られた後、すべてのサーバーが http コア モジュールのメイン構成のサーバー配列に保存され、その場所がロケーション ツリーに編成されます。各サーバーが押される 構成に表示される順序は、http コア モジュールの loc 構成のロケーション キューに保存されます。上記のコードでは、各サーバーの場所が最初に並べ替えられ、分類されます。このステップは ngx_http_init_location で発生します() 関数:


location tree和regex_locations数组建立过程在ngx_http_block中:
/* create location trees */ 
 
  for (s = 0; s < cmcf->servers.nelts; s++) { 
 
    clcf = cscfp[s]->ctx->loc_conf[ngx_http_core_module.ctx_index]; 
 
    if (ngx_http_init_locations(cf, cscfp[s], clcf) != ngx_ok) { 
      return ngx_conf_error; 
    } 
 
    if (ngx_http_init_static_location_trees(cf, clcf) != ngx_ok) { 
      return ngx_conf_error; 
    } 
  }
ログイン後にコピー

上記のステップは、通常の一致するロケーションに保存されます。処理後、ロケーション キューはすでに順番にあります。確立プロセスの主な作業三分ツリーは ngx_http_create_locations_list() と ngx_http_create_locations_tree() で完成します。これら 2 つの関数は両方とも再帰関数です。最初の関数はロケーション キュー内の各ノードを再帰し、現在のノードの名前がプレフィックスとして付けられたロケーションを取得し、リスト フィールドに保存されます。たとえば、次の場所:

static ngx_int_t 
ngx_http_init_locations(ngx_conf_t *cf, ngx_http_core_srv_conf_t *cscf, 
  ngx_http_core_loc_conf_t *pclcf) 
{ 
 ... 
  locations = pclcf->locations; 
 
 ... 
  /* 按照类型排序location,排序完后的队列: (exact_match 或 inclusive) (排序好的,如果某个exact_match名字和inclusive location相同,exact_match排在前面) 
    | regex(未排序)| named(排序好的) | noname(未排序)*/ 
  ngx_queue_sort(locations, ngx_http_cmp_locations); 
 
  named = null; 
  n = 0; 
#if (ngx_pcre) 
  regex = null; 
  r = 0; 
#endif 
 
  for (q = ngx_queue_head(locations); 
     q != ngx_queue_sentinel(locations); 
     q = ngx_queue_next(q)) 
  { 
    lq = (ngx_http_location_queue_t *) q; 
 
    clcf = lq->exact ? lq->exact : lq->inclusive; 
    /* 由于可能存在nested location,也就是location里面嵌套的location,这里需要递归的处理一下当前location下面的nested location */ 
    if (ngx_http_init_locations(cf, null, clcf) != ngx_ok) { 
      return ngx_error; 
    } 
 
#if (ngx_pcre) 
 
    if (clcf->regex) { 
      r++; 
 
      if (regex == null) { 
        regex = q; 
      } 
 
      continue; 
    } 
 
#endif 
 
    if (clcf->named) { 
      n++; 
 
      if (named == null) { 
        named = q; 
      } 
 
      continue; 
    } 
 
    if (clcf->noname) { 
      break; 
    } 
  } 
 
  if (q != ngx_queue_sentinel(locations)) { 
    ngx_queue_split(locations, q, &tail); 
  } 
  /* 如果有named location,将它们保存在所属server的named_locations数组中 */ 
  if (named) { 
    clcfp = ngx_palloc(cf->pool, 
              (n + 1) * sizeof(ngx_http_core_loc_conf_t **)); 
    if (clcfp == null) { 
      return ngx_error; 
    } 
 
    cscf->named_locations = clcfp; 
 
    for (q = named; 
       q != ngx_queue_sentinel(locations); 
       q = ngx_queue_next(q)) 
    { 
      lq = (ngx_http_location_queue_t *) q; 
 
      *(clcfp++) = lq->exact; 
    } 
 
    *clcfp = null; 
 
    ngx_queue_split(locations, named, &tail); 
  } 
 
#if (ngx_pcre) 
  /* 如果有正则匹配location,将它们保存在所属server的http core模块的loc配置的regex_locations 数组中, 
    这里和named location保存位置不同的原因是由于named location只能存在server里面,而regex location可以作为nested location */ 
  if (regex) { 
 
    clcfp = ngx_palloc(cf->pool, 
              (r + 1) * sizeof(ngx_http_core_loc_conf_t **)); 
    if (clcfp == null) { 
      return ngx_error; 
    } 
 
    pclcf->regex_locations = clcfp; 
 
    for (q = regex; 
       q != ngx_queue_sentinel(locations); 
       q = ngx_queue_next(q)) 
    { 
      lq = (ngx_http_location_queue_t *) q; 
 
      *(clcfp++) = lq->exact; 
    } 
 
    *clcfp = null; 
 
    ngx_queue_split(locations, regex, &tail); 
  } 
 
#endif 
 
  return ngx_ok; 
}
ログイン後にコピー

の場合、並べ替えの結果は /abc /efg /efgaa =/xyz / xyz /xyza /xyzab /xyzb となり、重複排除後の結果は次のようになります。 /abc /efg /efgaa /xyz /xyza /xyzab/xyzb、ngx_http_create_locations_list() の実行後の結果は次のとおりです:



最後に、見てみましょう。 ngx_http_create_locations_tree 関数:

Nginxサーバーでのロケーション構成例の分析

static ngx_http_location_tree_node_t * 
ngx_http_create_locations_tree(ngx_conf_t *cf, ngx_queue_t *locations, 
  size_t prefix) 
{ 
  ... 
  /* 根节点为locations队列的中间节点 */ 
  q = ngx_queue_middle(locations); 
 
  lq = (ngx_http_location_queue_t *) q; 
  len = lq->name->len - prefix; 
   
  node = ngx_palloc(cf->pool, 
           offsetof(ngx_http_location_tree_node_t, name) + len); 
  if (node == null) { 
    return null; 
  } 
 
  node->left = null; 
  node->right = null; 
  node->tree = null; 
  node->exact = lq->exact; 
  node->inclusive = lq->inclusive; 
 
  node->auto_redirect = (u_char) ((lq->exact && lq->exact->auto_redirect) 
              || (lq->inclusive && lq->inclusive->auto_redirect)); 
 
  node->len = (u_char) len; 
  ngx_memcpy(node->name, &lq->name->data[prefix], len); 
 
  /* 从中间节点开始断开 */ 
  ngx_queue_split(locations, q, &tail); 
 
  if (ngx_queue_empty(locations)) { 
    /* 
     * ngx_queue_split() insures that if left part is empty, 
     * then right one is empty too 
     */ 
    goto inclusive; 
  } 
 
  /* 从locations左半部分得到左子树 */ 
  node->left = ngx_http_create_locations_tree(cf, locations, prefix); 
  if (node->left == null) { 
    return null; 
  } 
 
  ngx_queue_remove(q); 
 
  if (ngx_queue_empty(&tail)) { 
    goto inclusive; 
  } 
  
 
  /* 从locations右半部分得到右子树 */ 
  node->right = ngx_http_create_locations_tree(cf, &tail, prefix); 
  if (node->right == null) { 
    return null; 
  } 
 
inclusive: 
 
  if (ngx_queue_empty(&lq->list)) { 
    return node; 
  } 
 
  /* 从list队列得到tree子树 */ 
  node->tree = ngx_http_create_locations_tree(cf, &lq->list, prefix + len); 
  if (node->tree == null) { 
    return null; 
  } 
 
  return node; 
} 
     location tree节点的ngx_http_location_tree_node_s结构:
struct ngx_http_location_tree_node_s { 
  ngx_http_location_tree_node_t  *left; 
  ngx_http_location_tree_node_t  *right; 
  ngx_http_location_tree_node_t  *tree; 
 
  ngx_http_core_loc_conf_t    *exact; 
  ngx_http_core_loc_conf_t    *inclusive; 
 
  u_char              auto_redirect; 
  u_char              len; 
  u_char              name[1]; 
};
ログイン後にコピー

location tree结构用到的是left,right,tree 这3个字段, location tree实际上是一个三叉的字符串排序树,而且这里如果某个节点只考虑左,右子树,它是一颗平衡树,它的建立过程有点类似于一颗平衡排序二叉树的建立过程,先排序再用二分查找找到的节点顺序插入,ngx_http_location_tree_node_s的tree节点也是一颗平衡排序树,它是用该节点由ngx_http_create_locations_list()得到的list建立的,也就是该节点的名字是它的tree子树里面的所有节点名字的前缀,所以tree子树里面的所有节点的名字不用保存公共前缀,而且查找的时候,如果是转向tree节点的话,也是不需要再比较父节点的那段字符串了。
ngx_http_create_locations_tree()函数写的很清晰,它有一个参数是队列locations,它返回一颗三叉树,根节点为locations的中间节点,其左子树为locations队列的左半部分建立的location tree,右子树为location队列的右半部分建立的tree,tree节点为该根节点的list队列建立的tree。

最终建立的location tree如下(为了方便阅读,图中列出了tree节点的完整名字):

Nginxサーバーでのロケーション構成例の分析

ps:关于 location modifier
1. =
这会完全匹配指定的 pattern ,且这里的 pattern 被限制成简单的字符串,也就是说这里不能使用正则表达式。

example:
server {
  server_name jb51.net;
  location = /abcd {
  […]
  }
}
ログイン後にコピー

匹配情况:

  http://jb51.net/abcd    # 正好完全匹配
  http://jb51.net/abcd    # 如果运行 nginx server 的系统本身对大小写不敏感,比如 windows ,那么也匹配
  http://jb51.net/abcd?param1&para;m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1&para;m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),nginx 不认为这种情况是完全匹配
  http://jb51.net/abcde  # 不匹配,因为不是完全匹配
ログイン後にコピー

2. (none)
可以不写 location modifier ,nginx 仍然能去匹配 pattern 。这种情况下,匹配那些以指定的 patern 开头的 uri,注意这里的 uri 只能是普通字符串,不能使用正则表达式。

example:
server {
  server_name jb51.net;
  location /abcd {
  […]
  }
}
ログイン後にコピー

匹配情况:

  http://jb51.net/abcd    # 正好完全匹配
  http://jb51.net/abcd    # 如果运行 nginx server 的系统本身对大小写不敏感,比如 windows ,那么也匹配
  http://jb51.net/abcd?param1&para;m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1&para;m2
  http://jb51.net/abcd/  # 末尾存在反斜杠(trailing slash)也属于匹配范围内
  http://jb51.net/abcde  # 仍然匹配,因为 uri 是以 pattern 开头的
ログイン後にコピー

3. ~
这个 location modifier 对大小写敏感,且 pattern 须是正则表达式

example:
server {
  server_name jb51.net;
  location ~ ^/abcd$ {
  […]
  }
}
ログイン後にコピー

匹配情况:

  http://jb51.net/abcd    # 完全匹配
  http://jb51.net/abcd    # 不匹配,~ 对大小写是敏感的
  http://jb51.net/abcd?param1&para;m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1&para;m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),并不匹配正则表达式 ^/abcd$
  http://jb51.net/abcde  # 不匹配正则表达式 ^/abcd$
ログイン後にコピー

注意:对于一些对大小写不敏感的系统,比如 windows ,~ 和 ~* 都是不起作用的,这主要是操作系统的原因。

4. ~*
与 ~ 类似,但这个 location modifier 不区分大小写,pattern 须是正则表达式

example:
server {
  server_name jb51.net;
  location ~* ^/abcd$ {
  […]
  }
}
ログイン後にコピー

匹配情况:

 http://jb51.net/abcd    # 完全匹配
  http://jb51.net/abcd    # 匹配,这就是它不区分大小写的特性
  http://jb51.net/abcd?param1&para;m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1&para;m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),并不匹配正则表达式 ^/abcd$
  http://jb51.net/abcde  # 不匹配正则表达式 ^/abcd$
ログイン後にコピー

5. ^~
匹配情况类似 2. (none) 的情况,以指定匹配模式开头的 uri 被匹配,不同的是,一旦匹配成功,那么 nginx 就停止去寻找其他的 location 块进行匹配了(与 location 匹配顺序有关)

6. @
用于定义一个 location 块,且该块不能被外部 client 所访问,只能被 nginx 内部配置指令所访问,比如 try_files or error_page

以上がNginxサーバーでのロケーション構成例の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

Tomcat サーバーへの外部ネットワーク アクセスを許可する方法 Tomcat サーバーへの外部ネットワーク アクセスを許可する方法 Apr 21, 2024 am 07:22 AM

Tomcat サーバーが外部ネットワークにアクセスできるようにするには、以下を行う必要があります。 外部接続を許可するように Tomcat 構成ファイルを変更します。 Tomcat サーバー ポートへのアクセスを許可するファイアウォール ルールを追加します。 Tomcat サーバーのパブリック IP を指すドメイン名を指す DNS レコードを作成します。オプション: リバース プロキシを使用して、セキュリティとパフォーマンスを向上させます。オプション: セキュリティを強化するために HTTPS を設定します。

nginxの起動コマンドと停止コマンドとは何ですか? nginxの起動コマンドと停止コマンドとは何ですか? Apr 02, 2024 pm 08:45 PM

Nginx の開始コマンドと停止コマンドは、それぞれ nginx と nginx -s quit です。 start コマンドはサーバーを直接起動し、stop コマンドはサーバーを正常にシャットダウンして、現在のすべてのリクエストを処理できるようにします。その他の使用可能な停止信号には、停止およびリロードがあります。

thinkphpの実行方法 thinkphpの実行方法 Apr 09, 2024 pm 05:39 PM

ThinkPHP フレームワークをローカルで実行する手順: ThinkPHP フレームワークをローカル ディレクトリにダウンロードして解凍します。 ThinkPHP ルート ディレクトリを指す仮想ホスト (オプション) を作成します。データベース接続パラメータを構成します。 Webサーバーを起動します。 ThinkPHP アプリケーションを初期化します。 ThinkPHP アプリケーションの URL にアクセスして実行します。

nginx へようこそ!それを解決するにはどうすればよいですか? nginx へようこそ!それを解決するにはどうすればよいですか? Apr 17, 2024 am 05:12 AM

「nginx へようこそ!」エラーを解決するには、仮想ホスト構成を確認し、仮想ホストを有効にし、Nginx をリロードする必要があります。仮想ホスト構成ファイルが見つからない場合は、デフォルト ページを作成して Nginx をリロードすると、エラー メッセージが表示されます。が消え、ウェブサイトは通常のショーになります。

phpmyadminの登録方法 phpmyadminの登録方法 Apr 07, 2024 pm 02:45 PM

phpMyAdmin に登録するには、まず MySQL ユーザーを作成して権限を付与し、次に phpMyAdmin をダウンロード、インストール、構成し、最後に phpMyAdmin にログインしてデータベースを管理する必要があります。

Nodejsプロジェクトをサーバーにデプロイする方法 Nodejsプロジェクトをサーバーにデプロイする方法 Apr 21, 2024 am 04:40 AM

Node.js プロジェクトのサーバー デプロイメント手順: デプロイメント環境を準備します。サーバー アクセスの取得、Node.js のインストール、Git リポジトリのセットアップ。アプリケーションをビルドする: npm run build を使用して、デプロイ可能なコードと依存関係を生成します。コードをサーバーにアップロードします: Git またはファイル転送プロトコル経由。依存関係をインストールする: サーバーに SSH で接続し、npm install を使用してアプリケーションの依存関係をインストールします。アプリケーションを開始します。node Index.js などのコマンドを使用してアプリケーションを開始するか、pm2 などのプロセス マネージャーを使用します。リバース プロキシの構成 (オプション): Nginx や Apache などのリバース プロキシを使用して、トラフィックをアプリケーションにルーティングします。

ウェブサイトにアクセスする際のnginxの問題を解決する方法 ウェブサイトにアクセスする際のnginxの問題を解決する方法 Apr 02, 2024 pm 08:39 PM

Web サイトにアクセスすると nginx が表示されます。その理由としては、サーバーのメンテナンス、サーバーのビジー状態、ブラウザーのキャッシュ、DNS の問題、ファイアウォールのブロック、Web サイトの構成ミス、ネットワーク接続の問題、Web サイトのダウンなどが考えられます。次の解決策を試してください: メンテナンスが終了するまで待つ、オフピーク時間にアクセスする、ブラウザのキャッシュをクリアする、DNS キャッシュをフラッシュする、ファイアウォールまたはウイルス対策ソフトウェアを無効にする、サイト管理者に連絡する、ネットワーク接続を確認する、または検索エンジンを使用するWeb アーカイブを使用して、サイトの別のコピーを見つけます。問題が解決しない場合は、サイト管理者にお問い合わせください。

Dockerコンテナ間で通信する方法 Dockerコンテナ間で通信する方法 Apr 07, 2024 pm 06:24 PM

Docker 環境でのコンテナ通信には、共有ネットワーク、Docker Compose、ネットワーク プロキシ、共有ボリューム、メッセージ キューの 5 つの方法があります。分離とセキュリティのニーズに応じて、Docker Compose を利用して接続を簡素化するか、ネットワーク プロキシを使用して分離を強化するなど、最も適切な通信方法を選択します。

See all articles