Nginx: TCP建立连接的优化和启用Fast Open功能

TCP 建立连接优化

在三次握手中，相关TCP的内核参数可优化这一过程
- net.ipv4.tcp_syn_retries = 6
- net.ipv4.tcp_synack_retries = 5
- net.ipv4.tcp_syncookies = 0
- net.ipv4.tcp_max_syn_backlog
- net.core.somaxconn
- net.core.netdev_max_backlog

1 ） net.ipv4.tcp_syn_retries = 6

上面，一个是 syn，一个是 synack，对应TCP的两个不同的阶段
Nginx 是一个中间服务器，下游服务器有这个客户端，它的上游服务器有应用程序服务器
假如，Nginx服务器想要作为客户端去请求上游应用程序服务器的数据的时候
Nginx 也需要向客户端一样发送一个SYN的请求包给后端的应用程序服务器建立这个TCP连接
Nginx 客户端在发送完这样一个SYN之后，有可能因为网络的原因导致后端的应用程序服务器
没有及时返回SYN加ACK的响应包给 Nginx 的时候，Nginx自身会再次发送这样一个SYN的包
TCP是有超时重传这样一个机制的, 因此这个参数其实就是用来决定Nginx和上游服务器交互的时候它
也就是跟上游服务器请求建立TCP连接的时候，首次发送SYN包这个重试次数
也就说Nginx第一次发送失败之后，会间隔一定的时间之后再去发送一次SYN包
如果说超过了这样一个次数之后，还是没有正确建立TCP连接，这个时候就会放弃
假如说，现在的Nginx服务器是一个高负载的服务器，想要去优化这样一个过程
通常跟后端的服务器来说，6 这个数值可能会有些偏大，通常需要调低到2或3

2 ）net.ipv4.tcp_synack_retries = 5

还有一个叫 tcp_synack_retries 在Nginx上去修改这样一个参数的话
它影响的是Nginx作为服务器的时候(对应用户的客户端，发一个请求到Nginx的时候)
客户端会发送给Nginx一个SYN的包，Nginx 会回送一个SYN加ACK的确认包
这个时候，假如说客户端不响应，最后一个ACK给我的时候，我会重试
这里5 并不是一个次数大概就是 180 秒，可以修改短一些，每个1大概 180 / 5 = 3x s
修改成2，就成了70s左右，这个参数影响的是Nginx服务器和应用程序服务器之间的一个连接
如果自己内部网络很好的话，可以把这个参数调小
对于Nginx高并发这样的一种服务器，必须让每一个细节尽可能的时间变少
在连接非常多的情形下，每一个点去耗费一些时间，整体性能会急剧的下降
上面两个参数是Nginx作为客户端的一个参数，下面这个参数是Nginx作为服务器端的一个参数

3 ）net.ipv4.tcp_syncookies = 0

默认在linux中配的是0，很多现在的一些linux服务器可能会把这个参数置为 1 了
它是为了应对 syn flood 攻击的
在之前TCP协议还不规范的时候，客户端可以通过一定的工具伪造很多不同IP的 syn 包
它们去向服务器发起 syn 请求, 去建立TCP连接, 这些过多的伪造包到达 Nginx 服务网卡
网卡收到这些 syn 包之后，就会递给 syn 队列，这样，syn队列很快被打满
同时，伪造的包，ip很多也是伪造的，不存在的，Nginx会送请求后是不能得到响应ACK的
这样，所有伪造的包伪造的 syn 在队列中不释放，新的连接无法进入服务器，正常请求无法处理
syn flood 攻击是最早TCP/IP设计不规范时候出现的，为了避免这种场景出现，则设计了这个参数

客户端发送SYN的时候，服务器收到这个SYN包之后，就会立即在服务器中的给它开辟一些内存空间来存放这个连接中的一些信息
这个连接过来之后，服务器就立马去分配存储空间的话，假如说客户端是一个黑客
他们用工具模拟了很多 syn 包发送到服务器端，服务器针对每一个连接都去分配一个存储空间
对我服务器影响性能是非常大的, 为了避免这种情形的话，当我的客户端在发送 syn 包给服务器的时候不会立即给你分配的一个存储空间
服务端会通过一定的算法计算出一个cookie，之后，把 SYN 包加ACK，发送给客户端
假如说, 客户端能够正确回送ACK的时候, 那就代表这个客户端是一个真实存在的客户端
验证客户端发过来的ACK这个报文中可能带有的cookie信息的真伪
假如，这个表中的cookie返回是一样的，再给客户端去分配这样一个存储空间，这个时候就验证了
假如说第一次，比如说你黑客发送了很多的syn包到我的服务器
没关系，服务器不会直接给你分配存储空间，既然不涉及在内存中分配存储空间
也就意味着，整个服务器不会被立马打死，这时候会送很多 SYN加ACK, 包含计算出的cookie
伪造IP的 syn 包，是无法正常回送 ACK包到服务器的，因此避免了 syn 的攻击
tcp_syncookies = 0 表示这个功能没有打开，置为 1 则表示开启，在centos7之后，就默认为1了

