TCP协议调优-强制快速重传技术（Spurious retransmissions）

最新推荐文章于 2025-10-28 17:30:10 发布
原创 最新推荐文章于 2025-10-28 17:30:10 发布 · 2.5w 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#tcp #google #服务器 #linux #优化

本文探讨了RTT（往返时间）分布特性及其对用户体验的影响，并深入分析了RTO（重传超时）的默认设置及优化策略。通过介绍Linux系统下的超时重传机制，提出了一种缩短超时时间的方法，同时指出了可能引发的问题及其解决方案。

 

RTT Distribution一般如下图：

以上数据来自google.com。注意大于1秒的RTT有大约2.5%。而超时重传的概率有0.8% - 2.4%。

 

RTO（Retransmission Timeout）操作系统默认如下：

 

 

Linux的超时重传默认是3秒，这就意味这，一旦发生丢包，用户的体验将会很不好，因此可以采用强制快速重传技术来进行提速（Spurious SYN/SYN-ACK retransmissions），将超时重传时间强制设定为1秒。但这可能会导致duplicate packets，可以通过修改TS（tcp_sack参数，链路质量良好的情况下一般设0）或DSACK（允许发多个ACK，这里也用设0的方式）等方式来进行改进。

sysctl -w net.ipv4.tcp_sack=0
sysctl -w net.ipv4.tcp_dsack=0

sysctl -p

 

据了解，google的前台服务器TCP重传率为0.8% - 2.4% 。SYN-ACK重传率0.6% - 3.8%（未优化的情况）。

 

----------------------------------------------------------------------------------------------------------- 

TCP/IP协议 慢启动，快速重传的一些资料：http://www.faqs.org/rfcs/rfc2001.html

RFC2988 计算TCP的重发定时器：http://www.itqun.net/content-detail/402763.html

pennyliang
关注
Linux: network: tcp spurious retrans 的一个原因
mzhan017的博客
05-29 981
但是根据里面的介绍，不能解释当前遇到的情况，但是里面有提到RTT的时间。这个重传的发生是根据以往的RTT时间，如果ACK突然慢了，就可能导致重传。从下面的RTT的图也可以看出来，RTT的时间突然就变成了40ms，原来是非常小的一个值。最近分析问题的时候，从wireshark里看有：tcp spurious retrans 的包，309这个是307 的retransmission，而且在308 回复了ACK。当前遇到的这个情况是，CPU使用率突然增加导致内核的ACK回复都变慢了。从网上找了一些，比如。
【网络协议】【TCP】精讲TCP重传机制！图解超赞超详细！！！
风云说通信
09-24 2470
正常情况下，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。但在复杂的网络下，并不一定能顺利的进行数据传输，万一数据在传输过程中丢失了呢？针对数据包丢失的情况，TCP会用重传机制解决。2.1 判定方法TCP重传的判定是基于一系列的机制和算法，这些机制和算法帮助TCP协议检测到数据包是否丢失或损坏，并决定是否需要进行重传。以下是一些主要的判定方法超时重传（Timeout Retransmission）
TCP Spurious Retransmission
qq_22325611的博客
12-10 2363
虚假重传通常是由误判超时或网络延迟引起的。虽然它不会直接导致严重的问题，但它会降低网络效率，浪费带宽，并影响TCP的吞吐量。通过使用网络监控工具、优化超时设置、调整拥塞控制机制等方法，可以减少虚假重传的发生。
《TCP 重传机制在 Linux 中的工作逻辑：超时重传与快速重传》
sghjcnmvnk的博客
10-28 269
TCP 作为可靠传输协议，通过重传丢失的报文段保证数据完整性。Linux 内核实现了两种核心重传机制：超时重传和快速重传。以下是详细工作逻辑：触发条件： 当发送方未在预定时间内收到报文段的确认（ACK）时触发。 工作逻辑：动态计算超时阈值： Linux 基于往返时间（RTT）动态计算 RTO。关键公式：重传行为：适用场景：触发条件： 当发送方收到 3 个重复 ACK（即对同一报文段的第 4 次 ACK）时触发。 工作逻辑：重复 ACK 检测：重传与恢复：适用场景：协同工作逻辑：在 Linux 中，超时重传
tcp spurious retransmission
懒雄熊的专栏
10-10 3万+
 tcp虚假重传 指实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种： （1）对于部分移动网络，当网络发生切换时会导致网络延时突增 （2）当网络的可用带宽突然变小时，网络rtt会出现突增的情况，这会导致虚假超时重传 （3）网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。
