搞IT的同学无论是做开发的、做测试的、做运维的一定都遇到过以下几种报错，导致服务调用失败：

connection timeout

read timeout

connection reset by peer

都是服务调用失败，但是有3种报错信息，到底有什么差别呢？

本文将给大家分享以上错误异常出现的一种可能性，希望对你理解TCP连接、解决系统问题有所帮助。

首先我们来看一下正常的TCP连接交互：

正常通信场景

如果你对TCP建立连接三次握手的流程可能有所了解，那么你对SYN,SYN-ACK,ACK,SYN_SENT,SYN_RECV,ESTABLISH一定并不陌生，但其中SYN Queue和Accept Queue你可能没有见过。这正是本文要讲的重点。

SYN Queue：接收TCP SYN连接的队列，由操作系统参数 tcp_max_syn_backlog 控制，如果处于SYN_RECV的数量超过tcp_max_syn_backlog的值，则操作系统将直接抛弃客户端发出的SYN。

客户端由于未收到服务端返回的SYN-ACK，将在客户端配置的系统参数tcp_syn_retries次数后，放弃建立该TCP链接，客户端侧的报错即：connection timeout

过程如下：

SYN Queue满的场景

Accept Queue：在完成SYN,SYN-ACK,ACK后，连接将进入accept queue，直到服务端将调用accept()后即开始正常处理后续的数据包请求。该值将在操作系统的somaxconn参数及该应用程序自身的backlog参数最小值决定，即min(somaxconn,backlog)，请注意，这里的backlog并不是操作系统参数 tcp_max_syn_backlog。

如果Accept Queue由于应用程序性能不足或配置不当导致用满了，则根据操作系统参数tcp_abort_on_overflow来进行处理，下图为tcp_abort_on_overflow为默认值0时的返回情况，即操作系统将直接抛弃ACK，相当于服务端没有收到该ACK，但客户端会并不知道，认为三次握手已经完成，所以会发送业务数据包PSH,ACK，可惜的是从服务端的角度看，三次握手其实并没有真正完成，且由于最后一次握手的ACK相当于没有收到，因此会再次发送SYN-ACK给客户端(发送次数由tcp_synack_retries决定)。客户端将再次发送第三次握手的ACK给服务端，多次尝试后，客户端超时，将报错：read timeout。

Accept Queue满的场景1

如果Accept Queue满了，且系统参数tcp_abort_on_overflow=1，则操作系统将直接返回RST给客户端，客户端将报错：connection reset by peer。

Accept Queue满的场景2

查看端口的accept queue队列最大值：

ss -nlt

找到对应服务端口的Send-Q列值，即accept queue队列的最大值。

查看端口的accept queue队列当前值：

ss -tonp

找到对应服务端口的Send-Q列值，即accept queue队列的当前值。

总结：

对于小并发的场景，类似报错基本上都是服务端应用程序自身问题，导致的没有办法及时处理连接/业务请求。

对于高并发的场景，如果应用程序自身并不是瓶颈，就要考虑增加参数看是否可以避免这些问题了，

如增加系统参数 tcp_max_syn_backlog 的值来让系统可以同时接受更多SYN连接；

增加系统参数 somaxconn 的值增加accept队列的长度，当然同时要考虑增加应用的backlog参数，这里列三个比较常用的应用backlog设置方法

Tomcat:server.xml acceptcount=100

Redis:redis.conf tcp-backlog 511

Nginx:listen backlog=511