為什麼有時候下載東西一開始很快，後來就越來越慢？

11-25

呈遞減趨勢，這是什麼原因呢？
比如我在下載安卓開發不同版本的SDK時就出現這種情況，還有平時下載東西的時候也遇到過

好吧，紙糊慣例：高票答案純屬一本正經的胡扯八道。

這個是FileZilla，server用來建立ftp伺服器，client就不用說了，碼農們最喜歡的ftp客戶端軟體，不知道有沒有之一，反正天天見。

The free FTP solution

兩者剛好一套。自己配個環境，試試看會不會出現「最後一段下載速度緩慢」問題。

Wireshark，協議分析利器。實際看看TCP協議運作過程。

Wireshark · Go Deep.

不要看見貼幾張圖片就以為那是標準答案。能幾乎每個關鍵點都說錯，學成這樣還真是難能可貴了。

1、「慢起動」速度真的慢，但持續時間極短。

慢起動階段，TCP window從極小（如1、2……10位元組等）開始，每個RTT周期下載速度最高增加一倍（RTT已知時，TCP window大小和傳輸速率成正比，故可認為每個RTT周期下載速度增加一倍）。

出現第一個丟包或滿足其它條件時（其它條件較複雜，不討論），慢起動停止。

對常見的寬頻鏈路，哪怕RTT取50ms，那也是每50ms鏈路下載速率翻一番。1秒鐘足夠下載速率上漲2^20倍。

哪怕最不利情況下，幾秒鐘也足夠跑到鏈路帶寬上限了……

神TM的「初始下載速度快是因為慢開始」。

2、「擁塞控制」很穩。

如前所述，你先下個FileZilla-server搭建個環境，然後用FileZilla-client從上面下一個大文件（比如高清視頻/遊戲安裝包什麼的）。

打開任務管理器，性能-乙太網，看看下載速率穩不穩，是不是一本道答案那樣大起大落。

恰恰相反，幾乎所有的擁塞控制演算法都可以保證「實際數據傳輸速率在網路允許的最大帶寬附近波動」——實際到任務管理器裡面看看是不是這樣。

神TM的「後面一直減半減半減半就會越來越慢越慢越慢」——真要把程序寫成那樣，搞網路的還是買塊豆腐碰死算了。

3、「快速重傳」對擁塞控制演算法的影響很複雜，不同演算法有不同的應對。

TCP congestion control

要談論「快速重傳」，需要先搞明白DUP ACK。

DUP ACK是這樣一種機制：通常情況下，接收端收到發送端發來的包後，需要回一個ACK包。這個ACK包的作用是「通知發送端，編號xx的包我已經收到了，請繼續發編號xx+1的包」。那麼如果包10延誤或丟失了，接收端就可能在收到包9後收到包11、12、13……協議規定，當收到這樣不按順序到來的包時，接收端也要回一個ACK，但這個ACK不能確認包11收到（因為TCP協議允許用一個ACK確認一系列包，比如對包11的ACK意味著包11之前的所有包已經全部收到），而是重複報告「包9已收到，請求包10」——這就叫DUP ACK。發送方見到這種DUP ACK，就明白接收方收到的包亂序了。

正常情況下，一個包必須經過足夠長時間才能確認其丟失，然後發送端才會重傳它。這個響應周期太長了，對傳輸速率影響太大。於是有些演算法就利用DUP ACK：一旦連續出現3個DUP ACK，就認為報文已經丟失，於是立即重傳DUP ACK請求的下一個包。這就叫「快速重傳」。

快速重傳大大加快了網路擁塞的發現/響應速度，依賴它的演算法自然就會比「超時重傳演算法」更「精細」一些——換句話說，就是「在網路允許最大帶寬」附近的波動更「細碎」一些，對網路帶寬的利用率也更高。

第一次丟包時TCP window size的一半被稱為"slow start threshold"，大多流控演算法遇到DUP ACK會直接回退到這個值（並不像最古老的演算法那樣重新執行slow start過程）。這就有效降低了波動幅度。再加上各種緩衝區起到的類「濾波」作用，從而可以用緩衝區內容「填充」網速「低谷」、又用緩衝區空間「削平」網速「高峰」：換句話說，雖然TCP演算法的發送速率的確是「鋸齒形」曲線，但實際的數據流卻相對平緩，只是RTT（可理解為報文發送-響應間隔時間）周期性變化而已。

