Nginx服務(wù)器中l(wèi)ocation配置的一些基本要點解析
在這一篇文章里，我將介紹nginx關(guān)于location的處理，大家都知道Nginx配置文件里面會有很多的location，nginx的配置指令的作用域可以分為 main，server，location這3個種，實際上這3者不是依次包含的關(guān)系，而是相互獨立的關(guān)系，比如一個只具有main級別作用域的指令，是不能寫在某個server或者location內(nèi)的，模塊的某個指令可以同時具有main，server，location這3種作用域，另外每個模塊有 main,srv,loc這3個級別的配置，一個模塊的main級別的配置對所有的server和location都是共享的，srv級別的配置對所有 location都是共享的，location只有自己獨立的loc級別的配置，這就是為什么一個模塊的srv和loc級別的配置需要merge，而 main級別的配置不需要merge的原因。這里看起來有點繞，區(qū)分一下main，server，location分別作為一種作用域級別和一個主體，類似于形容詞和名字的區(qū)別，nginx的配置關(guān)系還是不難理解的。
一般來說一個請求url過來，nginx會將它解析到某一個location來處理。這個解析的過程實際上根據(jù)location的配置基本可以分為字符串匹配和正則表達(dá)式匹配這2種。對于location的組織方式，最簡單的就是直接將它們保存為一個鏈表，解析url的時候一個一個遍歷即可找到相應(yīng)location，但是這樣效率太低，對像nginx這種高性能的服務(wù)器來說是完全不可取的，nginx將字符串匹配的location組織成了一個三叉的字符串排序樹，而且建立的時候也考慮了樹的平衡性。文章后面我講詳細(xì)介紹源碼的實現(xiàn)。
首先我來大概的介紹一下location的種類和匹配規(guī)則，以nginx wiki(http://wiki.nginx.org/HttpCoreModule#location)的例子做說明：
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 ]
}
可以看到上面的例子中有5種不同類型的location，其中第4個帶 “~” 號前綴的為需要正則匹配的location，nginx在進(jìn)行url解析時對這5種不同類型的location具有不同的優(yōu)先級規(guī)則，大致的規(guī)則如下：
1，字符串精確匹配到一個帶 “=” 號前綴的location，則停止，且使用這個location的配置；
2，字符串匹配剩下的非正則和非特殊location，如果匹配到某個帶 "^~" 前綴的location，則停止；
3，正則匹配，匹配順序為location在配置文件中出現(xiàn)的順序。如果匹配到某個正則location，則停止，并使用這個location的配置；否則，使用步驟2中得到的具有最大字符串匹配的location配置。
例如，對下面的請求有:
1， / -> 精確匹配到第1個location，匹配停止，使用configuration A
2，/some/other/url -> 首先前綴部分字符串匹配到了第2個location，然后進(jìn)行正則匹配，顯然沒有匹配上，則使用第2個location的配置configurationB
3，/images /1.jpg -> 首先前綴部分字符串匹配到了第2個location，但是接著對第3個location也前綴匹配上了，而且這時已經(jīng)是配置文件里面對這個url的最大字符串匹配了，并且location帶有 "^~" 前綴，則不再進(jìn)行正則匹配，最終使用configuration C
4，/some/other/path/to/1.jpg -> 首先前綴部分同樣字符串匹配到了第2個location，然后進(jìn)行正則匹配，這時正則匹配成功，則使用congifuration D
nginx的url匹配規(guī)則實際上有點不妥，大部分情況下一個url必須先進(jìn)行字符串匹配，然后再做正則匹配，但是實際上如果先做正則匹配，沒有匹配上再 做字符串匹配，在很多情況下可以節(jié)省掉做字符串匹配的時間。不管怎樣，先來看一下nginx源碼里面的實現(xiàn)，在介紹匹配location過程之前，先來介 紹一下nginx里面對location的組織方式，實際上在配置解析階段，nginx將字符串匹配的location和正則匹配的location分別 存儲在http core模塊的loc配置ngx_http_core_loc_conf_t結(jié)構(gòu)的下面2個字段：
ngx_http_location_tree_node_t *static_locations; (NGX_PCRE) ngx_http_core_loc_conf_t **regex_locations; if
從這2個字段的類型可以看出，字符串匹配的location被組織成了一個location tree，而正則匹配的location只是一個數(shù)組，
location tree和regex_locations數(shù)組建立過程在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;
}
}
經(jīng)過配置的讀取之后，所有server都被保存在http core模塊的main配置中的servers數(shù)組中，而每個server里面的location都被按配置中出現(xiàn)的順序保存在http core模塊的loc配置的locations隊列中，上面的代碼中先對每個server的location進(jìn)行排序和分類處理，這一步發(fā)生在 ngx_http_init_location()函數(shù)中：
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，這里需要遞歸的處理一下當(dāng)前l(fā)ocation下面的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數(shù)組中 */
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 數(shù)組中，
這里和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;
}
上面的步驟將正則匹配的location保存好了，location tree的建立在ngx_http_init_static_location_trees中進(jìn)行：
static ngx_int_t
ngx_http_init_static_location_trees(ngx_conf_t *cf,
ngx_http_core_loc_conf_t *pclcf)
{
ngx_queue_t *q, *locations;
ngx_http_core_loc_conf_t *clcf;
ngx_http_location_queue_t *lq;
locations = pclcf->locations;
if (locations == NULL) {
return NGX_OK;
}
if (ngx_queue_empty(locations)) {
return NGX_OK;
}
/* 這里也是由于nested location，需要遞歸一下 */
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;
if (ngx_http_init_static_location_trees(cf, clcf) != NGX_OK) {
return NGX_ERROR;
}
}
/* join隊列中名字相同的inclusive和exact類型location，也就是如果某個exact_match的location名字和普通字符串匹配的location名字相同的話，
就將它們合到一個節(jié)點中，分別保存在節(jié)點的exact和inclusive下，這一步的目的實際是去重，為后面的建立排序樹做準(zhǔn)備 */
if (ngx_http_join_exact_locations(cf, locations) != NGX_OK) {
return NGX_ERROR;
}
/* 遞歸每個location節(jié)點，得到當(dāng)前節(jié)點的名字為其前綴的location的列表，保存在當(dāng)前節(jié)點的list字段下 */
ngx_http_create_locations_list(locations, ngx_queue_head(locations));
/* 遞歸建立location三叉排序樹 */
pclcf->static_locations = ngx_http_create_locations_tree(cf, locations, 0);
if (pclcf->static_locations == NULL) {
return NGX_ERROR;
}
return NGX_OK;
}
經(jīng)過ngx_http_init_location（）函數(shù)處理之后，locations隊列已經(jīng)是排好序的了，建立三叉樹的過程的主要工作都在ngx_http_create_locations_list()和ngx_http_create_locations_tree()中完成，這2個 函數(shù)都是遞歸函數(shù)，第1個函數(shù)遞歸locations隊列中的每個節(jié)點，得到以當(dāng)前節(jié)點的名字為前綴的location，并保存在當(dāng)前節(jié)點的list字段 下，例如，對下列l(wèi)ocation：
location /xyz {
}
location = /xyz {
}
location /xyza {
}
location /xyzab {
}
location /xyzb {
}
location /abc {
}
location /efg {
}
location /efgaa {
}
排序的結(jié)果為/abc /efg /efgaa =/xyz /xyz /xyza /xyzab /xyzb，去重后結(jié)果為 /abc /efg /efgaa /xyz /xyza /xyzab/xyzb，ngx_http_create_locations_list()執(zhí)行后的結(jié)果為：
最后，來看下ngx_http_create_locations_tree函數(shù)：
static ngx_http_location_tree_node_t *
ngx_http_create_locations_tree(ngx_conf_t *cf, ngx_queue_t *locations,
size_t prefix)
{
...
/* 根節(jié)點為locations隊列的中間節(jié)點 */
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);
/* 從中間節(jié)點開始斷開 */
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節(jié)點的ngx_http_location_tree_node_s結(jié)構(gòu)：
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結(jié)構(gòu)用到的是left，right，tree 這3個字段， location tree實際上是一個三叉的字符串排序樹，而且這里如果某個節(jié)點只考慮左，右子樹，它是一顆平衡樹，它的建立過程有點類似于一顆平衡排序二叉樹的建立過程，先排序再用二分查找找到的節(jié)點順序插入，ngx_http_location_tree_node_s的tree節(jié)點也是一顆平衡排序樹，它是用該節(jié)點由ngx_http_create_locations_list()得到的list建立的，也就是該節(jié)點的名字是它的tree子樹里面的所有節(jié)點名字的前綴，所以tree子樹里面的所有節(jié)點的名字不用保存公共前綴，而且查找的時候，如果是轉(zhuǎn)向tree節(jié)點的話，也是不需要再比較父節(jié)點的那段字符串了。
ngx_http_create_locations_tree()函數(shù)寫的很清晰，它有一個參數(shù)是隊列l(wèi)ocations，它返回一顆三叉樹，根節(jié)點為locations的中間節(jié)點，其左子樹為locations隊列的左半部分建立的location tree，右子樹為location隊列的右半部分建立的tree，tree節(jié)點為該根節(jié)點的list隊列建立的tree。
最終建立的location tree如下（為了方便閱讀，圖中列出了tree節(jié)點的完整名字）：
PS：關(guān)于 location modifier
1. =
這會完全匹配指定的 pattern ，且這里的 pattern 被限制成簡單的字符串，也就是說這里不能使用正則表達(dá)式。
Example:
server {
server_name jb51.net;
location = /abcd {
[…]
}
}
匹配情況：
http://jb51.net/abcd # 正好完全匹配 http://jb51.net/ABCD # 如果運行 Nginx server 的系統(tǒng)本身對大小寫不敏感，比如 Windows ，那么也匹配 http://jb51.net/abcd?param1¶m2 # 忽略查詢串參數(shù)（query string arguments），這里就是 /abcd 后面的 ?param1¶m2 http://jb51.net/abcd/ # 不匹配，因為末尾存在反斜杠（trailing slash），Nginx 不認(rèn)為這種情況是完全匹配 http://jb51.net/abcde # 不匹配，因為不是完全匹配
2. (None)
可以不寫 location modifier ，Nginx 仍然能去匹配 pattern 。這種情況下，匹配那些以指定的 patern 開頭的 URI，注意這里的 URI 只能是普通字符串，不能使用正則表達(dá)式。
Example:
server {
server_name jb51.net;
location /abcd {
[…]
}
}
匹配情況：
http://jb51.net/abcd # 正好完全匹配 http://jb51.net/ABCD # 如果運行 Nginx server 的系統(tǒng)本身對大小寫不敏感，比如 Windows ，那么也匹配 http://jb51.net/abcd?param1¶m2 # 忽略查詢串參數(shù)（query string arguments），這里就是 /abcd 后面的 ?param1¶m2 http://jb51.net/abcd/ # 末尾存在反斜杠（trailing slash）也屬于匹配范圍內(nèi) http://jb51.net/abcde # 仍然匹配，因為 URI 是以 pattern 開頭的
3. ~
這個 location modifier 對大小寫敏感，且 pattern 須是正則表達(dá)式
Example:
server {
server_name jb51.net;
location ~ ^/abcd$ {
[…]
}
}
匹配情況：
http://jb51.net/abcd # 完全匹配 http://jb51.net/ABCD # 不匹配，~ 對大小寫是敏感的 http://jb51.net/abcd?param1¶m2 # 忽略查詢串參數(shù)（query string arguments），這里就是 /abcd 后面的 ?param1¶m2 http://jb51.net/abcd/ # 不匹配，因為末尾存在反斜杠（trailing slash），并不匹配正則表達(dá)式 ^/abcd$ http://jb51.net/abcde # 不匹配正則表達(dá)式 ^/abcd$
注意：對于一些對大小寫不敏感的系統(tǒng)，比如 Windows ，~ 和 ~* 都是不起作用的，這主要是操作系統(tǒng)的原因。
4. ~*
與 ~ 類似，但這個 location modifier 不區(qū)分大小寫，pattern 須是正則表達(dá)式
Example:
server {
server_name jb51.net;
location ~* ^/abcd$ {
[…]
}
}
匹配情況：
http://jb51.net/abcd # 完全匹配 http://jb51.net/ABCD # 匹配，這就是它不區(qū)分大小寫的特性 http://jb51.net/abcd?param1¶m2 # 忽略查詢串參數(shù)（query string arguments），這里就是 /abcd 后面的 ?param1¶m2 http://jb51.net/abcd/ # 不匹配，因為末尾存在反斜杠（trailing slash），并不匹配正則表達(dá)式 ^/abcd$ http://jb51.net/abcde # 不匹配正則表達(dá)式 ^/abcd$
5. ^~
匹配情況類似 2. (None) 的情況，以指定匹配模式開頭的 URI 被匹配，不同的是，一旦匹配成功，那么 Nginx 就停止去尋找其他的 Location 塊進(jìn)行匹配了（與 Location 匹配順序有關(guān)）
6. @
用于定義一個 Location 塊，且該塊不能被外部 Client 所訪問，只能被 Nginx 內(nèi)部配置指令所訪問，比如 try_files or error_page
- Nginx配置指令location匹配符優(yōu)先級和安全問題
- Nginx服務(wù)器中的location配置詳解
- 詳解nginx中l(wèi)ocation、rewrite用法總結(jié)
- nginx location中uri的截取的實現(xiàn)方法
- 詳解Nginx location 匹配規(guī)則
- nginx location 配置 正則表達(dá)式實例詳解
- nginx?location/區(qū)別詳解
- 詳解nginx rewrite和根據(jù)url參數(shù)location
- nginx?配置指令之location使用詳解
- 深入解析nginx路由location匹配規(guī)則及其優(yōu)先級
相關(guān)文章
這篇文章主要介紹了nginx配置ssl實現(xiàn)https的方法示例，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-01-01
下面小編就為大家分享一篇Nginx 日志改成 JSON 格式的方法，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2018-03-03
Nginx限制某個IP同一時間段的訪問次數(shù)和請求數(shù)示例代碼
nginx可以通過ngx_http_limit_conn_module和ngx_http_limit_req_module配置來限制ip在同一時間段的訪問次數(shù).具體示例代碼大家參考下本文2017-08-08
這篇文章主要介紹了Nginx在MAC上的安裝、啟動、重啟和關(guān)閉的相關(guān)資料,需要的朋友可以參考下2018-03-03
本文給大家分享基于域名、端口和IP搭建nginx虛擬主機的內(nèi)容，非常不錯，具有一定的參考借鑒價值，需要的朋友參考下吧2019-11-11
windows下nginx+tomcat配置負(fù)載均衡的方法
這篇文章主要介紹了windows下nginx+tomcat配置負(fù)載均衡的方法,需要的朋友可以參考下2016-09-09
這篇文章主要介紹了win10安裝配置nginx的過程，幫助大家更好的理解和使用nginx服務(wù)器，感興趣的朋友可以了解下2020-10-10
配置解決Nginx服務(wù)器中WordPress路徑不自動加斜杠問題
這篇文章主要介紹了配置解決Nginx服務(wù)器中WordPress路徑不自動加斜杠問題,nginx不會自動在請求的最后加上一個斜線的問題文中也有提到通用的規(guī)則改寫方法,需要的朋友可以參考下2016-01-01
nginx是我們最常用的服務(wù)器，常用于做內(nèi)容分發(fā)和反向代理，本文主要介紹了nginx+lua單機上萬并發(fā)的實現(xiàn)，有興趣的可以了解下2021-05-05
詳解Nginx 靜態(tài)文件服務(wù)配置及優(yōu)化
這篇文章主要介紹了Nginx 靜態(tài)文件服務(wù)配置及優(yōu)化，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2019-05-05