ftp下載速率慢原因分析與處理指導(dǎo)書(華為)-wenkub
2023-07-10 06:44:09 本頁面
【正文】 TCP會(huì)采用擁塞避免算法和慢啟動(dòng)來調(diào)整發(fā)送策略，避免傳輸線路上的數(shù)據(jù)擁塞。下面簡(jiǎn)單介紹一下快速、交織的處理過程；比如首先假定上層來的順序比特流如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1→→一般沒有交織的情況下（如快速方式），線路是按照上層來的比特流順序進(jìn)行傳送，這樣前面的比特先被傳送，并且先到接收端，相應(yīng)的時(shí)延較小，但誤碼的可能性就較大，比如如果線路上遇到脈沖干擾等，這些干擾持續(xù)的時(shí)間較短，但會(huì)致使連續(xù)的比特錯(cuò)誤，如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1→→由于以上是按照上層來的比特流順序進(jìn)行傳送的，這樣這些連續(xù)的比特錯(cuò)誤到達(dá)接收端也是連續(xù)的，達(dá)到一定程度，線路本身的差錯(cuò)控制碼（如FEC）等也將無能為力，最終產(chǎn)生線路誤碼，只能由高層協(xié)議的重傳協(xié)議來保證了。以前的線路模板中兩種單位都支持，后來因?yàn)镽FC標(biāo)準(zhǔn)中只支持ms為單位，線路模板中取消了對(duì)DMT單位的支持，只支持ms單位。4 一例FTP下載慢情況的分析測(cè)試場(chǎng)景1組網(wǎng)圖在上圖的組網(wǎng)方式下，F(xiàn)TP客戶端用PC1進(jìn)行下載。FTP客戶端用PC1進(jìn)行下載。ftp get d9gwqg1x200 PORT Command successful.150 Opening BINARY mode data connection for d9gwqg1x (16875520 bytes).226 Transfer plete.ftp: 16875520 bytes received in 我們先從數(shù)據(jù)的發(fā)送源端開始分析，看FTP SERVER是否把數(shù)據(jù)及時(shí)發(fā)送出來。如果沒有被ACK確認(rèn)的字節(jié)數(shù)加上一個(gè)報(bào)文長度（很可能是1460字節(jié)，請(qǐng)參考發(fā)送報(bào)文數(shù)據(jù)大小序列）大于對(duì)方的滑動(dòng)窗口，此時(shí)服務(wù)器是不會(huì)發(fā)送報(bào)文的，因?yàn)樵侔l(fā)送報(bào)文很可能會(huì)丟包。最近一次確認(rèn)報(bào)文在1433號(hào)報(bào)文處，確認(rèn)了1427號(hào)報(bào)文的數(shù)據(jù)，同時(shí)滑動(dòng)窗口為8760。這時(shí)，服務(wù)器肯定不會(huì)再發(fā)送報(bào)文了。也就是在1445報(bào)文的時(shí)刻，共有6個(gè)報(bào)文段沒有被確認(rèn)（143141441441441445號(hào)報(bào)文）。在等待31ms后接收到1446號(hào)ACK報(bào)文后，再繼續(xù)發(fā)送報(bào)文。 FTP Client端流量模型摘取一段報(bào)文來進(jìn)行分析。為什么等待ACK相應(yīng)的時(shí)間會(huì)比較長呢？這個(gè)時(shí)間等待就應(yīng)產(chǎn)生在傳輸線路上。 縮短線路時(shí)延根據(jù)前面的分析，線路時(shí)延大是造成單線程FTP下載速率低的主要原因。 增大滑動(dòng)窗口和發(fā)送緩沖區(qū)的容量從前面的分析可以看出，服務(wù)器端處于等待發(fā)送狀態(tài)，直接原因是在等待對(duì)方的ACK確認(rèn)報(bào)文。對(duì)于TCP傳輸能力大小，用帶寬時(shí)延乘積來描述比較合適。當(dāng)傳輸時(shí)延增大時(shí)，管道會(huì)變長，管道容積增加。如何更改發(fā)送緩沖區(qū)大小我們使用的FTP Server軟件為SERU version 。FTP服務(wù)器發(fā)送緩沖區(qū)為81920字節(jié)，客戶端最大滑動(dòng)窗口為65535字節(jié)。BAS是具有PPPoE終結(jié)功能的接入服務(wù)器，且配置有PPPoE帳號(hào)和IP地址池。 測(cè)試結(jié)果線路模板參數(shù)ftp下載速率（KB/s）MODEM類型上行下行通道模式（上行交織時(shí)延，下行交織時(shí)延）Ping時(shí)延（ms）線路模板類型ADSLADSL2+5124096Interleave（6，6）14345363MT8805124096Interleave（16，6）252325124096Fast84524585124096Interleave（6，6）14340378MT8005124096Interleave（16，6）5124096Fast8421422測(cè)試說明應(yīng)用不同模板激活端口，進(jìn)行FTP下載速率測(cè)試。通過比較了ADSL模板以及ADSL2+模板配置的差異，找出由于交織時(shí)延在ADSL模板上默認(rèn)的上下行時(shí)延為6，6；ADSL2+模板上默認(rèn)的上下行時(shí)延為16，6，由于上行設(shè)置時(shí)延值的不同，直接影響了ftp下載速度。測(cè)試過程建立不同ADSL線路模版在測(cè)試終端上發(fā)起PPPoE呼叫，申請(qǐng)IP地址，訪問Internet?？蛻舸砗炞郑簵罾鑽? 華為督導(dǎo)簽字：冼康怡 日期：測(cè)試地點(diǎn)：嶺南雅居接入通信機(jī)房測(cè)試結(jié)論： 同等條件下減小時(shí)延可以提高下載速率。此處可以使用路由器等其它具備功能條件的設(shè)備。不過隨著緩沖區(qū)的極大化，減少時(shí)延能帶來的速率提升變得不明顯上行下行通道模式（上行交織時(shí)延，下行交織時(shí)延）傳輸單元緩沖區(qū)TcpWindowSizeByte81922555525122048Interleave（16，6）1692325122048Fast2302355124096Interleave（16，6）2084655124096Fast3554675126144interleave（16，6）2296935126144Fast40769251224000interleave（16，6）機(jī)房上行帶寬不足無法測(cè)試51224000fast測(cè)試說明應(yīng)用不同模板激活端口，進(jìn)行速度測(cè)試。下載速率涉及到端到端整個(gè)業(yè)務(wù)流程的每個(gè)環(huán)節(jié)，包括了FTP Server和Client終端的硬件性能，傳輸線路的帶寬和時(shí)延，F(xiàn)TP Server的算法（包括發(fā)送緩沖區(qū)大?。?，Client端的算法（包括滑動(dòng)窗口大?。５瑫r(shí)也應(yīng)該看到，如果線路上一旦有丟包情況，WinXp發(fā)生超時(shí)重傳的機(jī)率就會(huì)高一些。如果線路的時(shí)延比較大，那么線路設(shè)備的緩存就需要夠大，能夠?qū)鬏敼艿馈叭麧M”數(shù)據(jù)。我們一般說下載速率慢就是與線路帶寬比較的，如果FTP下載速率接近了線路帶寬，那么下載速率就已經(jīng)達(dá)到最大了。一方面我們可以盡量降低線路時(shí)延，另一方面我們可以通過調(diào)整發(fā)送緩沖區(qū)和接收緩沖區(qū)的大小來規(guī)避解決。不要做金錢、權(quán)利的奴隸；應(yīng)學(xué)會(huì)做“金錢、權(quán)利”的主人。壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。最值得欣賞的風(fēng)景，是自己奮斗的足跡。贈(zèng)語； 如果我們做與不做都會(huì)有人笑，如果做不好與做得好還會(huì)有人笑，那么我們索性就做得更好，來給人笑吧！ 現(xiàn)在你不玩命的學(xué)，以后命玩你。判斷是否是時(shí)延因素導(dǎo)致FTP下載慢。我們要找出導(dǎo)致下載速率慢的瓶頸所在，然后想辦法解決。首先，下載速率不可能超過線路帶寬，超過部分一律會(huì)丟包。但對(duì)內(nèi)存因素要求比較大，因?yàn)橄到y(tǒng)分配的緩沖區(qū)比較大。 隨著緩沖區(qū)的極大化，減少時(shí)延能帶來的速率提升變得不明顯 下行速率模板越大，減小時(shí)延能帶來的速率提升越大 ADSL2+的交織模板，默認(rèn)上行交織時(shí)延是16ms，與上表對(duì)比，較大的時(shí)延差異影響較大的下載速度差異。使用不同線路模板并能正常激活，達(dá)到速率限制要求。連接終端MODEM支持ADSL2+業(yè)務(wù)。 測(cè)試結(jié)果線路模板（A
規(guī)章制度相關(guān)推薦
鄂ICP備17016276號(hào)-1