特斯拉的 ttpoe 出来有一段时间了，不出所料网上一如既往的一堆 pr 文，大多转译自 演讲 ppt 和 Replacing TCP for Low Latency Applications，看了不下 20 篇中文介绍，基本都是上面这篇文章里的内容，车轱辘话颠来倒去。
我也大致看了一下 ttpoe 在 github 上的代码和 spec，好家伙，真是大道至简(仅 17 页 spec，每页大量留白)。抛开商业相关的不谈，仅从传输优化的视角，本文谈点方法论。
说起传输，要分场景，一般我会区分数据中心和广域网，我早说过，数据中心不是互联网，广域网才是，怎么看这个说法呢？
数据中心看 pcie，它是主机的延展，需高速 link 连接不同组件，而广域网看 tcp/ip，它是独立的主机分布式通信。拿一把尺子量一量，长管道和短管道哪个增加截面收益更大且工作量更小，高下立判。
因此，数据中心重资源，广域网重算法。资源和算法，又是辩证的两面。
从性能优化看，协议和算法决定了资源利用率，兜住性能的下限，而资源本身才决定性能上限。换句话说，协议和算法让性能不至于太难看，而优化则需要增加资源。
“道生之，德畜之，物形之，势成之”，这是《道德经》里的话，以 tcp 为例，rfc793 谓之 “道”，sack/wscale/ts/reno/cubic/vegas/bbr 谓之 “德”，运行在某台主机上的 tcp 连接实例谓之 “物”，而带宽，光纤，路由器，交换机，供电设备，机房环境谓之 “势”，大概就是这个意思。
具体而言，想优化性能，需要的是 “势”，即资源。
而 “势” 和 “德” 又相互作用，在一个高尚的环境，人们便不需要过度宣扬德行，同样，在一个带宽资源足够丰盈的传输环境，传输算法就可以相对激进而不必过度谨慎。
带宽足够大时，传输算法就可以相对激进，比如可以使用 gbn 来恢复丢包而不必担心会浪费带宽，首先带宽是充足的，其次，带宽充足时丢包是罕见的，因此经得起 gbn 的少量浪费。一个反例，pfc 则是希望在一个资源一般的场景用算法构建一个无损网络，显然就是错误的做法了。
再联系 sack，早期 tcp rfc 793 满足了基本的可靠传输，但在一个资源简陋的高丢包环境 gbn 显得很不节约，于是 sack 避免了本就不丰富的带宽浪费，但如果一个网络好到丢包率小于 0.01%(约数) 时，sack 就没必要了。
ttpoe 所谓大道至简就是遵循了重资源轻算法之道，因为它是跑在好网络上的。ttpoe 的逻辑非常粗暴有效，看 receiver 如何处理：
/** Per TTP_Opcode spec:-* [OPEN] / [CLOSE_SENT] / [CLOSE_RECD]* TTP_ACK TxID <= local RxID* TTP_NACK TxID > local RxID* TTP_NACK_FULL local is temporarily full* [CLOSE_SENT] / [CLOSE_RECD]* TTP_NACK_NOLINK TxID > local closing ID <-- ** NOT IMPLEMENTED YET ***/
通过引入 nack operater，sender 就简化了：
nack 直接取消了 sender 所有预判逻辑，让一切启发式算法再无必要。按常规 tcp 早期逻辑，需等 3 个 dupack 触发重传以适应 reorder，后又用 rack 取而代之，不管怎样，预判的代价是时间。而 ttpoe 明确回复 nack，这部分时间节省了下来，代价转移到了 nack 误判后的不必要重传，辩证正在此处展现。
前面提到 tcp 之所以采用启发式预判，并采用一切手段追求预判精度，原因就是带宽匮乏，就是要节约，因此必须谨慎。而 ttpoe 的假设是它运行在足够好的网络上，丢包是小概率事件，一旦丢包，用积极激进的方式快速应对，而代价的交换方正是充裕的带宽。
这里不得不提到的是 ttpoe 的 packet retired 特性，让人联想到处理器的 instruction retired，大意是，处理器利用当前空闲的计算单元，提前将多个分支数据准备好，不管最终逻辑进入哪个分支，都可以直接使用。这意味着有大量指令是白白执行的，但 instruction retired 却作为一个特性而不是一个 bug 被广为人知。ttpoe 的 retired 特性非常类似。
当 sender 收到 ack/nack 时，ack 指示 dealloc，nack 指示重传，sender 可以任意方式调度 send-buffer(类似处理器 instruction-buffer) 发送，大不了就是在高带宽下微不足道的不必要传输，但收益肯定是低时延。
在上述前提下，用固定 buffer-size 做 cwnd 就顺理成章了，因为实属无必要动态计算 cwnd 引入复杂性，问题是十有八九还算不对。整个 tx buffer 固定，ack 一个 free 掉一个方可进入一个，维持持续滑动，而 win-stall 是很难的，因为丢包概率低，万一丢包，重传非常激进。
延展几个 argue 的点：
- 固定 cwnd 试过，效果不好：不是固定 cwnd 这个做法不好，是你的带宽不够大，数据流不够规则；
- ttpoe 在复杂的网络环境无法自适应：ttpoe 不是在动态网络环境中用的，不要指望它用于无线环境；
- ttpoe 不就是 udp 吗？：udp 还要 ack/nack 干嘛？另，ttpoe 无 ip 直接跑在以太网(oe)，协议号 0x9ac6；
- ttpoe 高带宽，低时延：没有任何协议可以用资源的属性特征来描述，凡是标榜于此的都有 pr 嫌疑；
- ttpoe 低时延来自于硬件实现：硬件省不了大头，低时延来自于它的部署环境足够好，它省了很多烦恼；
- 这高档鞋子能跑步吗？：皮鞋不能跑步，再贵也不能。
从 srd，homa，falcon，… 一直到 ttpoe，它们 ppt 的前几页无一例外都在喷 tcp，旨在 replace tcp in datacenter，人们也人云亦云，这些车轱辘话听到耳根发麻，直到最近理解 tcp 为什么那么不堪的人依然很少。
tcp 的不堪祸首在于资源不足，其次才是它的实现复杂，而它的实现复杂又来自于它本就是应对资源不足的环境。但 tcp 的自适应力极强，放在 100gbps 的网络，它真就能跑到接近 90gbps，想想看 tcp 是携带那么多好网络根本用不到的应对坏网络的特性大负重跑到接近 90gbps，这个情况下不是要重复造轮子取代它，而是为 tcp 减负，做减法。
好网络下的 tcp 卸载掉谨慎的特性便不再需要复杂的实现，唯一的不堪也不复存在。撤掉 sack 换 gbn，撤掉重传触发启发换 nack，简化 cc，大概就是 ttpoe 了。
至简之道就是做减法，因为只有减到不可再减，才能重新再做加法。回头看主机总线，优化方向一直是加频率，加 lane，加并行度，无止境增加传输带宽，而不是依靠精巧的算法，因为它有个可以 “二生三” 的极简核，才能彼此互联而不会把自己绕死。世界的另一面，广域网，它也有一个 “二生三” 的极简核，IP 协议，主机传输层只能采用端到端算法才不至于污染这个极简核，然后三生万物。
“道生一，一生二”，数据中心和广域网各有不同，被大道统一于至简，在各自方向 “二生三，三生万物”。
浙江温州皮鞋湿，下雨进水不会胖。
