做网站去哪里找t和p在一起怎么做网站

实时突发很难控制，因为 “实时” 和 “突发” 相互斥。实时要求避免排队，而突发必然要排队，最终的解决方案都指向找一个公说公有理，婆说婆有理的中间点，这并没解决问题，只是权衡了问题。

这种局部解决问题的例子遍地皆是，BBR 就是一例。号称 pacing rate control 替换 cwnd 有效抑制了 bufferbloat，但为了支撑 BBR 状态机，ProbeRTT 引入了周期性 send-buffer 的 bufferbloat，因为在 ProbeRTT 期间，应用程序的数据必须暂存在 send-buffer，进而引发 bufferbloat。BBR 并没有解决 bufferbloat，只是转移了它。我的具体解法参见 BBR 动力学观感

本文介绍一个控制实时突发的方法。

多路径传输不宜用于优化网络传输性能的手段，但可以由于提供路径备份以增强网络可靠性，也算是正向收益，除此之外，它还可以用于吸收网络突发，这是不易想到的点。但如果跨界看下别的方面，这偏偏又是最容易想到的点，毕竟宜疏不宜堵的自然方法论在自然界已经被见证了千万年。

互联网经理们思想太过局限不够狂野，提到多路径就是聚合带宽，提到抖动就用 buffer 平滑，要么提出一个有的没得形而上论点去除抖动，其实他们不知道，统计复用系统，抖动是客观的，就像 “世界是物质的” 一样客观。很少有经理哪怕去重组一下多路径，带宽，抖动，buffer 四者，用多路径平滑抖动，这不又是一篇可以参卷的论文么？

网络中的突发无法预测，似乎只能通过路径上的 buffer 来平滑，就像大坝一样，但如此一来则必然引入延时，所有的研究都在突发和延时之间做加减乘除的交易，毫无例外。

另一方面，近来兴起的多路径传输全部聚焦在提高聚合吞吐，可靠性以及负载均衡等目标，多路径似乎就是一个全有或全无的逻辑，但理论和实践表明，多路径传输非常不可控。

重组这些逻辑组件(方法论来自《技术的本质》[布莱恩·阿瑟])就是高尚的。当没有突发流量时，用单路径传输，遭遇突发流量时启用多路径实时分担剩余流量，仔细看，这是一个多么自然的方式，从溃坝，溃堤到脑出血，从长假景区，春运火车站到年前超市的临时服务点，无论自然界还是人类社会，无一例外都自发采用这种模式应对超额突发。

本质上，传输路径也是种 buffer，和路由器串行的内存 buffer 不同的是，它具有时间延展性，可以理解为一种并行 buffer，好处在于，缓存数据的同时，它还能往前走。那么当数据突发发生时，发送组件几乎肯定能检测到某种阈值越界而 “溢出”，只需要计算下面的值：

$T_{\mathrm{arrive}}=T_{\mathrm{MainQueueWait}}+\frac{\mathrm{MainRTT}}{2}=\frac{\mathrm{MainQueueLen}}{\mathrm{MainDeliveryRate}}+\frac{\mathrm{MainRTT}}{2}$

然后在分担路径中选择一个满足 $T_{\text{Sub\_arrive}}=\frac{\text{SubQueueLen}}{\text{SubDeliveryRate}}+\frac{\text{SubRTT}}{2}$ 的路径即可。既然是突发，当它发生时，SubDeliveryRate = ?，SubQueueLen = 0，只要知道 SubRTT 就能计算，不必太精确，随意选择一个近似满足条件的路径即可分担突发，receiver 要做的只是稍微增大接收 buffer，如此一来即可不损失延时而获得平滑突发的效果。

只近似而不求精确计算的考量在于，相比堵在静态 buffer 排队，把数据 schedule 到其它路径至少保证它随时间前行，延时肯定降低，同时又可省略甚至涉及编解码的机巧复杂但注定不准的启发式算法，反正怎么都算不准，干脆就不算，直接取近似(猜硬币正反面，随机蒙正确率最高)，所以我可以直接算 $T_{\text{Sub\_arrive}}=\alpha +\frac{\text{SubRTT}}{2}$，其中 $\alpha$ 取适合网络并足够小的常量，比如 DCN 取 5us，WAN 取 5ms，诸如此类。

只要 “溢出” 不再，立即停止分担路径，回归单路径，如此反复。

上善若水，下流至贱，突发洪水泛滥，蔓延出小流，洪峰后随即干涸，顺水流之自然性，有路就让它流走，否则必有害处。“天下莫柔弱于水，而攻坚强者莫之能胜”，“流水之为物也，不盈科不行”，“行于地中，流而不盈”，大禹，老子孔孟之天道，经理们未必真明白。

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