本文目录导读：
tcp_early_retrans（早期重传，简称ER）是Linux内核中TCP协议栈的一个拥塞控制优化机制，它的核心目的并不是要发明一种新的重传算法，而是让发送端更及时地检测到报文丢失，从而提前触发重传。
常规的TCP重传依赖于超时重传（RTO，Retransmission Timeout，超时后重传）或快速重传（收到3个重复ACK后重传），早期重传机制在快速重传的基础上更进一步，它通过降低触发重传所需的重复ACK阈值来实现“早期”效果。
下面从工作原理、触发条件、生效场景和配置方式四个方面详细解析。
工作原理：降低重传触发门槛
传统快速重传要求收到3个重复的ACK（TCP Reno/NewReno）才能判定丢包并触发重传。
早期重传机制的核心思路是：在当前网络条件下，如果传输中的数据包（in-flight packets）较少，那么收到更少的重复ACK（比如1个）就足以推断发生了丢包。
为什么这样是合理的？
- 当你在一次发送中发出了N个数据包，如果只有少数几个在途中,那么网络拥塞或随机丢包的概率相对较低。
- 此时如果收到重复ACK，它很可能确实意味着中间有包丢了,而不是网络抖动导致的乱序。
具体判断逻辑（Linux 内核实现）
要实现早期重传，不能简单地用dupthresh < 3，内核需要评估当前网络状态是否允许降低阈值，主要依据是tcp_min_tso_segs和tso_segs。
在路径 net/ipv4/tcp_input.c 中的函数 tcp_process_loss 或 tcp_dupack_alert 里,逻辑大致如下：
- 计算当前发送窗口中的“数据段数”：
tcp_highest_sack_seq相关的包数量，或者通过MSS和skb->tso_segs计算。 - 与阈值比较：如果这个段数非常小（小于
tcp_min_tso_segs），那么内核认为后续不会有足够的重复ACK来触发传统快速重传（因为数据本来就少）。 - 触发Early Retrans：如果收到的重复ACK数量（
dupthresh）已经从默认的3降低到1或2，并且满足上述条件，则立即认为发生丢包,进入快速恢复阶段并重传疑似丢失的报文。
关键点：
- 它不会降低
dupthresh的全局值,而是根据每个TCP连接当前发送的数据量动态决定是否用低阈值。 - 主要适用于短连接或突发小流量场景,因为这种情况下传统3个重复ACK很难出现。
主要应用场景
-
短连接（Web浏览 / API调用）： 比如HTTP请求，通常只有少量数据包，如果中间丢了一个，客户端不会连续收到3个重复ACK（因为服务器回复的数据量不够），传统机制就会一直等到RTO超时（可能是几百毫秒甚至几秒）才重传，造成极高延迟，早期重传此时能提前几个RTT响应,显著降低页面加载时间。
-
丢包率较高的无线/蜂窝网络： 这类网络随机丢包更频繁、时延不稳定，早期重传能让TCP更快地从单个丢包中恢复,避免不必要的拥塞窗口收缩。
-
避免“尾丢包”(Tail Loss)保护： 当一个流量传输结束时，最后几个包丢失，同样很难收到重复ACK,早期重传可以有效覆盖这种情况。
在Linux中的配置与确认
是否开启？
早期重传在Linux内核中通常是默认开启的,可以通过以下命令查看：
cat /proc/sys/net/ipv4/tcp_early_retrans
返回值：
- 1：启用（支持FRTO/F-RTO机制,含早期重传）
- 2：启用并强制使用（更激进）
- 0：关闭（几乎不会在现代内核出现）
相关参数
net.ipv4.tcp_early_retrans(sysctl)：上面的开关。net.ipv4.tcp_retries1/tcp_retries2：控制重传次数上限。
形象的类比
想象你在快递站有一个只装了几个小包裹的小推车。
- 传统快速重传（3个重复ACK）：需要收到3个“那个包裹没到”的反馈（重复ACK）才启动补发，如果你的小推车里只有2个包裹，你永远等不到第三个反馈,只能干等超时。
- 早期重传：当看到第一个“那个包裹没到”的反馈时，就立刻检查——噢，我这个小推车里总共也没几个包裹，这种反馈很靠谱，我立刻补发吧,这样你就不用等超时了。
tcp_early_retrans 如何实现早期重传？
一句话概括：它在TCP连接拥有少量在途数据包（即in-flight数据少）时，将触发重传所需的重复ACK数量从3个降低到1个或2个，从而在无法凑足传统快速重传条件的情况下，避免等待漫长的RTO超时,提前发现丢包并重传。
优点：显著降低短连接、小流量场景的尾延时。 权衡：在乱序严重的网络中，可能略微增加不必要的重传（假重传），但现代内核（结合F-RTO）已有较好遏制。
