2023年的tcp擁塞崩潰事件讓aimd模型在2023年後出來應對時局，從此以後網際網路協議的設計者和實現者聚焦於如何讓網路不擁塞。
毫無疑問，這裡最重要的是公平性，而非效率。不管是慢啟動，加性增窗，乘性減窗，還是後來的vegas演算法的主動退讓，其目標都在於保證多條流經過共享鏈路時能公平共享頻寬。這種機制的目標不是讓單條流跑得更快。
換句話說，2023年的模型是不患寡而患不均的模型。其中的 「不患寡」 給很多人帶來了誤解。
事情在2023年前後悄悄地起了變化。
aimd模型的目標是不患寡，而患不均，這注定單條tcp的頻寬利用率極低，因此http協議一般會採用多條tcp流**的方式來傳輸web伺服器的資料以增加頻寬，然而多tcp連線意味著連線管理的開銷會增大，同時資料同步的開銷也會增加，這導致了人們傾向於使用單獨的連線來完成所有的事情。
然而，又是乙個然而，tcp固有的隊頭擁塞問題導致單獨的tcp連線無法很好的進行http流的多路復用，這個難題促進了google對quic協議的設計和發布，同時，quic的一些顯而易見的優勢點也逐步的回移進了tcp(如果可能的話)。
不管怎樣，如今確實是傾向於減少tcp連線數量，這便弱化了公平性的約束，如今，提高單條連線的頻寬利用率，成了迫在眉睫的硬需求。
如何度量頻寬利用率？
我傾向於用一種 綜合的效用 來度量，而不僅僅是 把頻寬跑滿， 倘若如此，乙個包發十遍肯定能把頻寬跑滿，然而此時的利用率高嗎？
我傾向於把代價也算進去，最終，我們需要，在頻寬盡可能大的同時，保證代價盡可能小。
設g gg為收益，p pp為代價或者成本，那麼乙個綜合效用可以用以下的比值表示：
e=gp e=\dfrace= pg
我們的任務是，求出一組約束，使得e ee的值最大，此時頻寬的利用率最大。
本文以下的討論，假設鏈路的處理頻寬為常數u uu，處理方式為固定速率處理，處理單位為包粒度而不是位元組，那麼處理乙個包的時間便是1u \dfrac u1
，我們從一種極端情況開始，經由一種一般的情況，最終會得出結論，只有均勻按照每1u \dfrac u1
時間勻速到達的資料報，其e ee值最大，而這種方式就是pacing！
先看以極端情況下完全突發到達的資料報，即當到達率為λ \lambdaλ時，單位時間內所有的λ \lambdaλ個資料報同時到達。
我們知道，單位時間內系統可以處理u uu個資料報，是為服務率為u uu，然而當λ \lambdaλ個資料報在1u \dfrac u1
時間同時到達時，必然會有λ−1 \lambda-1λ−1個資料報排隊，而單位時間的空置時延依然是1−λu 1-\dfrac1− uλ
，因此總代價就是常數。如下圖所示：
雖然看樣子利用率接近了100%，然而代價確實巨大的！通過計算可知，這種情況下的e ee值並不高。然而這麼多年，tcp的aimd正是工作在這個模型上。
然而，正如我們分析網路資料流看到的那樣，情況可能比上面的模型展示的結果更加糟糕，這是為什麼？我們來接著分析。
下面我們看一種更加一般，更加符合真實環境的情況，即泊松到達的情況。這裡將會揭示乙個關於 100%利用率的神話永不可達 的事實：
至於說泊松到達的情況下，這張圖為什麼長這個樣子，我就不推導了，從排隊論的公式簡單理解作圖就能得到。注意這裡的事實，最佳利用率而不是最大利用率，為什麼？
從圖上可以看出，如果我們在泊松到達的情況下想逼近收益牆附近的最大100%利用率，代價將是無法承受的，我們看到佇列長度將趨向無窮大，這是根本無法處理的情況！
這背後的原因其實非常簡單，即在泊松到達到達的情況下，單位時間到達的資料報會有概率性的大於μ \muμ，此時就將付出排隊延時的代價，而同樣會有概率性的小於μ \muμ，此時便要付出空置的代價，而不管是排隊還是空置，對於服務方而言，都是成本，不幸的是，這兩種成本是疊加而非抵消的關係！它們對資料報到達的影響效果僅僅是在數值意義上使得其到達均值為到達率λ \lambdaλ！
這便是100%利用率永不可達的神話！
這個故事不斷在我們生活中上演，這也是為什麼運維們很怕cpu利用率達到100%的原因，100%並不意味著系統利用率高，而是意味著系統卡死！
同樣，我們的工作看上去永遠也做不完，因為你永遠不知道接下來會發生什麼，只要你沒有空閒的時候，那麼就意味著你將永遠沒有空閒的時候。你仔細想想，是不是這個道理。
如何解決這個問題呢？
破除泊松到達模式即可，取而代之，我們要適配固定的服務速率，即頻寬μ \muμ，如果我們能完全按照每1μ \dfrac μ1
的時間傳送乙個資料報，那豈不是意味著 既不用排隊，也不會空置 了嗎？這才是真正的100%的利用率！
是的，這就是pacing！
完全按照瓶頸頻寬來空置傳送的速率，使其和服務速率完全相匹配！這就是提高頻寬利用率的最佳方法。上圖也是tcp bbr的理論基礎。
然而，說起來容易做起來難，首先，端到端的tcp如何知道頻寬到底是多少？你又要說測量是不是？測量結果具有乙個rtt的滯後性。因此你測得的結果永遠都是以前的結果而不是現在的結果，由於網路情況存在隨機性，更無法**未來的情景，於是乎，完全按照瓶頸頻寬來傳送資料是不可能的，我們意識到一旦不可能實現這一點，就意味著會出現隨機的排隊或者資源空置，這無可避免！
其次，pacing的方法增加了tcp端到端實現的複雜性，破壞了tcp完美的 自時鐘。這個倒是有幾句話可以說說。
事實上tcp的aimd在設計之初就將pacing的希望寄託於其ack自時鐘了。因為當時的設計者們相信，完美的 雅各布森管道 會把突發出去的資料報整成pacing的方式到達對端，進而針對這些資料報ack也會是pacing的方式到達傳送端，從而驅動下一輪的資料以pacing的方式傳送。
然而事實證明，tcp的雅各布森管道並不完美，很少有網路能把突發的tcp資料整成pacing的，最終，tcp便背上了突發協議的罵名。那麼，雅各布森管道為什麼不完美？有以下原因：
網路上存在多個tcp流而不是乙個，新流的出現和舊流的消失不可預知；
ack的反向路徑與資料報正向路徑不對稱導致形成的pacing序列被破壞；
ack本身的丟失會導致突發；
一些路由器為了限制包量會根據tcp的積累應答機制將多個連續ack聚合，造成突發；
…總之，網路鏈路太複雜，這使得依賴自時鐘形成pacing是不現實的，那麼就不得不自己去算pacing rate了，而這個結果又是滯後的，或者說我們採集到的資訊僅僅夠算乙個所謂的均值，這些資訊遠遠不足以指導pacing傳送。
不管怎麼樣，我們依然會選擇pacing的方式來傳送資料，至少在沒有新的有別於aimd的全新數學模型出現之前吧。
如此一來，只要我們選擇了pacing，那麼就必然要在tcp傳送端內建一套資料採集和計算引擎，這是aimd模型所不需要的。
其實，很早以前就曾出現過一些爭論，比如關於完全速率控制的pacing rate傳送和完全ack自時鐘驅動的傳送之間的爭論，非常類似於中斷和輪詢之間的爭論，最終，我們現在使用的pacing傳送，比如bbr的pacing方式，事實上是融合了兩者：
用ack來驅動pacing rate的計算；
基於pacing rate來平滑傳送資料。
總之，提高頻寬的利用率的方法已經從**多條tcp連線的方式進化到了提高單條tcp連線的頻寬利用率。理論上證明pacing的方法是最好的，但是如何精確計算pacing卻成了新的問題。
那麼怎麼辦？
提高頻寬利用率！為什麼要Pacing？
1986年的tcp擁塞崩潰事件讓aimd模型在1988年後出來應對時局，從此以後網際網路協議的設計者和實現者聚焦於如何讓網路不擁塞。毫無疑問，這裡最重要的是公平性，而非效率。不管是慢啟動，加性增窗，乘性減窗，還是後來的vegas演算法的主動退讓，其目標都在於保證多條流經過共享鏈路時能公平共享頻寬。這...
RaySync 傳輸協議的有效頻寬利用率分析介紹
1 raysync 協議是在udp協議之上，增加了raysync的報文封裝，完成了擁塞控制 報文確認 丟包重傳等一系列完整的功能，可對比的實現包括 udt quic kcp 2 raysync傳輸協議重傳機制參考了tcp的快速重傳，但是做了全新的報文和確認機制設計，raysync的重傳機制可以確保在...
LVS負載均衡集群,提高網路利用率
lvs負載均衡集群介紹 負載均衡集群的作用 提供一種廉價 有效 透明的方法，來擴充套件網路裝置和伺服器的負載頻寬 增加吞吐量，加強網路資料處理能力 提高網路的靈活性和可用性。1 把單台計算機無法承受的大規模的併發訪問或資料流量分擔到多台節點裝置上分別處理，減少使用者等待響應的時間，提公升使用者體驗。...