而最新的BBR演算法直接依賴RTT的改變。它把網速穩定在RTT不會增長的最高速率上。
換句話說，它檢測的是鏈路中緩衝區的使用：因為一旦用了緩衝區，那麼RTT就會增加，所以RTT增加就說明有設備開始用緩衝區了。而使用緩衝區本身，又是網速已達上限的標誌（因為不緩衝就得丟包）。把網速錨定在這裡，顯然是更科學、更合理的。

重複一遍：擁塞控制演算法的目標是盡量提高網路帶寬的利用率、同時盡量保證每個鏈路公平分享帶寬。所謂「擁塞控制演算法導致下載越來越慢」純屬胡扯八道。

PS：google最新的BBR演算法無視DUP ACK。它比舊有演算法更接近本質。

但這些和主題無關，故不再深入討論。

TCP BBR演算法與Reno/CUBIC的對比

————————————————————————————

如果大家親自搭建ftp伺服器做過實驗，就會發現，哪怕下一個100G的大文件，整個下載過程都是非常平穩的：如果沒有其它干擾且硬碟訪問速度足夠，那麼你會發現，除了最開始速率略慢、但1秒不到就到了網速上限然後一直保持，直到文件全部下載完畢，沒有任何大的波動。

其中，這個「1秒不到就逼近網速上限」就是「慢起動」過程；之後使得網速在幾分鐘乃至幾小時內都一直保持穩定高速的，就是擁塞控制演算法。

但是……網上到別人的伺服器下載文件可不是這樣啊？

無論如何，我們已經通過實驗證明了，TCP/ftp協議本身沒有問題。那麼我們就不需要繼續在上面浪費時間了。

那麼，問題在哪呢？

1、很多朋友談到「多線程下載」了。尤其對P2P下載，這的確是一個重要影響因素。

這是因為，前面提到過，TCP擁塞演算法要保證「每個鏈路公平分享帶寬」——嗯，如果一共10M帶寬，我和張三等十人每人一條鏈接ftp下載，那麼每人都能達到1M的下載速率，很公平，對吧？

但，如果張三耍流氓，他多開了一條鏈接呢？

現在成了每條鏈接0.9M帶寬，仍然很公平，對吧？

……當然不對！

張三是兩條鏈接，他有1.8M的下載速率；而其它9人每人只有1條鏈接，所以只有0.9M的帶寬。

怎麼辦？多開鏈接唄。你敢開三條，我就開四條……你開200條，我開400條……誰開的多誰搶到的帶寬就越多，傻子才不開。

（網管：現在你們明白為啥要禁P2P了吧）

（服務提供商也不幹了：每條鏈接都得有個接受/發送緩衝區，這可都是內存啊。你們這麼整，我伺服器還不得累死。不行，我得配置個策略，每個用戶/ip至多只准建立一條鏈接[實際一般為1~5條]，多了就強制斷開，反覆重試我ban你ip）

（舉例只是類似宿舍共用路由的情形；實際上網路任何部分都可能出現瓶頸。但一般來說，瓶頸多出現在末端，即用戶路由器和內容提供商伺服器那裡；另外就是跨國通信帶寬不足導致瓶頸——電信-聯通這種奇葩情況不予討論）

下載一個文件時，只剩最後一點點了，多開鏈接就不划算了——還沒跑滿帶寬就搬回來了，開越多反而更慢，還討人厭；還有的乾脆從協議上就不支持過小的分塊……所以多線程下載到最後，只能1條鏈接搬，速度自然就慢了。

但，如果僅僅是爭搶帶寬的話……經常P2P下載單鏈接也能跑到400K啊；為什麼只剩一點點時，速度總是只剩2~3K？

這是因為：

2、資源提供者的心機

我們知道，P2P號稱「下載者越多速度越快」；原理很簡單，程序會自動讓每個人把自己下載到的部分分享出去，下載的人越多，分享者自然也越多，速度當然就越快了。

但現實中，有些人只下載不上傳（這種行為被形象的稱為「吸血」，現在有不少專門的反吸血模塊可以檢測到他們並拒絕他們下載）；同時，多數用戶的下載帶寬和上傳帶寬不對等（說的就是你，ADSL；其實現在的光纖寬頻，一般也多是下載帶寬幾倍於上傳帶寬）；最後，多數人夜裡掛P2P軟體，並且會設置「下載結束後關機」。

