目錄
- 帶寬
- 帶寬和延時、丟包的關系
- 帶寬的估算方法
- 小結以及一些值得注意的點
除了上篇提到的RTT與丟包率，大多數人更關心的也許是網路的帶寬（Bandwidth，Bw），畢竟電信、聯通等公司廣告主打的就是一個百兆、千兆帶寬，聽著嘎嘎猛，
很自然的一個認知是，帶寬好的鏈路在同樣的資料源與流控策略的前提下，相對RTT也丟包率也會更好，但深究一下原因又會覺得模糊，本文便從帶寬的概念開始詳細解釋下上面問題的原因，
帶寬
此帶寬非彼帶寬，作為信電系出身的我，之前常用的帶寬表示無線信號對應的頻帶寬度，而在網路傳輸的數字信號中，帶寬是指單位時間內鏈路能夠通過的資料量，即發端到收端單位時間內能夠交付的最大資料量（最大吞吐量），
對于一個固定的發送端和接收端而言（暫時不考慮中間路由器交換機等設備的中轉，當做一個非共享介質的單個資料鏈路傳輸），Bw主要受限于客觀物理因素，即具體傳輸鏈路能夠實作的最大傳輸速率，這一最大傳輸速率又受限于發送端和接收端的最大交付/接受能力，舉個例子，假設發端能夠將數字信號轉換為模擬信號交付到資料鏈路中的最快速度為\(v_{send}\)，單位是Bytes/s，收端能夠從資料鏈路中將模擬信號轉換為數字信號反饋給上層的速率為\(v_{recv}\)，如果\(v_{send} \ge v_{recv}\)，那么收端的接收速率為\(v_{recv}\)，因為有處理不完的資料源源不斷到達，收端可以以最大的速率處理并向上交付資料，反之，如果\(v_{send} < v_{recv}\)，那么收端的接收速率為\(v_{send}\)，因為收端的處理能力超過的資料到達的速度，發端發送的速度決定了整個鏈路的傳輸上限，因此可以認為：
\[Bw = \min(v_{send},v_{recv}) \]進一步，在將傳輸路徑中所有中轉節點考慮進來后，帶寬即變為了發端、收端以及路徑中所有節點加在一起，交付速率最慢的一個，就像一根長長的水管，有的地方粗，有的地方細，水管流出的最大速率受限于最細的那個地方，所以當你開通了千兆帶寬又訪問網頁很慢的時候，先別著急噴垃圾電信（手動狗頭），
上面的場景只考慮了一個發送端-接收端的場景，實際上很多網路鏈路中都是有多個用戶在同時傳輸的，以家庭最常見的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
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文連接，否則保留追究法律責任的權利，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/554806.html
標籤：其他
下一篇：返回列表