nginx的配置系统
nginx的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件,全部位于nginx安装目录下的conf目录下。
配置文件中以#开始的行,或者是前面有若干空格或者TAB,然后再跟#的行,都被认为是注释,也就是只对编辑查看文件的用户有意义,程序在读取这些注释行的时候,其实际的内容是被忽略的。
由于除主配置文件nginx.conf以外的文件都是在某些情况下才使用的,而只有主配置文件是在任何情况下都被使用的。所以在这里我们就以主配置文件为例,来解释nginx的配置系统。
在nginx.conf中,包含若干配置项。每个配置项由配置指令和指令参数2个部分构成。指令参数也就是配置指令对应的配置值。
配置指令是一个字符串,可以用单引号或者双引号括起来,也可以不括。但是如果配置指令包含空格,一定要引起来。
指令的参数使用一个或者多个空格或者TAB字符与指令分开。指令的参数有一个或者多个TOKEN串组成。TOKEN串之间由空格或者TAB键分隔。
如果一个配置指令的参数全部由简单字符串构成,也就是不包含复合配置块,那么我们就说这个配置指令是一个简单配置项,否则称之为复杂配置项。例如下面这个是一个简单配置项:
例如:
error_page 500 502 503 504 /50x.html;
对于简单配置,配置项的结尾使用分号结束。对于复杂配置项,包含多个TOKEN串的,一般都是简单TOKEN串放在前面,复合配置块一般位于最后,而且其结尾,并不需要再添加分号。例如下面这个复杂配置项:
例如:
location / { root /home/jizhao/nginx-book/build/html; index index.html index.htm; }
nginx.conf中的配置信息,根据其逻辑上的意义,对它们进行了分类,也就是分成了多个作用域,或者称之为配置指令上下文。不同的作用域含有一个或者多个配置项。
当前nginx支持的几个指令上下文:
main: | nginx在运行时与具体业务功能(比如http服务或者email服务代理)无关的一些参数,比如工作进程数,运行的身份等。 |
---|---|
http: | 与提供http服务相关的一些配置参数。例如:是否使用keepalive啊,是否使用gzip进行压缩等。 |
server: | http服务上支持若干虚拟主机。每个虚拟主机一个对应的server配置项,配置项里面包含该虚拟主机相关的配置。在提供mail服务的代理时,也可以建立若干server.每个server通过监听的地址来区分。 |
location: | http服务中,某些特定的URL对应的一系列配置项。 |
mail: | 实现email相关的SMTP/IMAP/POP3代理时,共享的一些配置项(因为可能实现多个代理,工作在多个监听地址上)。 |
典型的,如下的一个标准配置:
user nobody; worker_processes 1; error_log logs/error.log info; events { worker_connections 1024; } http { server { listen 80; server_name www.linuxidc.com; access_log logs/linuxidc.access.log main; location / { index index.html; root /var/www/linuxidc.com/htdocs; } } server { listen 80; server_name www.Androidj.com; access_log logs/androidj.access.log main; location / { index index.html; root /var/www/androidj.com/htdocs; } } } mail { auth_http 127.0.0.1:80/auth.php; pop3_capabilities "TOP" "USER"; imap_capabilities "IMAP4rev1" "UIDPLUS"; server { listen 110; protocol pop3; proxy on; } server { listen 25; protocol smtp; proxy on; smtp_auth login plain; xclient off; } }
存在于main上下文中的配置指令如下:
存在于http上下文中的指令如下:
存在于mail上下文中的指令如下:
存在于server上下文中的配置指令如下:
存在于location上下文中的指令如下:
当然,这里只是一些示例。具体有哪些配置指令,以及这些配置指令可以出现在什么样的上下文中,需要参考nginx的使用文档。
nginx的模块化体系结构
nginx提供了web服务器的基础功能,同时提供了web服务反向代理,email服务反向代理功能。nginx core实现了底层的通讯协议,为其他模块和nginx进程构建了基本的运行时环境,并且构建了其他各模块的协作基础。除此之外,或者说大部分与协议相关的,或者应用相关的功能都是在这些模块中所实现的。
nginx将各功能模块组织成一条链,当有请求到达的时候,请求依次经过这条链上的部分或者全部模块,进行处理。每个模块实现特定的功能。
nginx的模块根据其功能基本上可以分为以下几种类型:
event module: | 搭建了独立于操作系统的事件处理机制的框架,及提供了各具体事件的处理。包括ngx_events_module, ngx_event_core_module和ngx_epoll_module等。nginx具体使用何种事件处理模块,这依赖于具体的操作系统和编译选项。 |
---|---|
phase handler: | 此类型的模块也被直接称为handler模块。主要负责处理客户端请求并产生待响应内容,比如ngx_http_static_module模块,负责客户端的静态页面请求处理并将对应的磁盘文件准备为响应内容输出。 |
output filter: | 也称为filter模块,主要是负责对输出的内容进行处理,可以对输出进行修改。例如,可以实现对输出的所有html页面增加预定义的footbar一类的工作,或者对输出的图片的URL进行替换之类的工作。 |
upstream: | upstream模块实现反向代理的功能,将真正的请求转发到后端服务器上,并从后端服务器上读取响应,发回客户端。upstream模块是一种特殊的handler,只不过响应内容不是真正由自己产生的,而是从后端服务器上读取的。 |
load-balancer: | 负载均衡模块,实现特定的算法,在众多的后端服务器中,选择一个服务器出来作为某个请求的转发服务器。 |
nginx使用一个多进程模型来对外提供服务,其中一个master进程,多个worker进程。master进程负责管理nginx本身和其他worker进程。
所有实际上的业务处理逻辑都在worker进程。worker进程中有一个函数,执行无限循环,不断处理收到的来自客户端的请求,并进行处理,直到整个nginx服务被停止。
worker进程中,ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中,一个请求的简单处理流程如下:
以HTTP Request为例,nginx的请求处理过程如下:
一个phase handler通常执行以下几项任务:
当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依次尝试:
内容产生阶段完成以后,生成的输出会被传递到filter模块去进行处理。filter模块也是与location相关的。所有的fiter模块都被组织成一条链。输出会依次穿越所有的filter,直到有一个filter模块的返回值表明已经处理完成。
这里列举几个常见的filter模块,例如:
原文:https://www.cnblogs.com/Anderson-Chaow/p/12317857.html