網路傳輸中的重要引數（1）
目前從事于音視頻流媒體領域的我，主要作業在傳輸層與應用層的交界處，研究如何針對流媒體場景實作高效而可靠的傳輸協議，作業兩年比較深刻的體會之一就是網路傳輸是個看似簡單清晰實則到處是坑的領域，本系列將首先對網路傳輸中重要的幾個引數進行梳理，討論各個引數的實際意義，以及各自常見的獲取方式，
理想的傳輸鏈路
在上層將需要傳輸的資料劃分為一個個小于MTU的資料包Packet后，在理想的傳輸鏈路中，發送端即按照上層Packet交付的順序，通過socket將資料按序交付給接收端，整個資料交付流程沒有延遲，沒有丟失，完全按序，
誰又不想擁有這樣完美的傳輸體驗呢？但現實往往比理想殘酷一些，在實際場景中，還有很多因素會影響傳輸體驗，其實這些因素是顯而易見且易于理解的，只是這里進行一下簡單的歸納與總結，
延時與RTT
無論在哪里，主機之間的資料傳輸都是通過下層各種各樣的物理資料鏈路實作的，基站、交換機與網橋等設備將一個個獨立的資料鏈路們相連，打通互聯網的每一個角落，既然信號在網路中進行物理傳輸，那自然需要時間，即端到端延時，為了明確端到端延時的概念，這里首先需要明確幾個概念，首先是傳播時延與傳輸時延，
傳播時延：是指電磁信號或光信號在傳輸介質中傳播一定的距離所花費的時間，即從發送端發送資料開始，到接收端收到資料（或者從接收端發送確認幀，到發送端收到確認幀），總共經歷的時間，
傳輸時延：是指結點在發送資料時使資料塊從結點進入到傳輸媒體所需的時間，即一個站點從開始發送資料幀到資料幀發送完畢（或者是接收站點接收一個資料幀的全部時間）所需要的全部時間，
通俗點解釋，傳播時延是信號在物理介質內傳播的時延，比如對于一個電磁波信號，在10km的距離傳輸1bit所需要的時間為10km/c，c即為光速，對應該時間也就是傳播時延，傳輸時延則為設備將一個Packet所有的bit推入網路所需要的時間（收端則為接收需要的時間），這個時長不受限于傳輸介質，而更受限于具體的設備性能，除了傳播時延與傳輸時延之外，端到端的傳輸還需要經歷端上設備以及傳輸路徑中各個節點的處理時延和排隊時延，處理時延即設備檢查分組（這里只分組交換中的分組，簡單理解也可以當做Packet）的首部，差錯驗證等需要的時間，排隊時延則為資料在端上緩沖中等待被處理的時間，舉個簡單的例子，假設發端的發送速率\(v_{send}\)大于接收端的處理速率\(v_{recv}\)，那么收端便會由于處理不過來到達的而外資料而將這些資料臨時快取起來處理，Packet在快取中等待的時間即為排隊時延，如果快取為0，排隊時延也自然為0，如果快取很大，排隊時延也會跟隨著增長，如果快取已滿，則會發生丟包，
綜上，傳播時延、傳輸時延、處理時延以及排隊時延共同組成了端到端時延，即資料（分組或Packet）從發送端到接收端總花費的時間，
\[端到端時延 = 傳播時延 + 傳輸時延 + 處理時延 + 排隊時延 \]除了端到端時延之外，另外一個重要（也許更重要）的與時間相關的指標為RTT（Round-trip delay time，RTT），即往返時間/來回通信延遲，參考維基百科的定義：“在雙方通信中，發訊方的信號（Signal）傳播（Propagation）到收訊方的時間，加上收訊方回傳訊息到發訊方的時間”，可以簡單理解為發端到收端的端到端時延+收端到發端的端到端時延，由于現在基本所有的傳輸場景都支持雙向通信，且為了支持可靠傳輸，發端需要收端的反饋以確認資料是否成功到達，發送+反饋這樣一來一回的機制讓RTT引數在可靠傳輸協議的設計中占據重要的地位，在丟包恢復（ARQ）與流控（CC）等領域，RTT也起著重要作用，坑先挖好，日后再談，
\[RTT = 端到端時延_{s2r} + 端到端時延_{r2s} \]常見的RTT獲取方法依賴于ACK確認機制，即收端接受到資料包后，會像發端回復一個ACK告知該資料包已經被成功接受，ACK的內容一般是資料包的序號Seq，具體跟隨使用的傳輸協議而定，在發端收到ACK后，便能夠根據資料包發送的時間與ACK接收的時間對RTT進行采樣與估計，假設資料包的Seq為k即有RTT采樣值為
\[RTT_{samp}^k = t_{recvAck}^k - t_{send}^k - ACKdelay^k \]這里\(t_{recvAck}^k\)為該包收到ACK的時間，\(t_{send}^k\)為該包發送的時間，\(ACKdelay^k\)為收端的處理時延，即接收到包到發送ACK的時間，在獲取采樣值之后，我們便可以利用各種各樣的濾波方法對RTT值進行預測估計了，比較常用的是指數加權移動平均法EWMA（TCP使用的方案），計算復雜度低，易于實作，效果也不錯，這里不再展開，貼個鏈接：https://www.cnblogs.com/keye/p/14958351.html，
丟包率
上學的時候我們的教材是經典的《計算機網路-自頂向下方法》，我記著原文寫的“如果將網路傳輸領域最重要的10個問題拿出來，可靠傳輸是第一位的有力候選者”（肯定有出入，懶得回去驗證了），為什么可靠傳輸這么重要，因為他能夠保證傳輸層之上各個應用的正常作業，為用戶正常的互聯網產品體驗提供保障，為什么可靠傳輸這么困難，因為它面向的是底層未知的傳輸鏈路，面對隨時可能發生的各種情況導致的丟包，
丟包的種類有很多，根據資料鏈路的不同發生的形式也不同，在共享介質的網路里可能會發生多個終端間的沖突（感興趣的可以了解下CSMA相關的協議），在非共享介質下也可能由于鏈路中節點的處理錯誤或是上面提到的快取已滿而導致的丟包，anyway，對于發端而言，相對可以簡單的把丟包分為兩類：隨機丟包和擁塞丟包，擁塞丟包即為在鏈路擁塞，收端快取滿時候，新到達的資料包由于無處快取而被丟失導致的丟包，隨機丟包即除了擁塞丟包之外的其他（手動狗頭），
發端能夠準確的識別丟包型別與丟包強度對于發端高效利用帶寬有著重要的意義，這里先不對如何利用進行展開，主要關注丟包強度，一般我們使用丟包率lossRate來描述這一特性，丟包率的定義為“傳輸中所丟失資料包數量占所發送資料組的比率”，理解起來比較簡單直白，即一段時間內，記發端發送的包數個數為n，其中收到ACK的個數為m，\(\frac{n-m}{m}\)即為簡單的丟包率估計，需要注意的是對于那些剛剛發送的包，一般不納入統計，因為這些包可能未發生丟包，只是還沒有收到ACK，上一節提到，包往返的時間是RTT，或許取now-RTT直接的一段時間進行丟包率的采樣是更好的選擇，采樣伴隨著誤差，在得到丟包率的采樣后，不同的策略也同樣可以通過濾波手段進一步估計網路中實際的丟包表現，進一步決定策略的調整與適配，
小結
本文簡單梳理了網路傳輸中RTT與丟包率兩個引數的定義（物理意義）與常見的獲取收端，在人均百兆帶寬的今天，丟包率和RTT就能夠很大程度上對網路畫像進行有效的描述，后續的ARQ與CC等可靠傳輸策略也離不開對于這兩個引數的理解與應用，
本文來自博客園，轉載請注明原文鏈接：https://www.cnblogs.com/mapleumr/p/17464980.html
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文連接，否則保留追究法律責任的權利，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/554699.html
標籤：其他
下一篇：返回列表