关于nginx location,写的很好,本文转自
http://blog.csdn.net/fengmo_q/article/details/6683377关于nginx代码解析,我师兄雕梁的博客()
有一系列的文章可以阅读。我这里将只介绍他博客里没有关注到的或者讲述不详细的,但是我个人又认为是nginx里面比较重要的东西。在这一篇文章里,我将
介绍nginx关于location的处理,大家都知道Nginx配置文件里面会有很多的location,nginx的配置指令的作用域可以分为
main,server,location这3个种,实际上这3者不是依次包含的关系,而是相互独立的关系,比如一个只具有main级别作用域的指令,是
不能写在某个server或者location内的,模块的某个指令可以同时具有main,server,location这3种作用域,另外每个模块有
main,srv,loc这3个级别的配置,一个模块的main级别的配置对所有的server和location都是共享的,srv级别的配置对所有
location都是共享的,location只有自己独立的loc级别的配置,这就是为什么一个模块的srv和loc级别的配置需要merge,而
main级别的配置不需要merge的原因。这里看起来有点绕,区分一下main,server,location分别作为一种作用域级别和一个主体,类
似于形容词和名字的区别,nginx的配置关系还是不难理解的。
一般来说一个请求url过来,nginx会将它解析到某一个location来处理。这个解析的过程实际上根据location的配置基本可以分为字符串
匹配和正则表达式匹配这2种。对于location的组织方式,最简单的就是直接将它们保存为一个链表,解析url的时候一个一个遍历即可找到相应
location,但是这样效率太低,对像nginx这种高性能的服务器来说是完全不可取的,nginx将字符串匹配的location组织成了一个三叉
的字符串排序树,而且建立的时候也考虑了树的平衡性。文章后面我讲详细介绍源码的实现。
首先我来大概的介绍一下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中:
-
-
- 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;
-
- ...
-
-
- 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;
-
- 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);
- }
-
- 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)
-
-
- 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中进行:
- 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;
- }
-
- 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;
- }
- }
-
-
- if (ngx_http_join_exact_locations(cf, locations) != NGX_OK) {
- return NGX_ERROR;
- }
-
- ngx_http_create_locations_list(locations, ngx_queue_head(locations));
-
-
- pclcf->static_locations = ngx_http_create_locations_tree(cf, locations, 0);
- if (pclcf->static_locations == NULL) {
- return NGX_ERROR;
- }
-
- return NGX_OK;
- }
经过ngx_http_init_location()函数处理之后,locations队列已经是排好序的了,建立三叉树的过程的主要工作都在
ngx_http_create_locations_list()和ngx_http_create_locations_tree()中完成,这2个
函数都是递归函数,第1个函数递归locations队列中的每个节点,得到以当前节点的名字为前缀的location,并保存在当前节点的list字段
下,例如,对下列location:
- location /xyz {
-
- }
-
- location = /xyz {
-
- }
- location /xyza {
-
- }
-
- location /xyzab {
-
- }
- location /xyzb {
-
- }
- location /abc {
-
- }
- location /efg {
-
- }
- location /efgaa {
-
- }
排序的结果为/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函数:
- static ngx_http_location_tree_node_t *
- ngx_http_create_locations_tree(ngx_conf_t *cf, ngx_queue_t *locations,
- size_t prefix)
- {
- ...
-
- 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)) {
-
-
-
-
- goto inclusive;
- }
-
-
- 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;
- }
-
-
-
- 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;
- }
-
-
- 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节点的完整名字):
location的匹配发生在nginx请求处理的NGX_HTTP_FIND_CONFIG_PHASE阶段(请求的处理所有PHASE可以看这篇博客
/blog/670326),匹配的规则文章前面已经做过介绍,源码的实现也很简单,这里不再做介绍了
阅读(555) | 评论(0) | 转发(0) |