优秀自适应网站建设哪家好前端性能优化

TCP重传机制详解——04FACK

什么是FACK

FACK的全称是forward acknowledgement，FACK通过记录SACK块中系列号最大(forward-most)的SACK块来推测丢包信息。
举例说明：
Server:

• P1(0-9)、P2(10-19)、P3(20-29)、P4(30-39)、P5(40-49)

Client:

1. 正常收到了P1包并回复了ACK确认包，P2、P3、P4则由于网络拥塞等原因丢失;
2. 在收到P5时候回复一个Ack=10的确认包，并携带P5有SACK块信息(40-50)

这样server在收到P1的确认包和P5的dup ACK时候，就可以根据dup ACK中的SACK信息得知client端收到了P1报文和P5报文，计算出P1和P5两个数据包中间间隔了3个数据包，达到了dup ACK门限(默认为3)，进而推测出P2报文丢失。

发送端根据发送数据的缓存区和SACK块信息，完全可以计算出丢失的数据包个数(即使这些数据包不是满MSS大小)

SO,当使能FACK的时候，实际上我们可以通过ACK + 一个SACK块信息来推测丢包情况进而触发快速重传。

FACK的发展

/proc/sys/net/ipv4开启 TCP FACK(Forward Acknowledgement) 支持。选项废弃了，新版内核不再生效。

FACK 是拥塞控制中快速恢复（Fast Recovery）阶段相关的机制，它主要解决有多个报文丢失的情况下，通过准确估计（当前连接）还在网络中传输的报文大小，在恢复阶段做出精确的拥塞控制。计算的方式如下：

记录 SACK 的最大序号数为 snd.fack
定义 awnd 代表正在网络中传输的数据：awnd = snd.nxt - snd.fack，这里假设了不存在乱序报文
在重传时，awnd 要加上重传的数据：awnd = snd.nxt - snd.fack + retran_data
于是在拥塞时，cwnd 会根据算法改变，此时为了充分利用带宽，可以使用如下方法控制包的发送：

while (awnd < cwnd)
sendsomething()
该方法比起 Reno 通过接收到的 dupack 数量来调整 cwnd 值更为精确。对于快速恢复的触发也有变化：

正常 Reno 算法会在 dupacks = 3 时触发快速恢复，如果丢失多个包，则 ACK 数量也随之减少，导致等待重传的时间变长，而 FACK 额外增加了一个触发条件：(snd.fack – snd.una) > (3*MSS)，即假设没有乱序包的情况下，如果该条件成立，则说明网络中丢失了 3 个包，等价于 dupacks == 3，可以触发重传和快速恢复。

注：在 Linux 4.15[16] 中移除了 FACK 的支持，使用 RACK 机制替代。

为什么要引入FACK

因为当开始有SACK块信息的支持下，你可以准确的知道丢失包的范围信息。正是因为有了这些信息，不必再等待原有的dup ACK重复三次，而是应该计算这个范围丢包个数与阈值的关系从而决定是否快速重传。即发送端完全可以通过SACK+ack number来决定快速重传，不需要等待dup ACK三次

实战抓包讲解

开启FACK场景，且达到dup ACK门限值

开启FACK场景，未达到dup ACK门限值

为什么要淘汰FACK

1. 过于激进的重传FACK依赖于接收端发送的SACK信息来判断丢包，有时候网络中的乱序可能被错误地解读为丢包，从而导致不必要的重传。特别是在网络拥塞时，频繁的重传可能会加剧拥塞，降低网络性能。
2. 复杂度较高：FACK的实现和维护需要较为复杂的逻辑，包括跟踪和处理SACK信息，以及根据这些信息来决定何时重传。这种复杂性可能会影响内核的执行效率，也可能引入额外的实现风险。
3. 难以适应极端网络状况：在某些网络环境下，如严重的网络延迟或大规模乱序，FACK可能不如后来提出的更为先进和适应性强的算法，如RACK（Receiver-based ACKnowledgment）等。RACK通过接收端的延迟信息来推测丢包，对网络状况变化的适应性更强。
4. 对SACK的支持要求：并非所有TCP实现或网络设备都支持SACK选项，这意味着FACK的功能在这些环境下无法完全发挥，限制了其普适性。
5. 并发丢包处理：FACK在处理并发丢包时可能不如其他算法有效，例如在连续丢包且数量较多时，FACK可能无法一次性准确判断所有丢失的数据段。

总结

1. FACK的触发快速重传的原理就是：计算ACK和SACK块信息之间的丢失数据包个数是否达到3个
2. FACK乱序场景下的判断是失准的，可能导致过多的重传。
3. FACK已被淘汰，更优选为RACK

REF

FACK在Linux的落幕
TCP FACK与RACK