应用程序 App/QoE-Based Congestion control

分层协议栈层内自决意味着拥塞控制逻辑在传输层闭环。保持优雅代价是降低效能，不可不察。

比如，TCP 检测到拥塞后降低 cwnd，传输速率因此而颠簸，需传输的数据总量却没有改变，应用程序端到端总有一个环节出现数据堆积，最终还是要传输固定量的数据，只是产生了延迟，这对流媒体传输尤其不利。

再如，BBR 为保证其状态机转换，不得不每隔 10s 进入 ProbeRTT 致 inflight 降为 4，这意味着 BBR 本身就是一台不匀速的引擎，动力定期抖动，就像铁轨或高架桥上存在接缝一样。

铁轨和高架桥的接缝不可规避，但拥塞控制可以。

不在传输层降低 cwnd 或降低 pacing rate，将拥塞控制事件及相关数据反馈给应用程序，应用程序自行决定降速，分流，服务降级，甚至丢弃一些数据，自然就解除了拥塞，这种做法可维持平稳的 pacing 间隔，保证 QoE。应用程序需要做的是准备多套数据，在不同程度拥塞时实时切换。

带宽固定，流越多，每流可用带宽越少，体现在每流影响上，如果每流依然坚持传输数据量不变，势必造成延时增加，拥塞维持，如果传输数据量下降，则可压缩时间，解除拥塞。对流媒体，完全可接受码率换流畅，对文件，可用多路径分流保证无损。

若拥塞由高并发引发，优待哪条流或惩罚哪条流都不合适，拥塞公平性也一直是难题，如果每条流承载的应用程序自行降低服务等级，传输数据总量均匀下降，拥塞缓解。

对于拥塞降速场景，高尚的做法是无级变速，但 AIMD 显然不是，BBR-ProbeRTT 也不是。显然只有应用程序拥有完成无级变速所需的信息。拥塞控制由传输层自决转换成了应用程序自决。

OK，大致就这个意思。下面说点悲伤的。

应用程序不仅能做拥塞控制，还可引发拥塞崩溃。想想 TCP 拥塞崩溃是如何发生并如何被解决的。

当 Buffer 瞬时堆积，Host 尚未采集到已经暴涨的 RTT 前屡次超时，越来越多的报文副本灌入网络，引发拥塞崩溃。解决方案是报文守恒，禁止多余的报文副本进入网络。AIMD + 退避 RTO 可解拥塞崩溃问题。

若多条 TCP 共享带宽，按现代 TCP 拥塞控制机制，拥塞崩溃是可避免的。最坏的情况是随着流增多，每流分配的带宽越来越小，但不会引发高重传，拥塞控制算法可以自适应该情景。

但传输层着手控制拥塞时，应用程序超时断开呢？很明显前面的数据并未丢失，只是延迟，由于应用程序配置了更小的超时时间，所以连接断开并提前重试，应用层复现了 1986 年的拥塞崩溃。关联本文前半部分，问题在于传输层和应用程序没有互通有无。

应用程序只知超时时间以及数据总量，却不知拥塞，应用程序有权在任何时间断开连接并重新发送数据，这行为可能抵消底层拥塞控制算法的努力。

总结：

各种传输层拥塞控制算法都表现得不尽人意，在我看来不是算法不好，而是要么做的太多，要么做的太少，本质上都是信息不够。无论是锯齿状的 Reno/CUBIC，还是心电图模样的 BBR，对于流媒体传输这种只需要一条直线的场景，都表现的不好，何不让应用程序自己做拥塞控制呢？有人要保持优雅，有人要保证高效，你选哪一个？有人说应用程序自决无法保证公平，有人担心恶意应用故意误用机制而挤占带宽...总之就是权力扩大后如何控制权限的问题，但事实上，难道不是保证应用的 QoE 才是终极目标，而不是全局公平性吗？平日的一些想法，周末写下。

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

（编辑：91站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!