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 数据，直接开始请求。

TFO
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

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 状态连接的最大数量。超出后直接关闭连接。