Nginx 是一款高性能的web服务器与反向代理器，其高性能是因为利用了Linux内核中的epoll机制，让CPU尽可能的运作起来，不要有阻塞。并且其采用多进程单线程的模式，将cpu与worker进程绑定，尽量减少cpu的上下文切换。
CPU
有效的使用cpu
1. 尽可能使用所有的cpu
场景一：为了让nginx尽可能的使用cpu，所以在配置时，尽量让每个Nginx的worker进程绑定一个cpu。
worker_processes auto;
场景二：为了防止惊群问题，以前有一个 accep_mutex 选项，但是新版本的Nginx内核（3.9）会使用reuseport。在内核中实现了负载均衡。
场景三：使得每一个worker进程可以独享一个核，提供cpu亲核性，避免多进程争抢。提升CPU的缓存命中率。
worker_cpu_affinity 1000 0100 0010 0001; # 4核为例 或者直接设置为auto
2. nginx的进程尽量保持全速运行状态。
worker进程不应该在繁忙的时候主动让出cpu。什么情况下会出现worker进程阻塞呢。硬件处理的速度跟不上，比如读磁盘中的数据太慢，读一个网络报文，都会导致nginx的进程处于S 状态，而Nginx的进程应该在高并发的场景下时刻保持R状态。
场景一：在建立一次新的连接的时候，tcp请求刚建立好，还没有数据发过来的时候，nginx不去关注这个连接，当有数据真正发过来了，再开始处理。
server {
listen 80 deferred;
return 200 "OK\n";
}
2. nginx的进程不能被其他进程争抢资源。
尤其在nginx lua的使用时，应该注意严禁使用lua自带的一些库，严禁使用会造成阻塞的库，尽量使用 lua-resty-* 的库，这些是openresty的相关库，是经过验证的。
场景一：提升Nginx的优先级，增大Nginx相关进程运行时的时间片时长。
进程优先级最低的可能使用的时间片只有5ms，而最高的优先级可能使用到800ms的时长，默认nginx的worker的优先级是0 ，处于中间。
worker_priority -20;
网络
优化tcp的握手
1. TCP的三次握手阶段的优化
场景一：如果nginx所在机器遭遇到syn攻击，对于nginx这层而言，那么就需要在内核参数上下手，首先降低syn的重试次数.扩大SYN_RCVD 的个数。
- net.ipv4.tcp_max_syn_backlog
- SYN_RCVD 状态连接的最大个数, SYN队列的大小（调大）。
- net.ipv4.tcp_synack_retries
- 被动建立连接时，发SYN/ACK 的重试次数（可适当减小）。
- net.core.netdev_max_backlog
- 接受网卡、但未被内核协议栈处理的报文队列长度大小。
- net.ipv4.tcp_abort_on_overflow
- 当超出处理能力时，对新来的SYN直接回RST，丢弃连接。
SYN_RCVD 的数量太小的，会 tcp_overflow
其他的解决办法：
- net.ipv4.tcp_syncookies = 1
- 当SYN队列满后，新的SYN不进入队列，计算出cookie后再以SYN+ACK中的序列号返回客户端，正常客户端发报文时，服务根据报文中携带的cookie重新恢复连接
- 由于cookie占用序列号空间，导致此时所有的可选功能失效，例如扩充窗口，时间戳等。
2. tcp fast open
tcp fast open 是 TFO（TCP Fast Open）是一种能够在TCP连接建立阶段传输数据的机制。使用这种机制可以将数据交互提前，降低应用层事务的延迟。
其原理是降低2次 握手期间的 rtt。当建立过一次3次握手后，server 会存一个cookie。client也会存一个cookie。下次再握手，带着cookie和syn+data 数据，直接开始请求。
nginx同样可以开启TFO
listen address[:port] [fastopen=numbers]
超时指令
-
client_body_timeout 60s
- 两次读操作间的超时 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout 注意这是两个连续读取操作之间的时间段，而不是整个请求主体的传输，如果客户端在此时间内未传任何消息，回以408 错误终止。
-
send_timeout 60s
- 两次写操作间的超时
-
proxy_timeout 10m
- 以上两者兼具
TCP，HTTP中的keepalive
TCP和HTTP的keepalive 的功能上是不一样的。
TCP的keepalive
- 实际应用
- 检测实际断掉的连接
- 用于维持与客户端间的防火墙有活跃的网络包
- 操作
- tcp keealive
- 发送心跳周期
- net.ipv4.tcp_keepalive_time = 7200
- 探测包的发送间隔
- net.ipv4.tcp_keepalive_intvl = 75
- 探测包重试次数
- net.ipv4.tcp_keepalive_probes = 9
- 发送心跳周期
- tcp keealive
HTTP的keepalive
- 实际应用
- 复用TCP连接去发送HTTP报文。减少TCP 握手，挥手次数。
减少关闭连接导致的time_wait 端口数量
首先明确，time_wait 过多会导致的问题是端口被占用。time_wait 在主动关闭方比较多。 CLOSE_WAIT 和 LAST_ACK 在被动关闭连接端比较多（CLOSE_WAIT 太多，可能应用程序有bug，别人发你fin，你总是不回fin，LAST_ACK过多，对方不给你发最后一个ACK）。
一般开了keepalive 的话，client连接nginx，nginx是不会主动关闭连接的，所以timewait会存在在客户端，不开keepalive，nginx处理完后会主动关闭连接，所以会有大量的timewait。
- 为了解决time_wait 过多的问题。
- net.ipv4.tcp_tw_reuse = 1
开启后，作为客户端时发起新连接可以使用仍处于TIME_WAIT状态的端口
由于timestamp的存在，操作系统可以拒绝迟到的报文。
- net.ipv4.tcp_timestamps = 1
这里强烈不建议使用 net.ipv4.tcp_tw_recycle
因为，开启后，同时作为客户端和服务器端都可以使用 TIME-WAIT 状态的端口，不安全，无法避免报文延迟，重复等给新连接造成的混乱。
- net.ipv4.tcp_max_tw_buckets = 262144
- 设置time_wait 状态连接的最大数量。超出后直接关闭连接。
