曾倾向于优化异常流的做法竟然最保守，异常是小概率事件，处理它只保障可用性，而不是优化性能，恰恰需要加速大概率的正常流处理，数据中心传输优化投入大量精力在丢包检测和重传上的思路需重估。
为 1% 的可能性而增加的 if 判断，将给 99% 的逻辑增加指令周期，对数据中心这种主机处理时延占比很大的场景影响巨大。我为什么一开始极力为数据中心传输增加 sack，后来又为此而忏悔，原因正在于此。
其实丢包并不可怕，也不怕丢包检测和重传，应该惧怕的是 TCP 那个 AIMD 中的 cwnd = cwnd / 2，即过激反应。
一毫克毒药就能毒死人，但没必要为避开毒药，每顿饭都毒检，我们需要解药。但这似乎又和 “别让拥塞发生，而不是拥塞了之后去恢复” 相违背，正确的做法是减少对异常的过激反应，集中优化正常流，我们既不能每顿饭都毒检，也不要找解药，但异常必须反应，严重后果可能真的就过激，此时需要依靠自身免疫。这种方式的极端就是过度免疫的 BBR。
BBR 属大开合算法，也就是王八拳。BBR 高吞吐依托的大开合招式有 “maxbw-filter 足够持久，乘性 probe 足够频，cwnd gain 足够大”，这些不涉及精细控制，几乎无需任何 if 条件判断，全属上述 “正常流下的优化”，但 BBR 有些过度免疫，以至于它几乎不对任何 event 做哪怕合理的反应。BBR2 认识到这一点，引入对丢包的反应，但吞吐也降低了。所以 BBRv1 并非一个合适的算法，大摆拳固然厉害，却上不了台面。
BBRv2 稍回归，你会发现，只要回归了正常，就再也看不到 BBRv1 那种秒杀的效果。
当把所有条件都加上，效果就差不多了。经常有人说 UDP 比 TCP 快得多，我说你给 UDP 加上可靠和保序后看看还剩多少优势。最终你会发现绕了一圈就是拆东墙补西墙，怎么都不行。
所谓优化，是一个把约束换成假设的过程，但假设在多大程度上意味着承诺，取决于你有多少信息量。
以丢包重传为例，总有人比较 FEC 和 ARQ，但其实两者是等价的，不同手段而已，FEC 用空间换时间，ARQ 用时间换空间，但如果没有精确信息区分拥塞丢包 or 随机丢包，两者都换不成。如果很确定是随机丢包，则 FEC 则用冗余的带宽代价换来了时间不浪费，而 ARQ 则花费一个 RTT 重传后 restore cwnd 而不浪费带宽。两者都 OK。但如果拥塞丢包误判为随机丢包，FEC 和 ARQ 均加重拥塞。问题的关键并不在 FEC 和 ARQ 哪个更好，而是你如何区别丢包的原因。
如果被承诺一条完全不丢包的链路，传输协议就可以卸掉丢包检测和重传逻辑，这将极大优化性能，这意味着端到端优化不如优化下层来得划算，即使链路只是承诺不会轻易丢包，传输层也可用 unlikely 加速异常判断。
越下层的承诺收益越大，并不是简单将上层问题推到了下层：
只有 A，B，C 同时丢包，才等价于一次 S-D 端到端丢包，而底层链路丢包是 “or” 关系，全部丢包的概率极低。
这意味着提供好的底层支撑要远好于提供好的端到端算法。
回到开头点个题，有好的底层支撑，上层才能更好地假设，将时间片更多用在正常流，而非异常流处理。
最高效的优化就是提供一条好链路，从而可以依赖这条链路的承诺而做出假设。
浙江温州皮鞋湿，下雨进水不会胖。
