2017年2月 总版技术专家分月排行榜第三
2017年5月 .NET技术大版内专家分月排行榜第一2017年4月 .NET技术大版内专家分月排行榜第一2017年3月 .NET技术大版内专家分月排行榜第一2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2017年3月 .NET技术大版内专家分月排行榜第三2017年2月 .NET技术大版内专家分月排行榜第三2016年9月 .NET技术大版内专家分月排行榜第三2016年8月 .NET技术大版内专家分月排行榜第三2016年7月 .NET技术大版内专家分月排行榜第三2016年3月 .NET技术大版内专家分月排行榜第三2016年1月 .NET技术大版内专家分月排行榜第三2015年12月 .NET技术大版内专家分月排行榜第三2015年11月 .NET技术大版内专家分月排行榜第三
2017年3月 .NET技术大版内专家分月排行榜第三2017年2月 .NET技术大版内专家分月排行榜第三2016年9月 .NET技术大版内专家分月排行榜第三2016年8月 .NET技术大版内专家分月排行榜第三2016年7月 .NET技术大版内专家分月排行榜第三2016年3月 .NET技术大版内专家分月排行榜第三2016年1月 .NET技术大版内专家分月排行榜第三2015年12月 .NET技术大版内专家分月排行榜第三2015年11月 .NET技术大版内专家分月排行榜第三
2013年5月 总版技术专家分月排行榜第一
2016年7月 总版技术专家分月排行榜第二2016年3月 总版技术专家分月排行榜第二2015年12月 总版技术专家分月排行榜第二2014年8月 总版技术专家分月排行榜第二2014年7月 总版技术专家分月排行榜第二2013年6月 总版技术专家分月排行榜第二
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。对于nginx $request_time的一些理解 - CSDN博客
对于nginx $request_time的一些理解
以前的理解
$request_time是 nginx收到第一个字节 到 nginx把所有响应内容放到tcp 发送缓冲区的时间。
很长一段时间，我都觉得上面的说法是正确的。
直到前两天跟同事探讨$request_time，才发现并不完全正确，才把以前的一些疑问解释了，觉得挺有意义，这里记录一下。
request_time对于很多CDN厂商来说是一个十分敏感的变量，某些时候可能涉及客户对于质量的考察，当然也许只是一些不太了解request_time变量的人。
Nginx文档对于$request_time的定义如下：
request processing time in seconds with a mil time elapsed since the first bytes were read from the client
文档只介绍了何时开始计算request_time，没有说何时结束。
对于开启长连接的请求处理，上面的说法是完全正确的。
但是对于短连接的呢？
大概是16年初，曾经某水果台曾使用我们公司CDN。客户使用几家CDN,对比发现我们的CDN慢速请求（byte_sent/request_time）数较多。
讲道理的话，这时候应该优化了。当然首先想到的肯定是sndbuf，恩，其实很多公司也确实是这么做的。
把sndbuf调整到2M, 果然排名靠前了不少。
这时候售前同学就统计了，说Http 1.0的慢速请求数还是很多。
sndbuf还区分协议的？
显然，http1.0和http1.1的一个主要区别就是http1.0默认是关闭长连接的。
查了下代码，发现 ngx_http_finalize_connection中对于是否开启长连接，走了两种不同的路径。
显然，开启了keep_alive，会走ngx_http_set_keepalive分支；但是，如若不开启，keepalive则有两种可能：
ngx_http_close_
ngx_http_set_lingering_ 显然调用lingering_close的话，会导致打印日志的时间推迟；
if (!ngx_terminate
&& !ngx_exiting
&& r-&keepalive
&& clcf-&keepalive_timeout & 0)
ngx_http_set_keepalive(r);
if (clcf-&lingering_close == NGX_HTTP_LINGERING_ALWAYS
|| (clcf-&lingering_close == NGX_HTTP_LINGERING_ON
&& (r-&lingering_close
|| r-&header_in-&pos & r-&header_in-&last
|| r-&connection-&read-&ready)))
ngx_http_set_lingering_close(r);
ngx_http_close_request(r, 0);
Nginx对于epoll采用的是NGX_USE_GREEDY_EVENT策略（The event filter requires to do i/o operation until EAGAIN: epoll.）。
这种策略导致，在调用ngx_http_finalize_connection时，read-&ready一直为1，从而调用ngx_http_set_lingering_close关闭连接。
但是这个问题在1.11.13版本，nginx引入epoll对于EPOLL_RDHUP的处理后有所改变，代码如下：
if (n == 0) {
rev-&ready = 0;
rev-&eof = 1;
if (n & 0) {
#if (NGX_HAVE_EPOLLRDHUP)
if ((ngx_event_flags & NGX_USE_EPOLL_EVENT)
&& ngx_use_epoll_rdhup)
if ((size_t) n & size) {
if (!rev-&pending_eof) {
rev-&ready = 0;
rev-&available = 0;
if ((size_t) n & size
&& !(ngx_event_flags & NGX_USE_GREEDY_EVENT))
rev-&ready = 0;
err = ngx_socket_
if (err == NGX_EAGAIN || err == NGX_EINTR) {
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c-&log, err,
"recv() not ready");
n = NGX_AGAIN;
n = ngx_connection_error(c, err, "recv() failed");
所以对于nginx 1.11.13之后的版本，无论是否开启keepalive上述的结论仍然是正确的。
对于之前版本，如果想避免lingering_close，可以在配置项中lingering_close off。
TCP Socket对于linger close的支持
close(l_onoff=0缺省状态):在套接口上不能在发出发送或接收请求;套接口发送缓冲区中的内容被发送到对端.如果描述字引用计数变为0;在发送完发送缓冲区中的数据后,跟以正常的TCP连接终止序列(发送FIN);套接口接受缓冲区中内容被丢弃
close(l_onoff = 1, l_linger =0):在套接口上不能再发出发送或接受请求,如果描述子引用计数变为0,RST被发送到对端;连接的状态被置为CLOSED(没有TIME_WAIT状态),套接口发送缓冲区和套接口接受缓冲区的数据被丢弃
close(l_onoff =1, l_linger != 0):在套接口上不能在发出发送或接收请求;套接口发送缓冲区中的内容被发送到对端.如果描述字引用计数变为0;在发送完发送缓冲区中的数据后,跟以正常的TCP连接终止序列(发送FIN);套接口接受缓冲区中内容被丢弃;如果在连接变成CLOSED状态前延滞时间到,那么close返回EWOULDBLOCK错误.
本文已收录于以下专栏：
相关文章推荐
笔者在根据nginx的accesslog中$request_time进行程序优化时，发现有个接口，直接返回数据，平均的$request_time也比较大。原来$request_tim...
今天老师在trello上给我提了个任务，就是修改nginx的日志格式，对nginx进行监控，因此又接触了两个nginx常用参数，这里记录一下
$request_time&&$upst...
   在nginx中想利用$request_body命令获取post请求的body参数，并落日志，但是发现该变量值为空，查看官网中对$request_body的描述如下：
$request...
nginx配置：
fastcgi_param
SCRIPT_FILENAME
$document_root$fastcgi_script_
fastcgi_param
本文讲解了如何设置Java VM参数实现在Full GC前后自动生成Dump。共有三个VM参数需要设置：
HeapDumpBeforeFullGC， HeapDumpBeforeFullGC和Hea...
转自：.cn/s/blog_4f9fc6e10102uxib.html
这几天在优化服务器的响应时间，为了方便的知道响应时间，打算吧request_...
vi操作，跳到最后一行按“:G”
跳到最后一行的最后一个字符 ，进入vi后按“$”键，即“shift+4”。
跳到一行的第一个字符，进入vi后按“0”。
vi真的很牛X啊。
vi加密。:X 之后就提示...
默认情况下，access log放在： …\nginx\logs目录下，文件名为：access.log，默认格式为预配置格式：combinedlog_format combined '$remote_...
前边介绍了apache服务器下的访问日志与错误日志的介绍查看与简单的分析
那么本篇介绍一下在nginx服务器的的两种日志的查看。
查找日志存放地址
find / -name nginx....
问题：nginx会按照nginx.conf的配置生成access.log和error.log，随着访问量的增长，日志文件会越来越大，既会影响访问的速度(写入日志时间延长)，也会增加查找日志的难度，ng...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)WEB请求处理二：Nginx请求反向代理 - 简书
WEB请求处理二：Nginx请求反向代理
字数 13901
上一篇，我们讲述了浏览器端请求发起过程，通过DNS域名解析服务器IP，并建立TCP连接，发送HTTP请求。本文将讲述请求到达反向代理服务器的一个处理过程，比如：在Nginx中请求的反向代理处理流程，请求都是经过了哪些模块，做了哪些处理，又是如何找到应用服务器呢？
为直观明了，先上一张图，红色部分为本章所述模块：
本章所述模块
正如标题所述，Nginx功能是进行请求的反向代理，在讲解Nginx请求处理之前，首先要给大家清楚地说明下反向代理是什么？它的功能是什么？它在Nginx中又是怎么配置实现的？
1 反向代理
反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
举个例子，比如我想访问
，但上并不存在readme页面，于是他是偷偷从另外一台服务器上取回来，然后作为自己的内容返回用户，但用户并不知情。这里所提到的
这个域名对应的服务器就设置了反向代理功能。
结论就是，反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理服务器将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。
正向代理，既然有反向代理，就肯定有正向代理。什么叫正向代理呢？
正向代理（Forward Proxy）通常都被简称为代理，就是在用户无法正常访问外部资源，比方说受到GFW的影响无法访问twitter的时候，我们可以通过代理的方式，让用户绕过防火墙，从而连接到目标网络或者服务。
正向代理的工作原理就像一个跳板，比如：我访问不了，但是我能访问一个代理服务器A，A能访问，于是我先连上代理服务器A，告诉他我需要的内容，A就去取回来，然后返回给我。从网站的角度，只在代理服务器来取内容的时候有一次记录，有时候并不知道是用户的请求，也隐藏了用户的资料，这取决于代理告不告诉网站。
结论就是，正向代理是一个位于客户端和原始服务器(origin server)之间的服务器。为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。
反向代理VS正向代理：
反向代理VS正向代理
1.2 工作流程
用户通过域名发出访问Web服务器的请求，该域名被DNS服务器解析为反向代理服务器的IP地址；
反向代理服务器接受用户的请求；
反向代理服务器在本地缓存中查找请求的内容，找到后直接把内容发送给用户；
如果本地缓存里没有用户所请求的信息内容，反向代理服务器会代替用户向源服务器请求同样的信息内容，并把信息内容发给用户，如果信息内容是缓存的还会把它保存到缓存中。
保护了真实的web服务器，web服务器对外不可见，外网只能看到反向代理服务器，而反向代理服务器上并没有真实数据，因此，保证了web服务器的资源安全
通常的代理服务器，只用于代理内部网络对Internet外部网络的连接请求，客户机必须指定代理服务器，并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。不支持外部网络对内部网络的连接请求，因为内部网络对外部网络是不可见的。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。
代理服务器充当内容服务器的替身，如果您的内容服务器具有必须保持安全的敏感信息，如信用卡号数据库，可在防火墙外部设置一个代理服务器作为内容服务器的替身。当外部客户机尝试访问内容服务器时，会将其送到代理服务器。实际内容位于内容服务器上，在防火墙内部受到安全保护。代理服务器位于防火墙外部，在客户机看来就像是内容服务器。
当客户机向站点提出请求时，请求将转到代理服务器。然后，代理服务器通过防火墙中的特定通路，将客户机的请求发送到内容服务器。内容服务器再通过该通道将结果回传给代理服务器。代理服务器将检索到的信息发送给客户机，好像代理服务器就是实际的内容服务器。如果内容服务器返回错误消息，代理服务器会先行截取该消息并更改标头中列出的任何URL，然后再将消息发送给客户机。如此可防止外部客户机获取内部内容服务器的重定向URL。
这样，代理服务器就在安全数据库和可能的恶意攻击之间提供了又一道屏障。与有权访问整个数据库的情况相对比，就算是侥幸攻击成功，作恶者充其量也仅限于访问单个事务中所涉及的信息。未经授权的用户无法访问到真正的内容服务器，因为防火墙通路只允许代理服务器有权进行访问。
可以配置防火墙路由器，使其只允许特定端口上的特定服务器有权通过防火墙进行访问，而不允许其他任何机器进出。安全反向代理，指当代理服务器与其他机器之间有一个或多个连接使用安全套接字层 (SSL) 协议加密数据时，即会进行安全反向代理。
节约了有限的IP地址资源
企业内所有的网站共享一个在internet中注册的IP地址，这些服务器分配私有地址，采用虚拟主机的方式对外提供服务。
减少WEB服务器压力，提高响应速度
反向代理就是通常所说的web服务器加速，它是一种通过在繁忙的web服务器和外部网络之间增加一个高速的web缓冲服务器来降低实际的web服务器的负载的一种技术。反向代理是针对web服务器提高加速功能，作为代理缓存，它并不是针对浏览器用户，而针对一台或多台特定的web服务器，它可以代理外部网络对内部网络的访问请求。
反向代理服务器会强制将外部网络对要代理的服务器的访问经过它，这样反向代理服务器负责接收客户端的请求，然后到源服务器上获取内容，把内容返回给用户，并把内容保存到本地，以便日后再收到同样的信息请求时，它会把本地缓存里的内容直接发给用户，以减少后端web服务器的压力，提高响应速度。因此Nginx还具有缓存功能。
（1）请求的统一控制，包括设置权限、过滤规则等；
（2）区分动态和静态可缓存内容；
（3）实现负载均衡，内部可以采用多台服务器来组成服务器集群，外部还是可以采用一个地址访问；
（4）解决Ajax跨域问题；
（5）作为真实服务器的缓冲，解决瞬间负载量大的问题；
2 Nginx常用配置
写到这时，一直在由于要不要去开这一节Nginx配置的讲解，如果讲的话，感觉与本文的主题有所偏离，但又考虑到，如果对Nginx配置文件都不熟悉的话，下面的内容再去讲解Nginx反向代理处理流程就有点纸上谈兵了，担心大家有些云里雾里，毫无收获。
终究旨在为了要让大家有所收获的初衷，决定还是要着重讲解Nginx的几种常见配置，其中包括：动静分离、缓存设置、负载均衡、反向代理、还有虚拟主机功能。
2.1 Nginx启动和关闭
Mac平台，我用brew安装的：
/usr/local/bin/nginx # 启动
/usr/local/bin/nginx -s reload #平滑重启
/usr/local/etc/f #配置文件。
2.2 配置文件详解
其实，对比，apache的配置文件，它的相对比较清晰和简单，之前觉得很难，现在沉下心来想想，其实很简单。大致的分块下，基本就分为以下几块：
main # 全局设置
events { # Nginx工作模式
http { # http设置
upstream myproject { # 负载均衡服务器设置
{ # 主机设置
location { # URL匹配
location {
2.2.1 main模块
下面是一个main区域，它是一个全局的设置：
worker_processes 2;
error_log /usr/local/var/log/nginx/error.
pid /usr/local/var/run/nginx/nginx.
worker_rlimit_nofile 1024;
user 来指定Nginx Worker进程运行用户以及用户组，默认由nobody账号运行。
worker_processes 来指定了Nginx要开启的子进程数。每个Nginx进程平均耗费10M~12M内存。根据经验，一般指定1个进程就足够了，如果是多核CPU，建议指定和CPU的数量一样的进程数即可。我这里写2，那么就会开启2个子进程，总共3个进程。
error_log 来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少。
pid 来指定进程id的存储文件位置。
worker_rlimit_nofile 来指定一个nginx进程可以打开的最多文件描述符数目，这里是65535，需要使用命令“ulimit -n 65535”来设置。
2.2.2 events模块
events模块来用指定nginx的工作模式和工作模式及连接数上限，一般是这样：
worker_connections
use 用来指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是标准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系统中，因为Mac基于BSD,所以Mac也得用这个模式，对于Linux系统，epoll工作模式是首选。
worker_connections 用于定义Nginx每个进程的最大连接数，即接收前端的最大请求数，默认是1024。最大客户端连接数由worker_processes和worker_connections决定，即Max_clients = worker_processes * worker_connections，在作为反向代理时，Max_clients变为：Max_clients = worker_processes * worker_connections / 4。
进程的最大连接数受Linux系统进程的最大打开文件数限制，在执行操作系统命令“ulimit -n 65536”后worker_connections的设置才能生效。
2.2.3 http模块
http模块可以说是最核心的模块了，它负责HTTP服务器相关属性的配置，它里面的server和upstream子模块，至关重要，等到反向代理和负载均衡以及虚拟目录等会仔细说。
include mime.
default_type application/octet-
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /usr/local/var/log/nginx/access.
keepalive_timeout 10;
upstream myproject {
用来设定文件的mime类型,类型在配置文件目录下的mime.type文件定义，来告诉nginx来识别文件类型。
default_type
设定了默认的类型为二进制流，也就是当文件类型未定义时使用这种方式，例如在没有配置asp的locate 环境时，Nginx是不予解析的，此时，用浏览器访问asp文件就会出现下载窗口了。
log_format
用于设置日志的格式，和记录哪些参数，这里设置为main，刚好用于access_log来纪录这种类型。
main的类型日志如下：也可以增删部分参数。
127.0.0.1 - - [21/Apr/:54 +0800] "GET /index.php HTTP/1.1" 200 87151 "-" "Mozilla/5.0 (M Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36"
access_log
用来纪录每次的访问日志的文件地址，后面的main是日志的格式样式，对应于log_format的main。
用于开启高效文件传输模式。将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞。
keepalive_timeout
设置客户端连接保持活动的超时时间。在超过这个时间之后，服务器会关闭该连接。
2.2.4 server模块
server模块是http的子模块，它用来定一个虚拟主机，我们先讲最基本的配置，这些在后面再讲。我们看一下一个简单的server是如何做的？
listen 8080;
server_name localhost 192.168.12.10 ;
# 全局定义，如果都是这一个目录，这样定义最简单。
/Users/yangyi/
index.php index.html index.
charset utf-8;
access_log
usr/local/var/log/host.access.
usr/local/var/log/host.error.
server 标志定义虚拟主机开始。
listen 用于指定虚拟主机的服务端口。
server_name 用来指定IP地址或者域名，多个域名之间用空格分开。
root 表示在这整个server虚拟主机内，全部的root web根目录。注意要和locate {}下面定义的区分开来。
index 全局定义访问的默认首页地址。注意要和locate {}下面定义的区分开来。
charset 用于设置网页的默认编码格式。
access_log 用来指定此虚拟主机的访问日志存放路径，最后的main用于指定访问日志的输出格式。
2.2.5 location模块
location模块是nginx中用的最多的，也是最重要的模块了，什么负载均衡啊、反向代理啊、虚拟域名啊都与它相关。
location根据它字面意思就知道是来定位的，定位URL，解析URL，所以，它也提供了强大的正则匹配功能，也支持条件判断匹配，用户可以通过location指令实现Nginx对动、静态网页进行过滤处理。像我们的php环境搭建就是用到了它。
我们先来看这个，设定默认首页和虚拟机目录
location / {
/Users/yangyi/
index.php index.html index.
location / 表示匹配访问根目录。
root 指令用于指定访问根目录时，虚拟主机的web目录，这个目录可以是相对路径（相对路径是相对于nginx的安装目录）。也可以是绝对路径。
index 用于设定我们只输入域名后访问的默认首页地址，有个先后顺序：index.php index.html index.htm，如果没有开启目录浏览权限，又找不到这些默认首页，就会报403错误。
location 还有一种方式就是正则匹配，开启正则匹配这样：location ~。后面加个~
下面这个例子是运用正则匹配来链接php。我们之前搭建环境也是这样做：
location ~ \.php$ {
/Users/yangyi/
fastcgi_pass
127.0.0.1:9000;
fastcgi_index
.php$ 熟悉正则的我们直到，这是匹配.php结尾的URL，用来解析php文件。里面的root也是一样，用来表示虚拟主机的根目录。
fastcgi_pass 链接的是php-fpm的地址。其他几个参数我们以后再说。
location 还有其他用法，等讲到实例的时候，再看吧。
2.2.6 upstream模块
upstream 模块负责负载均衡模块，通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡。先学习怎么用，具体的使用实例以后再说。
server 192.168.12.1:80;
server 192.168.12.2:80
server 192.168.12.3:8080
max_fails=3
fail_timeout=20s;
server 192.168.12.4:8080;
在上面的例子中，通过upstream指令指定了一个负载均衡器的名称。这个名称可以任意指定，在后面需要的地方直接调用即可。里面是ip_hash这是其中的一种负载均衡调度算法，下面会着重介绍。紧接着就是各种服务器了。用server关键字表识，后面接ip。
Nginx的负载均衡模块目前支持4种调度算法：
weight 轮询（默认）。每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，故障系统被自动剔除，使用户访问不受影响。weight。指定轮询权值，weight值越大，分配到的访问机率越高，主要用于后端每个服务器性能不均的情况下。
ip_hash。每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题。
fair（第三方）。比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair的，如果需要使用这种调度算法，必须下载Nginx的upstream_fair模块。
url_hash（第三方）。按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身是不支持url_hash的，如果需要使用这种调度算法，必须安装Nginx的hash软件包。
在HTTP Upstream模块中，可以通过server指令指定后端服务器的IP地址和端口，同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的状态有：
down，表示当前的server暂时不参与负载均衡。
backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
max_fails，允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
fail_timeout，在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用。
注意：当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能是weight和backup。
2.3 基于域名的虚拟主机
假设我们在本地开发有3个项目，分别在hosts里映射到本地的127.0.0.1上：
有这样3个项目，分别对应于web根目录下的3个文件夹，我们用域名对应文件夹名字，这样子好记：
/Users/yangyi/www//
/Users/yangyi/www//
/Users/yangyi/www//
每个目录下都有一个index.php文件，都是简单的输入自己的域名。
下面我们就来搭建这3个域名的虚拟主机，很显然，我们要新建3个server来完成。建议将对虚拟主机进行配置的内容写进另外一个文件，然后通过include指令包含进来，这样更便于维护和管理。不会使得这个nginx.conf内容太多：
include vhost/www.iyangyi.
include vhost/api.iyangyi.
include vhost/admin.iyangyi.
# 或者用 *.conf
# include vhost/*.conf
include：主模块指令，实现对配置文件所包含的文件的设定，可以减少主配置文件的复杂度。
既然每一个conf都是一个server，前面已经学习了一个完整的server写的了。下面就开始：
# www.iyangyi.conf
listen 80;
root /Users/yangyi/www//;
index index.php index.html index.
access_log /usr/local/var/log/nginx/www.iyangyi.access.
error_log /usr/local/var/log/nginx/www.iyangyi.error.
location ~ \.php$ {
fastcgi_pass
127.0.0.1:9000;
fastcgi_index
# api.iyangyi.conf
listen 80;
root /Users/yangyi/www//;
index index.php index.html index.
access_log /usr/local/var/log/nginx/api.iyangyi.access.
error_log /usr/local/var/log/nginx/api.iyangyi.error.
location ~ \.php$ {
fastcgi_pass
127.0.0.1:9000;
fastcgi_index
# admin.iyangyi.conf
listen 80;
root /Users/yangyi/www//;
index index.php index.html index.
access_log /usr/local/var/log/nginx/admin.iyangyi.access.
error_log /usr/local/var/log/nginx/admin.iyangyi.error.
location ~ \.php$ {
fastcgi_pass
127.0.0.1:9000;
fastcgi_index
这样3个很精简的虚拟域名就搭建好了。重启下nginx，然后打开浏览器访问一下这3个域名，就能看到对应的域名内容了。
2.4 反向代理
Nginx 使用反向代理，主要是使用location模块下的proxy_pass选项。
来个最简单的。当我访问 mac 上的nginx 的
的内容时候, 就反向代理到虚拟机centos上的 apache 192.168.33.10 的index.html页面。
192.168.33.10 中的html 是很简单的一句输出：
centos apache2 index.html
在hosts里新加上这个域名：
#vi /etc/hosts
在vhost目录中新建一个conf server：
#centos.iyangyi.conf
listen 80;
access_log /usr/local/var/log/nginx/centos.iyangyi.access.
error_log /usr/local/var/log/nginx/centos.iyangyi.error.
location / {
proxy_pass http://192.168.33.10;
重启下nginx：
sudo nginx -s reload
当然。proxy 还有其他的参数，比如：proxy_set_header 用来设置header头部信息参数转发等，等用了可以仔细看看。
2.5 负载均衡
别被这个名字给吓住了，以为是什么很牛逼的东西的。其实不然。也很简单。
先简单说下负载均衡是干嘛的？举个例子：我们的小网站，刚开始就一台nginx服务器，后来，随着业务量增大，用户增多，一台服务器已经不够用了，我们就又多加了几台服务器。那么这几台服务器如何调度？如何均匀的提供访问？这就是负载均衡。
负载均衡的好处是可以集群多台机器一起工作，并且对外的IP和域名是一样的，外界看起来就好像一台机器一样。
基于 weight 权重的负载
先来一个最简单的，weight权重的：
upstream webservers{
server 192.168.33.11 weight=10;
server 192.168.33.12 weight=10;
server 192.168.33.13 weight=10;
listen 80;
access_log /usr/local/var/log/nginx/upstream.iyangyi.access.
error_log /usr/local/var/log/nginx/upstream.iyangyi.error.
location / {
proxy_pass http://
proxy_set_header
我们再来继续看几个参数 : max_fails和fail_timeout
max_fails : 允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
fail_timeout : 在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用，进行健康状态检查。
upstream webservers{
server 192.168.33.11 weight=10 max_fails=2 fail_timeout=30s;
server 192.168.33.12 weight=10 max_fails=2 fail_timeout=30s;
server 192.168.33.13 weight=10 max_fails=2 fail_timeout=30s;
down： 表示这台机器暂时不参与负载均衡。相当于注释掉了。
backup： 表示这台机器是备用机器，是其他的机器不能用的时候，这台机器才会被使用，俗称备胎
upstream webservers{
server 192.168.33.11
server 192.168.33.12 weight=10 max_fails=2 fail_timeout=30s;
server 192.168.33.13
基于 ip_hash 的负载
这种分配方式，每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题。
upstream webservers{
server 192.168.33.11 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.33.12 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.33.13
ip_hash 模式下，最好不要设置weight参数，因为你设置了，就相当于手动设置了，将会导致很多的流量分配不均匀。
ip_hash 模式下，backup参数不可用，加了会报错，为啥呢？因为，本身我们的访问就是固定的了，其实，备用已经不管什么作用了。
2.6 页面缓存
页面缓存也是日常web 开发中很重要的一个环节，对于一些页面，我们可以将其静态化，保存起来，下次请求时候，直接走缓存，而不用去请求反相代理服务器甚至数据库服务了。从而减轻服务器压力。
nginx 也提供了简单而强大的下重定向，反向代理的缓存功能，只需要简单配置下，就能将指定的一个页面缓存起来。它的原理也很简单，就是匹配当前访问的url, hash加密后，去指定的缓存目录找，看有没有，有的话就说明匹配到缓存了。
我们先来看一下一个简单的页面缓存的配置：
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=cache_zone:10m inactive=1d max_size=100m;
upstream myproject {
location ~ *\.php$ {
proxy_cache cache_ #keys_zone的名字
proxy_cache_key $host$uri$is_args$ #缓存规则
proxy_cache_valid any 1d;
proxy_pass http://127.0.0.1:8080;
下面我们来一步一步说。用到的配置参数，主要是proxy_*前缀的很多配置。
首先需要在http中加入proxy_cache_path 它用来制定缓存的目录以及缓存目录深度制定等。它的格式如下：
proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size];
path是用来指定 缓存在磁盘的路径地址。比如：/data/nginx/cache。那以后生存的缓存文件就会存在这个目录下。
levels用来指定缓存文件夹的级数，可以是：levels=1, levels=1:1, levels=1:2, levels=1:2:3 可以使用任意的1位或2位数字作为目录结构分割符，如 X, X:X,或 X:X:X 例如: 2, 2:2, 1:1:2，但是最多只能是三级目录。
那这个里面的数字是什么意思呢。表示取hash值的个数。比如：
现在根据请求地址localhost/index.php?a=4 用md5进行哈希，得到e0bd26aad9
levels=1:2 表示建立2级目录，把hash最后1位(9)拿出建一个目录，然后再把9前面的2位(ad)拿来建一个目录, 那么缓存文件的路径就是/data/nginx/cache/9/ad/e0bd26aad9
以此类推：levels=1:1:2表示建立3级目录，把hash最后1位(9)拿出建一个目录，然后再把9前面的1位(d)建一个目录, 最后把d前面的2位(8a)拿出来建一个目录 那么缓存文件的路径就是/data/nginx/cache/9/d/8a/e0bd26aad9
keys_zone 所有活动的key和元数据存储在共享的内存池中，这个区域用keys_zone参数指定。zone_name指的是共享池的名称，zone_size指的是共享池的大小。注意每一个定义的内存池必须是不重复的路径，例如：
proxy_cache_path
/data/nginx/cache/one
keys_zone=one:10m;
proxy_cache_path
/data/nginx/cache/two
levels=2:2
keys_zone=two:100m;
proxy_cache_path
/data/nginx/cache/three
levels=1:1:2
keys_zone=three:1000m;
inactive 表示指定的时间内缓存的数据没有被请求则被删除，默认inactive为10分钟。inactive=1d 1小时。inactive=30m 30分钟。
max_size 表示单个文件最大不超过的大小。它被用来删除不活动的缓存和控制缓存大小，当目前缓存的值超出max_size指定的值之后，超过其大小后最少使用数据（LRU替换算法）将被删除。max_size=10g表示当缓存池超过10g就会清除不常用的缓存文件。
clean_time 表示每间隔自动清除的时间。clean_time=1m 1分钟清除一次缓存。
好。说完了这个很重要的参数。我们再来说在server模块里的几个配置参数：
proxy_cache 用来指定用哪个keys_zone的名字，也就是用哪个目录下的缓存。上面我们指定了三个one, two,three 。比如，我现在想用one 这个缓存目录 : proxy_cache one
proxy_cache_key 这个其实蛮重要的，它用来指定生成hash的url地址的格式。根据这个key映射成一个hash值，然后存入到本地文件。proxy_cache_key $host$uri表示无论后面跟的什么参数，都会访问一个文件，不会再生成新的文件。 而如果proxy_cache_key $is_args$args，那么传入的参数 localhost/index.php?a=4 与localhost/index.php?a=44 将映射成两个不同hash值的文件。
proxy_cache_key 默认是 "$scheme$host$request_uri"。但是一般我们会把它设置成：$host$uri$is_args$args 一个完整的url路径。
proxy_cache_valid 它是用来为不同的http响应状态码设置不同的缓存时间。
proxy_cache_valid
proxy_cache_valid
表示为http status code 为200和302的设置缓存时间为10分钟，404代码缓存1分钟。 如果只定义时间：
proxy_cache_valid 5m;
那么只对代码为200, 301和302的code进行缓存。 同样可以使用any参数任何相响应：
proxy_cache_valid
200 302 10m;
proxy_cache_valid
proxy_cache_valid
any 1m; #所有的状态都缓存1小时
好。缓存的基本一些配置讲完了。也大致知道了怎么使用这些参数。现在开始实战！我们启动一台vagrant linux 机器 web1 (192.168.33.11) 用作远程代理机器，就不搞复杂的负载均衡了。
先在Mac本地加一个域名, 然后按照上面的配置在vhost 下新建一个proxy_cache.iyangyi.conf 文件:
proxy_cache_path /usr/local/var/cache levels=1:2 keys_zone=cache_zone:10m inactive=1d max_size=100m;
listen 80;
access_log /usr/local/var/log/nginx/cache.iyangyi.access.
error_log /usr/local/var/log/nginx/cache.iyangyi.error.
add_header X-Via $server_
add_header X-Cache $upstream_cache_
location / {
proxy_set_header
proxy_cache cache_
proxy_cache_key $host$uri$is_args$
proxy_cache_valid 200 304 1m;
proxy_pass http://192.168.33.11;
打开审核元素或者firebug。看network网络请求选项，我们可以看到，Response Headers，在这里我们可以看到：
X-Cache:MISS
X-Via:127.0.0.1
X-cache 为 MISS 表示未命中，请求被传送到后端。因为是第一次访问，没有缓存，所以肯定是未命中。我们再刷新下，就发现其变成了HIT, 表示命中。它还有其他几种状态：
MISS 未命中，请求被传送到后端
HIT 缓存命中
EXPIRED 缓存已经过期请求被传送到后端
UPDATING 正在更新缓存，将使用旧的应答
STALE 后端将得到过期的应答
BYPASS 缓存被绕过了
我们再去看看缓存文件夹 /usr/local/var/cache里面是否有了文件：
cache git:(master) cd a/13
13 git:(master) ls
5bd1af99bcb0db45c8bd601d9ee9e13a
13 git:(master) pwd
/usr/local/var/cache/a/13
已经生成了缓存文件。
我们在url 后面随便加一个什么参数，看会不会新生成一个缓存文件夹及文件： 。因为我们使用的生成规则是全部url转换(proxy_cache_key $host$uri$is_args$)
查看 X-cache 为 MISS，再刷新 ，变成HIT。再去看一下缓存文件夹 /usr/local/var/cache。
~cache git:(master) ls
果然又生成了一个4文件夹。
2.7 location 正则模块
这一小节，主要来学习nginx中的URL重写怎么做。url重写模块，主要是在location模块面来实现，我们一点一点的看。
首先看下location 正则匹配的使用。还记得之前是如何用location来定位.php文件的吗?
location ~ \.php$ {
fastcgi_pass
127.0.0.1:9000;
fastcgi_index
我们用~来表示location开启正则匹配, 这样：location ~。还可以用这个来匹配静态资源，缓存它们，设置过期时间：
location ~ .*\.(gif|jpg|jpeg|bmp|png|ico|txt|mp3|mp4|swf){
expires 15d;
location ~ .*\.(css|js){
expires 12h;
expires 用来设置HTTP应答中的Expires和Cache-Control的头标时间，来告诉浏览器访问这个静态文件时，不用再去请求服务器，直接从本地缓存读取就可以了。
语法： expires [time|epoch|max|off]
默认值： expires off
作用域： http, server, location
可以在time值中使用正数或负数。“Expires”头标的值将通过当前系统时间加上您设定的 time 值来获得。可以设置的参数如下：
epoch 指定“Expires”的值为 1 January, :01 GMT。
max 指定“Expires”的值为 31 December :59 GMT，“Cache-Control”的值为10年。
-1 指定“Expires”的值为 服务器当前时间 -1s,即永远过期。
负数：Cache-Control: no-cache。
正数或零：Cache-Control: max-age = #, # 会转换为指定时间的秒数。比如：1d、2h、3m。
off 表示不修改“Expires”和“Cache-Control”的值。
比如再看个例子: 控制图片等过期时间为30天
location ~ \.(gif|jpg|jpeg|png|bmp|ico)$ {
expires 30d;
我们还可以控制哪一个文件目录的时间，比如控制匹配/resource/或者/mediatorModule/里所有的文件缓存设置到最长时间。
location ~ /(resource|mediatorModule)/ {
2.8 URL重写模块
重写模块与很多模块一起使用。先看一下是怎么用的，看2个例子，然后我们再一点一点讲每个的使用方法：
location /download/ {
if ($forbidden) {
if ($slow) {
limit_rate
rewrite ^/(download/.*)/media/(.*)\..*$
/$1/mp3/$2.mp3
location / {
index.html index.
rewrite ^/bbs/(.*)$ http://192.168.18.201/forum/$1;
上面2个例子就是利用rewrite来完成URL重写的。我们慢慢来看它的用法。
break和编程语言中的用法一样，就是跳出某个逻辑。
语法：break
默认值：none
使用字段：server, location, if
if (!-f $request_filename) {
上面这个例子就是在if里面使用break,意思是如果访问的文件名不存在，就跳出。后续会有更多的例子。
if 判断一个条件，如果条件成立，则后面的大括号内的语句将执行，相关配置从上级继承。
语法：if (condition) { … }
默认值：none
使用字段：server, location
可以在判断语句中指定下列值：
一个变量的名称；不成立的值为：空字符传”“或者一些用“0”开始的字符串。
一个使用=或者!=运算符的比较语句。
使用符号~*和~模式匹配的正则表达式：
~为区分大小写的匹配。
~*不区分大小写的匹配（firefox匹配FireFox）。
!~和!~*意为“不匹配的”。
使用-f和!-f检查一个文件是否存在。
使用-d和!-d检查一个目录是否存在。
使用-e和!-e检查一个文件，目录或者软链接是否存在。
使用-x和!-x检查一个文件是否为可执行文件。
$http_user_agent变量获取浏览器的agent，使用~ 来匹配大小写。用户如果使用的IE 浏览器，就执行if里面的操作。
if ($http_user_agent ~ MSIE) {
$request_method变量获取请求的方法，使用=来判断是否等于POST 。如果复合，就执行if 里面的操作。
if ($request_method = POST ) {
return 405;
$request_filename变量获取请求的文件名，使用!-f来匹配文件，如果不是一个文件名，就执行if 里面的逻辑。
if (!-f $request_filename) {
proxy_pass
http://127.0.0.1;
这个指令结束执行配置语句并为客户端返回状态代码，可以使用下列的值：204，400，402-406，408，410, 411, 413, 416与500-504。此外，非标准代码444将关闭连接并且不发送任何的头部。
语法：return code
默认值：none
使用字段：server, location, if
语法：rewrite regex replacement flag
默认值：none
使用字段：server, location, if
rewrite用来重写url,有3个位置：
regex 表示用来匹配的正则
replacement 表示用来替换的
flag 是尾部的标记
flag可以是以下的值：
last - url重写后，马上发起一个新的请求，再次进入server块，重试location匹配，超过10次匹配不到报500错误，地址栏url不变
break - url重写后，直接使用当前资源，不再执行location里余下的语句，完成本次请求，地址栏url不变
redirect - 返回302临时重定向，url会跳转，爬虫不会更新url。
permanent - 返回301永久重定向。url会跳转。爬虫会更新url。
为空 - URL 不会变，但是内容已经变化，也是永久性的重定向。
上面的正则表达式的一部分可以用圆括号，方便之后按照顺序用$1-$9来引用。
我们来看几个例子：
需要将/photos/123456重写成/path/to/photos/12/.png
可以这样：
"/photos/([0-9] {2})([0-9] {2})([0-9] {2})" /path/to/photos/$1/$1$2/$1$2$3.
下面是一些简单的常见的重写：
rewrite ^/js/base.core.v3.js /js/base.core.v3.dev.
rewrite ^/js/comment.frame.js /js/comment.frame.dev.
rewrite ^/live-static/(.*)$ /public/$1
2.9 配置整理
在此记录下Nginx服务器nginx.conf的配置文件说明, 部分注释收集与网络：
# 运行用户
# 启动进程,通常设置成和cpu的数量相等
worker_processes
# 全局错误日志及PID文件
/var/log/nginx/error.
/var/run/nginx.
# 工作模式及连接数上限
#epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能
worker_connections 1024; #单个后台worker process进程的最大并发链接数
#设定http服务器，利用它的反向代理功能提供负载均衡支持
#设定mime类型,类型由mime.type文件定义
/etc/nginx/mime.
default_type
application/octet-
#设定日志格式
access_log
/var/log/nginx/access.
#sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用，
#必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的uptime.
#将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞
#连接超时时间
keepalive_timeout
#开启gzip压缩
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
#设定请求缓冲
client_header_buffer_size
large_client_header_buffers
include /etc/nginx/conf.d/*.
include /etc/nginx/sites-enabled/*;
#设定负载均衡的服务器列表
upstream mysvr {
#weigth参数表示权值，权值越高被分配到的几率越大
#本机上的Squid开启3128端口
server 192.168.8.1:3128 weight=5;
server 192.168.8.2:80
server 192.168.8.3:80
#侦听80端口
#定义使用访问
#设定本虚拟主机的访问日志
access_log
logs/.access.
location / {
#定义服务器的默认网站根目录位置
index index.php index.html index.
#定义首页索引文件的名称
fastcgi_param
SCRIPT_FILENAME
$document_root/$fastcgi_script_
include /etc/nginx/fastcgi_
# 定义错误提示页面
error_page
500 502 503 504 /50x.
location = /50x.html {
#静态文件，nginx自己处理
location ~ ^/(images|javascript|js|css|flash|media|static)/ {
root /var/www/virtual/
#过期30天，静态文件不怎么更新，过期可以设大一点，如果频繁更新，则可以设置得小一点。
expires 30d;
#PHP 脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.
fastcgi_param SCRIPT_FILENAME /home/www/www$fastcgi_script_
include fastcgi_
#设定查看Nginx状态的地址
location /NginxStatus {
auth_basic
"NginxStatus";
auth_basic_user_file
#禁止访问 .htxxx 文件
location ~ /\.ht {
#第一个虚拟服务器
#侦听192.168.8.x的80端口
server_name
192.168.8.x;
#对aspx后缀的进行负载均衡请求
location ~ .*\.aspx$ {
/#定义服务器的默认网站根目录位置
index index.php index.html index.#定义首页索引文件的名称
proxy_pass
http://#请求转向mysvr 定义的服务器列表
#以下是一些反向代理的配置可删除.
#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
proxy_set_header Host $
proxy_set_header X-Real-IP $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
client_max_body_size 10m;
#允许客户端请求的最大单文件字节数
client_body_buffer_size 128k;
#缓冲区代理缓冲用户端请求的最大字节数，
proxy_connect_timeout 90;
#nginx跟后端服务器连接超时时间(代理连接超时)
proxy_send_timeout 90;
#后端服务器数据回传时间(代理发送超时)
proxy_read_timeout 90;
#连接成功后，后端服务器响应时间(代理接收超时)
proxy_buffer_size 4k;
#设置代理服务器（nginx）保存用户头信息的缓冲区大小
proxy_buffers 4 32k;
#proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
proxy_busy_buffers_size 64k;
#高负荷下缓冲大小（proxy_buffers*2）
proxy_temp_file_write_size 64k;
#设定缓存文件夹大小，大于这个值，将从upstream服务器传
3 Nginx模块
上面我们已经详细讲解了Nginx常用配置，从中我们已经体会到了，Nginx模块化配置的优点。其中，模块化设计类似于面向对象中的接口类，它增强了nginx源码的可读性、可扩充性和可维护性。
所以，Nginx有五大优点：模块化、事件驱动、异步、非阻塞、多进程单线程。由内核和模块组成的，其中内核完成的工作比较简单，仅仅通过查找配置文件将客户端请求映射到一个location block，然后又将这个location block中所配置的每个指令将会启动不同的模块去完成相应的工作。
3.1 模块划分
Nginx的模块从结构上分为核心模块、基础模块和第三方模块：
核心模块：HTTP模块、EVENT模块和MAIL模块
基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，
第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。
Nginx的模块从功能上分为如下三类：
Core(核心模块)：构建nginx基础服务、管理其他模块。
Handlers（处理器模块）：此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）：此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）：此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。
Nginx的核心模块主要负责建立nginx服务模型、管理网络层和应用层协议、以及启动针对特定应用的一系列候选模块。其他模块负责分配给web服务器的实际工作：
(1) 当Nginx发送文件或者转发请求到其他服务器，由Handlers(处理模块)或Proxies（代理类模块）提供服务；
(2) 当需要Nginx把输出压缩或者在服务端加一些东西，由Filters(过滤模块)提供服务。
3.2 模块处理
当服务器启动，每个handlers(处理模块)都有机会映射到配置文件中定义的特定位置（location）；如果有多个handlers(处理模块)映射到特定位置时，只有一个会“赢”（说明配置文件有冲突项，应该避免发生）。
处理模块以三种形式返回：
或者放弃处理这个请求而让默认处理模块来处理（主要是用来处理一些静态文件，事实上如果是位置正确而真实的静态文件，默认的处理模块会抢先处理）。
如果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处理周期是这样的：
客户端发送HTTP请求 –&
Nginx基于配置文件中的位置选择一个合适的处理模块 -&
(如果有)负载均衡模块选择一台后端服务器 –&
处理模块进行处理并把输出缓冲放到第一个过滤模块上 –&
第一个过滤模块处理后输出给第二个过滤模块 –&
然后第二个过滤模块又到第三个 –&
依此类推 –& 最后把响应发给客户端。
下图展示了Nginx模块处理流程：
Nginx模块处理流程
Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。
4 Nginx请求处理
Nginx在启动时会以daemon形式在后台运行，采用多进程+异步非阻塞IO事件模型来处理各种连接请求。多进程模型包括一个master进程，多个worker进程，一般worker进程个数是根据服务器CPU核数来决定的。master进程负责管理Nginx本身和其他worker进程。如下图：
Master进程负责管理Nginx本身和其他worker进程
从上图中可以很明显地看到，4个worker进程的父进程都是master进程，表明worker进程都是从父进程fork出来的，并且父进程的ppid为1，表示其为daemon进程。
需要说明的是，在nginx多进程中，每个worker都是平等的，因此每个进程处理外部请求的机会权重都是一致的。
Nginx架构及工作流程图：
Nginx架构及工作流程图
Nginx的每一个Worker进程都管理着大量的线程，真正处理请求业务的是Worker之下的线程。worker进程中有一个ngx_worker_process_cycle()函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个Nginx服务被停止。
worker 进程中，ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中，一个请求的简单处理流程如下：
操作系统提供的机制（例如 epoll, kqueue 等）产生相关的事件。
接收和处理这些事件，如是接收到数据，则产生更高层的 request 对象。
处理 request 的 header 和 body。
产生响应，并发送回客户端。
完成 request 的处理。
重新初始化定时器及其他事件。
4.1 多进程处理模型
下面来介绍一个请求进来，多进程模型的处理方式：
首先，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就控制了多进程间连接的平衡了。
4.2 一个简单的HTTP请求
从 Nginx 的内部来看，一个 HTTP Request 的处理过程涉及到以下几个阶段：
初始化 HTTP Request（读取来自客户端的数据，生成 HTTP Request 对象，该对象含有该请求所有的信息）。
处理请求头。
处理请求体。
如果有的话，调用与此请求（URL 或者 Location）关联的 handler。
依次调用各 phase handler 进行处理。
在建立连接过程中，对于nginx监听到的每个客户端连接，都会将它的读事件的handler设置为ngx_http_init_request函数，这个函数就是请求处理的入口。在处理请求时，主要就是要解析http请求，比如：uri，请求行等，然后再根据请求生成响应。下面看一下nginx处理的具体过程：
Nginx处理的具体过程
在这里，我们需要了解一下 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 上。
4.3 请求完整处理过程
根据以上请求步骤所述，请求完整的处理过程如下图所示：
请求完整的处理过程
做一个比较注重实际工作的有用的人