本文详解高并发场景下backlog的配置和作用

 

 

环境介绍： PHP 7.3.5 +nginx/1.16.0 +Linux VM_0_15_centos 3.10.0-514.26.2.el7.x86_64

 

backlog定义：

 

已连接但未进行accept处理的SOCKET队列大小，并非syn的SOCKET队列。如果这个队列满了，将会发送一个ECONNREFUSED错误信息给到客户端,即 linux 头文件 /usr/include/asm-generic/errno.h中定义的“Connection refused”

 

在linux 2.2以前:

在底层维护一个由backlog指定大小的队列。服务端收到SYN后，返回一个SYN/ACK，并把连接放入队列中，此时这个连接的状态是SYN_RECEIVED。当客户端返回ACK后，此连接的状态变为ESTABLISHED。队列中只有ESTABLISHED状态的连接能够交由应用处理。第一种实现方式可以简单概括为：一个队列，两种状态。

 

linux 2.2以后:

在底层维护一个SYN_RECEIVED队列和一个ESTABLISHED队列，当SYN_RECEIVED队列中的连接返回ACK后，将被移动到ESTABLISHED队列中。backlog指的是ESTABLISHED队列的大小。SYN_RECEIVED队列的大小由/proc/sys/net/ipv4/tcp_max_syn_backlog系统参数指定，ESTABLISHED队列由backlog和/proc/sys/net/core/somaxconn中较小的指定。

 

当前最流行的DoS(拒绝服务)与DDos(分布式拒绝服务)的方式之一，这是一种利用TCP协议缺陷，导致服务器保持大量的SYN_RECV状态的“半链接”，并且会重试默认的5次回应第二个握手包，塞满TCP等待连接队列，耗尽资源(CPU满负载或内存不足)，让正常的业务请求连接不进来。

 

TCP 3次握手
可分为4步

1 客户端发起connect()，发送SYN j
2 服务器从半链接队列(syn queue)中建立条目，响应SYN k, ACK J+1
3 客户端connect()成功返回，响应ACK K+1,服务器将socket从半链接队列(syn queue)移入全连接队列(accept queue)，accept()成功返回
如何观察socket overflow 和 socket droped。

如果应用处理全连接队列(accept queue)过慢则会导致socket overflow

影响半连接队列(syn queue)溢出而导致socket dropped

[root@VM_0_15_centos ~]# netstat -s | grep -i listen    
62678 times the listen queue of a socket overflowed
65640 SYNs to LISTEN sockets dropped
如果SYN socket overflow和socket droped急剧增加的话则说明，TCP的三次握手是存在很大的问题的。

验证

查看全连接队列(accept queue)溢出之后，OS处理设置:

0:表示如果三次握手第三步的时候全连接队列满了那么server扔掉client发过来的ack(在server端则会认为连接没有建立起来)，server过一段时间再次发送syn+ack给client（也就是重新走握手的第二步），如果client超时等待比较短，client就很容易异常了。

1:表示如果三次握手第三步的时候全连接队列满了，server端就会发送一个reset包给client端，表示废弃这个握手过程和这个链接。(在server端也会认为连接没有建立起来)

cat /proc/sys/net/ipv4/tcp_abort_on_overflow

设置tcp_abort_on_overflow为1

echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow

查看server端的web服务是否存在许多的connection reset peer错误。

​

 

在使用listen函数时，内核会根据传入参数的backlog跟系统配置参数/proc/sys/net/core/somaxconn中，二者取最小值，作为“ESTABLISHED状态之后，完成TCP连接，等待服务程序ACCEPT”的队列大小。在kernel 2.4.25之前，是写死在代码常量SOMAXCONN，默认值是128。在kernel 2.4.25之后，在配置文件/proc/sys/net/core/somaxconn (即 /etc/sysctl.conf 之类 )中可以修改。

[root@VM_0_15_centos ~]# cat /proc/sys/net/core/somaxconn
32768
[root@VM_0_15_centos ~]# cat /usr/local/php/etc/php-fpm.conf |grep backlog
listen.backlog = 1024
[root@VM_0_15_centos ~]# ss -ln |grep -E 'php|Netid'
Netid  State      Recv-Q Send-Q Local Address:Port               Peer Address:Port              
u_str  LISTEN     0      1024   /dev/shm/php-cgi.sock 79785144              * 0
 

可见： 内核会根据传入参数的backlog跟系统配置参数/proc/sys/net/core/somaxconn中，二者取最小值

我这里php-fpm 配置的 listen = /dev/shm/php-cgi.sock ，如果你配置的 tcp监听9000，应该用如下命令验证

[root@VM_0_15_centos ~]# ss -lt
State      Recv-Q Send-Q Local Address:Port             Peer Address:Port                
LISTEN     0      1024   0.0.0.0:9000               *:*
 

backlog大小设置为多少合适？

 

1、backlog太大了，导致php-fpm处理不过来，nginx那边等待超时，断开连接，报504 gateway timeout错。同时php-fpm处理完准备write 数据给nginx时，发现TCP连接断开了，报“Broken pipe”。

2、php-fpm的backlog太小的话，nginx之类的client请求，根本进入不了php-fpm的accept queue，报“502 Bad Gateway”错。所以，这还得去根据php-fpm的QPS来决定backlog的大小。计算方式最好为QPS=backlog。建议设置在1024以上，最好是2的幂值（因为内核会调整成2的n次幂）

 

SYN queue长度由tcp_max_syn_backlog指定，accept queue则由net.core.somaxconn决定，listen(fd, backlog)的backlog上限由somaxconn决定.

 

php-fpm下backlog配置

php-fpm.conf进行配置

listen.backlog = 1024  默认值是 511 ，是在2014年7月22日修改的， Set FPM_BACKLOG_DEFAULT to 511
 

其中理由是“backlog值为65535太大了。会导致前面的nginx(或者其他客户端)超时”，假设FPM的QPS为5000，那么65535个请求全部处理完需要13s的样子。但nginx(或其他客户端)已经等待超时，关闭了这个连接。当FPM处理完之后，再往这个SOCKET ID 写数据时，却发现连接已关闭，得到的是“error: Broken Pipe”，在nginx、redis、apache里，默认的backlog值都是511。故这里也建议改为511。

 

 

nginx下backlog配置

/etc/nginx/nginx.conf进行配置

 

listen       80 backlog=8192; # 默认为511
 

linux下backlog配置

 

/etc/sysctl.conf 进行配置

 

net.core.somaxconn = 1048576 # 默认为128
net.core.netdev_max_backlog = 1048576 # 默认为1000
net.ipv4.tcp_max_syn_backlog = 1048576 # 默认为1024