TCP连接被意外重置的原因

明显服务器端上层读取过慢了，窗口填满了

今天在做服务器压力测试的时候，出现了很奇怪的情况，与服务器建立连接会成功，但是很快会被重置(RESET)掉。花了半天时间，终于找到原因所在，我把过程和结果写下来与大家分享。

服务器正常逻辑是：接受连接，等待用户注册报文，处理其他请求，如果连接一段时间没有活动，则主动关闭连接。

客户端逻辑是：与服务器建立连接后，马上发送注册报文，然后每隔一段时间发送一个请求。有上万个客户端同时连接一个服务器，当连接出现错误时，马上重新连接。

出现错误时，客户端会报告下面一连串错误：

recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer
recv: Connection reset by peer

进一步的测试发现只有在客户端数目超过一定数量才会出现这样的情况，于是联想到Linux进程打开文件描述符（Linux下套接字也是一种文件描述符）的数量限制（前几天刚刚增加了这个数量限制），但是到底有什么联系不知道。

开始以为服务器程序逻辑主动关闭了连接，但是根据抓包的结果，服务器根本就没有发送TCP FIN报文，下面是一个典型的连接建立与重置的过程：

14:01:03.567888 IP 192.168.6.45.36692 > 192.168.6.46.8080: S 1231228012:1231228012(0) win 5792 <mss 1460,sackOK,timestamp 174530727 168899918,nop,wscale 8>
14:01:03.567969 IP 192.168.6.46.8080 > 192.168.6.45.36692: S 909133089:909133089(0) ack 1231228013 win 5792 <mss 1460,sackOK,timestamp 168900338 174530727,nop,wscale 8>
14:01:03.567978 IP 192.168.6.45.36692 > 192.168.6.46.8080: . ack 1 win 23 <nop,nop,timestamp 174530727 168900338>
14:01:03.568022 IP 192.168.6.45.36692 > 192.168.6.46.8080: P 1:76(75) ack 1 win 23 <nop,nop,timestamp 174530727 168900338>
14:01:03.568110 IP 192.168.6.46.8080 > 192.168.6.45.36692: . ack 76 win 23 <nop,nop,timestamp 168900338 174530727>
14:01:03.568769 IP 192.168.6.46.8080 > 192.168.6.45.36692: R 1:1(0) ack 76 win 23 <nop,nop,timestamp 168900338 174530727>

检查服务器的日志，也没有主动关闭连接的记录，甚至并没有接受到新的连接。这说明连接是由底层协议栈关闭的，但协议栈为什么会主动关闭呢？

用telnet连接服务器，也不正常，但是是被正常关闭的（有正常的FIN序列），而不是重置。

是否与侦听套接字的就绪连接队列长度有关？但是连接队列满时，协议栈不做任何操作，而是让客户端超市重发SYN报文，与出现的情况不一致。

看来还是有打开文件描述符的数量限制有关，那么不能再打开文件描述符时，会出现什么情况呢？为什么telnet连接会出现不同的情形呢？对这些问题的回答就要透过现象看本质了，我的分析如下：

首先，连接确实是建立了，说明协议栈是接受了这个连接的，当然，应用程序肯定没有接受，否则打开文件描述符数目超过上限了。另一方面，协议栈当然要关闭这个连接，但是没有立即关闭，应该是在应用程序接受连接时(accept)关闭（尚未验证），进一步跟踪，accept会产生too many open files错误。这也说明套接字这个文件描述符是在accept时打开的，在协议栈中建立的连接并没有对应的套接字描述符。

telnet连接的不同之处在于没有向服务器发送数据，此时采用正常方式关闭，这是协议的要求还是Linux实现的特例没有考证过。

还有另外一个结论是在accept之前收到的数据仍然会被接受并应答，并且连接上的数据是存储在协议栈中的，这符合我先前的概念。

TCP连接被意外重置的原因相关推荐

close wait 过多原因_干货分享！服务端 TCP 连接的 TIME_WAIT 问题分析与解决
写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨:最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下. ...
面试官问：大量的 TIME_WAIT 状态 TCP 连接，对业务有什么影响？怎么处理？
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 几个方面: 问题描述:什么现象?什么影响? 问题分析解决 ...
大量的 TIME_WAIT 状态 TCP 连接，对业务有什么影响？
点击上方蓝色"程序猿DD",选择"设为星标" 回复"资源"获取独家整理的学习资料! 来源 | ningg.top/computer-basi ...
83998 连接服务器出错_服务端 TCP 连接的 TIME_WAIT 问题分析与解决
民工哥技术之路写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨:最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时 ...
基础原理系列：服务端 TCP 连接的 TIME_WAIT 问题
几个方面: 问题描述:什么现象?什么影响? 问题分析解决方案底层原理 1.问题描述模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接: 短时间后,所有的 TIME_WAIT 全 ...
rabbitmq链接超时_RabbitMQ前置SLB中TCP连接超时900秒限制
问题背景当前RabbitMQ集群架构如图所示,消费者consumer通过SLB连接到RabbitMQ集群. 但是SLB有连接超时限制,具体限制如下: 4. 负载均衡各监听连接超时时间是多少? TCP ...
【Linux网络编程笔记】TCP短连接产生大量TIME_WAIT导致无法对外建立新TCP连接的原因及解决方法—实践篇
1. 查看系统网络配置和当前TCP状态在定位并处理应用程序出现的网络问题时,了解系统默认网络配置是非常必要的.以x86_64平台Linux kernelversion 2.6.9的机 ...
TCP短连接产生大量TIME_WAIT导致无法对外建立新TCP连接的原因及解决方法—基础知识篇...
最近遇到一个线上报警:服务器出现大量TIME_WAIT导致其无法与下游模块建立新HTTP连接,在解决过程中,通过查阅经典教材和技术文章,加深了对TCP网络问题的理解.作为笔记,记录于此. ...
tcp连接时，BROKEN PIPE错误的原因以及解决方法
tcp连接时,BROKEN PIPE错误的原因以及解决方法参考文章: (1)tcp连接时,BROKEN PIPE错误的原因以及解决方法 (2)https://www.cnblogs.com/ctho ...

TCP连接被意外重置的原因

TCP连接被意外重置的原因相关推荐

最新文章

热门文章