除了上篇提到的RTT與丟包率,大多數人更關心的也許是網路的頻寬(Bandwidth,Bw),畢竟電信、聯通等公司廣告主打的就是一個百兆、千兆頻寬,聽著嘎嘎猛。
很自然的一個認知是,頻寬好的鏈路在同樣的資料來源與流控策略的前提下,相對RTT也丟包率也會更好。但深究一下原因又會覺得模糊,本文便從頻寬的概念開始詳細解釋下上面問題的原因。
此頻寬非彼頻寬,作為信電系出身的我,之前常用的頻寬表示無線訊號對應的頻頻寬度,而在網路傳輸的數位訊號中,頻寬是指單位時間內連路能夠通過的資料量。即發端到收端單位時間內能夠交付的最巨量資料量(最大吞吐量)。
對於一個固定的傳送端和接收端而言(暫時不考慮中間路由器交換機等裝置的中轉,當做一個非共用媒介的單個資料鏈路傳輸),Bw主要受限於客觀物理因素,即具體傳輸鏈路能夠實現的最大傳輸速率,這一最大傳輸速率又受限於傳送端和接收端的最大交付/接受能力。舉個例子,假設發端能夠將數位訊號轉換為模擬訊號交付到資料鏈路中的最快速度為\(v_{send}\),單位是Bytes/s,收端能夠從資料鏈路中將模擬訊號轉換為數位訊號反饋給上層的速率為\(v_{recv}\),如果\(v_{send} \ge v_{recv}\),那麼收端的接收速率為\(v_{recv}\),因為有處理不完的資料來源源不斷到達,收端可以以最大的速率處理並向上交付資料,反之,如果\(v_{send} < v_{recv}\),那麼收端的接收速率為\(v_{send}\),因為收端的處理能力超過的資料到達的速度,發端傳送的速度決定了整個鏈路的傳輸上限。因此可以認為:
進一步,在將傳輸路徑中所有中轉節點考慮進來後,頻寬即變為了發端、收端以及路徑中所有節點加在一起,交付速率最慢的一個,就像一根長長的水管,有的地方粗,有的地方細,水管流出的最大速率受限於最細的那個地方。所以當你開通了千兆頻寬又存取網頁很慢的時候,先彆著急噴垃圾電信(手動狗頭)。
上面的場景只考慮了一個傳送端-接收端的場景,實際上很多網路鏈路中都是有多個使用者在同時傳輸的。以家庭最常見的WiFi場景為例,當你家人開始刷抖音的時候,你的遊戲很可能就會出現卡頓了,假設你獨享WiFi的頻寬為\(Bw_{along}\),在另一個使用相同傳輸策略的終端接入後,你就很難有\(Bw_{along}\)甚至\(Bw_{along}/2\)的傳輸體驗了,WiFi的監聽退避機制以及擁塞控制的策略能夠儘量避免鏈路的丟包和擁塞,但也會導致你損失一部分傳輸體驗。這時,能讓你穩定以接近\(Bw_{along}/2\)的速率進行傳輸已經成為了傳輸流控策略的優化目標。
開頭提到「頻寬好的鏈路在同樣的資料來源與流控策略的前提下,相對RTT也丟包率也會更好」,結合上一篇中RTT和丟包率的定義,就可以知道在頻寬較低的鏈路中,如果傳送策略過於激進,或者是有其他的使用者加入傳輸,導致資料進入鏈路的速度大於頻寬,那麼資料就會在鏈路中發生堆積(在收端或者中間節點的快取佇列中),那麼這裡的排隊時延就會逐漸增高,即鏈路的時延/RTT會發生增長。當堆積進一步加重,快取已經堆滿時候,鏈路就發生了擁塞,新到達的資料會發生丟失,即產生擁塞丟包。上述的場景常常發生在網路頻寬較差或不穩定的使用者身上,而對於那些網路頻寬較大的使用者,即使發生了使用者數目波動或者資料來源傳送激進,也很難超過剩餘的頻寬大小,使用者依然能夠以低延時零丟包體驗網路服務。
這個坑留在後面整理CC擁塞控制的時候再填,在實際應用場景中,最簡單的方法就是對一段時間(記為t)內被ACK的所有封包大小進行求和(記為D),\(D/t\)就是這段時間取樣得到的接收速率,或者是資料成功交付的速率,隨著時間的推移持續對該值進行取樣,取樣得到的最大值就是最靠近頻寬的值。(比較簡單、實用但不準確的方法)
本文對網路傳輸中的頻寬進行了解讀,結合延時與丟包,網路畫像的基本要素已經相對齊全了,即將踏上進階之路。
一些值得注意的點
本文來自部落格園,轉載請註明原文連結:https://www.cnblogs.com/mapleumr/p/17469513.html
本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須在文章頁面給出原文連線,否則保留追究法律責任的權利。