Google Swift 与 DC 传输

Posted 2022-11-18 dog250

网络拥塞，默认指转发节点出现了严重的排队现象，甚至队列溢出而丢包。、

但接收端也是一个统计复用系统(通用 OS 均为统计复用系统，比如 Linux)，但凡统计复用系统就是潜在拥塞点，即可套用排队论模型。

人们很少将最后一跳接收端纳入拥塞控制对象，和转发节点潜在的排队时延相比，< 10 微秒甚至纳秒级的处理时延微不足道。 当然，在广域网上尤为如此。

但在 DC 内，传输时延也是微秒级，交换机 buffer 普遍偏小，接收端主机处理时延在整个 RTT 的占比显著提高到不能继续忽略它。

为识别主机时延变化以判断是否主机是否拥塞，Google Swift 提出一种工程化方案，在不同处理阶段精确打点时间戳：

基于这些精确的时间戳，Swift 可分别追踪 “网络时延” 和 “主机时延” 的变化，便可维护两个拥塞窗口，fcwnd 代表网络拥塞窗口，ecwnd 代表端主机拥塞窗口，取 min(fcwnd, ecwnd) 为最终拥塞窗口。

想象一下 Swift 能应用在 TCP 吗？

必然不行，TCP 没有空余的空间保存时间戳，说到底还是 TCP 表达能力弱，反馈信息噪声太大，而这噪声是固有的，由 TCP 头的表达能力决定。

DC 网络继续使用 TCP 有很多弊端，长流传输场景与短消息完全不同。试想你在自己的城市里生活，每当决定要去哪里时，都是直接快去快回，但如果是去一个长途的地方，就需要事先 “连接”。

DC 网络很少有流式传输，基本都是 Request/Response 这种短消息模式，RPC 是个典型的例子。

幸运的是，既然 DC 网络不适合使用 TCP 做传输，部署一个非 TCP 协议并不是难事，全在 DC 内部自主可控。比方说 ECN 就很高尚。和 RED 不同，ECN 以一种告知而非惩罚的方式传递拥塞信息。这机制也只适合拓扑简单，链路跳数短的传输，在 Internet 上是不可想象的。
不拘泥 TCP/UDP，DC 可各种花式传输，依赖交换机的 ECN，INT，QCN，PFC 只是冰山一角，丢包，ECN 打标是常规做法，自研交换机还可以往数据包头里加字段，裁掉 payload，只留报头返回给发送端，或者像运载火箭一样，没用的信息 cut 掉，不一而足。

总之，DC 网络不拘泥 TCP/IP 的端到端原则就是了，相比 Internet，DC 网络无需过度关注新节点接入成本。

但也不能矫枉过正，TCP 不是一无是处，无论对于 Internet，还是对于 DC，都不存在所谓的替代者或者下一个。对于 DC 传输，如果要传输短消息，你是换个协议，还是继续使用 TCP，当然首选后者，只是需要改个小配置：

• 将 init cwnd 提升到 30～50 (拍的数据，总之稍微增大，根据短消息的大小和 FCT 做统计分析，选 P99 最好的那个)即可。

看，这是不是和 Aeolus 的思路差不多，第一笔数据突发，事实上大多数传输也就仅这一笔数据，赢了稳赚，输了回退到重传，用 2 个(或 3 个，总之不会太多) RTT。

随便写写。

浙江温州皮鞋湿，下雨进水不会胖。