實時突發很難控制，因為 “實時” 和 “突發” 相互斥。實時要求避免排隊，而突發必然要排隊，最終的解決方案都指向找一個公說公有理，婆說婆有理的中間點，這并沒解決問題，只是權衡了問題。

這種局部解決問題的例子遍地皆是，BBR 就是一例。號稱 pacing rate control 替換 cwnd 有效抑制了 bufferbloat，但為了支撐 BBR 狀態機，ProbeRTT 引入了周期性 send-buffer 的 bufferbloat，因為在 ProbeRTT 期間，應用程序的數據必須暫存在 send-buffer，進而引發 bufferbloat。BBR 并沒有解決 bufferbloat，只是轉移了它。我的具體解法參見 BBR 動力學觀感

本文介紹一個控制實時突發的方法。再遇到微突發，incast 的時候，應對自如。

多路徑傳輸不宜用于優化網絡傳輸性能的手段，但可以由于提供路徑備份以增強網絡可靠性，也算是正向收益，除此之外，它還可以用于吸收網絡突發，這是不易想到的點。但如果跨界看下別的方面，這偏偏又是最容易想到的點，畢竟宜疏不宜堵的自然方法論在自然界已經被見證了千萬年。

互聯網經理們思想太過局限不夠狂野，提到多路徑就是聚合帶寬，提到抖動就用 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，諸如此類。

只要 “溢出” 不再，立即停止分擔路徑，回歸單路徑，如此反復。

上善若水，下流至賤，突發洪水泛濫，蔓延出小流，洪峰后隨即干涸，順水流之自然性，有路就讓它流走，否則必有害處。“天下莫柔弱于水，而攻堅強者莫之能勝”，“流水之為物也，不盈科不行”，“行于地中，流而不盈”，大禹，老子孔孟之天道，經理們未必真明白。

浙江溫州皮鞋濕，下雨進水不會胖。