认识网络随机丢包

news2024/9/22 10:07:11

考虑一根漏水的管子，希望出水口接到和不漏的管子等量的水，要么靠时间，反复将漏掉的水重新注入，直到漏掉的水可忽略：
在这里插入图片描述

要么靠空间，在漏的地方将管子加粗，一次性注入更多的水：
在这里插入图片描述

不管哪种方式，总有一段管子要承担更大压力，要么来自多次小冲刷，要么来自一次大冲刷，换句话说，因为漏不可避免，造成额外压力的这些流量就是用来漏掉的，这是不可避免的补偿。

当我们评估网络丢包时，注意以上的类比。

网络丢包分两类，拥塞丢包和随机丢包，拥塞丢包是自找的，来自传输协议自身，可避免，随机丢包则来自下层，可能是路由问题，可能是信道质量问题，这种丢包无法避免，只能补偿。

如漏水管类比，随机丢包的补偿一定要增加流量，额外的这部分流量要在丢包处损失掉，但这部分额外流量可能增加丢包处上游链路的拥塞，因此随机丢包可能造成拥塞丢包，随机丢包率越高，拥塞越可能发生，这反馈环很有趣。

假设丢包率 P，传输总量为 1 的数据，计算一下需要额外多发的流量。

非常简单，x * (1 - P) = 1，解得 x = 1 / (1 - P)。但这只是一个式子，下面看具体补偿过程。

对于一次性大冲刷，本来要发送 1，在丢包率 P 下要发送 1 / (1 - P)。

对于多次小冲刷，累加每次重传的丢包量即可：

A = 1 + 1 * P + 1 * P * P + 1 * P * P * P + … 1 * P^n = (1 - P^n)/(1 - P)

在 n 趋向于无穷时，A = 1 / (1 - P)

不管分批补偿，还是一次补偿，随机丢包率 P 的可靠传输，必须多付出 1 / (1 - P) - 1 的额外流量作代价，而这部分多出来的流量将可能在别处造成拥塞。

当随机丢包大于一定的概率，用户保障就会激增，运营商必须主动干预维修，否则随机丢包将恶化成严重拥塞。随机丢包的原因不外乎线缆老化，设备老化，线路受损，人为干预等，但对于接入区域而言，比如 Wi-Fi 网络的 CSMA/CA 碰撞，信号问题也是随机丢包源之一。

以上就是随机丢包的根本以及影响。

随机丢包是固有损失，要接受它。在可靠传输场景，要用 “多次小冲刷” 方式补偿，除此之外采取柔性降级应对损失而尽量不要补偿。

对端到端拥塞控制算法如何应对随机丢包，没有定论，各算法都在宣扬自家抗随机丢包能力，但实际上没有任何端到端算法有这能力。这就好比说人群围绕篝火，引发了火灾，只有看到树木被点着了才知道是篝火还是火灾。

即便端侧有能力干预拥塞丢包，也很难识别这种丢包。虽然很难很粗糙，但我们假设端到端算法有能力检测丢包，但算法能做到的仅此而已，它只能判定丢包事实(虽然也有误判)，却无法得到丢包的原因：

如果随机丢包，保持现状重传。
如果拥塞丢包，降低速率重传。

TCP sender 只能通过观察 RTT，RTT 抖动，有效吞吐等信息来猜测丢包的原因并做出相应决策，而这些二手信息并不可靠。BBR 采用 “观望一会儿看看”(10-round maxbw-filter) 的策略(BBR2 采用了更锉的方案，引入一个丢包率，大于这个比率才反应)，如果真着火了，火很快就会蔓延，如果不是，就什么都不做，这种策略显然代价高昂。

一种更有效的方法是通过 receiver 主动通告更精确的信息而不是即时反馈裸事件给 sender。比如 receiver 反馈即时接收速率以及速率的变化而不是为每一个或每几个接收段生成一个仅为确认的 ACK，这不是 TCP 的方式，但它显然比 TCP 更有效。

TCP ACK 最开始是为可靠传输而不是被 sender 用来测量连接指标的，否则不会引入模棱两可的 delayed ACK，这个问题一直持续到今天。

ACK 发送过多但携带的信息量一点也不多，反而会引入反向路径干扰以及 cwnd 糊涂窗口。

ACK 发送频率过高，导致每个 ACK 释放的 cwnd 空间过快且小，而 SACK 需要非 delay 立即发送，这加重了重传时 cwnd 糊涂窗口，高频但少量消耗 cwnd，这是个正反馈，非常不稳定的平衡，除非持续主动 capacity-seeking probe，cwnd 很容易消耗殆尽，吞吐下跌。

ACK 携带的精确信息仅是积累确认，而拥塞信息属启发信息，需要注意的是，ACK 不光启发拥塞，也启发抖动，因此 ACK 携带的启发信息误判概率非常大，它本身就是 receiver 侧的二手失真镜像。如果 receiver 没有检测到明确抖动信号，就不应该将一个疑似抖动信号反馈给 sender。

TCP 过分依赖 ACK 时钟造成这个不稳定的正反馈，BBR 也没改善现状。我在 CUBIC 动力学中提出用定时器驱动 pacing 而摆脱 ACK 时钟，但并不适用 TCP，因为 ACK 携带的信息虽少，但它却是 TCP sender 唯一可获得的信息，摆脱不了的同时造成 TCP 反应过于敏感。

如果能换另外一个传输协议，它不应该为每个或每几个接收段生产 ACK，而应该对事件计算信息，将信息进行 ACK，“没有消息就是好消息”，它应该倾向于边沿触发。

多少有点遗憾，QUIC 继承了 TCP 大部分特性，只是对一些明显的问题进行了修补。

…

目前不管在广域网还是数据中心，有两种倾向让我觉得很多人走偏了。

广域网传输，大家希望即使在丢包率很高的情况下依然要保持足够高的吞吐，但如果丢包是固有随机丢包，比如 Wi-Fi 信号太差，做这件事的结果非但解决不了随机丢包，还会引入拥塞，如果人进入电梯了，server 拼命激进发送除了拥塞链路还有什么用呢？

可以想象，提供一个绝对的信号很差的无线场景，或把光纤弯折后再跺两脚的有线场景，绝大多数人的优化手段是用数量补偿质量，几乎没有人放任 TCP Tahoe 什么都不做，可是要知道，TCP 伊始应对的就是这环境。

另一方面，在数据中心，很多人希望传输协议足够完备，虽然 TCP 有诸多缺陷，但在数据中心做传输协议时，大家依然要模仿 TCP 的样子，TCP 有什么就做什么。比如为 TCP or RoCE 引入 SACK 替换 GBN，但实际上没必要。

数据中心链路随机丢包极罕见，而 SACK 在应对随机丢包方面优于 GBN，在链路质量很好时，GBN 足够。此外 SACK 需扫描传输队列，很耗 CPU，而数据中心传输协议的目标之一就是 offloading，解放 CPU，为传输协议实现 SACK 是帮倒忙。怪不得像 lwIP，seastar 都没实现 SACK，也许是偷懒，但确实没用。