nginx原理解析

安装环境准备

• linux 内核2.6及以上版本:
  只有2.6之后才支持epool ，在此之前使用select或pool多路复用的IO模型，无法解决高并发压力的问题。通过命令uname -a 即可查看。
  #查看 linux 内核
  uname -a
• GCC编译器
  GCC（GNU Compiler Collection）可用来编译C语言程序。Nginx不会直接提供二进制可执行程序,只能下载源码进行编译。
• PCRE库
  PCRE（Perl Compatible Regular Expressions，Perl兼容正则表达式）是由Philip Hazel开发的函数库，目前为很多软件所使用，该库支持正则表达式。
• zlib库
  zlib库用于对HTTP包的内容做gzip格式的压缩，如果我们在nginx.conf里配置了gzip on，并指定对于某些类型（content-type）的HTTP响应使用gzip来进行压缩以减少网络传输量。
• OpenSSL开发库
  如果我们的服务器不只是要支持HTTP，还需要在更安全的SSL协议上传输HTTP，那么就需要拥有OpenSSL了。另外，如果我们想使用MD5、SHA1等散列函数，那么也需要安装它

模块

epool如何高效

首先看提供的C语言方法

int epoll_create(int size);  
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);  
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout); 

使用起来很清晰，首先要调用epoll_create建立一个epoll对象。参数size是内核保证能够正确处理的最大句柄数，多于这个最大数时内核可不保证效果。
epoll_ctl可以操作上面建立的epoll，例如，将刚建立的socket加入到epoll中让其监控，或者把 epoll正在监控的某个socket句柄移出epoll，不再监控它等等。
epoll_wait在调用时，在给定的timeout时间内，当在监控的所有句柄中有事件发生时，就返回用户态的进程。
从上面的调用方式就可以看到epoll比select/poll的优越之处：因为后者每次调用时都要传递你所要监控的所有socket给select/poll系统调用，这意味着需要将用户态的socket列表copy到内核态，如果以万计的句柄会导致每次都要copy几十几百KB的内存到内核态，非常低效。而我们调用epoll_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的句柄列表。
epoll原理 ：epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。
epoll的高效：当我们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的句柄给我们用户。这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已，如何能不高效？！那么，这个准备就绪list链表是怎么维护的呢？当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。如此，一颗红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。
最后看看epoll独有的两种模式LT和ET。无论是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时次次返回这个句柄，而ET模式仅在第一次返回。

常用场景配置案例

动静分离实现

创建静态站点、配置 location /static、配置 ~* .(gif|png|css|js)$
基于目录动静分离

   server {
        listen 80;
        server_name *.gongxun.com;
        root /usr/www/luban;
        location / {
                index gongxun.html;
        }
        location /static {
         alias /usr/www/static;
        }
 }

基于正则动静分离

location ~* \.(gif|jpg|png|css|js)$ {
      root /usr/www/static;
}

防盗链

加入至指定location 即可实现
valid_referers none blocked *.gongxun.com;
if ($invalid_referer) {
return 403;
}

多域名站点

下载限速

location /download {
limit_rate 1m; //限制每S下载速度
limit_rate_after 30m; // 超过30 之 后在下载
}

IP 黑名单

• 封禁指定IP
  deny 192.168.0.1;
  allow 192.168.0.1;
• 开放指定IP 段
  allow 192.168.0.0/24;
• 封禁所有
  deny all;
• 开放所有
  allow all;
• 创建黑名单文件
  echo ‘deny 192.168.0.132;’ >> balck.ip
• http 配置块中引入 黑名单文件
  include black.ip;

基于user-agent分流

日志配置

log_format main '$remote_addr - $remot{e}_{u}ser[$time_local] “KaTeX parse error: Double superscript at position 33: … '̲status $bod{y}_{b}yte{s}_{s}ent"$http_referer” ’
‘“$htt{p}_{u}se{r}_{a}gent""$http_x_forwarded_for”’;
access_log logs/access.log main;

• 基于域名打印日志
  access_log logs/$host.access.log main;
• error日志的设置
  语法：error_log /path/file level;
  默认：error_log logs/error.log error;
  level是日志的输出级别，取值范围是debug、info、notice、warn、error、crit、alert、emerg，
• 针对指定的客户端输出debug级别的日志
  语法：debug_connection[IP|CIDR]
  events {
  debug_connection 192.168.0.147;
  debug_connection 10.224.57.0/200;
  }
  注意：debug 日志开启 必须在安装时 添加 --with-debug (允许debug)

反向代理基本配置

正向代理的概念

正向代理是指客户端与目标服务器之间增加一个代理服务器，客户端直接访问代理服务器，在由代理服务器访问目标服务器并返回客户端并返回 。这个过程当中客户端需要知道代理服务器地址，并配置连接。

反向代理的概念

反向代理是指 客户端访问目标服务器，在目标服务内部有一个统一接入网关将请求转发至后端真正处理的服务器并返回结果。这个过程当中客户端不需要知道代理服务器地址，代理对客户端而言是透明的。

区别

	正向代理	反向代理
代理服务器位置	客户端与服务都能连接的们位置	目标服务器内部
主要作用	屏蔽客户端IP、集中式缓存、解决客户端不能直连服务端的问题。	屏蔽服务端内部实现、负载均衡、缓存。
应用场景	爬虫、翻墙、maven 的nexus 服务	Nginx 、Apache负载均衡应用

Nginx代理基本配置

