TCP 真的不合时宜了吗

前文 谈谈网络流量控制 谈到了以太网，本文谈它同年的 TCP。

近年来，越来越多观点指向 TCP 已不再合时宜，各种新协议被提出，各大厂都在自研新的或魔改已有的传输协议(比如各种 QUIC)，号称能解决 TCP 的一个或几个固有问题。每当出现这种势头，我就有缕一缕的想法。

数据中心场景不谈，那种可控环境中，确实可以部署新协议替代 TCP，理由也非常充分，挥洒的余地也多，但在广域网，就没那么简单。

说起 TCP 不合时宜，我此前写过一系列文章，但今天这篇不是为了自己打脸，而是从行业内总拿 TCP 不适合流媒体传输展开说：

• TCP 拥塞控制倾向于填满 buffer，bufferbloat 问题；
• TCP 不能柔性容忍丢包，而重传必然引入延时；
• TCP 在系统内核实现，不好改；
• …

初看这些都是硬伤问题，细看却都是硬造出来的问题，来，细说。

很多人对 buffer 有一种矛盾的执念，说起防丢包，buffer 恨不得越大越好，说起超低时延需求的满足，buffer 似乎就成了原罪，不依赖 buffer 反成了卖点。对时延理解不到位导致了这种矛盾的认知，假设一条从广州到上海的直连链路，传播时延 10ms，没有任何人叫，但将源搬到厦门，缩短一半传播时延到 5ms，棒极了，但再加入 5ms 的 buffer，很多人就不乐意了，他们只想着这 5ms 只要拿掉 buffer 就能取消，却想不到这个 buffer 带来的 5ms 的代价能换取什么收益。

这是对抖动的误解，统计复用系统中抖动是固有的，独立流量数据的任何分布都会有期望，均值，方差等属性，长程依赖的自相似流量虽然更可预测，但依然没有任何技术可以消除抖动，只有 buffer 可用时间平滑它，水坝的例子不再赘述。

换个说法，实时系统若要无抖动，必须在应用层和传输层之间加 buffer，代价是引入 buffer 延时，能控制的只有 buffer 大小。receiver 通过观测 buffer 水位，在一个更大(大得多)的时间尺度上通知 sender 多发点还是少发点，而在 sender 的传输层看来，这与传统的大文件传输没什么不同，再不用关注它发送的是什么。buffer 解除了传输速率和实时速率(比如播放速率)之间的耦合，想想看，传输层摆脱了实时传输需求的约束，丢包检测，重传都交给原生 TCP 即可，TCP 做不到最优，但在 buffer 时延的掩护下，够用，系统设计因此变简单了。

再看柔性丢包以及一系列相关问题。首先，如果数据流是压缩流，解压缩需要底层传输是无损的，然而对于很多视频流，P 帧可随意丢但 I 帧丢了代价就很大，若紧密化 I 帧，整个视频流就会变得更大，消耗带宽也更大，若稀疏化 I 帧，万一丢了就引入很久的卡顿，这会带来很复杂的算法需求，促进更多工人经理卷绩效，不停开会讨论，设计，编码，灰度，拨测，迭代…。但如果在上段提到的 buffer 下面直接用 TCP，什么事都不用做了。至于 TCP 不能丢包，丢包干什么，收到再丢掉就意味着能耗浪费，通知 sender 降码率少发一点不是更好吗。buffer + TCP 可以容忍更稀疏的 I 帧间隔，这意味着对带宽的节约。

buffer 固然引入时延，但不能保证自研协议一定做得更好，多数是卷活儿水论文开大会罢了。

面向 buffer 做实时应用，而不是面向传输，buffer 把应用和传输隔离了。那么，buffer 多大，或如何控制 buffer 水位阈值就成了唯一问题，这就与 TCP 无关了。buffer 水位阈值是带宽，观测时延(RTT)，甚至用户习惯等因素的函数：

• 传输层带宽越大，RTT 越稳定，水位阈值越小，反之越大；
• 用户滑屏，暂停，拖拽越频繁，水位越小(最少浪费)，反之越大；
• 丢包越高，I 帧间隔越大越省带宽，越小越容错，buffer 水位越小；
• …

至于 bufferbloat，TCP + BBR(BBR 对拥塞控制的创新，我是服气的，但它对微观控制的执着，在实际效果上我存疑，任何作用于统计复用系统的算法，都只能在宏观控制层面有效，包括拥塞控制) 已经可以解决问题的大部分，不最优，但够用，buffer 弱化了需求约束的强度。

最后一个问题，TCP 在内核里，不好改。确实不好改，但为什么要改，仅仅为了吞吐，时延？这些问题已经被 buffer 隔离了。

TCP 是一个稳定运行 40 年几乎没被大改过的传输协议，单独拎出来谈它的传输性能，它有很大的改进空间，但基于它构建好的一个系统后专注于 QoE 本身，性能问题就不再是问题，不再值得去魔改和优化，就像千百年来我们不会去优化铁锅，瓷碗以及皮鞋一样，我们甚至注意不到这些东西的材质拥有的缺点，重，易碎，进水会胖。

从传输大文件，远程登录传输终端字节的成功，到如今的流媒体传输，一个最简单最高效的实时系统只需要一套接口，一个 buffer，一个控制 buffer 水位阈值的算法，配合原生 TCP 即可，天然极简。

在性能之外，TCP 可能确实存在分发问题，比如它不能把数据流分发到多个接收端，但这已经不仅仅是传输问题。

和以太网一样，TCP 处处不最优，但做得足够好，部署简单廉价，向下兼容是它们更加关注的方向。它们诞生于 1973 同年(TCP 于次年 1974 年 RFC675 首次标准化)，40 多年来一直有在某些片面号称更优的竞争者(也更复杂，部署更昂贵)欲打着 “下一代” 的旗号取而代之，但没有成功的，这个名单以后还会不断更新。

我经常披露 TCP 天生的问题，但本文却似持相反态度，为消除自我打脸嫌疑，不得不加两段澄清。流媒体等实时系统是一个应用系统，关注 QoE，它甚至都不是网络问题，TCP 作为应用的承载协议是足够的，甚至优秀高尚的，TCP 还将继续成功。而传输协议更关注的是公平性和收敛，TCP 从这个层面的视角看，确实不合时宜了，因为现在网络环境已经和它诞生的 1970 年代完全不同了。

早期的互联网流量多为点到点通信流量而非点到海量点的内容流量，点对点流量或点对少量点的流量组成的网络流量在统计复用网络中是自然收敛的，但随着 Web 的不断增长，内容流量剧增，即使有了 CDN， 少量 sender 侧和海量异构(比如 Wi-Fi) receiver 侧的流量具有了非常不同的统计特征，而 TCP 流量假设下的拥塞控制并不适合这种模型，同时前面提到的多 receiver 分发也是问题，有趣的是，即使这样，TCP 一开始就是 C/S 协议，而 C/S 协议天然就是点到多点，但多到一定程度，反而不适合了。前前后后，左右左右，BA。

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