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

呈遞減趨勢,這是什麼原因呢?
比如我在下載安卓開發不同版本的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%下載完成的視頻沒區別


推薦閱讀:

為什麼微軟在財富雜誌 2014 最受尊敬公司排行裡面靠後不及麥當勞?
在你所在的行業里,100 萬美元是什麼概念?
如何看待馬雲收購恒生電子?

TAG:互聯網 | 移動互聯網 | 下載 | IT 行業 | 下載速度 |