tcp 抓包出现spurious retransmission
热门推荐
七号空间
01-09 3万+
一、tcp虚假重传 指实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种： （1）对于部分移动网络，当网络发生切换时会导致网络延时突增 （2）当网络的可用带宽突然变小时，网络rtt会出现突增的情况，这会导致虚假超时重传 （3）网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。 二、tcp虚假重传分析(摘自网络) 当Client端收到Server的SYN+...
信息安全_数据安全_us-18-Mulasmajic-Peterson-Why-So-Spurious.pdf
08-22
文档标题为"信息安全_数据安全_us-18-Mulasmajic-Peterson-Why-So-Spurious.pdf"，它指出了文档的主题集中在信息安全与数据安全两个方面，并涉及了对某个名为"Why so Spurious?"问题的深入探讨，该问题与x86/x64 CPU...
LWIP协议栈解析（八）——网络传输管理之TCP协议
qq_30781193的博客
09-03 1638
本章主要介绍了TCP协议以及LWIP对其的封装和使用
rto初始化和计算_理解TCP协议的重传时间（下）
weixin_39535287的博客
12-30 811
回顾我们上部分讲了跟RTO相关的RFC，主要是一个RTO的计算公式(RFC2988引入)和握手阶段3秒到1秒的初始化RTO的改变(RFC6298引入)。现在可以接着看linux代码的相关实现了，本文尽量将内容收敛到RTO主题。至于重传和拥塞算法等话题，我们(计算机学习微信公众号：jsj_xx)以后再谈。RTO计算的代码之实现公式具体实现和我们之前描述的公式是一致的：均值权重是1/8，偏差权重是1/...
#TCP你学得会# Wireshark中的"TCP Spurious Retransmission"
weixin_34272308的博客
01-29 5981
2019独角兽企业重金招聘Python工程师标准>>> ...
TCP系列24—重传—14、F-RTO虚假重传探测
maimang1001的专栏
08-31 3565
原文：https://www.cnblogs.com/lshs/p/6038603.html 一、虚假重传 在一些情况下，TCP可能会在没有数据丢失的情况下初始化一个重传，这种重传就叫做虚假重传(Spurious retransmission)。发生虚假重传的原因可能是包传输中重排序、传输中发生包复制、ACK确认包传输中丢失等等。如果由于链路时延变化或者负载变化等因素导致RTT突然变大等原因，TCP的发送端可能还没收到ACK确认包就已经RTO超时而触发重传，这种重传就叫做虚假超时重传(Spurious
[TCP Spurious Retransmission] 和[TCP Retransmission] 的关系
zengliguang的专栏
11-09 1190
总之，“TCP Spurious Retransmission” 是 “TCP Retransmission” 的一种异常情况，它们都与数据包的传输和确认相关，但 “TCP Spurious Retransmission” 并不是真正的数据包丢失导致的重传，而是由于网络中的一些异常情况导致的误判。在网络分析和优化中，需要准确地区分这两种情况，以便采取正确的措施来提高网络性能。
tcp 伪重传 [TCP Spurious Retransmission]
zengliguang的专栏
11-09 1735
在 TCP（传输控制协议）的通信中，其主要功能之一是确保数据的可靠有序传输，当数据包丢失或未得到确认时会进行重传。然而，有时会出现一种异常情况，即数据包已经被接收方成功接收，但发送方却由于某些原因误判数据包丢失，从而进行了不必要的重传，这种情况就称为 “TCP 伪重传”。此外，合理调整网络设备的配置、优化 TCP 的参数设置以及及时修复硬件故障等措施，都有助于减少 TCP 伪重传的发生1。还可能使发送方的拥塞窗口大小调整不当，影响整个网络的拥塞控制机制，降低网络的整体吞吐量。
TCP Analysis Flags 之 TCP Spurious Retransmission
7ACE的博客
12-04 1414
文档中关于的定义看起来简单，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于是与等在一起判断标记乱序或重传类型，而在不少场景还会有判断出错的问题，当然 Wireshark 考虑到这种情况，也有手动修正的选项，这正好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。SYN 或者 FIN 标志位设置不是 Keep-Alive 数据包TCP 段长度大于零该 TCP 流的数据已被确认，也就是说，反方向之前的 LastACK Num 已被设置。
TCP retransmission statistics from Google
weixin_30411239的博客
01-17 228
Abstract This article is an abstract from a paper which analyses TCP data from Google Web and vedio servers and present key statistics on the nature of retransmissions. Statistics （1）...
Wireshark抓包 [Tcp Previous Segment Not captured][Tcp Out-Of-Order][Tcp Spurious Retransmissiion]
zhangbaolin的专栏
07-04 1万+
Wireshark抓包时，除了TCP协议的三次握手建立连接、数据收发和四次握手断开连接外，还经常能看到如下几种不太常见的报文，具体包括：1.Tcp Previous Segment Not captured2.Tcp Out-Of-Order3.Tcp Dup Ack 12345#14.Tcp Spurious Retransmissiion5.Tcp Retransmission其中1、2、3会相伴出现，3、4、5会相伴出现。对应第一种情况是由于由于TCP数据被分块后，传输过程中经过不同的路径，到达目的端
Wireshark TS | 再谈虚假的 TCP Spurious Retransmission
7ACE的博客
02-11 1783
所以仅仅是捕获数据包的问题，实际的生产交互完全不会有这样的问题，因此类似这样的案例学习了解原因即可，也就完全没必要在 Wireshark 中手动修改该重传数据包为乱序，没有意义。
Troubleshooting Common Networking Problems with Wireshark, Pt. 2: TCP Retransmissions
chengfangang的专栏
11-05 929
Author’s Note: This is the second part in a six-part series about finding and solving many networking anomalies using the Wireshark network protocol analyzer. If you are new to the series, you can f
怎么减小tcp的重传超时时间
最新发布
12-18
<think>我们正在讨论如何减小TCP的重传超时时间（RTO）。在TCP协议中，重传超时时间是根据网络的往返时间（RTT）动态计算的。但是，我们可以通过调整一些系统参数来影响RTO的最小值、初始值以及退避行为。 在Linux系统中，我们可以通过sysctl接口来调整相关的TCP参数。以下是一些关键参数： - net.ipv4.tcp_rto_min: 最小重传超时时间（单位：毫秒），默认值为200ms。 - net.ipv4.tcp_syn_retries: SYN报文的重传次数，这会影响建立连接时的超时时间。 - net.ipv4.tcp_retries1: 在连接建立后，触发重传的次数阈值（用于判断是否需要重新路由或MTU探测）。 - net.ipv4.tcp_retries2: 在连接建立后，最大重传次数（超过则断开连接），默认值为15。 注意：减小重传超时时间可能会在丢包率高的网络中导致不必要的重传，从而增加网络拥塞。因此，调整前需要评估网络状况。 下面给出调整步骤和示例： </think> ### 减小TCP重传超时时间的方法 #### Linux系统调整方案 ```bash # 查看当前TCP重传参数 sysctl net.ipv4.tcp_retries2 net.ipv4.tcp_syn_retries net.ipv4.tcp_synack_retries # 永久修改配置（在/etc/sysctl.conf中添加） echo "net.ipv4.tcp_retries2 = 5" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.tcp_syn_retries = 3" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.tcp_synack_retries = 3" | sudo tee -a /etc/sysctl.conf # 立即生效 sudo sysctl -p ``` #### 关键参数说明 | 参数 | 默认值 | 建议值 | 作用 | |------|--------|--------|------| | `tcp_retries2` | 15 | 5-8 | 已建立连接的最大重传次数 | | `tcp_syn_retries` | 6 | 3-4 | SYN连接请求的重传次数 | | `tcp_synack_retries` | 5 | 3 | SYN-ACK响应的重传次数 | | `tcp_retries1` | 3 | 保持默认 | 触发路由缓存更新的重传次数 | #### 应用程序级优化 ```c // 在C语言中设置TCP_USER_TIMEOUT选项 int timeout = 5000; // 5秒超时 setsockopt(sockfd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout)); ``` #### 效果验证方法 ```bash # 监控TCP重传统计 watch -n 1 "grep 'TCPRetransFail\|TCPTimeouts' /proc/net/netstat" # 使用tc模拟网络延迟后测试 tc qdisc add dev eth0 root netem delay 100ms loss 5% iperf3 -c <server_ip> -t 60 ``` #### 注意事项 1. **平衡调整**：过小的超时值会导致虚假重传（spurious retransmissions） 2. **网络环境**：在RTT>100ms的高延迟网络中需谨慎 3. **协议支持**：确保对端设备支持TCP快速重传（Fast Retransmit） 4. **监控基线**：调整前后记录`ss -ti`输出对比
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值