Nginx的优化配置 - Zhengyue34/itsma-shell GitHub Wiki

应用服务器的性能优化

应用服务器的性能优化主要在合理使用CPU、内存、磁盘IO和网络IO四个方面,修改的唯一文件是/etc/nginx/nginx.conf,它主要包括这几个模块：
http://blog.csdn.net/xifeijian/article/details/20956605

main work_proess等         
events{事件驱动相关}    
httpd{http相关配置}     
server{虚拟主机}       
location{URI访问属性}       
location{proxy_pass http://176.10.12.1}

优化基础配置：

1.高层的配置

user www-data;       #user应该按默认设置，我们不会更改这些内容；我们可以在编译安装时就自己添加用户。       
pid /var/run/nginx.pid;  #pid也安装默认设置       
worker_processes 8;   #定义了nginx对外提供web服务时的worker进程数，最优值取决于许多因素，包括（但不限于）CPU核的数量、存储数据的硬盘数量及负载模式。不能确定的时候，将其设置为可用的CPU内核数；       
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;   #为每个进程分配cpu，上例中将8 个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。绑定工作进程到对应CPU核心，Nginx默认未开启CPU绑定。目前的服务器一般为多核CPU，当并发很大时，服务器各个CPU的使用率可能出现严重不均衡的局面，这时候可以考虑使用CPU绑定，以达到CPU使用率相对均匀的状态，充分发挥多核CPU的优势。         
worker_rlimit_nofile 100000;  #worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了       
/*
ulimit 在资源的合理限制和分配（开启文件描述符的数量，分配堆栈的大小，CPU 时间，虚拟内存大小）起作用，是一种简单并且有效的实现资源限制的方式
*/

2. Event模块

events {      
worker_connections 2048;  #单个进程允许的最多连接数，所以理论上，一个nginx server的最大连接=worker_processes*worker_connections          
multi_accept on;    #告诉nginx收到一个新连接通知后接受尽可能多的连接   
use epoll;
#网络IO模型
Poll和Select和Epoll都是事件触发机制,用于复用客户端线程的轮询方法,Linux 2.6+内核推荐使用epoll，FreeBSD推荐使用kqueue，安装时Nginx会自动根据系统来选择。        
}

3.http模块

http{
server_tokens off; #它可以关闭在错误页面中的nginx版本数字，这样对于安全性是有好处的,不被骇客找到版本号对应的漏洞，从而被攻击
sendfile on; #开启高效文件传输模式，防止网络堵塞
tcp_nopush on; #当使用sendfile函数时，tcp_nopush才起作用，可理解为把包裹放到集散地，等一定数量后统一投递。它和指令tcp_nodelay是互斥的.
tcp_nodelay on; #为了解决网络阻塞，采用Nagle算法把较小的包组装为更大的帧,目的希望发送小块数据。
access_log off； #功效是关闭日志。当并发很大时，Nginx的访问日志和错误日志的保存肯定会造成对磁盘的大量读写，也将影响Nginx的性能。并发量越大，IO越高。这时候可以考虑关闭访问日志和错误日志。
error_log /var/log/nginx/error.log crit; #一般线上环境建议错误日志设置为 error 或者 crit
keepalive_timeout 10; #持久连接。一个http产生的tcp连接在传送完最后一个响应后，还需要hold住 keepalive_timeout秒后，才开始关闭这个连接。在http早期 ，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接；使用keep-alive机制，可以减少tcp连接建立次数（更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用）。但是配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置 keep-alive timeout时间非常重要。
/*
1.每一次TCP连接都需要三个阶段：连接建立、数据传送和连接释放。“三次握手”就发生在连接建立阶段。
TCP连接建立过程中为什么需要“三次握手”    
    目的是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
  
 “已失效的连接请求报文段”的产生在这样一种情况下：
    
 client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。若不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
(1)第一次握手
         客户端发送一个TCP的SYN标志位置1的包，指明客户打算连接的服务器的端口，以及初始序号X, 保存在包头的
         序列号(Sequence Number)字段里。
(2)第二次握手
         服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)
         设置为客户的I S N加1以.即X+1。
(3)第三次握手
        客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段
        中发送给对方.并且在数据段放写ISN的+1
2. SYN攻击
        在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态. 当收到ACK后，服务器转入ESTABLISHED状态.
        Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
        Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV
一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.但是不能完全防范syn攻击。
*/

client_header_timeout 10;   #客户端请求头的超时时间
client_body_timeout 10;     #客户端请求体的超时时间，可以把这个设置低些
reset_timedout_connection on; #告诉nginx关闭不响应的客户端连接。这将会释放那个客户端所占有的内存空间。
send_timeout 10;  #客户端响应超时时间，仅限于两个连接活动之间的时间。在这段时间内，客户端没有读取任何数据，nginx就会关闭连接

include /etc/nginx/mime.types; #只是一个在当前文件中包含另一个文件内容的指令
default_type text/html;   #属于http核心模块指令，设置默认类型为text/html，当文件类型未定义时使用这种方式
charset UTF-8;   #设置我们的头文件中的默认的字符集

gzip on;   #Nginx默认开启了gzip压缩功能。
/*
1.关闭了gzip压缩功能的Nginx虽然减少了CPU计算，节省了服务器的响应时间，但网站页面总体响应时间反而加长了，原因在于js和css、xml、json、html等等这些静态文件的数据传输时间的增长大大超过了服务器节省出来的响应时间.
2.gzip on 开启压缩后，大约可以减少75%的文件尺寸，不但节省了比较多的带宽流量，也提高了页面的整体响应时间.
3.是否需要对Web网站开启压缩，以及对哪些文件过滤压缩，大家可以通过使用HttpWatch、Firebug等等网络分析工具对比测试.
*/
gzip_disable "msie6"; #为指定的客户端禁用gzip功能
# gzip_static on; #告诉nginx在压缩资源之前，先查找是否有预先gzip处理过的资源。这要求你预先压缩你的文件（在这个例子中被注释掉了），从而允许你使用最高压缩比，这样nginx就不用再压缩这些文件了
gzip_proxied any; #允许或者禁止压缩基于请求和响应的响应流。我们设置为any，意味着将会压缩所有的请求。
gzip_min_length 1000; #指定压缩的文件最小尺寸，单位bytes字节.太小的文件没必要压缩，压缩过小尺寸文件带来增加的CPU消耗时间和压缩减少的文件尺寸降低的数据下载时间互相抵消，并有可能增加总体的响应时间
gzip_comp_level 4; #指定压缩等级，其值从1到9，数字越大，压缩率越高，越消耗CPU，负载也越高.设置为4，这是一个比较折中的设置.
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;  #指定允许压缩的文件类型，Nginx配置目录conf下的 mime.types 文件存放了Nginx支持的文件类型.推荐压缩类型如例。

open_file_cache max=100000 inactive=20s; #开启关闭打开文件缓存，默认值off关闭，强烈建议开启，可以避免重新打开同一文件带来的系统开销，节省响应时间。指定了缓存最大数目，以及缓存的时间
open_file_cache_valid 30s; #设置检查open_file_cache缓存的元素的时间间隔。
open_file_cache_min_uses 2; #设置在由open_file_cache指令的inactive参数配置的超时时间内， 文件应该被访问的最小次数。如果访问次数大于等于此值，文件描述符会保留在缓存中，否则从缓存中删除
open_file_cache_errors on; 

include /etc/nginx/conf.d/*.conf; 
include /etc/nginx/sites-enabled/*;
}
HTTP模块控制着nginx http处理的所有核心特性

Linux内核调优部分参数说明

http://www.ttlsa.com/nginx/web-server-nginx-optimization/
Linux内核参数部分默认值不适合高并发，一般临时方法可以通过调整/Proc文件系统，或者直接修改/etc/sysctl.conf配置文件永久保存