目錄
- 快取
- 網路畫像
- 客觀網路條件
- 主觀外部輸入
- 小結
在前兩篇博文對帶寬、時延與丟包率有了初步的認識后(引流引流哈哈哈),我們已經可以對網路鏈路進行簡單的畫像描述了,不同畫像的網路在現實中復雜的場景下也會有著不同的表現,在分析這些表現之前,首先對一個引數進行補充,
快取
還是在前兩篇都有提到,端到端的傳輸鏈路中存在很多節點(路由器或交換機等),在這些節點+發端和收端中,每個節點都有自己的資料處理(發或收)速度上限(最慢的那個成為了帶寬大小的限制),如果一段時間內,擁入鏈路中的單位時間資料量超過了某些節點的限制,那么在這些節點的快取中就會逐漸積累起資料佇列,
舉個簡單的例子,假設一個發端+路由器1+收端的簡單鏈路,發端push資料進鏈路的速度為\(v_{send}\),路由器接收并轉發資料的最大速度為\(v_{route}\),收端接收資料的最大速度為\(v_{recv}\),且有\(v_{send} > v_{route} > v_{recv}\),那么會發生什么事?即在路由器的接收快取中,資料會以\(v_{send} - v_{route}\)的速度進行累積,在收端的快取中,資料會以\(v_{route} - v_{recv}\)的速度進行累積,如果發端push資料的速度不減,那慢慢這兩個節點的快取都會堆滿,開始丟包,并且在堆積的程序中,兩個節點的排隊延時會上漲,RTT也會上漲,直到兩個節點都開始丟包,RTT達到增長上限,
這里有兩個需要注意的點:
- 兩個節點丟包的時間點一樣嗎:顯然不一樣,因為快取有大有小(深快取、淺快取),淺快取下佇列稍一堆積就會發生丟包,深快取下能夠堆積較多的資料也不會觸發丟包;
- RTT的上漲與快取的關系:絕大部分情況下淺快取下RTT的漲幅上限是小于深快取的(考慮到一些硬體原因),如果發現RTT持續增長到很大卻一直沒有發生丟包,很可能鏈路中有一個深快取節點,反之,如果RTT增長一點就發生了丟包,大概率鏈路有淺快取節點,
網路畫像
結合已經梳理的引數,我們就可以簡單對網路畫像進行一個描述,我這里將畫像分為兩部分:客觀網路條件與主觀外部輸入,
客觀網路條件
主要包括鏈路的帶寬、節點快取大小、除了排隊時延之外的時延、鏈路隨機丟包率,這些引數在短時間內是固定不變的,屬于客觀因素,在路由路徑發生改變或者其他用戶加入鏈路時也會發生改變,但在短時間內或者穩定的網路環境下,是比較可靠的,其中,鏈路隨機丟包率是傳輸程序中資料包損壞或碰撞的概率,取決于傳輸鏈路,與擁塞無關,通常都比較小(不足1%),
主觀外部輸入
主觀外部輸入則可以籠統的概括為資料進入網路的模式,資料是以穩定的速度均勻進入網路還是周期性的短時間內發送大量資料,又或是毫無規律的發送,由“主觀”可以知道,很多時候資料進入網路的模式是發端可以控制的,如果不加控制會是什么樣的場景呢?
穩定的速度均勻發送:如果發送速度小于帶寬,發端到收端能夠以發送速率的速度穩定交付資料,且時延保持較低水平,只會遇到較低的隨機丟包;如果發送速度大于帶寬,那么發端到收端能夠以帶寬的速度交付資料,時延呈線性增長,直到發生擁塞丟包,嚴重影響體驗;
周期性短時間內發送大量資料:這里只考慮短時間速度大于帶寬的場景,小于沒什么好說的,如果資料量較小,短時間不足以填滿快取,在這段時間發端到收端能夠以帶寬的速度交付資料,時延先增長后下降(取決于發端停止傳輸的時間);如果資料量較大,短時間填滿了快取,在這段時間發端到收端能夠以帶寬的速度交付資料,時延先增長后下降,但會承受一定程度的丟包(取決于資料量與發送速度);
毫無規律的發送:那我也一言半語說不好了,,,需要具體問題具體分析,有點中學做物理題的感覺,
小結
總而言之,在已知網路客觀網路條件與主觀外部輸入的前提下,我們能夠從理論上分析具體得資料傳輸表現與預測可能出現的問題,進一步,在已知客觀網路條件下,我們能夠制定發送策略以獲取優質的傳輸體驗,即低延時,低丟包,高速率,
那么問題來了,怎么獲取客觀網路條件呢?自然而然就提到了擁塞控制CC(Congestion Control),CC是現代網路傳輸領域最重要的難題之一,旨在怎么獲取可靠的網路引數并制定資料發送策略,使得用戶能夠獲取低延時、低丟包、高速率的網路傳輸體驗,這里以BBR論文里的示意圖作為結尾(對于初涉傳輸的我,這張圖給了我很多啟發),

本文來自博客園,轉載請注明原文鏈接:https://www.cnblogs.com/mapleumr/p/17483724.html
本文著作權歸作者和博客園共有,歡迎轉載,但未經作者同意必須在文章頁面給出原文連接,否則保留追究法律責任的權利,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/555280.html
標籤:其他
上一篇:k8s實戰案例之基于StatefulSet控制器運行MySQL一主多從
下一篇:返回列表