這就導致下載量總是遠大於上傳量——這麼一來，「人越多反而越快」就成了一句空話，玩不起來了。

怎麼辦？

檢查誰快下載完了，限他的速，讓他多做會兒種。

類似的，普通的下載站，他們當然希望吸引更多用戶；怎麼吸引呢？豐富的內容+更高的下載速度。

但，想提供更高的下載速度，就必須購買更多的帶寬……可買帶寬是需要錢錢的……

怎麼辦？

當同時下載量太大時，發現一個用戶剛開始下載，就給他一個更高的限速，允許他「光速下載」；下載一段時間後再限速——用戶沒耐心一直盯著看，剛開始速度快讓他很高興，中後期他不看了就降速節約帶寬：這就解決了「更快的下載速度」和「帶寬得花錢買」之間的矛盾。

於是，買下和競爭對手一樣多的帶寬，用戶就是感覺我更快！

————————————————————

最後，很多人可能會奇怪：下載到最後一點點，速度總是很慢；我暫停/斷開一小會兒，重新開始時下載速度就會很快，然後很快又降低到原來的程度了，這是為什麼？

不，這可不是因為高票那個一本道答案的「慢起動」。

要說清這個，咱得從限速演算法的原理說起。

具體細節太複雜了；簡而言之，為了滿足各種刁鑽古怪的要求，限速演算法的原理並不是直接限制網路傳輸速度（沒法實現），而是「你想傳出去每一個位元組的數據，都得得到我的授權；而『授權令』的產生速度很容易控制；那麼如果我每秒只產生1M個授權令，你的傳輸速率自然最高只有1M/s；最後，規定『授權令』可累積，但有上限」。

明白了這個，問題就很容易解答了：下載到最後速度很慢是因為限速，給你的授權令產生太慢，產生一點你用一點，傳輸速率自然就被限到幾K了；暫停/斷開後，授權令就給你累計下來，那麼恢復傳輸後，你就可以一次性把積攢下來的授權給用完——於是瞬時傳輸速度就飆到了幾百K甚至若干M；可一旦積攢的授權用完了，你還是只能等新的授權，傳輸速率自然就又回到了幾K……

你以為自己得了實惠……實際上，瞬時幾百K的速度用的還是暫停時本就該分給你的授權；反倒是，因為暫停/斷開時間過長，你還因為溢出而浪費了一些「多餘」的授權令……

PS：很多軟體計算傳輸速率用的是平均值。所以看起來傳輸速率並不是暴起暴落，而是先600K後300K然後160K最後又回到20K；但實際上只有第一秒是600K，第二秒已經是20K了；但它把兩秒的流量加起來一平均……

PS2：有些時候，因為最後一段時間被嚴重限速，導致相關線程優先順序過低；然後如果軟體實現有問題，就很容易在這段時間暴露出來。此時斷開鏈接重試就類似網路版的「重啟下說不定就好了」。對這種情況，斷開重試的確有助於提高最後一段的下載速度。

PS3：家用路由器的CPU太弱、內存也太少，所以打開流控/QOS時，經常在一段時間的使用後導致軟體狀態紊亂。此時，經過路由器的報文延遲極大增加、頻頻出現丟包/亂序問題，且延遲時間忽高忽低。這也會嚴重影響下載速率（網遊什麼的當然更沒法玩）。這種情況往往需要重啟路由才能恢復正常（有的路由甚至可能因為過熱而自動重啟）。但如果關閉流控等高級功能，拿這種路由當交換機用，就極少出現這種問題了。

這大概也就是為何外部參數（速率、網口數、支持功能等）差不多的路由器，有的只要幾十元，有的卻敢「獅子大開口」要幾千甚至幾萬的原因吧。

PS4：國內因為牆的干擾，有時下載正常內容也會遭遇牆發來的RST包。這也會導致下載中斷。由於大多軟體不知道如何處理RST包（這種報文太特殊，正常情況下壓根就不應該出現），故此時往往只能通過人工干預恢復……

PS5：如果你對網路感興趣，想知道更多……那麼裝個Linux吧。裝虛擬機裡面也行。

Linux實現了幾乎所有的流控演算法，你可以從中自由選擇，以便觀察它們在實際網路環境中的表現。

你可以很容易的使用TCP DUMP配合腳本，深入觀察/分析各種演算法的表現；還可以利用TC模擬網路抖動、丟包、亂序等幾乎所有你能想到的奇葩狀況，從而觀察異常情況下各種流控演算法的實際表現。

