TCP连接被意外重置的原因

2024-06-15 01:48
文章标签 连接 tcp 重置 原因 意外

本文主要是介绍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连接被意外重置的原因的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1062092

相关文章

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因?

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台,是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力,在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术,能够处理多种视频流格式,并以多种格式(RTMP、RTSP、HTTP-FLV、WebS

W外链微信推广短连接怎么做?

制作微信推广链接的难点分析 一、内容创作难度 制作微信推广链接时,首先需要创作有吸引力的内容。这不仅要求内容本身有趣、有价值,还要能够激起人们的分享欲望。对于许多企业和个人来说,尤其是那些缺乏创意和写作能力的人来说,这是制作微信推广链接的一大难点。 二、精准定位难度 微信用户群体庞大,不同用户的需求和兴趣各异。因此,制作推广链接时需要精准定位目标受众,以便更有效地吸引他们点击并分享链接

【测试】输入正确用户名和密码,点击登录没有响应的可能性原因

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题: 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定,导致点击后无法触发登录操作。 页面可能存在

Java 连接Sql sever 2008

Java 连接Sql sever 2008 /Sql sever 2008 R2 import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; public class TestJDBC

实例:如何统计当前主机的连接状态和连接数

统计当前主机的连接状态和连接数 在 Linux 中,可使用 ss 命令来查看主机的网络连接状态。以下是统计当前主机连接状态和连接主机数量的具体操作。 1. 统计当前主机的连接状态 使用 ss 命令结合 grep、cut、sort 和 uniq 命令来统计当前主机的 TCP 连接状态。 ss -nta | grep -v '^State' | cut -d " " -f 1 | sort |

【Go】go连接clickhouse使用TCP协议

离开你是傻是对是错 是看破是软弱 这结果是爱是恨或者是什么 如果是种解脱 怎么会还有眷恋在我心窝 那么爱你为什么                      🎵 黄品源/莫文蔚《那么爱你为什么》 package mainimport ("context""fmt""log""time""github.com/ClickHouse/clickhouse-go/v2")func main(

2024.9.8 TCP/IP协议学习笔记

1.所谓的层就是数据交换的深度,电脑点对点就是单层,物理层,加上集线器还是物理层,加上交换机就变成链路层了,有地址表,路由器就到了第三层网络层,每个端口都有一个mac地址 2.A 给 C 发数据包,怎么知道是否要通过路由器转发呢?答案:子网 3.将源 IP 与目的 IP 分别同这个子网掩码进行与运算****,相等则是在一个子网,不相等就是在不同子网 4.A 如何知道,哪个设备是路由器?答案:在 A

图解TCP三次握手|深度解析|为什么是三次

写在前面 这篇文章我们来讲解析 TCP三次握手。 TCP 报文段 传输控制块TCB:存储了每一个连接中的一些重要信息。比如TCP连接表,指向发送和接收缓冲的指针,指向重传队列的指针,当前的发送和接收序列等等。 我们再来看一下TCP报文段的组成结构 TCP 三次握手 过程 假设有一台客户端,B有一台服务器。最初两端的TCP进程都是处于CLOSED关闭状态,客户端A打开链接,服务器端

nginx长连接的问题

转自: http://www.360doc.com/content/12/1108/17/1073512_246644318.shtml

NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64

转自:http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=190176&id=4234854 一 前言 当管理大量连接时,特别是只有少量活跃连接,NGINX有比较好的CPU和RAM利用率,如今是多终端保持在线的时代,更能让NGINX发挥这个优点。本文做一个简单测试,NGINX在一个普通PC虚拟机上维护100k的HTTP