首先我來大概的介紹一下location的種類和匹配規則,以nginx wiki的例子做說明:
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在進行url解析時對這5種不同類型的location具有不同的優先權規則,大致的規則如下:
1,字串精確匹配到一個帶有「=」 號前綴的location,則停止,且使用這個location的配置;
2,字串匹配剩下的非正則和非特殊location,如果匹配到某個帶"^~" 前綴的location,則停止;
3,正則匹配,匹配順序為location在配置文件中出現的順序。如果匹配到某個正則location,則停止,並使用這個location的配置;否則,使用步驟2中得到的具有最大字串匹配的location配置。
例如,對下面的請求有:
#1, / -> 精確配對到第1個location,配對停止,使用configuration a
2,/some/other/url -> 首先前綴部分字串匹配到了第2個location,然後進行正規匹配,顯然沒有匹配上,則使用第2個location的配置configurationb
3,/images /1.jpg -> 首先前綴部分字串匹配到了第2個location,但是接著對第3個location也前綴匹配上了,而且這時已經是配置文件裡面對這個url的最大字符串匹配了,並且location帶有"^~" 前綴,則不再進行正規匹配,最終使用configuration c
4,/some/other/path/to/1.jpg -> 首先前綴部分同樣字符串匹配到了第2個location,然後進行正則匹配,這時正則匹配成功,則使用congifuration d
nginx的url匹配規則實際上有點不妥,大部分情況下一個url必須先進行字符串匹配,然後再做正則匹配,但是實際上如果先做正規匹配,沒有匹配上再做字符串匹配,在很多情況下可以節省掉做字符串匹配的時間。不管怎樣,先來介紹一下nginx源碼裡面的實現,在介紹匹配location過程之前,先來介紹一下nginx裡面對location的組織方式,實際上在配置解析階段,nginx將字符串匹配的location和正則匹配的location分別儲存在http core模組的loc配置ngx_http_core_loc_conf_t結構的下面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只是一個數組,
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; } }
配置的讀取之後,所有server都被保存在http core模組的main配置中的servers數組中,而每個server裡面的location都被按配置中出現的順序保存在http core模組的loc配置的locations佇列中,上面的程式碼中先對每個server的location進行排序和分類處理,這一步發生在ngx_http_init_location()函數中:
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; }
卷[ 之後,locations佇列已經是排好序的了,建立三叉樹的過程的主要工作都在ngx_http_create_locations_list()和ngx_http_create_locations_tree()中完成,這2個函數都是遞歸函數,第1個函數遞歸locations佇列中的每個節點,得到以目前節點的名字為前綴的location,並保存在目前節點的list欄位下,例如,對下列location:
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名字相同的话, 就将它们合到一个节点中,分别保存在节点的exact和inclusive下,这一步的目的实际是去重,为后面的建立排序树做准备 */ if (ngx_http_join_exact_locations(cf, locations) != ngx_ok) { return ngx_error; } /* 递归每个location节点,得到当前节点的名字为其前缀的location的列表,保存在当前节点的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; }
排序的結果為/abc /efg /efgaa 排序的結果為/abc /efg /efgaa =/zz xyz /xyza /xyzab /xyzb,去重後結果為/abc /efg /efgaa /xyz /xyza /xyzab/xyzb,ngx_http_create_locations_list()執行後的結果為:
最後,來看ngx_http_create_locations_tree函數:
#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节点的完整名字):
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¶m2 # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶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¶m2 # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶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¶m2 # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶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¶m2 # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶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伺服器中location設定實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!