爲何多 TCP 鏈接比單TCP鏈接傳輸快

轉自:https://www.zhihu.com/questio...python

TCP特性使得每一個TCP鏈接能夠獲得均等的帶寬。在多用戶環境下,一個用戶擁有越多TCP鏈接,得到的帶寬越大。
具體來講:
這個涉及到了TCP的擁塞控制。
咱們先看一下單TCP鏈接的擁塞控制。
這是一個TCP鏈接的發送窗口。服務器

clipboard.png

綠色部分爲發送者已發送,且接收者已確認(ACKed)。
黃色部分爲發送者已發送,但接收者還沒有確認("in-flight")。
藍色部分爲可用但還沒有發送。
灰色部分爲不可用。因此在RTT(round-trip time,來回通信延遲)不變的狀況下,cwnd這個變量基本決定傳輸速率。網絡

clipboard.png

發送者總會試圖找到不丟包狀況下的最大速率。按照TCP協議,在傳輸開始以後,每接收到一個確認(ACK)就會把cwnd這個變量增大一倍。因此TCP鏈接開始以後應該是這個樣子。併發

clipboard.png

剛開始的時候傳輸速率應該是指數被增加的,直到丟包發生。丟包會有兩種狀況:
1.當接收者發送給發送者的ACK丟失了,這時會觸發超時(timeout)。
2.當發送者發送給接收者的數據包丟失了,發送者會收到接收者發來的重複ACK,若是發送者收到了3個重複的ACK,也會認爲發生了丟包。性能

具體對這兩種狀況採起的措施略有不一樣,但粗略來講,變量cwnd會被減半,也就是說傳輸速率減半。而後cwnd會再次增大,直到下次丟包發生。因此忽略最開始,TCP的吞吐量應該是這樣。spa

clipboard.png

好,那麼如今咱們來看多TCP鏈接的擁塞控制。
咱們假設有兩條一樣的TCP鏈接。在他們的鏈接中間有一個共用的瓶頸路由器,帶寬爲R。blog

clipboard.png

假設這兩條鏈接都須要傳輸足夠大量的數據,那麼不論他們誰先開始傳輸,最後必定會均分帶寬。ip

clipboard.png

由於若是總傳輸速率低於R的時候就會不斷增大傳輸速率,某個鏈接在增大傳輸速率的時候發生丟包就會減半傳輸速率,最後趨於平衡。
因此k條通過同一節點TCP鏈接會平分帶寬R,每條鏈接獲得帶寬R/k。正由於如此,不管是之前的net vampire,仍是如今的迅雷都採起增長併發鏈接數的方法來加快下載速度。內存

在不存在鏈路爭用的狀況下,單鏈接能夠作到和多鏈接同樣快。
例如,我這裏局域網用的是百兆交換機,下載文件到內存,能夠達到11.3MB/s:路由

clipboard.png

百兆的理論速率是12.5MB/s(100Mbps),考慮到幀間隔、不一樣包長等因素,這個速率比較接近理論速率了。
在此狀況下,「多鏈接比單鏈接下載快」並不成立,或者說,只有很小的性能提高。

推而廣之,假設你的PC和http://python.org的服務器之間的全部交換設備(路由器、防火牆、交換機等),都只爲你的這個下載提供服務,等價於你獨佔這整個傳輸通道的所有帶寬,此時,單鏈接下載也不會比多鏈接下載慢多少。

問題是,這些中間設備,一般服務於成千上百(萬)的用戶,帶寬是供全部的用戶共享使用的。路由器的帶寬有限,沒法保證每一個鏈接都按照它所能支持的最大速率進行傳輸,即使不考慮路由器自己作的流量控制功能,單單這成百上千(萬)的用戶訪問所造成的TCP鏈接之間的競爭,就會產生如1樓所說的,各鏈接均分整個帶寬的狀況。

所以,現實環境下,因爲傳輸網絡的帶寬有限,一般各個鏈接會均分帶寬,致使單鏈接下載時速率較低,而多鏈接下載時速率較高。

相關文章
相關標籤/搜索