缓存服务器syns to listen sockets drop导致创建socket失败

Posted 2021-04-25 IT技术精选文摘

问题描述：

最近遇到了一个syn丢包的情况，当系统磁盘、网络、cpu都无压力的时候，系统莫名其妙出现“sync to listen sockets drop”问题；无论带宽是10M还是8G，都会出现这种这种情况。现象为：输入系统命令：netstat -s | grep LISTEN，会出现 syns to listen sockets dropped; 但是并没有times the listen queue of a socket overflowed；连接队列包括两种，一个是半连接队列（syn queue），一个是全连接队列（accept queue）；根据上述描述，accept队列并没有溢出，而syn队报丢失有可能是syn队列溢出的原因，也可能是其他原因；"syns to listen sockets dropped"意思是：收到三次握手的ack包，因为各种原因导致创建socket的过程中被丢弃；

首先我们分析了一下netstat -s里面的数据，发现"passive connections rejected because of time stamp"的值和"syns to listen sockets dropped"相差不大，很多服务器他们的值都是相同的，这个让人感觉sync to listen sockets drop的原因有可能与时间戳有关；

我们检查了一下系统的配置：

or的keepalive设置为512个,总共40个cpu；系统级别的监听队列长度是65535，syn队列是26w；or的每个进程监听队列是20w；

我们的架构是上层是openresty，下层是我们的自研缓存软件；

syns to listen sockets dropped;  是由于在三次握手过程中创建socket失败，但是我们不知道是or或者cache软件作为客户端丢失syn包还是or或者cache软件作为服务器丢失syn包；于是我们做了一系列测试；

发现以下几点：

1. client（用户）访问or层，会导致or层作为服务器端的syn包丢失；

2. or作为客户端，访问cache软件时，or发出的syn包没有丢失；（or和cache软件是同一个机房）；

3. cache软件作为服务器，接受到的syn包没有丢失；

4. cache软件作为客户端，发出去的syn包没有丢失（cache软件主要是给其他IDC发送http请求）；

于是我们的重点是解决用户给or的syn包丢失的问题；

我们从网上查找原因，查到了最有可能的原因：

：因为2.6内核以上中tcp_timestamps默认是打开的，所以当打开 tcp_tw_recycle时会导致部分通过NAT上网client无法正确连接服务器，故障表现为client发出SYN后无法收到server返回 的SYN+ACK，推荐的解决方法是关闭tcp_tw_recycle，打开tcp_tw_reuse解决TIME-WAIT过多的问题。

我们将/proc/sys/net/ipv4/tcp_tw_recycle修改为0，drop情况就不发生了；

然后查看tw个数：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

有可能drop package的情况：(服务器端tcp_tw_recycle和tcp_timestamp都开启)

1.lvs处于NAT模式（咱们是DR）；

2.客户端处于NAT模式；
3.IDC处于NAT模式；有人对国内的节点做了一个可视化分析，发现有2.61%的概率出口存在NAT的这种情况；

在服务器上最好打开tcp_tw_reuse，并且关闭tcp_tw_recycle。
tcp_tw_reuse和tcp_tw_recycle区别：

1. tw_reuse，tw_recycle 必须在客户端和服务端timestamps 开启时才管用（默认打开）

2. tw_reuse 只对客户端起作用，开启后客户端在1s内回收

3. tw_recycle 对客户端和服务器同时起作用，开启后在 3.5*RTO 内回收，RTO 200ms~ 120s 具体时间视网络状况。内网状况比tw_reuse 稍快，公网尤其移动网络大多要比tw_reuse 慢，优点就是能够回收服务端的TIME_WAIT数量；

可长按扫码关注，谢谢