从历史和文化内涵的视角看 TCP 协议的优势和局限，这些都刻在基因里。节约和经济获得向下兼容，但这也意味着它没有浪费带宽的本意，任何相左的优化策略终将遇到无法解决的困难，大致就这样，这为设计新协议提了意见，别抄 TCP，否则就容忍继承它的一切。
最近看了一份考古文献，来自范雅各布森(VJ)：The original Van Jacobson memo，它讲的是一个正常流优化的故事，即坊间著名的 "30 instruction TCP receive"。
结合相关 RFC 和实现，讨论一下 TCP 的文化内涵。
如果过度关注 TCP 性能，会发现这实际上是与 TCP 的核心思想相违背的，而 TCP 核心思想能用两个字总结："节约" 或 "经济"。
RTO 被认为是个兜底策略，总是被各种优化试图绕开，这是从快速重传(rfc1072，VJ88)开始的，这些优化逐渐模糊并偏离了 TCP 的内涵，给人 "优化可以一直持续下去" 的错觉，现在我们很清楚，很多困难根本无法解决。
VJ 开启了 TCP 优化，但这种优化风格却最终终止了优化，从 RTO 开始，结束于无解的 rate-based cc，大致我们可以看清这个过程。
TCP 作为一个端到端协议，经过多跳收到确认所需时间的概率密度函数图像随着距离的增加越发矮胖，这意味着 RTT 预测非常困难，这是固有的。举例说明，去阳台拿个东西，超过 10 秒就会被催，去 500 米外买东西，20 分钟到 30 分钟都是允许的，因为过路口，排队结账都不可预期，去 30 公里以外上班，1 小时到 2 小时之间都合理。
RTO 最终被确定为：
R T O = S R T T + γ ⋅ R T T V A R RTO=SRTT+\gamma\cdot RTTVAR RTO=SRTT+γ⋅RTTVAR
其中：
R T T V A R = β ⋅ R T T V A R + ( 1 − β ) ⋅ ∣ S R T T − R ∣ RTTVAR=\beta\cdot RTTVAR+(1-\beta)\cdot|SRTT-R| RTTVAR=β⋅RTTVAR+(1−β)⋅∣SRTT−R∣
S R T T = α ⋅ S R T T + ( 1 − α ) ⋅ R SRTT=\alpha\cdot SRTT+(1-\alpha)\cdot R SRTT=α⋅SRTT+(1−α)⋅R
VJ 的著名参数 α = 7 8 , β = 3 4 , γ = 4 \alpha=\dfrac{7}{8},\beta=\dfrac{3}{4},\gamma=4 α=87,β=43,γ=4 多少有些随意，"调得一手好参数" 并不能被人信服，但 "容易计算" 似乎是一个更好的理由，仅用简单的移位，加减就能快速计算正体现了节约和经济，这与文初的引用连接的思想完全一致，这就是 VJ-Style。
粗看起来，节约似乎和优化在结果看来都是 "速度更快"，但也仅仅是结果一致。"更快" 只是节约的顺便，而不是它的目标。这个文化内涵让 TCP 可运行在所有设备上，就像 Linux 和猫科动物，适应所有环境，向下兼容的高尚正由此文化内涵体现，向下兼容确实好。
节约和经济决定了 TCP 的保守。
TCP 尽量少处理异常，因为异常处理需要比正常流执行更多的指令，这意味着节约和经济的反面。如文初链接所体现，要让正常流变得普遍，就要让异常不发生，这决定了传输策略的保守，够用但不逞强。一个具体的例子就是 "重传期间不更新 SRTT"，我前面专门说过这个遗憾源自 TCP 最初的内核，就是上面这段话的意思。同时这也决定了测量 TCP 的 RTT 真的很难，即便如今已经为其添加了那么多 feature，依然摆脱不了这个难题。
另一方面，对指令的节约为我们设计新传输协议也指明了方向，空间换时间，设计更大的序列号空间，避免回绕问题，剪除 PAWS，设计更大滑动窗口空间，剪除 WSCALE，设计更大的端口号空间，剪除端口分配的把戏。
再看看这种文化内涵的背景，摩尔定律，吉尔德定律的曲线即便已经弯折，通信速度的提升仍然快于计算速度的提升，为计算速度而不是带宽来做优化是划算的。软件开发中有一个类似的例子，不要优化代码，而要等待更新的硬件。
在这种背景中孕育的文化的影响下，TCP 不会故意注入更多数据到网络以获得更大的吞吐，因为这种为吞吐而进行的赌博需要更多的异常处理来兜底赌输的情景，这与节约和经济的文化内涵不符。这也是近些年各种为带宽而做优化的算法效果普遍不好的原因，因为这与 TCP 的内核相左，于是人们开始纷纷研发新协议。
让我们再看看现实，马上就会明白为什么 TCP 不再合时宜，也就知道新协议应该怎么做。
网络带宽越来越大，虽然从计算的视角看依然要节约，但带宽却是可是浪费的，于是 TCP 在 2010 年代遭遇带宽利用率不足的问题也就是不足为奇了。我们看一下 VJ-Style 的 loss-based 拥塞控制模型，设 B 为吞吐带宽，p 为容忍丢包率， B = α ⋅ p β B=\alpha\cdot p^{\beta} B=α⋅pβ，这个公式对 p 要求过高了，要想获得更大吞吐，p 必须足够低，低到超过介质的传输误码率极限。
这意味着若要适配高速网络，这个模型必须被废弃，BBR 只解决了理论问题，因为互联网规模已经足够庞大，全网如何平滑切换到一个仅仅吞吐较高但尚未论证稳定性和公平性的算法，风险何其大。
在尚未有能力切换到一个 "完备的下一代协议" 之前，来看 TCP 的解法会存在哪些问题，并给出新协议的建议。
随着网络越加长肥，TCP 反馈慢的代价越大，如果网络过长，拥塞信号至少 1 个 RTT 的反馈时间就显得很慢，而如果网络同时又过肥，这 1 个 RTT 的时间段中 sender 会注入非常大量的数据到网络，从而加重拥塞。CDN 的部署缓解了这个问题，但远未解决。
虽 CDN 已大量部署，但静态资源的需求逐渐减少，随着直播流量占比增加，传统远距离高吞吐认知中的长肥管道拥塞问题会越来越严重。
在本质上，避免反馈的协议才是正确解法，receiver 主导的拥塞控制或许要胜过 sender 依赖的确认反馈，但如何让 sender 对拥塞快速反应，就依赖层间协作了。
总之，不光 TCP，连同整个 TCP/IP 协议族都不太适应越来越高速的网络，和本文前面说的节约的文化内涵一致，这也是整个 TCP/IP-based 互联网的文化内涵，而它源自旨在抵抗核打击的 DARPA。
分组交换带来的收益一定需要付出成本来交换，成本之一就是性能。
so？是层间解耦与高速网络不适应，那耦合它们呢？很难。
幸运的是，这条路在数据中心完全可以走通(infiniband? roce?)，总之，网络越往高速发展，就越不可抗拒地将设计推回到面向连接的电路交换。
范雅各布森的 style 就是 TCP 的文化精髓，谨慎，保守，精细。如果你问 srtt 的 α 为什么是 1/8，rto 的 β 为啥是 4，真是调得一手好参数吗，非也！因为 2 的次幂容易算啊，这不但迎合了低端机器，也迎合了 Linux 内核不支持浮点数，顺便和统计概率吻合而已，只有 1% 的概率超过 4 确定的平均方差边界，道出了统计复用动力学的本质。在遥远的 1980 年代，为计算速度而不是带宽优化，已经开始成了信条，最终成了文化。
浙江温州皮鞋湿，下雨进水不会胖。