Linux 高級流控

linux--TC - 龍沙寶石 - 博客園

基本上是多線程分段式下載的結果。

現在很多下載演算法都有一個默認分段下載，比如超過100M大小就分段，最多分10段，每個分段至少20M

這樣一個400M的文件可能一開始被分成10段下載，每段40M，同時開10個tcp鏈接下載。

tcp下載速度和幾個因素有關：時延，接收端窗口大小，丟包率。（參考：TCP傳輸性能剖析 - 推酷http://www.tuicool.com/articles/reEVr2M），TCP Throughput Calculator，A Very Simple Model for TCP Throughput | Blog | ThousandEyes | Network Monitoring Software，其中最後一個的公式是「大眾」參考公式（即簡化版）， $T=frac{MSS*C}{ RTT*sqrt{p}}$ ，其中T是TCP吞吐量，MSS是窗口，RTT是雙向時延，p是丟包率，C是一個常數，一般取 $sqrt{frac{3}{2}}$ ）。

當網路狀況一樣，窗口大小一樣時，每個tcp線程最高速度確定。所以分段多線程下載要比單線程下載快很多。尤其是帶寬很大時。

但是不同的線程下載速度並不是完全相等的。有的快有的慢（因為tcp總是嘗試提高速度塞了再降），另外還有就是分段的最後一段可能不夠長（比如一個360M的文件最後一個分段才10M其他段是40M）。快的線程結束後，會去看看其他線程剩下的部分是不是夠20M，如果超過20M，可以再分成兩段，原來那段繼續下，新加入的一段則是提速的。這時，總速度還是10個線程的速度。

但是，總有剩下部分不夠20M的時候。這時候下載程序就會降低線程數（已經完成任務的部分就退出）。所以會看到速度越來越慢，最後的速度就是一個單線程的速度。

所以將近結束時，會越來越慢。如果仔細觀察，一般能觀察到線性下降的過程。

當然，這個機制前提是伺服器支持多線程下載。如果伺服器不支持就不存在了。

看到有答案說到P2P了。也是類似的機制，分段，多線程。但是，每個段還是有下限。P2P的一個特殊點就是還要提供上傳。如果本地已經給其他人提供了上傳數據，那麼需要等上傳的「段」結束以後才能結束一個下載任務。

一般情況是樓主的下載軟體帶了P2P加速功能，初期連上的P2P源很快的都把自己有的資源分享完了，一直到最後選到的源都已經無法提供P2P加速為止，速度變為最慢。P2P協議本身是有隨機拋棄源重選機制的。只不過暫停後所有源重選，效率可能會高點。

我也注意到過。我想也有一直很快的，一直很慢的，還有一開始慢後來快的，只是從我們的「偏見」上，更會注意到先快後慢的情況。先得到，再失去，最刺激神經。

如果是迅雷這樣的P2P軟體的話，是會出現這樣的現象的，

因為他的數據來源是其他用戶上載的流量，越到後面仍然在下載的客戶端就會越少（有人放棄），這又使得相對前期下載速度更慢，放棄的人更多，形成惡性循環，巨大的文件尤其如此；

還有就是下載完成後通常會關閉客戶端，通常來說能夠上載後半段文件的客戶端必然能夠上載前半段，前半段的速度顯然會更快；

另外bt種子這樣的，有些放資源的人為了有更多的上載流量，最後10%故意卡一下，慢點出。

如果不是迅雷這樣的，，，，那就一直都很慢。

高票答案這麼多點贊的

充分證明了在知乎，只要你上幾個圖，隨便答都有大群人點贊的呵呵哈哈哈，

別的不說，現實中用的都是四層模型，

下載速度慢還有下載速度先快後慢和這個擁堵毛線關係都沒有，區域網的速度百兆千兆萬兆，真要出現影響到網速的現象，那就是網路部署的有問題，比如說錯了線有迴環，布線的人太外行，一個網段客戶端實在太多，現在設備這麼先進弄個迴環都不一定有問題。他的老師講這個的時候，前面一定帶了前提的，只是他可能沒有在聽課。

為什麼車子跑在馬路上一會兒加速一會兒減速啊？請你拿個放大鏡看看路面，是不是發現有很多小疙瘩啊？都是因為這個小疙瘩，路面不平當然會導致車子一會兒快一會兒慢不是嗎？

