決定用戶下載大文件速度快慢的終極因素，在於用戶下載進程實時搶占網絡帶寬的大小。其它的因素與它相比，可以忽略不計。
任意一個與互聯網通信的進程，理論上都有一個實時最大可用帶寬，這是客觀存在，不以用戶意志為轉移。 如果 用戶進程實時搶占的帶寬 = 實時網絡可用帶寬 那是最最理想的，用戶進程100%利用網絡帶寬，無論進程（Process）是單線程（Thread）的還是多線程的，下載速度幾乎沒有任何區別。
理想是豐滿的，但現實是骨感的，因為： 用戶進程實時搶占的帶寬 ≤實時網絡可用帶寬 Forever！！！
既然如此，如果能讓用戶進程實時搶占的帶寬無限接近實時網絡可用帶寬，那也是非常完美的。可是，實時網絡帶寬是多少？ 沒有人知道！實時網絡可用帶寬每一刻都在變化！ 操作系統很願意為用戶效勞，TCP通過流量探測機制，不間斷地探測實時網絡可用帶寬，並將實時的發送速率與之匹配（相等）起來，這個騷操作看起來很美！
為什么這么說呢？傳統的TCP流量探測機制有一個非常致命的缺陷：一旦檢測到有丟包，立馬將發送速率降為1/2。降速1/2后，如果沒有丟包，將會在1/2速率的基礎上，按照固定的增長值（線性增長），加大發送的速率。接下來就會一直按照這個節奏到達丟包的那一刻（實時可用帶寬）為止。然后再1/2降速，循環往復，直到文件下載結束。 如果下一個檢測周期依然有丟包現象，會在當前1/2速率的基礎上繼續降速1/2。剩下的故事情節以此類推。
很顯然，指數級降速，線性增速，這很不公平！降速很快，但升速卻很漫長！造成的直接惡果就是真實的傳輸速率遠遠小於實時可用帶寬。
多線程相比單線程的優勢是，由於有多個線程在競爭實時可用帶寬。盡管多線程邏輯上是並行的，但其實還是按時序的串行處理。所以每個線程處於的階段並不一致。 在任意時刻，有的線程處於丟包被罰1/2降速，有的線程處於2倍增速階段（SlowStart），而有的線程處於線性增長階段。通過多個線程的下載速率的加權平均，得到的是一根相對平滑的下載曲線。這條平滑曲線在大多數時候應該位於單線程下載速率的上方。這就是多線程下載速率更有優勢的體現。 但是，如果TCP流量探測機制更加智能，比如BBR算法。BBR算法最大的進步，就是摒棄傳統TCP流量調度算法（基於是否丟包而升速或降速）， BBR采取的是，實時測量網絡最大的可用帶寬，並將發送速率與之相匹配，一直在實時可用帶寬附近小范圍徘徊，避免大起大落的情況發生。測量速率能無限接近實時可用帶寬，多線程相比單線程，優勢就體現不出來了。
本文轉載自 VX公眾號：車小胖談網絡