文章总结： 本文分析内网SCP传输慢问题，通过Wireshark抓包发现大量重传与DupACK现象。深入分析指出接收端服务器因性能不足在内部处理时丢弃数据，导致罕见的TCPSACKReneging现象，即接收方丢弃了先前SACK确认的数据。最终确认为服务器内存不足，建议检查系统资源或调整tcp_mem参数。 综合评分： 93 文章分类： 实战经验,网络安全,安全运营
Wireshark TS | TCP SACK Reneging
原创
7ACE 7ACE
Echo Reply
2026年3月9日 08:15 江苏
传输慢的难题
前言
看到数据包就像看到知识点，有时候就是这样一种感觉，更别说看到一些很不常见的数据包现象，就像是SACK Reneging ，活久见。
SACK Reneging 是 TCP 协议中的一种异常行为，指接收方先前通过 SACK（Selective Acknowledgment）选项确认已成功接收某些数据段，但后续因特殊原因（如内存不足）主动丢弃这些已确认的数据。这种行为导致发送方依赖的 SACK 信息失效，需要特殊处理机制来维持可靠性。
问题信息
问题的起源很简单，就是有业务同事反馈通过 SCP 传输文件慢，说是网络慢。当然这种单方面的结论，我一向自然是不认可的，更何况是在纯内网环境。🤣
必现的问题，在某一端捕获了数据包，文件基本信息如下：
# capinfos "sack reneging.pcapng"File name: sack reneging.pcapngFile type: Wireshark/... - pcapngFile encapsulation: EthernetFile timestamp precision: nanoseconds (9)Packet size limit: file hdr: (not set)Packet size limit: inferred: 56 bytes - 1518 bytes (range)Number of packets: 20 kFile size: 23 MBData size: 22 MBCapture duration: 25.187304974 secondsEarliest packet time: 2025-11-12 19:38:30.159666647Latest packet time: 2025-11-12 19:38:55.346971621Data byte rate: 902 kBpsData bit rate: 7221 kbpsAverage packet size: 1136.83 bytesAverage packet rate: 794 packets/sSHA256: 18ec016652552fa409eb568f6110b87385e76acaa66559a0d3a579c7eae7ad0aSHA1: 470d625d346c8e8c5966eb38fd8ad3273332a265Strict time order: TrueCapture application: Editcap (Wireshark) 4.6.4 (v4.6.4-0-g93282876538d)Number of interfaces in file: 1Interface #0 info: Encapsulation = Ethernet (1 - ether) Capture length = 2048 Time precision = nanoseconds (9) Time ticks per second = 1000000000 Time resolution = 0x09 Number of stat entries = 0 Number of packets = 20000#
专家信息如下，存在重传、快速重传、虚假重传、乱序、Dup ACK 等现象，数量不是特别多，但考虑到纯内网环境，还是需要进一步查看原因。
问题分析
该数据包在 10.1.1.2 服务器所捕获，数据包详情信息主要如下：
既然说慢，首先自然是需要关注那些异常的信息，像是重传、快速重传、乱序之类的问题。实际上在专家信息中，有一类重传的数量相对于其他特别的突出，那就是“This frame is a (suspected) retransmission” 大概有 177 个。
根据以前介绍的 TCP Analysis Flags 系列分析，TCP Retransmission 已经是根据异常序列号判断的最后一道了，这说明很大可能就是 超时重传。为什么在纯内网环境会产生超时重传，带着这样的疑问，具体到异常数据包前后去分析。
No.595 第一个 TCP Retransmission 数据包，原始数据包是 No.589，但仔细看，它俩间隔的时间很短，实际上并没有达到 RTO 超时重传的时间，No.595 实际上是一个快速重传，肯定是由 No.594 SACK 数据包所触发出来的。但因为 10.1.1.1 是个 Windows 系统，所以仅能从数据包现象推断是这样，可参考下 Linux 系统的实现。
如果是 Linux 系统，那么可以解释是因为 SACK 包含确认了 3 个数据段 SLE 65661 SRE 661041 ，也就是确认了 No.591-No.593 数据包，在 Linux 实现中就会触发出快速重传。
但为什么 Wireshark 没有把 No.595 数据包标记成快速重传，自然是 Wireshark 判断逻辑需要基于至少 2 个 Dup ACK 的情况下才判断是快速重传，在这里并不匹配，所以最后认定是 TCP Retransmission ，但实际是快速重传。
继续第二个（不一样现象） 的 TCP Retransmission 数据包，No.839，就会有不一样的地方了。 No.839 相对于原始数据包 No.832 的间隔时间达到了 300ms，已经明显是超时重传了。
但这里 No.838 SACK 数据包为啥没有触发出快速重传呢？No.838 SACK 同样包含确认了 3 个数据段 SLE 924981 SRE 929029，也就是确认了 No.834、No.835 和 No.837 三个数据包，却没有和 No.594 实现同样的效果，还是推断是 Windows 系统和 Linux 系统机制有不一样的地方，这留作以后再研究。
但为什么 Wireshark 也没有把 No.839 数据包标记成快速重传，虽说 Wireshark 判断逻辑需要基于至少 2 个 Dup ACK，在这里能匹配（No.836、No.838），但因为间隔时间超过了 20ms ，所以还是不满足 Wireshark 对于快速重传的判断，最终还是认定是 TCP Retransmission ，但这个真的是超时重传。
其他的重传数据包的现象几乎都类似这两个数据包，在这里需要再提及的是，这个数据包文件是在 10.1.1.2 服务器所捕获的，再回看以上两张图，你就会发现 10.1.1.2 已经在本地网卡捕获看到了 10.1.1.1 发送的多个数据段，但在后续处理过程中，也就是在服务器内部发生了丢失，产生了很多 Dup ACK，也因此触发 10.1.1.1 服务器进行了很多次不应该有的重传，特别是超时重传。
根据 Time Delta 进行排序，你就会发现排名靠前，满屏幕的都是 900ms+、300ms+，如此之多的超时重传间隔，传输文件能不慢嘛，而原因自然是 10.1.1.2 服务器自身的性能问题。
说了半天，解释了传输慢的现象和原因，反而是标题说的 TCP SACK Reneging 没有提及，🤔 当然这也是服务器性能不足产生的一个现象，看看就好。
10.1.1.2 服务器 No.1748 SACK 数据包，ACK Num 1902849 SLE 1904309 SRE 1907229，也就说明了没有收到 Seq Num 1902849 – 1904309 的数据段。
而在之后 10.1.1.1 服务器进行了超时重传，也就是 No.1750 数据包 Seq Num 1902849 – 1904309，但 10.1.1.2 服务器收到后所响应的 No.1751 ACK 数据包仅仅是 ACK Num 1904309，却并不是 1907229，说明 10.1.1.2 服务器主动丢弃了之前已经确认过的数据（SLE 1904309 SRE 1907229），这就是典型的 TCP SACK Reneging 现象。
问题总结
根据数据包分析出来的结论，直指 10.1.1.2 的性能问题，反馈给服务器同事，后续经排查确认确实是有性能问题，在之后还提供了一个 dmesg 的输出信息，有提示 TCP: Out of memory — consider tuning tcp_mem 。
挺有意思的一个案例，不是嘛。
往期推荐
1. Wireshark 提示和技巧 | 捕获点之 TCP 三次握手
2. Wireshark 提示和技巧 | a == ${a} 显示过滤宏
3. Wireshark TS | 当超时或快速重传遇到零窗口
4. Wireshark TS | 防火墙空闲会话超时问题
5. 网络设备 MTU MSS Jumboframe 全解
后台回复「TT」获取 Wireshark 提示和技巧系列 合集
后台回复「TS」获取 Wireshark Troubleshooting系列 合集
如需交流，可后台直接留言，我会在第一时间回复，谢谢！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Echo Reply 7ACE 7ACE《Wireshark TS | TCP SACK Reneging》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论