上午跟一个朋友聊拥塞控制算法，我问他 “你真的需要拥塞控制吗？”
脱离业务场景谈拥塞控制算法的下辈子还是经理。
被捧为圣经的《tcp/ip 详解(卷 1)》将 tcp 传输分为 “交互流”(比如 telnet，ssh) 和 “块流”(比如 ftp 文件下载)，虽然这种简单的分类现在已经不合时宜，但用不同的方式对待不同的数据流却永远正确。
前面说过数据中心传输，要将大象流和短突发用不同的网络切片隔离，广义上就是将数据流按突发时长分类，就是为了让场景隔离，但广域网核心的中立性原则使这种隔离并不现实，那就只能在端侧做场景区分，这也是端到端算法的初衷，可反过来在数据中心搞端到端就扯了。
简单总结，广域网用端到端算法区别不同场景，数据中心靠虚通道区别不同场景。
我简单梳理一些典型场景。
- 交互流，比如 telnet，ssh，im 聊天，数据量少，强调反应和实时性。
- 控制，信令流，比如 iot 传感器采集的数据，边缘计算信令，数据量少，强调实时性。
- 网页浏览，比如文字，图片类，微信公众号，头条新闻，数据量中等，强调首屏时间。
- 电子邮件，如有附件，数据量不定，附件下载强调下载总时长，需要 capacity-seeking。
- 音频流，数据量中等，速率稳定，支持有损，无需 capacity-seeking。
- 高清视频流，数据量大，速率高但稳定，支持有损，可结合编码和 qoe 卸载传输压力。
- 数据搬迁和备份，数据量大，要求无损，传输总时长要求低。
- app 下载和更新，数据量不定，要求无损，传输总时长要求低。
- 科研数据分发，数据量大，要求无损，传输总时长要求高。
- 直播，远程会议，数据量大，支持有损，但大部分都是静态背景，可结合编码和 qoe 卸载传输压力。
- 远程医疗，数据量大，要求无损，要求实时。
- 金融交易，数据量小，要求无损，要求实时。
- 内容预分发，数据量大，要求无损，传输总时长要求低。
- 游戏，数据量取决于玩家，要求无损，要求实时。
- …
所有这些几乎又都可归到双向交互，批量传输，实时流传输这种分类方式，无论如何区分场景，有悖于常识的是，随着带宽的提高，对待传统大象流的拥塞控制算法越来越不起作用了，原因是：
- 带宽越大，腾空 buffer 的时间越短，拥塞信号越来越不准。
- 接入节点越多，app 越丰富，数量种类越多，人们单位注意力时长越短，内容传输时间越短，传统拥塞控制没有足够时间收敛。
- 人们逐渐明白结合编码和支持有损来卸载传输协议压力是重要的，比如直播，开会场景，大部分只有头，手在动，实际有效数据量并不大。
我们也发现短视频逐渐取代了长视频，7 分钟电影解说取代了电影，在被信息淹没的时代，人们很难在单独一份数据上保持几分钟甚至十几秒以上的注意力，其实这现象在信息时代以前就早已有之，流行歌曲只有 3 到 5 分钟不光受早起介质限制，还和人的保持注意力的时长有关，进入磁带时代后，循环播放倒带子时间也不能太久。
把人的注意力想象成带宽，各类内容就是企图抢占这种带宽的数据流，核心就是抢占人的注意力时间，人们的 mark，收藏行为相当于这些数据流在人的注意力这里 buffer 起来了，只有实际去读，去看了，才算获得了带宽。这种暗喻下，随着内容越来越丰富，人的注意力会被切割得更细，没有什么理由提供大块数据通过长时间传输的必要。
有趣的点就在这里，大部分要求实时性的数据流都很短，这种假设下，数据量大的情况也不多，而数据量大的场景，比如内容预分发，数据搬迁备份，软件升级等对实时性要求并不高。除了个别的科研，远程医疗等场景数据传输之外，其它场景要么流很短，要么不过分在乎吞吐。
如果一个短视频只有 30 秒，几百 MB，bbr 撑不过 2 次 probertt，如果是一个 1GB 的附件下载，有谁会在乎它是 30 秒完成还是 29 秒完成呢。
把这个问题想透了，我们发现其实我们一直在用 1990～2010 年移动互联网前的场景映射现在的技术，在当时，人们真的在乎下载下载一个 1GB 的电影是 1 小时还是 1 小时 5 分钟，电影下载完才能看，真是 1 秒都不想再等，如今一部电影 1 GB，可看一部电影至少要 1.5 小时，想想看，2024 年看一部电影所需的带宽比 2002 年还要低，但如果算上人的带宽，还是 2002 年的低，因为那时 1GB 数据需要 1 小时下载 + 1.5 小时观看，一共 2.5 小时。你看，技术也在应和注意力压缩现象。
tcp 内部定时器时间动辄 200ms，1s，rto 不到几次就是一个短视频的时长，tcp 序列号 32bit，足足 4 GB，现在哪有这么大的数据经常要下载，要真有，为什么不用多个连接。
为什么不能把多个短视频捆入一条流，这不就是个长流了么，反正人们看短视频是一个一个刷的，观看总时长并不短。这是典型的削足适履，如果真这么做了，那就必须让这些短视频同源，如果不这样就要钻隧道，这显然增加了约束和复杂性。
我们要知道什么场景用什么策略，而不是设计一个所谓通用算法或称什么通用框架，要么就是虚构一个我以为的场景然后去水论文。比如在小数据量无损交互场景，很多 tcp 特性都是多余甚至有害的，比如 nagle，delayed ack，而且根本不用任何拥塞控制，这种情况应该关注重传，为了让 tcp 尽快应答，甚至可以尾随一个乱序报文而无需担心浪费带宽，tcp receiver 也应该能感知这些，比如看到一个小于某长度(比如 1000B)的报文就立即应答。
在设计新协议的时候，如果把这些 tcp 的特性不假思索全部照抄还说是拿来主义，显然就教条了。
其实，我也不知道那些死抠每一个字节的长流算法到底在适配什么场景，如果一条流真的能持续足够久，那稍微慢一点点的时间在总时间的占比更微不足道，更久的传输时长本就是一个现成的松弛策略。对于绝大部分短流，app-limited 表现并不弱，对于首屏，增加首窗大小，怼出去就是了。
先说到这，
浙江温州皮鞋湿，下雨进水不会胖。