在这一篇文章里，我将介绍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(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在进行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 "htmlcode">
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 "htmlcode">
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)
{
...
/* 根节点为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"htmlcode">
Example:
server {
server_name jb51.net;
location /abcd {
[…]
}
}
匹配情况：
http://jb51.net/abcd # 正好完全匹配
http://jb51.net/ABCD # 如果运行 Nginx server 的系统本身对大小写不敏感，比如 Windows ，那么也匹配
http://jb51.net/abcd"htmlcode">
Example:
server {
server_name jb51.net;
location ~ ^/abcd$ {
[…]
}
}
匹配情况：
http://jb51.net/abcd # 完全匹配
http://jb51.net/ABCD # 不匹配，~ 对大小写是敏感的
http://jb51.net/abcd"htmlcode">
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
DDR爱好者之家 Design By 杰米
广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
DDR爱好者之家 Design By 杰米
暂无评论...
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]