4 ）net.ipv4.tcp_max_syn_backlog

换一种角度看我们客户端和我的这个服务器，建立三次握手的中间的一些细节
客户端发送一个SYN的包到 Nginx 服务器上
Nginx 服务器拿到之后，它内核的TCP/IP协议栈会处理这样一个数据包
这个数据包会被它放到SYN队列里边，这个队列长度很小的话，必然会影响整个Nginx的并发数量
通常情况下，会把这样一个队列的长度调大，由这个内核参数决定：tcp_max_syn_backlog
当这个连接到SYN队列之后，这个Nginx服务器的TCP/IP协议栈，会回送一个SYN加ACK的包给客户端
之后，假如说客户端正确的回送了ACK给Nginx服务器，内核中的TCP/IP协议栈拿到之后
它会在这个SYN队列中找到对应客户端的一个连接，会把这个连接从队列中剔除掉
同时它会把这个连接放到accept队列，表示这个连接已经正确的建立了，三次握手已经完成了
接下来需要有上层的应用层的应用进程来处理。比如accept的队列需要对应上面的应用程序进程是80
也就是这个时候Nginx可以到这个对应的队列中去找到这个TCP连接，进行处理
Nginx进程的accept队列它有多大呢？通过这样一个参数：listen :80 backlog=248000;
这个 backlog=248000 就是 accept 队列的长度
在整个linux服务器中，作为一个服务器，上面不只有Nginx进程，可能还有很多其他的进程
如果其他的应用程序也需要通过TCP协议来进行处理的话, 其他应用程序也应该有 accept 队列
所以，在我们的系统中，还有一个决定系统级的这个accept队列长度的一个内核参数值
Nginx 是通过在listen指令后面加 backlog 这样一个参数来决定 accept 队列的长度的
如果 Nginx 的 accept队列很大，但是整个系统级的 accept 队列定义的很小也没用
所以说还对应的需要去优化整个系统级的accept队列的长度，如果服务器只跑一个Nginx服务
那可以把整个系统级的这个accept队列指定和Nginx这个backlock队列指定一样
也就是尽可能让Nginx 去使用整个系统的 backlog accept队列，从而尽可能的压榨服务器的性能

5 ) net.core.somaxconn

这个参数是用来指定整个系统的 accept 队列，也就是能够正确建立完TCP连接的一个队列长度
因此，Nginx的 accept 的 backlog 值尽可能接近上面这个参数值

6 ）net.core.netdev_max_backlog

字面意思，网络设备最大的队列长度，网络设备指代我们的网卡
很多连接数据已经到达了网卡，但是一部分连接已经发送给SYN队列了
但是还有一部分并没有，这里就是在网卡上滞留的一些数据，通常情况下也要把它给改大一些

7 ）综合配置

$ cat /proc/sys/net/core/netdev_max_backlog
```
1000
```
$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog
```
128
```
$ cat /proc/sys/net/core/somaxconn
```
128
```
以上都是默认值，看起来值比较小，如果要更改，不能直接更改上述配置文件
因为 /proc 下都是临时文件，改了临时文件会立即生效，但是重启后就变回去了

通过这个命令，查看系统内核参数 $ sysctl -a | grep somaxconn

net.core.somaxconn=128
sysctl:readingkey "net.ipv6.conf.all.stable secret"
sysctl:reading key "net.ipv6.conf.default.stable secret"
sysctl:readingkey"net.ipv6.conf.ens33.stablesecret"
sysctl:readingkey"net.ipv6.conf.ens37.stable secret"
sysctl:readingkey "net.ipv6.conf.ens38.stable secret"
sysctl:reading key "net.ipv6.conf.lo.stable secret"

我们现在可以修改 $ vim /etc/sysctl.conf

net.core.somaxconn = 8000
net.core.netdevmaxbacklog = 248000
net.ipv4.tcp_max_syn_backlog = 248000
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp synack_retries = 1

让其生效，$ sysctl -p 生效

net.core.somaxconn=65535     # 注意这个是最大值，不能超过这个值
net.core.netdev_max_backlog = 248000
net.ipv4.tcp_max_syn_backlog = 248000
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1

检查配置是否生效，$ sysctl -a | grep tcp_max_syn_backlog

