各位做网络开发、运维和性能排查的朋友对RST包肯定不陌生。我就是那个在机房里抱着笔记本一遍遍敲tcpdump抓包对着Wireshark红色标记看到眼花的工程师。TCP RSTReset可能是网络世界里最让人“又爱又恨”的报文了爱它是因为它能快速终止一个异常连接恨它是因为它出现时往往意味着你的服务又出问题了。我经常被问到“连接为什么被重置了”、“对端是不是把我们的包丢了”、“为什么负载均衡器老发RST”这篇文章我就系统地梳理一下我们在实际项目里最常遇到的几种TCP连接中出现RST的情况把每种情况对应的抓包特征、内核行为、排查思路都讲透最后再分享一套我自己常用的排查方法论希望能帮大家少踩一些坑。1. RST的本质TCP协议栈的“强制挂断”在彻底拆解各种触发场景之前我们得先把RST报文的底层逻辑聊透。很多人把它和普通的数据包混淆实际上RST在TCP报文头里是一个极简的控制标志位。我的理解是它干的事情和打电话时的“直接摔话筒”是一个道理——不需要和你礼貌道别也不给你机会说“再见”直接把这条连接的状态从两端的内存里抹掉。1.1 RST报文的信息量少得可怜如果你用tcpdump抓到一个RST报文仔细看它的内容会发现它通常不携带应用层数据甚至序列号和确认号的处理也看起来很奇怪。它的核心语义只有一句话“我不承认这条连接了请你立刻删除关于它的一切状态。”正因为这种“暴力”特性无论是服务端还是客户端收到RST后都得立刻终止该连接。这和FIN报文有本质区别——FIN是“我想正常结束通话了等你说完再见”而RST是“我不想再听你说话了马上给我挂断”。在内核协议栈的实现里收到合法的RST报文后本地会直接丢弃发送缓冲区里的所有数据并把错误码通常是ECONNRESET传给上层应用。如果是主动发送方收到RST那问题通常出在对端如果应用层代码write()时收到了EPIPE错误那八成是你自己提前关闭了一端对端后续数据发过来无从投递直接回了一个RST。1.2 合法RST与无效RST的判断基准这里有个细节值得留意不是所有RST都会生效。TCP协议栈对RST报文的合法性有一个基本的校验逻辑主要是检查序列号是否落在接收窗口内。如果收到一个序号完全不在窗口内的RST严格实现的内核会选择忽略它或者回复一个ACK而不是直接断开连接。这个机制避免了一些“幽灵包”误伤正常连接。这一点在排查问题时的意义在于——如果你在抓包里看到RST先别急着判定连接断了。要结合它前后报文的序号和确认号一起看。通常我们关注的特征是RST包的Win窗口字段设为0Sequence Number指向当前需要被确认的位置一旦被对端内核接受双方便彻底告别。2. 建连瞬间被重置目标端口连不通最常见的RST场景几乎都集中在“连接压根没建立起来”的阶段。我自己排查过的业务告警里大概有40%属于这一类。表现就是客户端发起SYN服务端立刻回一个RST,ACK三次握手还没完成就黄了。2.1 端口根本没在监听内核的直接响应服务端某个端口压根没有进程监听这时TCP握手包进来内核协议栈会毫不客气地回一个RST。这个行为在内核里写得很死几乎是立刻响应。我们在tcpdump里看到的抓包特征非常明显客户端发出SYN紧接着收到服务端回复的RST,ACK握手过程直接夭折。测试方法也很土但很有效用nc或者telnet打一下就行。如果端口是关闭的你会立刻看到Connection refused错误。这是因为本地内核没有对应的socket可以接收这个连接数据包到达传输层时查找不到匹配的四元组只能通过RST来拒绝服务。一个容易被误解的点是很多人以为防火墙会直接丢弃包导致超时实际上如果是本机端口没监听那是内核回RST而如果是中间网络设备拦截表现往往是连接超时不是立刻RST。这两者的差异在排查链路故障时是很好的分水岭。2.2 防火墙和安全组的“礼貌拒绝”比端口未监听更隐蔽的是安全策略主动发了RST而不是直接丢包。有些防火墙比如某些安全组规则或ACL配置在拦截命中特定策略的连接时会配置成“拒绝并通知”模式目的就是快速让客户端感知到失败避免客户端傻等超时。最常见的例子是云安全组入方向规则忘了放行某个端口。客户端SYN发到中间设备中间设备直接回一个RST服务端本身完全不知道自己被攻击了。这时候你去服务端抓包什么都抓不到因为包根本没进来但客户端的抓包里能看到RST的来源是防火墙的接口IP或者是完全不认识的一个中间节点IP。提示根据我的经验遇到“SYN发出后立刻收到RST但服务端自己抓包没有任何东西”的情况基本可以先假定是中间网络设备搞得鬼优先检查安全组、网络ACL、以及机房防火墙的拦截日志。2.3 backlog溢出导致的内核激进重置这种场景比较有意思端口有监听但新建连接还是被RST了。原因在于全连接队列accept queue满了。Linux内核里有一个开关net.ipv4.tcp_abort_on_overflow如果设置为1当全连接队列已满时内核会对新到达的SYN握手完成的连接直接回RST而不是丢弃SYN包等待重传。我遇到过一个高并发的服务瞬时洪峰流量打过来backlog设置得太小结果客户端看到的就是大量的Connection reset而不是Connection refused。理论上更温和的做法是丢包让客户端重试但有些场景下内核选择直接重置。排查这类问题时ss -tlnp可以看到Send-Q的溢出情况netstat -s里的times connection dropped because of full accept queue计数也是重要线索。3. 运行中的长连接被RST最常见也最费眼神这个部分是我重点想说的。很多线上事故的锅最后都甩给了“网络抖动”或“机房不稳定”但实际上大量RST是应用层和TCP协议栈交互不当导致的。这种运行中连接被重置的场景排查起来最费劲因为连接线上跑着好好的突然某个时间点就断了。3.1 半关闭后对端还来发数据编程模型里很多初学者容易犯的错就是只关了读端或只关了写端。比如服务端代码里调用shutdown(fd, SHUT_WR)表示我不再发送数据但并没有关闭读端。如果此时客户端不管不顾继续发送请求数据服务端内核收到数据后发现对应socket写方向已经关闭于是立刻返还一个RST——因为协议栈没法把数据交给应用层了留着也是浪费内存。这个场景我见过一个很具代表性的案例某框架的HTTP健康检查机制服务端处理完业务后立刻close()了socket但客户端那边发送缓冲里可能还残留有先前积压的数据。服务端关闭后的socket收到客户端迟到的数据内核直接回RST客户端应用层报错java.net.SocketException: Connection reset。本质原因很简单关闭连接时没有确保对端已经把数据读完。正常关闭TCP连接的正确姿势是四次挥手谁先调用close谁进入TIME_WAIT但如果你直接关闭读写两端对端后续发的数据包找不到接收者自然会收到RST。3.2 序列号错乱引发的“幽灵RST”这里聊一个比较反直觉的场景。抓包时明明看到对端发了一个RST过来但业务日志显示两边都在正常工作。为什么因为此时RST针对的可能是旧连接的“迷路包”。举个例子客户端和服务端之间建立过一个连接后来因为超时或者重启这条连接被其中一端遗忘了。此时服务端可能重新创建了相同四元组同一个IP和端口的新连接而旧连接上迟到的数据包这时突然到达服务端。服务端通过序列号判断发现这个包不在当前连接接收窗口内属于合法TCP语义之外的包于是直接回RST把这个“错误数据”打死。这种问题在新旧连接复用四元组时特别容易出现。我的处理经验是如果连接断掉之后立即用同样端口重连前一个连接残留的数据包很容易导致新连接收到RST。这种场景下抓包看到的现场是seq数字乱飘窗口里多了一个莫名其妙的旧数据包然后立刻触发RST。3.3 双方超时时间不一致导致的“误杀”TCP连接建立后如果长时间没有数据传输很多服务都会有心跳机制。但网络设备、负载均衡器、甚至操作系统自身都有空闲连接超时设置。我遇到过一个经典事故应用层心跳间隔是90秒但中间某云负载均衡器的连接空闲超时阈值设置成了60秒。结果就是连接在60秒空闲时被中间设备默默回收此时客户端以为自己连接还活着等到90秒心跳发出时发现对端已经完全没有这条连接状态了于是中间设备或服务器回一个RST。应用层因此误判对端崩溃触发大量重连和异常告警。注意排查这类问题一定要把“链路各节点的空闲超时时间”全部拉出来对比一遍。很多所谓的TCP连接莫名被重置不是服务端干的也不是客户端干的而是中间的转发节点或者网关设备干的。3.4 Keepalive探测失败后的内核裁决Linux的TCP Keepalive机制默认是关闭的除非你显式开启。一旦开启如果连接空闲超过tcp_keepalive_time默认7200秒内核会开始发送Keepalive探测包。如果探测包连续多次没有回应默认9次内核会认为对端已经不可达于是主动关闭连接连接关闭前会发一个RST给对端。这个RST不是对方发来的恰恰是本端内核“忍无可忍”之后自己发的。很多做实时消息推送的服务在移动网络下经常遇到这类问题。手机切到弱网环境TCP连接名存实亡等到网络恢复后服务端发现探测无响应直接RST断连。移动端的同学如果收到大量这类报错可以先检查一下是不是Keepalive参数设置不合理探测时间太短或者重试次数太少导致正常的网络抖动也被判定为死链。4. 中间网络设备“帮倒忙”注入的RST这一类属于最让人脑壳疼的问题因为应用层代码、操作系统内核看起来都没有问题但连接就是被重置了。用抓包工具在服务器上抓到RST来源既不是本端也不是远端而是一种“天外来客”。4.1 安全设备检测到攻击特征后双向重置入侵检测和防御系统IPS/IDS在识别到某个连接有攻击特征时通常会主动注入RST报文来切断这条连接。很多安全设备还会把RST同时发给通信的两端让两个方向都快速终止。看起来就像双方互相不承认这条连接实际上是第三方强制干预的。我经历过一个诡异案例某内网服务之间的调用频繁出现RST抓包发现来源是一个安全设备因为我这台服务器向另一台服务器发送的数据库查询语句里包含了一些类似注入的关键字特征被安全策略误判为攻击流量。解决办法是联系安全团队调整策略白名单或者给这条业务链路单独加白。这类RST最典型的特征抓包看到的RST报文TTL值和正常业务TTL不一样。因为正常收发的包TTL基本固定而安全设备注入的包会再经过几跳到达你这里TTL会明显小几跳。4.2 NAT表项老化导致的后知后觉RST内网服务器访问外部服务时很多场景会经过NAT网关网络地址转换。NAT网关维护着一张地址映射表记录内网IP和端口跟外网地址的映射关系。如果这条表项在空闲时被老化掉之后内网再有数据包发出去NAT网关就找不到对应表项了这会被视为非法数据包于是直接给发送端回一个RST。这个场景的坑在于NAT设备的老化时间通常是不可控的而且你根本看不到它内部的表项。定位方法只能是抓包确认——服务器A发出去的包一直有响应过了空闲期后发出第一笔数据时立刻收到了一个RST且RST的来源是网关地址。如果是直连外网就不存在这个RST只有在经过NAT时才出现那基本可以锁定是NAT表项的问题。5. 排查RST问题的现场实践方法论方法论往往是最后才沉淀下来的东西。踩了太多坑之后我摸索出一套排查RST问题的流程现在无论遇到什么奇怪的连接重置问题基本都能在半小时内缩小范围。5.1 先分清是谁发起的RST这是第一步也是最关键的一步。tcpdump抓包时tcpdump -i eth0 tcp[13] 4 ! 0只抓RST报文然后看RST报文的源地址是本机IP说明本机内核主动重置了这条连接去看本机应用日志和后端服务状态。RST报文的源地址是远端IP说明对端主动断开或对端协议栈认为连接非法需要去检查对端程序和对端抓包。源地址都不是通信双方那大概率是中间设备注入优先查安全策略和NAT的配置。实操经验我的习惯是同时两端抓包只一端抓容易误判方向。客户端抓到的RST可能是服务端发的也可能是中间人发的。只有两端的抓包对齐才能判断这个RST是在网络路径上哪一段被注入的。5.2 查内核计数器和Socket统计服务器上执行netstat -s可以看到TCP层面的异常计数信息。我重点关注这几行connections reset due to unexpected data说明有数据发送到了已经关闭的socket上程序关闭逻辑大概率有问题。connections reset due to early user close本端还在收数据时应用就关闭了socket。times connection dropped because of full accept queue全连接队列溢出需要调大backlog和应用层的accept线程数。配合ss -tnlp查看各连接的状态和Send-Q/Recv-Q可以快速判断是不是连接接收缓冲或发送缓冲被撑满缓冲满后内核也会先关闭连接后续行为可以表现为RST。5.3 抓包文件里如何快速定位关键特征Wireshark打开抓包文件后我通常直接输入tcp.flags.reset 1过滤所有RST包。然后定位到每一处RST位置看RST包前后的报文序列如果RST前面是一个SYN说明是连接建立阶段被拒绝重点查端口监听和防火墙策略。如果RST前面是一串连续的重传包则可能是对端已经消失但本端还在疯狂重传最终某个节点忍无可忍发送RST。如果RST前面是FIN,ACK说明是正常关闭阶段但关闭过程中有一端还在发数据可能是应用层关闭顺序不对。如果RST前面是一个乱序包tcp.analysis.out-of-order标记那多半是时序或者序列号的问题。5.4 总结一个千万字级的排查案例说个我自己印象最深的案例。某天业务群里突然反馈某个内部系统提交订单时偶发失败报错是Connection reset by peer。一开始怀疑是应用服务器的问题于是我在客户端、服务端和中间负载均衡器三层同时抓包。最终抓到的是客户端发出的POST请求在中间负载均衡器被RST了而且RST包的TTL和正常数据包TTL有明显差异。查负载均衡器的访问日志后发现那条连接因为长时间空闲会话已经被后端连接池回收。客户端恰好在这个时间点发出了新请求而请求被负载均衡器转发到一个已经被关闭的后端口于是后端直接回了RST。这个问题的根因其实是在负载均衡器的空闲超时和后端连接池的空闲回收时间不一致一个设成了60秒另一个设成了90秒导致中间60到90秒之间的请求命中了一个“半死”连接。解决方式很简单把两边的超时时间统一调整到40秒以下。但这背后的排查过程花了两天也让我深刻认识到一条连接从客户端到服务端之间每一层的超时时间和连接回收策略都可能成为RST的来源。写在最后的一些观察心得经过这几年和RST的反复缠斗我对TCP的理解已经从“三次握手四次挥手”升级到“每个包都有它存在的意义”。RST本质上是TCP协议栈的一种自我保护机制它在过滤异常、终止错误上非常高效但同时它对上层应用掩盖了很多细节。排查过程中我们不只要关心应用日志里报了什么错更要关心这个错误是内核哪个模块、哪条路径上报上来的。我个人现在遇到任何连接异常第一反应不是去应用代码里翻找try-catch而是先抓包。用一个最简单的tcpdump -i eth0 -nn port 8080先看一遍到底发生了什么。很多时候数据包本身就能把真相原原本本地告诉你。希望大家能在自己的环境里多试试这些方法遇到RST不用慌按着上面的思路一步步来你很快就会从“看到RST就头疼”变成“看到RST就兴奋”的状态——因为每一个RST背后大概率都藏着一个等待被优化的系统设计。