車子加速減速和這個有關係嗎？不是和油門剎車關係最大嗎？真要路面原因影響速度那就是爛泥巴路了。這麼說，看得明白嗎？

答主考完試來更新了~先說正事

1、關於P2P

P2P可以簡單理解為好多個原回答過程的疊加，但因為每個點的起點，網路環境不同，疊加狀態並不同步，故速度也不能確定，使用P2P下載的文件（通常都是很大的文件）在下載後期速度變慢的原因主要是【可供分享的資源越來越少】即，已經全部下載完成，擁有所有資源的人一定比剛下載了一部分，擁有一部分已下載資源的人少，所以越到後面分享資源的人越少，所以越慢。可以理解為下載過程中的靡不有初鮮克有終。

2、關於TCP

然而並不是所有的下載過程都是P2P下載，例如題設「下載安卓開發不同版本的SDK」場景，就是簡單的TCP下載過程，另外一些常見的場景包括幾乎所有的瀏覽器下載。關於百度雲是不是P2P下載，有的文件是有的文件不是，P2P下載的文件有標記。

2.1 TCP版本問題

TCP有30+個版本不過大致原理與擁塞控制過程都差不多，可能的差別就是擁塞窗口從1還是從2開始，加法增加的門限是24還是30之類，不能將這麼多個版本一一列舉，但基本的過程都是遵循AIMD模型，即加法增加乘法減小。

2.2 現在早就不用TCP協議了？

TCP擁塞控制依舊是最廣泛使用的擁塞控制策略，沒有之一，也一直有版本的更新。

2.3 加法增加的門限？

自己設定的門限，也與版本有關

2.4 若不丟包會一直增加下去么？

還與接受區域的緩存大小有關，也就是說人家發給你這麼多內容，你也得有緩存區域放得下才行，實際上的接收速度是擁塞窗口與緩存窗口兩者中的較小那個值。

2.5 一個擁塞窗口傳輸的文件大小？

差不多1500KB左右，也就是一兆多點兒

再說非正事

1、計算機網路及格了么？

這個知識點雖然計算機網路也學到過，但是關於為什麼越來越慢是通信網老師講的，計算機網路92，通信網A~

2、剛學完就出來賣弄？

已經畢業了，這個屬於基礎課，後面學習的是其他方向

最後

歡迎討論拒絕上來就噴

對於上來就噴的評論：噴完就走真tm刺激，這種情況答主只能雙擊666了~最煩不說正事只是噴噴噴的人，除了戾氣以外什麼都沒貢獻。

對於認真討論與反駁的答主：謝謝大家的討論，自己的姿勢水平也提高了~根據各位的評論又完善了一下回答，原答案不刪，因為沒錯~

最後的最後

很開心能夠引起討論與關注

很開心能夠幫助到一部分人

很開心各位非專業能看懂我的回答

——————————————————————以下原回答：

不是套路！！！是TCP協議的擁塞控制機制導致的！

要理解TCP的擁塞控制機制，還得從古老的七層模型說起……

其中TCP協議應用於傳輸層，下載就是傳輸的一種，而TCP傳輸的速度基本是這樣的

其中橫坐標是傳輸次數，縱坐標是「擁塞窗口」數，就是要傳輸的報文需要先進入這個窗口才能發出去，簡單的理解成傳輸速度就可以了

假設我要在百度雲上下載一個文件，以之為例解釋一下這個過程。

（A→B段）

百度云：不知道當前網路環境怎麼樣，路上堵不堵……不管了發一個報文試試。

我：收到啦收到啦！

百度云：誒呦不錯那再發兩個試試~

……

百度云：行了行了差不多了可以慢點兒增加了

這一段，起點學名叫做慢開始，後面叫指數增大

（B→C段）

百度云：加一個

我：收到啦

百度云：再加一個

我：收到啦

百度云：再加一個

我：……

百度云：？誒好像堵了= =

這一段，學名叫做，擁塞避免演算法，即，加法增大

（C→D段）

百度云：算了從頭開始

這一段叫做，乘法減小，開始新的慢開始，指數增大，但是，只增大到剛剛的一半，就進入擁塞避免階段啦！（D→E段，E縱坐標是C的一半）

以上是TCP Tahoe版本的傳輸過程（也是主要考試的內容），然而實際上這個版本太基礎了，已經廢棄不用了，實際使用的是紅線的版本，叫做TCP Reno（但是這個不考）