sysctl:readingkey "net.ipv6.conf.all.stable_secret"
net.ipv4.tcp_max_syn_backlog = 248000
sysctl:readingkey "net.ipv6.conf.default.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens33.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens37.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens38.stable_secret"
sysctl:reading key "net.ipv6.conf.lo.stable_secret"

发现已生效
其他参数，也可以类似进行验证，此处不再赘述

现在，我们可以去修改 nginx 的 backlog 队列

server {
	listen 443 ssl deferred backlog=248000; # 注意这里，大于 65535 即可，不会受限于系统
	# ... 其他
}

启用TCP的Fast Open功能

1 ) TCP 的 Fast Open

TCP Fast Open(TFO) 是用来加速连续TCP连接的数据交互的TCP协议扩展
由Google于2011年的论文提出并实现

1.1 最初RFC中实现 TCP 协议的状态如下

最初实现的是客户端发送SYN，服务端收到 SYN 包值以后回送SYN + ACK
客户端收到SYN加ACK包之后，还要回送给客户端 ACK
三次握手建立完连接之后，客户端就可以向服务端发送请求资源了
服务端在收到这样一个请求之后，会构建响应报文，再把数据返回给我的客户端
RFC 在演进的时候，优化了这一过程

1.2 RFC 优化的过程

当客户端第一次发送 SYN 之后，服务端回给客户端 SYN加ACK
在最后一次, 客户端回送ACK的时候，在这个ACK包中直接加一些 DATA 数据
比如说, 通过HTTP的get方法去请求某一个资源
之前是客户端把ACK 这个包是单独发送给服务端之后，客户端建立连接之后，再去发送请求数据包
这个优化，就是少了这样一个过程，优化了一步，在大并发中，性能提升明显

1.3 2011年 Google 提出的TFO的优化

当客户端发送一个 SYN 给服务端的时候，当服务器收到 SYN 包之后
它会通过一定的算法, 比如根据客户端的信息，去计算出来一个cookie
之后，服务端会发送SYN加ACK加cookie给客户端
客户端就拿到这样一个cookie 并保存起来
客户端再次最后发送 ACK 的时候，也把请求数据带上，即直接发请求(基于RFC的优化)
之后就是一些数据交互了，经过一段时间之后，客户端断开连接了
后面客户端又想请求数据的时候，在前面没有TFO的情形下，还是继续要发送SYN
也就是说，不可避免的重复建立TCP的连接，每一次都需要三次握手过程
其实，当有了TFO之后，客户端保存的cookies, 就不需要三次握手了，直接通过
SYN+Cookie+Data的形式与服务端通信，如上图所示
服务端验证一致后，直接构建报文返回客户端DATA
当服务端打开这样一个 TFO 功能，客户端也要支持这样的 TFO 功能才能生效
在实际生产中，打开 TFO 功能也是极大提高吞吐性能

2 ）实际环境开启 Fast Open

先看一下这个核心参数 $ sysctl -a | grep tcp_fast
```
sysctl:readingkey"net.ipv6.conf.all.stable_secret"
net.ipv4.tcp_fastopen = 0
net.ipv4.tcp_fastopen_key=00000000-00000000-00000000-00000000
sysctl:reading key "net.ipv6.conf.default.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens33.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens37.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens38.stable_secret"
sysctl:reading key "net.ipv6.conf.lo.stable_secret"
```
- 这里有一个叫做：net.ipv4.tcp_fastopen 的内核参数
- 默认为 0 意思是关闭这个TFO功能，这个值的范围是 0, 1, 2, 3
- 1 代表，Nginx 作为客户端来说开启 TFO 的功能 (nginx 和上游应用服务器之间)
- 2 代表，Nginx 作为服务端来说开启 TFO 的功能，这时不管上游服务器是否开启，没用
- 3 代表，Nginx 不论作为服务端还是客户端都开启这个 TFO 功能

现在，我们写进去 $ vim /etc/sysctl.conf

net.ipv4.tcp_fastopen  =  3  # 添加这一行进去

验证下，$ sysctl -p

# ... 其他
net.ipv4.tcp_fastopen  =  3  # 可以看到，这里有了

再次验证， $ sysctl -a | grep fast 可见下面已经打开这个功能了

net.core.default_qdisc=pfifo_fast
sysctl:readingkey "net.ipv6.conf.all.stable_secret"
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_fastopen_key=00000000-00000000-00000000-00000000
sysctl:readingkey "net.ipv6.conf.default.stable_secret"
sysctl:readingkey "net.ipv6.conf.ens33.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens37.stable_secret"
sysctl:readingkey"net.ipv6.conf.ens38.stable_secret"
sysctl:readingkey "net.ipv6.conf.lo.stable_secret"