Nginx的模块化体系结构
模块概述
Nginx的内部结构是核心部分和一系列的功能模块所组成。
我们一般将
Nginx core
称为Nginx核心,其提供了web服务器的基础功能,同时提供了web服务反向代理,email服务反向代理,Nginx核心实现了底层的通讯协议,为其他模块和Nginx进程构建了基本的运行时环境。
Nginx将各功能模块组成成一条链,请求依次经过这条链上的部分或者全部模块进行处理。
模块的分类
event module
:搭建了独立于操作系统的事件处理机制框架,及提供了各具体事件的处理。包括ngx_event_module,ngx_event_core_module和ngx_epoll_module等。phase handler
:此模型又被称为handler模块,主要负责处理客户端请求并产生响应内容的output filter
:filter模块,主要负责对输出的内容进行处理,可以对输出进行修改。upstream
:此模块实现反向代理功能,将真正的请求转发到后端服务器上,并从后端服务器上读取响应,发回客户端- load-balancer:负载进行模块,实现特点的算法,在众多后端服务器中,选择一个服务器来作为某个请求的转发服务器。
Nginx的请求处理
Nginx使用一个多进程模型来对外提供服务,一个master进程,多个worker进程。master进程负责管理Nginx本身和其他worker进程。
所有的业务逻辑处理都在worker进程。worker进程中有一个函数,执行无限循环,不断处理收到的来自客户端的请求,并进行处理,直到整个Nginx服务器被停止。
worker进程中,ngx_worker_process_cycle()
函数就是这个无限循环的处理函数。在这个函数中,一个请求的处理如下:
- 操作系统提供的机制产生相应的事件
- 接受和处理这些事件,如是接收到 数据,则产生更高层的request对象
- 处理request的
header
和body
- 产生响应,并发送回客户端
- 完成request的处理
- 重新初始化定时器和其他事件
请求的处理流程
以HTTP Request
为例
从Nginx的内部来看,一个HTTP Request
的处理过程涉及到以下几个阶段:
- 初始化HTTP Request
- 处理请求头
- 处理请求体
- 调用与此请求相关的handler(如果有的话)
- 依次调用各phase handler进行处理
通常情况下,一个phase handler对这个request进行处理,并产生一些输出。通常phase handler是与定义在配置文件中的某个location相关联的。
一个phase handler通常执行以下几项任务:
- 获取location配置
- 产生适当的响应
- 发送response header
- 发送response body
当Nginx读取到header的实收,会查找与这个请求相关的虚拟主机的配置,然后执行以下几个阶段:
在内容产生阶段,为了给一个request产生正确的响应,Nginx必须把这个request
交给一个合适的content handler
进行处理,如果这个request
对应的location
在配置文件中被明确指定了一个content handler
,那么Nginx就可以通过对location
的匹配直接找到这个对应的handler,并把这个request
交给这个handler。
如果一个request
对应的location
并没有直接配置的content handler
,那么Nginx会依次做以下尝试:
- 如果location里面配置有r
andom_index on
,那么随机选择一个文件,发给客户端。 - 如果location配置有
index
指定,那么发送index
指令指明的文件。 - 如果location里面有配置
autoindex on
,那么就发送请求地址对应的服务端路径下的文件列表给客户端 - 如果location有设置
gzip_static on
,那么查找是否有对应的.gz
文件存在,有就发送 - 请求的URL如果对应一个静态文件,
static module
就发送静态文件的内容到客户端
内容产生阶段完后,生成的输出会被传递到filter
模块去进行处理。filter模块也是与location相关的。所有的filter模块都被组织成一条链。输出会依次穿越所有的filter,直到有个filter模块的返回值表明已经处理完成。
参考文献
[1] Nginx开发从入门到精通