Tcp异常断开之Connection reset

最新推荐文章于 2025-06-16 18:37:07 发布

原创最新推荐文章于 2025-06-16 18:37:07 发布 · 置顶 · 1.2w 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#Tcp连接异常断开 #Connection reset #wireshark抓包分析 #socket连接 #远程debug

tcp协议专栏收录该内容

2 篇文章

订阅专栏

本文通过实验测试和Wireshark抓包分析，详细记录了一次TCP连接异常现象的排查过程，揭示了连接断开的原因，并最终定位到了MAC地址相关的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、背景

192.168.15.81（linux机器）机器访问192.168.0.139（linux机器）的任意端口，建立的tcp连接成功，但是连接会莫名奇妙的消失，导致Connection reset的错误。

192.168.5.81的mac地址：6C:92:BF:0B:2F:9D（linux）

192.168.0.139的mac地址：未知(linux)

192.168.15.186的mac地址：44-47-C6-37-7D-A6（window）

二、wireshark抓包分析

在linux下执行抓包命令：tcpdump –i eth1 host 192.168.0.139 –w /iflytek/raw.cap,会抓去和0.139上的tcp报文传递，如图所示:

报文分析：15.81和0.139三次握手成功，但是15.81像0.139发送一段Request,Connect(1), Connect的时候，连接莫名奇妙的消失了，导致0.139像15.81发送RST（连接复位）。这个连接到底被谁偷走了呢？答案是：15.81，0.139或者是中间经过的路由均可以断掉连接。

三、问题排查

机器问题排查

写了一个简单的socket程序进行测试，加入一台机器192.168.15.186进行测试，15.81~0.139，0.139~15.81，15.81~15.186，15.186~15.81，15.186~0.139，0.139~15.186，程序如下图：

Reader Writer

1、15.81~0.139发送数据

数据流：15.81-->81网卡-->交换机—>路由1—>交换机—>139网卡—>0.139。

前提条件：将Reader部署到0.139上，Writer部署到15.81上，采用远程debug的方式控制程序的执行进度,远程debg命令：java –Xdebug–Xrunjdwp:transport=dt_scoket,address=8555,server=y,suspend=y –jar ****.jar

发送数据：11，21，31，检测tcp连接正常，不会被断掉。

发送数据：122，2123，32232，检测tcp连接，消失了，原因不明。

结果解释：说明tcp连接15.81~0.139发送数据不能超过两个字节，这也说明了上文抓包中的过程，因为三次我手发送的是空包，所以握手可以建立，但是当15.81像0.139发送Connect的包时，tcp连接断掉了，所以，0.139回复了RST。

2、0.139 ~ 15.81发送数据

数据流：0.139-->139网卡-->交换机—>路由2—>交换机—>81网卡—>15.81。

前提条件：同上。

发送数据：11，21，31，检测tcp连接正常，不会被断掉。

发送数据：122，2123，32232，检测tcp连接，不会被断掉。

结果解释：这个很奇怪，像是单向连通，0.139可以向15.81发送数据，但是15.81不能像0.139发送数据。

3、15.186~0.139发送数据

数据流：15.186-->186网卡-->交换机—>路由1—>交换机—>139网卡—>0.139。

前提条件：同上。