紅色版本與藍色版本的區別就是，紅色版本的乘法減小並不是直接減到1然後重新慢開始，而是採用了效率高一些的「快恢復快重傳」演算法，也就是乘法減小至原來的一半（C→F段，F是C的一半）然後直接開始加法增大。這樣可以看到比原來的藍色版本稍微快了一點。

但下載還是很慢啊怎麼辦，關於這點老師的說法是，自己手動暫停一下，再重新開始下載，就又能享受一次第一次的指數增加加法增加的速度，不然後面一直減半減半減半就會越來越慢越慢越慢………………

以上都是與TCP協議有關的理論因素，其他因素還包括加速器啊下載器啊什麼的

最後，這篇回答叫做：「為什麼有時候下載東西一開始很快，後來就越來越慢」回答暨通信網理論基礎課程複習筆記

這個問題，在實際技術層面上是有一定關係的，但是在設計套路層面上也是相關性很大的。
怎樣的設計套路呢？就是一開始給你一個下載很快的假象，實際進度並沒有像顯示的那麼快，營造一種這個工具下載速度很快的假象。在後面，當顯示快下載完的時候，實際上可能還差好多呢！但沒辦法，工具會把進度條變慢下來，而你卻以為已經下載了大部分了，只差一點再等等吧！然後就被心機程序猿給套路了！
哦不對～這不關程序猿的事，他也是被逼的～

先問是不是。我在美帝下載steam遊戲，從來都是越來越快的，一開始只有5mps，到後面都15-20mps了，一直到完。

這個我不是很懂，但是我知道的是很多下載網站。

你下個軟體，下個包，過了500M 就要你什麼先下那個什麼加速的，然後你下載的時候就有什麼捆綁軟體，當然你可以點擊消除不安裝，呵呵你不安裝那就不要下載了，能到100%算我輸，到了100%能用算我輸。

並且這能解釋為什麼很多妹子電腦上賊多無用的軟體，並且C 盤爆炸的原因。。。並且這個防不勝防。。就算良心點的可以下載可以安裝嗯，到最後安裝完成彈窗，

【安裝完成

[確定]

√]安裝某某管家 [√]安裝某某瀏覽器】

點擊確定，美滋滋。然後你電腦就是三個管家，五個世界的窗口。

他們都是確定確定確定。。。安裝 login .....就是這樣的。

高票答案真邪乎，不敢苟同。

在互聯網上，下載分多類型，有些是P2P，有的是直接從伺服器下載，有的是混合方式。

互聯網上的文件有些是會被切割成很多塊的，這些塊存儲在各個伺服器或者P2P電腦上，一般發生剛開始很快，後邊越來越慢的情況是大部分是 P2P下載的原因，比如迅雷，他會從伺服器直接查找資源，也會尋找P2P資源，剛開始很快，有可能是伺服器及P2P上有該文件的分段資源，後邊越來越慢是因為這個文件的分段在網路上資源越來越少，從而導致下載越來越慢。

當然這是說的較長的一個下載過程。最噁心的是下載到99%你發現再也下不動了，那就是這個文件最後一點點的分段找不到資源了。

還有一種情況是區域網內經常遇到的，比如員工從公司伺服器拷貝一個文件夾，文件夾裡邊包含很多文件夾和文件。可能剛開始拷貝，會非常快，但是你會發現後邊越來越慢，原因是硬碟對零碎的文件的寫入比較費時，不信的話，你可以試試建立100個1mb的文件然後拷貝到電腦，作為對比，拷貝一個100Mb的單個文件，速度相差非常大。這也是rar壓縮包的作用之一，可以減小文件體積，同時便於在互聯網上傳播，加快下載速度。返回問題，剛開始拷貝很快原因是最開始大塊是文件被拷貝出來了，所以顯示傳輸速度快，到了後邊，小塊文件以及眾多的文件夾的拷貝非常耗時。硬碟不斷的建立目錄，建立文件索引非常的費時間。所以很慢。機械硬碟最為突出，換成ssd會好些。

我覺得對於p2p下載,應該會存在這種問題吧.
舉個例子,你有一個100M的文件要下載,有100個可用資源,你可以分成100份, 100個連接同時下載,這樣在開始的時候,速度就是100份疊加,但是由於可用資源的速度不同,有先下載完的,此時同時進行的任務就變少了,速度自然就會下降啊.
當然,這種情況應該在下載快要結束的時候發生的概率比較大.
以上純屬猜測,不知道迅雷等p2p下載軟體的具體實現方法.歡迎指出錯誤

