Nginx源码剖析--server和location的组织

---

前言

我们知道，Nginx的配置文件的http块中一般会存在多个server块，每个server块中也会有多个locations块，而每个location块中也允许有多个location块。前面我们在分析http模块的配置结构体的时候也看到，这些块是通过上一级配置块对应的的ngx_http_core_module模块创建的配置结构体管理的。比如http块中的所有server块都是由ngx_http_core_module模块的ngx_http_core_main_conf_t->servers成员组织，server块和location块中的所有location块都是由ngx_http_core_module模块创建的ngx_http_core_loc_conf_s结构体的locations成员管理。其中servers是一个数组，locations是一个队列。

---

servers和locations的组织

一般一个NGINX上的支持的虚拟主机不会很多，所以server块的配置结构体就直接存在serves数组中，不需要做额外的处理了。但是location不同，location的作用是和请求的url匹配，然后利用匹配的location块的配置结构体来处理这个请求，而且一般location的数量比较多，因此，为了加速请求的url匹配到对应的location块，Nginx对每个locations队列都进行了重新组织，将每个locations队列重新单独组织成一个三叉树，并将这个三叉树存储到ngx_http_core_loc_conf_s结构体的static_locations中。这里需要额外提一句的是，locations分为多种：

1. 绝对匹配
2. 前缀匹配
3. 正则匹配

url在匹配location的时候，是有一个顺序的：官方文档
而三叉树主要是用来组织绝对匹配和前缀匹配的location块。像正则匹配的location块则是用ngx_http_core_loc_conf_s中的regex_locations数组来管理。所以说，重新组织之后，后面匹配location时就和原来的locations队列没什么关系了。

至于三叉树的构建方式，可以参考这篇博文。也是挺复杂的。

---

总结

本篇博文主要介绍了Nginx中为了加快查找匹配的server和location块的组织方式。server块的配置结构体使用数组存储；location块的配置结构体是用三叉树来存储。Nginx为每个locations队列都单独组建一个三叉树。