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

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

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

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

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

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

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

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

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

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

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

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

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

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

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