• 正向代理到baidu 服务
  location = /baidu.html {
  proxy_pass http://www.baidu.com;
  }

• 反向代理至 本机的8010服务
  location /luban/ {
  proxy_pass http://127.0.0.1:8010;
  }

代理相关参数：
proxy_pass # 代理服务
proxy_redirect off; # 是否允许重定向
proxy_set_header Host $host; # 传 header 参数至后端服务
proxy_set_header X-Forwarded-For $remote_addr; # 设置request header 即客户端IP 地址
proxy_connect_timeout 90; # 连接代理服务超时时间
proxy_send_timeout 90; # 请求发送最大时间
proxy_read_timeout 90; # 读取最大时间
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

负载均衡配置与参数解析

通过proxy_pass 可以把请求代理至后端服务，但是为了实现更高的负载及性能， 我们的后端服务通常是多个， 这个是时候可以通过upstream 模块实现负载均衡。
演示upstream 的实现。
upstream backend {
server 127.0.0.1:8010 weight=1;
server 127.0.0.1:8080 weight=2;

server 127.0.0.1:8030 weight=1 backup;
}
location / {
proxy_pass http://backend;
}

upstream 相关参数:
server 反向服务地址 加端口
weight 权重
max_fails 失败多少次 认为主机已挂掉则，踢出
fail_timeout 踢出后重新探测时间
backup 备用服务
max_conns 允许最大连接数
slow_start 当节点恢复，不立即加入,而是等待 slow_start 后加入服务对列。

upstream 负载均衡算法

ll+weight： 轮询加权重 (默认)
**ip_hash **: 基于Hash 计算 ,用于保持session 一至性
url_hash: 静态资源缓存,节约存储，加快速度（第三方）
least_conn ：最少链接（第三方）
least_time：最小的响应时间,计算节点平均响应时间，然后取响应最快的那个，分配更高权重（第三方）

高速缓存

以网页为例

更新修改

静态缓存基本配置

http元素下添加缓存区声明
proxy_cache_path 缓存路径
levels 缓存层级及目录位数
keys_zone 缓存区内存大小
inactive 有效期
max_size 硬盘大小
proxy_cache_path /data/nginx/cache_gongxun levels=1:2 keys_zone=cache_gongxun:500m inactive=20d max_size=1g;

二、为指定location 设定缓存策略。

指定缓存区

proxy_cache cache_gongxun;
以全路径md5值做做为Key
proxy_cache_key $host$uri$i{s}_{a}rgs$args;
对不同的HTTP状态码设置不同的缓存时间
proxy_cache_valid 200 304 12h;

缓存生效过程

配置声明缓存路径
为location 配置缓存策略
重启nginx（修改了）
查看缓存目录生成

缓存的清除

该功能可以采用第三方模块 ngx_cache_purge 实现。
为nginx 添加 ngx_cache_purge 模块
下载ngx_cache_purge 模块包 ,这里nginx 版本为1.6.2 purge 对应2.0版
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
查看已安装模块
./sbin/nginx -V
进入nginx安装包目录 重新安装 --add-module为模块解压的全路径
./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/root/svr/packages/ngx_cache_purge-2.3
重新编译
make
拷贝 安装目录/objs/nginx 文件用于替换原nginx 文件
检测查看安装是否成功
nginx -t

清除配置：
location ~ /clear(/.*) {
允许访问的IP
allow 127.0.0.1;
allow 192.168.0.193;
禁止访问的IP
deny all;
配置清除指定缓存区和路径(与proxy_cache_key一至)
proxy_cache_purge cache_luban $host$1$is_args$args;
}
配置好以后 直接访问 ：
访问生成缓存文件
http://www.gongxun.com/?a=1
清除生成的缓存,如果指定缓存不存在 则会报404 错误。
http://www.gongxun.com/clear/?a=1

性能参数调优

worker_processes number;

每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。例如，如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件，而且服务器上的内存较小，以至于大部分的请求访问静态资源文件时都必须读取磁盘（磁头的寻址是缓慢的），而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时间，进而导致服务整体性能下降。

每个worker 进程的最大连接数

语法：worker_connections number;
默认：worker_connections 1024

worker_cpu_affinity cpumask[cpumask……]

绑定Nginx worker进程到指定的CPU内核
为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。
例如，如果有4颗CPU内核，就可以进行如下配置：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
注意 worker_cpu_affinity配置仅对Linux操作系统有效。

Nginx worker 进程优先级设置

语法：worker_priority nice;
默认：worker_priority 0;
优先级由静态优先级和内核根据进程执行情况所做的动态调整（目前只有±5的调整）共同决定。nice值是进程的静态优先级，它的取值范围是–20～+19，–20是最高优先级，+19是最低优先级。因此，如果用户希望Nginx占有更多的系统资源，那么可以把nice值配置得更小一些，但不建议比内核进程的nice值（通常为–5）还要小

Nginx worker进程可以打开的最大句柄描述符个数

语法： worker_rlimit_nofile limit;
默认：空
更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。

是否打开accept锁

语法：accept_mutex[on|off]
默认：accept_mutext on;
accept_mutex是Nginx的负载均衡锁，当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连接的机会，accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。

使用accept锁后到真正建立连接之间的延迟时间

语法：accept_mutex_delay Nms;
默认：accept_mutex_delay 500ms;
在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是堵塞锁，如果取不到会立刻返回。如果只有一个worker进程试图取锁而没有取到，他至少要等待accept_mutex_delay定义的时间才能再次试图取锁。