发布于 2016-05-06 02:30:33 | 431 次阅读 | 评论: 0 | 来源: 分享
这里有新鲜出炉的Nginx开发从入门到精通,程序狗速度看过来!
Nginx WEB服务器
Nginx 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。
(点击查看大图)
(点击查看大图)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
#define NGX_MODULE_V1 0, 0, 0, 0, 0, 0, 1 // 初始化 ngx_module_s 前7个字段
#define NGX_MODULE_V1_PADDING 0, 0, 0, 0, 0, 0, 0, 0 // 初始化 ngx_module_s 最后8个字段
typedef struct ngx_module_s ngx_module_t;
struct ngx_module_s {
ngx_uint_t ctx_index; // ctx:context 分类模块索引,比如http类型模块有很多实例
ngx_uint_t index; // 全局模块索引,在nginx.c中main函数体内进行动态初始化
ngx_uint_t spare0; // 目前未使用
ngx_uint_t spare1; // 目前未使用
ngx_uint_t spare2; // 目前未使用
ngx_uint_t spare3; // 目前未使用
ngx_uint_t version; // 模块版本
void *ctx; // 该模块的上下文,一般用来创建和初始化模块配置数据结构,每个种类的模块有不同的上下文
ngx_command_t *commands;// 该模块对应的配置文件中的语句块,指向一个ngx_command_t结构数组
ngx_uint_t type;// 该模块的种类,为core/conf/event/http/mail中的一种
// 以下是一些callback函数
ngx_int_t (*init_master)(ngx_log_t *log); // 初始化master: 目前未使用
ngx_int_t (*init_module)(ngx_cycle_t *cycle);// 初始化模块
ngx_int_t (*init_process)(ngx_cycle_t *cycle); // 初始化工作进程
ngx_int_t (*init_thread)(ngx_cycle_t *cycle); // 初始化线程:目前未使用
void (*exit_thread)(ngx_cycle_t *cycle); // 退出线程:目前未使用
void (*exit_process)(ngx_cycle_t *cycle); // 退出工作进程
void (*exit_master)(ngx_cycle_t *cycle); // 退出master:目前未使用
// 这些字段:目前未使用
uintptr_t spare_hook0;
uintptr_t spare_hook1;
uintptr_t spare_hook2;
uintptr_t spare_hook3;
uintptr_t spare_hook4;
uintptr_t spare_hook5;
uintptr_t spare_hook6;
uintptr_t spare_hook7;
};
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
typedef struct ngx_command_s ngx_command_t;
#define NGX_CONF_NOARGS 0x00000001
#define NGX_CONF_TAKE1 0x00000002
#define NGX_CONF_TAKE2 0x00000004
#define NGX_CONF_TAKE3 0x00000008
#define NGX_CONF_TAKE4 0x00000010
#define NGX_CONF_TAKE5 0x00000020
#define NGX_CONF_TAKE6 0x00000040
#define NGX_CONF_TAKE7 0x00000080
#define NGX_CONF_MAX_ARGS 8
#define NGX_CONF_TAKE12 (NGX_CONF_TAKE1|NGX_CONF_TAKE2)
#define NGX_CONF_TAKE13 (NGX_CONF_TAKE1|NGX_CONF_TAKE3)
#define NGX_CONF_TAKE23 (NGX_CONF_TAKE2|NGX_CONF_TAKE3)
#define NGX_CONF_TAKE123 (NGX_CONF_TAKE1|NGX_CONF_TAKE2|NGX_CONF_TAKE3)
#define NGX_CONF_TAKE1234 (NGX_CONF_TAKE1|NGX_CONF_TAKE2|NGX_CONF_TAKE3|NGX_CONF_TAKE4)
#define NGX_CONF_ARGS_NUMBER 0x000000ff
#define NGX_CONF_BLOCK 0x00000100
#define NGX_CONF_FLAG 0x00000200
#define NGX_CONF_ANY 0x00000400
#define NGX_CONF_1MORE 0x00000800
#define NGX_CONF_2MORE 0x00001000
#define NGX_CONF_MULTI 0x00000000 /* compatibility */
#define NGX_DIRECT_CONF 0x00010000
#define NGX_MAIN_CONF 0x01000000
#define NGX_ANY_CONF 0x0F000000
#define NGX_CONF_UNSET -1
#define NGX_CONF_UNSET_UINT (ngx_uint_t) -1
#define NGX_CONF_UNSET_PTR (void *) -1
#define NGX_CONF_UNSET_SIZE (size_t) -1
#define NGX_CONF_UNSET_MSEC (ngx_msec_t) -1
#define NGX_CONF_OK NULL
#define NGX_CONF_ERROR (void *) -1
#define NGX_CONF_BLOCK_START 1
#define NGX_CONF_BLOCK_DONE 2
#define NGX_CONF_FILE_DONE 3
// 模块种类宏,定义为一个十六进制的数,这个十六进制的数就是其类型对应的ASCII码。
// 因此,nginx共有5种类型的模块,分别为"CORE","CONF","EVNT","HTTP","MAIL"。
#define NGX_CORE_MODULE 0x45524F43 /* "CORE" */
#define NGX_CONF_MODULE 0x464E4F43 /* "CONF" */
#define NGX_MAX_CONF_ERRSTR 1024
struct ngx_command_s {
ngx_str_t name; // 配置文件中的指令,如 daemon
// 指令出现的位置(main/http/server/location/upstream/mail)
// 指令值的数据类型,如NGX_CONF_FLAG表示指令读入一个布尔型数据
// 指令后带的参数,如NGX_CONF_TAKE1表示带一个参数
ngx_uint_t type;
char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf); // 设置指令值到模块自定义数据结构
ngx_uint_t conf; // 一般为 0
ngx_uint_t offset; // 指令在数据结构的偏移量
void *post; // 一般为 NULL
};
#define ngx_null_command { ngx_null_string, 0, NULL, 0, 0, NULL }
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
typedef char *(*ngx_conf_handler_pt)(ngx_conf_t *cf, ngx_command_t *dummy, void *conf);
typedef struct ngx_conf_s ngx_conf_t;
struct ngx_conf_s {
char *name; // 指令名
ngx_array_t *args; // 指令后的参数
ngx_cycle_t *cycle; // 全局数据结构
ngx_pool_t *pool; // 内存池
ngx_pool_t *temp_pool; // 临时内存池
ngx_conf_file_t *conf_file; // 指令所在配置文件
ngx_log_t *log; // 日志记录
void *ctx; // 模块上下文
ngx_uint_t module_type; // 模块类型
ngx_uint_t cmd_type; // 指令类型
ngx_conf_handler_pt handler; // set函数指针
char *handler_conf; // set函数返回值
};
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
typedef struct ngx_cycle_s ngx_cycle_t;
struct ngx_cycle_s {
void ****conf_ctx; // 配置上下文数组(含所有模块)
ngx_pool_t *pool; // 内存池
ngx_log_t *log; // 日志
ngx_log_t new_log;
ngx_connection_t **files; // 连接文件
ngx_connection_t *free_connections; // 空闲连接
ngx_uint_t free_connection_n; // 空闲连接个数
ngx_queue_t reusable_connections_queue; // 再利用连接队列
ngx_array_t listening; // 监听套接字数组
ngx_array_t pathes; // 路径数组
ngx_list_t open_files; // 打开文件链表
ngx_list_t shared_memory; // 共享内存链表
ngx_uint_t connection_n; // 连接个数
ngx_uint_t files_n; // 打开文件个数
ngx_connection_t *connections; // 连接
ngx_event_t *read_events; // 读事件
ngx_event_t *write_events; // 写事件
ngx_cycle_t *old_cycle; // old cycle指针
ngx_str_t conf_file; // 配置文件
ngx_str_t conf_param; // 配置参数
ngx_str_t conf_prefix; // 配置文件目录
ngx_str_t prefix; // 程序工作目录
ngx_str_t lock_file; // 锁文件,用在不支持accept_mutex的系统中
ngx_str_t hostname; // 主机名
};
|
每个handlers(处理模块)都有机会映射到配置文件中定义的特定位置(location)
;如果有多个handlers(处理模块)映射到特定位置时,只有一个会“赢”(说明配置文件有冲突项,应该避免发生)。处理模块以三种形式返回:
OK
ERROR
或者放弃处理这个请求而让默认处理模块来处理(主要是用来处理一些静态文件,事实上如果是位置正确而真实的静态文件,默认的处理模块会抢先处理)。
如果handlers(处理模块)把请求反向代理到后端的服务器,就变成另外一类的模块:load-balancers(负载均衡模块)
。负载均衡模块的配置中有一组后端服务器,当一个HTTP请求过来时,它决定哪台服务器应当获得这个请求。Nginx的负载均衡模块采用两种方法:
轮转法,它处理请求就像纸牌游戏一样从头到尾分发;
IP哈希法,在众多请求的情况下,它确保来自同一个IP的请求会分发到相同的后端服务器。
如果handlers(处理模块)没有产生错误,filters(过滤模块)将被调用
。多个filters(过滤模块)能映射到每个位置,所以(比如)每个请求都可以被压缩成块。它们的执行顺序在编译时决定。filters(过滤模块)是经典的“接力链表(CHAIN OF RESPONSIBILITY)”模型
:一个filters(过滤模块)被调用,完成其工作,然后调用下一个filters(过滤模块),直到最后一个filters(过滤模块)。过滤模块链的特别之处在于:
每个filters(过滤模块)不会等上一个filters(过滤模块)全部完成;
它能把前一个过滤模块的输出作为其处理内容;有点像Unix中的流水线。
过滤模块能以buffer(缓冲区)为单位进行操作,这些buffer一般都是一页(4K)大小,当然你也可以在nginx.conf文件中进行配置
。这意味着,比如,模块可以压缩来自后端服务器的响应,然后像流一样的到达客户端,直到整个响应发送完成。
总之,过滤模块链以流水线的方式高效率地向客户端发送响应信息。
客户端发送HTTP请求 –>
Nginx基于配置文件中的位置选择一个合适的处理模块 ->
(如果有)负载均衡模块选择一台后端服务器 –>
处理模块进行处理并把输出缓冲放到第一个过滤模块上 –>
第一个过滤模块处理后输出给第二个过滤模块 –>
然后第二个过滤模块又到第三个 –>
依此类推 –> 最后把响应发给客户端。
下图展示了nginx模块处理流程:
(点击查看大图)
Nginx在启动时会以daemon形式在后台运行
,采用多进程+异步非阻塞IO事件模型
来处理各种连接请求。多进程模型包括一个master进程,多个worker进程,一般worker进程个数是根据服务器CPU核数来决定的
。master进程负责管理Nginx本身和其他worker进程
。如下图:
从上图中可以很明显地看到,4个worker进程的父进程都是master进程,表明worker进程都是从父进程fork出来的,并且父进程的ppid为1,表示其为daemon进程。
需要说明的是,在nginx多进程中,每个worker都是平等的,因此每个进程处理外部请求的机会权重都是一致的。
所有实际上的业务处理逻辑都在worker进程。worker进程中有一个ngx_worker_process_cycle()函数,执行无限循环,不断处理收到的来自客户端的请求,并进行处理
,直到整个Nginx服务被停止。
worker 进程中,ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中,一个请求的简单处理流程如下:
- 操作系统提供的机制(例如 epoll, kqueue 等)产生相关的事件。
- 接收和处理这些事件,如是接收到数据,则产生更高层的 request 对象。
- 处理 request 的 header 和 body。
- 产生响应,并发送回客户端。
- 完成 request 的处理。
- 重新初始化定时器及其他事件。
下面来介绍一个请求进来,多进程模型的处理方式:
首先,master进程一开始就会根据我们的配置,
来建立需要listen的网络socket fd
,然后fork出多个worker进程。其次,根据进程的特性,新建立的worker进程,也会和master进程一样,具有相同的设置。因此,
其也会去监听相同ip端口的套接字socket fd
。然后,这个时候有多个worker进程都在监听同样设置的socket fd,
意味着当有一个请求进来的时候,所有的worker都会感知到。这样就会产生所谓的“惊群现象”
。为了保证只会有一个进程成功注册到listenfd的读事件,nginx中实现了一个“accept_mutex”类似互斥锁,只有获取到这个锁的进程,才可以去注册读事件
。其他进程全部accept 失败。最后,监听成功的worker进程,读取请求,解析处理,响应数据返回给客户端,断开连接,结束。因此,一个request请求,只需要worker进程就可以完成。
进程模型的处理方式带来的一些好处就是:进程之间是独立的
,也就是一个worker进程出现异常退出,其他worker进程是不会受到影响的;此外,独立进程也会避免一些不需要的锁操作,这样子会提高处理效率,并且开发调试也更容易。
如前文所述,多进程模型+异步非阻塞模型
才是胜出的方案。单纯的多进程模型会导致连接并发数量的降低,而采用异步非阻塞IO模型很好的解决了这个问题
;并且还因此避免的多线程的上下文切换导致的性能损失。
worker进程会竞争监听客户端的连接请求:这种方式可能会带来一个问题,就是可能所有的请求都被一个worker进程给竞争获取了,导致其他进程都比较空闲,而某一个进程会处于忙碌的状态,这种状态可能还会导致无法及时响应连接而丢弃discard掉本有能力处理的请求
。这种不公平的现象,是需要避免的,尤其是在高可靠web服务器环境下。
针对这种现象,Nginx采用了一个是否打开accept_mutex选项的值,ngx_accept_disabled标识控制一个worker进程是否需要去竞争获取accept_mutex选项,进而获取accept事件
。
ngx_accept_disabled值,nginx单进程的所有连接总数的八分之一,减去剩下的空闲连接数量,得到的这个ngx_accept_disabled。
当ngx_accept_disabled大于0时,不会去尝试获取accept_mutex锁,并且将ngx_accept_disabled减1,于是,每次执行到此处时,都会去减1,直到小于0。不去获取accept_mutex锁,就是等于让出获取连接的机会,很显然可以看出,
当空闲连接越少时,ngx_accept_disable越大,于是让出的机会就越多,这样其它进程获取锁的机会也就越大
。不去accept,自己的连接就控制下来了,其它进程的连接池就会得到利用,这样,nginx就控制了多进程间连接的平衡了。
从 Nginx 的内部来看,一个 HTTP Request 的处理过程涉及到以下几个阶段:
初始化 HTTP Request(读取来自客户端的数据,生成 HTTP Request 对象,该对象含有该请求所有的信息)。
处理请求头。
处理请求体。
如果有的话,调用与此请求(URL 或者 Location)关联的 handler。
依次调用各 phase handler 进行处理。
以上步骤,如下图所示:
在这里,我们需要了解一下 phase handler 这个概念。phase 字面的意思,就是阶段。所以 phase handlers 也就好理解了,就是包含若干个处理阶段的一些 handler
。
在每一个阶段,包含有若干个 handler
,再处理到某个阶段的时候,依次调用该阶段的 handler 对 HTTP Request 进行处理。
通常情况下,一个 phase handler 对这个 request 进行处理,并产生一些输出。通常 phase handler 是与定义在配置文件中的某个 location 相关联的
。
一个 phase handler 通常执行以下几项任务:
获取 location 配置。
产生适当的响应。
发送 response header。
发送 response body。
当 Nginx 读取到一个 HTTP Request 的 header 的时候,Nginx 首先查找与这个请求关联的虚拟主机的配置
。如果找到了这个虚拟主机的配置,那么通常情况下,这个 HTTP Request 将会经过以下几个阶段的处理(phase handlers):
NGX_HTTP_POST_READ_PHASE: 读取请求内容阶段
NGX_HTTP_SERVER_REWRITE_PHASE: Server 请求地址重写阶段
NGX_HTTP_FIND_CONFIG_PHASE: 配置查找阶段
NGX_HTTP_REWRITE_PHASE: Location请求地址重写阶段
NGX_HTTP_POST_REWRITE_PHASE: 请求地址重写提交阶段
NGX_HTTP_PREACCESS_PHASE: 访问权限检查准备阶段
NGX_HTTP_ACCESS_PHASE: 访问权限检查阶段
NGX_HTTP_POST_ACCESS_PHASE: 访问权限检查提交阶段
NGX_HTTP_TRY_FILES_PHASE: 配置项 try_files 处理阶段
NGX_HTTP_CONTENT_PHASE: 内容产生阶段
NGX_HTTP_LOG_PHASE: 日志模块处理阶段
在内容产生阶段,为了给一个 request 产生正确的响应,Nginx 必须把这个 request 交给一个合适的 content handler 去处理
。如果这个 request 对应的 location 在配置文件中被明确指定了一个 content handler,那么Nginx 就可以通过对 location 的匹配,直接找到这个对应的 handler,并把这个 request 交给这个 content handler 去处理。这样的配置指令包括像,perl,flv,proxy_pass,mp4等。
如果一个 request 对应的 location 并没有直接有配置的 content handler,那么 Nginx 依次尝试:
如果一个 location 里面有配置 random_index on,那么随机选择一个文件,发送给客户端。
如果一个 location 里面有配置 index 指令,那么发送 index 指令指明的文件,给客户端。
如果一个 location 里面有配置 autoindex on,那么就发送请求地址对应的服务端路径下的文件列表给客户端。
如果这个 request 对应的 location 上有设置 gzip_static on,那么就查找是否有对应的.gz文件存在,有的话,就发送这个给客户端(客户端支持 gzip 的情况下)。
请求的 URI 如果对应一个静态文件,static module 就发送静态文件的内容到客户端。
内容产生阶段完成以后,生成的输出会被传递到 filter 模块去进行处理
。filter 模块也是与 location 相关的。所有的 fiter 模块都被组织成一条链。输出会依次穿越所有的 filter,直到有一个 filter 模块的返回值表明已经处理完成。
这里列举几个常见的 filter 模块,例如:
server-side includes。
XSLT filtering。
图像缩放之类的。
gzip 压缩。
在所有的 filter 中,有几个 filter 模块需要关注一下。按照调用的顺序依次说明如下:
copy: 将一些需要复制的 buf(文件或者内存)重新复制一份然后交给剩余的 body filter 处理。
postpone: 这个 filter 是负责 subrequest 的,也就是子请求的。
write: 写输出到客户端,实际上是写到连接对应的 socket 上。