再看一遍最传统 TCP AIMD 吞吐的推导:
这个积分用离散求和表示很简单,一个锯齿发送的报文总数为:
( W 2 + 0 ) + ( W 2 + 1 ) + ( W 2 + 2 ) + . . . ( W 2 + ( W − W 2 ) ) ≈ 3 ⋅ W 2 8 (\dfrac{W}{2}+0)+(\dfrac{W}{2}+1)+(\dfrac{W}{2}+2)+...(\dfrac{W}{2}+(W-\dfrac{W}{2}))\approx\dfrac{3\cdot W^2}{8} (2W+0)+(2W+1)+(2W+2)+...(2W+(W−2W))≈83⋅W2
一个锯齿丢一个报文,求丢包率:
p = 1 3 ⋅ W 2 8 = 8 3 ⋅ W 2 p=\dfrac{1}{\dfrac{3\cdot W^2}{8}}=\dfrac{8}{3\cdot W^2} p=83⋅W21=3⋅W28
设往返时间为 T,一个锯齿的时间为:
D = T ⋅ W 2 D=T\cdot\dfrac{W}{2} D=T⋅2W
假设一个包中的数据量为 K,则吞吐量 R 为:
R = 3 K W 2 8 D = 3 K W 4 T R=\dfrac{3KW^2}{8D}=\dfrac{3KW}{4T} R=8D3KW2=4T3KW
将 p 代入,得:
R = 1.25 K T p R=\dfrac{1.25K}{T\sqrt{p}} R=Tp1.25K
这就是最传统的 TCP 吞吐公式。
只要你的传输协议理论吞吐(T 一样)比它大,你的协议就很难被标准华文档(BBR 持续停留在 Draft 阶段很大程度因为此)接纳,更严重的是,这个公式是脆弱的,不保真的。此话怎讲?
上述公式是没有任何噪声丢包和链路误码丢包的前提下推导出的 TCP 最高吞吐率,即丢包完全由 buffer overflow 导致。然而实际链路难免会出现误码丢包,因此该公式是要打折扣的:
R = 1.25 K T p + p N R=\dfrac{1.25K}{T\sqrt{p+p_N}} R=Tp+pN1.25K
其中 pN 为噪声丢包率,链路越长,噪声丢包概率越大。对应到上面的图示,假设范雅各布森管道中 buffer_size = BDP,如果加上与 p 相等的 pN,相当于 buffer_size 减半了,即明明是一个 deep buffer 链路,由于出现过大的噪声丢包,大量的 buffer 是无用的,对 TCP 而言等效于一个 shallow buffer 链路。
由于现实中存在大量多年前部署的 “传统 TCP 服务”,因此去抢占这些倚老卖老的旧服务的带宽是不光彩的,也是不讨好的,除非说服它们升级到一个对新事物更加公平的支撑平台,比如 5.4 以上的内核 + BBR/Quic。
另一方面,提高物理链路的可靠性是一劳永逸的,最大限度降低噪声丢包率,尽量给传统 TCP 这些脆弱的老家伙们舒适的环境,使它们的吞吐无限接近上述公式里没有 pN 的 R,但在这些老家伙身上再动大手术是不合适的,比如优化 CUBIC。
下层对上层提供服务本就是协议栈所以为栈的一部分内容,提供优质服务更是逐渐成为刚需。因此不要再将 “TCP 在劣质链路提供可靠服务” 的假设作为上限,而是反过来督促底层链路的优化。“能用就行” 在早期筚路蓝缕,以启山林,但如今的这种假设不再合适。
从广域网说到数据中心,在这里发生着一件类似的事情,指望 PFC 提供无损网络类似于 TCP 之于劣质长肥管道,Pause 帧是一种兜底,但不能用于优化,就像 AIMD 不能用于优化传输吞吐一样。如果本末倒置,事情就会变得越来越复杂。
扩容,增加带宽,优化收敛比就能解决大部分问题,非要引入 PFC,随着端网卡带宽增加,BDP 增加,PFC 所需的 buffer 持续增加,时延以及时延抖动持续增加,此外,PFC 解决不了链路误码丢包问题,最终还是要端主机 GBN 兜底。
在数据中心传输优化这条路上,特斯拉的 TTPoE 显然是正确的,因为它先天假设了一条非常良好的底层链路,因此它不断最减法,不断简化,就像当年 TCP 假设了一条非常恶劣的底层链路,只能不断做加法,不断复杂化的反面一样。
昨天的文章里说了一句话,大自然是和谐的,当一件事变得越来越复杂时,大概率就是路线错了,如果一个结论不美不封闭,可能就是来自错误的路线。我跟八年级女儿讲,在解一道数学题时,如果中间步骤出现了丑陋繁杂胶着的无理数运算,几乎就已经错了,这是一个真理。
浙江温州皮鞋湿,下雨进水不会胖。