一個是網速不好，一個是下載源的問題。換個下載源試試吧

因為你在我的店裡蹭網各種下載，開始沒注意我在做咖啡，後來顧客抱怨你家網速真慢，我開後台看一眼就特么你一個人流量飛快，果斷限速。。

這就是你網速後來變慢了的原因

這種情況大多數都是p2p下載情況，目前第一名回答比例不大。

這就是概率問題，一個文件被分很多段，那麼一般都是從頭開始下載，雖然不一定這樣，但大部分都是這樣！所以提供資源也是前面部分偏多。p2p下載，你下載的同時也在上傳，記住這個就想的明白。而且這種情況下，一般是鏡像資源少，或者沒有。如果不用p2p下載軟體。你用idm下載，你設置很多線程下載看會不會擁塞導致下載變慢,幾乎不會變慢。有時間後面補充，以前做過一段時間下載開發.

我再來補充一點：
所有p2p 軟體都有檢驗（無論是BT還是迅雷P2p），由於文件可能會更新（比喻我們app 有不同版本，但其實可能只一些內容改變，其他內容都沒變化），如果某一塊大部分都是從老資源下載，那麼校驗通不過，就會一直丟棄，當其他塊都下完，他還沒有下載合適數據，那麼速度就會越來越慢，這個稍微想想多線程（本質多連接，早就都是非同步+ 事件循環，不需要那麼多線程，反而增加線程切換消耗），迅雷對視頻文件剩下一塊檢驗不過，直接就認為完成了，因為視頻損壞也沒有關係，整體不影響就可以了。有時候為什麼非視頻暫停可以下載完成，因為資源重新獲取了，可能拿到資源正好合適，或者從原始url 下載到那一塊了。

下載開發大分布就這些邏輯，怎麼更好獲取資源等等選擇合適方式進行加速。迅雷對資源有分類，所以有優先順序。

有dalao說是因為我們在意下的快的時候，
然而，我覺得手機版UC瀏覽器卻很符合題主所描述，

昨晚我下一個文件，0.6M大小，
最開始70kb/s，後面就慢慢降下來了，變成30kb/s，最諷刺的就是有加速下載字眼，而且最後也沒下載成功，有點像卡在99%的迅雷

然後我再下一次，還是老樣子。

大概和他們用的加速引擎有關吧 )

關於具體原因我學藝不精不太清楚，但是最高贊的答主用擁塞控制解釋感覺還是不太靠譜，至少不會是主要原因。
按那位答主的邏輯來說，慢開始階段擁塞窗口是乘法增加那網速應該是先迅速增加，達到門限後啟用擁塞避免，這時候擁塞窗口開始加法增加，但這都是在增加的
只有網路發生擁塞是才會啟用慢開始，這時候擁塞窗口降到1，門限減小，重新開始乘法增大，這就不對了呀，題目說的是逐漸減小，按這個邏輯應該是個反覆增大減小的過程呀。
還有就是不是只有一個擁塞窗口啊，發送窗口和接收窗口有多努力你知道嗎？

同感，特別是下大文件的時候，心情隨著下載速度起伏~~~

因為預載入你沒點按鈕就開始下載了

說一種場景吧，運營商為了減少出口帶寬，一般都有緩存系統，比如採用華為的icache系統，作用就是緩存一些熱度高、佔用帶寬比較大的東西，比如視頻，下載的時候首先都是去運營商自己的緩存系統裡面去拉內容，但是由於版權問題，緩存系統有一種策略，不會緩存全部的內容，以免構成侵權，這就形成一種情況，前面99%的內容在運營商自己的緩存伺服器上拉，最後1%的內容需要回源，通常是跨網，甚至跨國，就會很慢。這個和為什麼360測網速結果是100M，但是實際開網頁都卡一個道理。

如果下的是視頻文件的話，其實這問題很容易解決

如果下載跑到98、99%就走不動了（多數情況），就把下載任務暫停，把下載臨時文件的文件名類型改成目標類型就可以了

大多數下載軟體的臨時文件都是在原文件名後加臨時文件名後綴，比如下一部名叫zhihu.mp4的文件，下載中的臨時文件名一般被命名為http://zhihu.mp4.xxx，複製臨時文件後把.xxx刪掉，就直接可以觀看了

基本不卡頓，跟100%下載完成的視頻沒區別