【正文】 壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。最值得欣賞的風景，是自己奮斗的足跡。不要做金錢、權利的奴隸；應學會做“金錢、權利”的主人。贈語； 如果我們做與不做都會有人笑，如果做不好與做得好還會有人笑，那么我們索性就做得更好，來給人笑吧！ 現(xiàn)在你不玩命的學，以后命玩你。一方面我們可以盡量降低線路時延，另一方面我們可以通過調整發(fā)送緩沖區(qū)和接收緩沖區(qū)的大小來規(guī)避解決。判斷是否是時延因素導致FTP下載慢。我們一般說下載速率慢就是與線路帶寬比較的，如果FTP下載速率接近了線路帶寬，那么下載速率就已經達到最大了。我們要找出導致下載速率慢的瓶頸所在，然后想辦法解決。如果線路的時延比較大，那么線路設備的緩存就需要夠大，能夠將傳輸管道“塞滿”數(shù)據(jù)。首先，下載速率不可能超過線路帶寬，超過部分一律會丟包。但同時也應該看到，如果線路上一旦有丟包情況，WinXp發(fā)生超時重傳的機率就會高一些。但對內存因素要求比較大，因為系統(tǒng)分配的緩沖區(qū)比較大。下載速率涉及到端到端整個業(yè)務流程的每個環(huán)節(jié)，包括了FTP Server和Client終端的硬件性能，傳輸線路的帶寬和時延，F(xiàn)TP Server的算法（包括發(fā)送緩沖區(qū)大?。?，Client端的算法（包括滑動窗口大?。?。 隨著緩沖區(qū)的極大化，減少時延能帶來的速率提升變得不明顯 下行速率模板越大，減小時延能帶來的速率提升越大 ADSL2+的交織模板，默認上行交織時延是16ms，與上表對比，較大的時延差異影響較大的下載速度差異。不過隨著緩沖區(qū)的極大化，減少時延能帶來的速率提升變得不明顯上行下行通道模式（上行交織時延，下行交織時延）傳輸單元緩沖區(qū)TcpWindowSizeByte81922555525122048Interleave（16，6）1692325122048Fast2302355124096Interleave（16，6）2084655124096Fast3554675126144interleave（16，6）2296935126144Fast40769251224000interleave（16，6）機房上行帶寬不足無法測試51224000fast測試說明應用不同模板激活端口，進行速度測試。使用不同線路模板并能正常激活，達到速率限制要求。此處可以使用路由器等其它具備功能條件的設備。連接終端MODEM支持ADSL2+業(yè)務。客戶代表簽字：楊黎崗 華為督導簽字：冼康怡 日期：測試地點：嶺南雅居接入通信機房測試結論： 同等條件下減小時延可以提高下載速率。 測試結果線路模板（ADSL模板）ftp下載速率（KB/s）結論：同等條件下減小時延可以提高下載速率。測試過程建立不同ADSL線路模版在測試終端上發(fā)起PPPoE呼叫，申請IP地址，訪問Internet。BAS是具有PPPoE終結功能的接入服務器，且配置有PPPoE帳號和IP地址池。通過比較了ADSL模板以及ADSL2+模板配置的差異，找出由于交織時延在ADSL模板上默認的上下行時延為6，6；ADSL2+模板上默認的上下行時延為16，6，由于上行設置時延值的不同，直接影響了ftp下載速度。如上表，交織時延有6加大到16，速率降低不少。 測試結果線路模板參數(shù)ftp下載速率（KB/s）MODEM類型上行下行通道模式（上行交織時延，下行交織時延）Ping時延（ms）線路模板類型ADSLADSL2+5124096Interleave（6，6）14345363MT8805124096Interleave（16，6）252325124096Fast84524585124096Interleave（6，6）14340378MT8005124096Interleave（16，6）5124096Fast8421422測試說明應用不同模板激活端口，進行FTP下載速率測試。測試過程建立不同ADSLADSL2+線路模版在測試終端上發(fā)起PPPoE呼叫，申請IP地址，訪問Internet。BAS是具有PPPoE終結功能的接入服務器，且配置有PPPoE帳號和IP地址池。ftp get D9GWQG1X200 PORT Command successful.150 Opening BINARY mode data connection for D9GWQG1X (16875520 bytes).226 Transfer plete.ftp: 16875520 bytes received in 在服務器端的抓包分析模型如下圖：優(yōu)化后的FTP下載模型很明顯的看到，雖然服務器突發(fā)的間隔與以前相比差不多（線路時延沒有改變），但突發(fā)的流量大了很多（注意縱軸刻度有變化），這就是因為發(fā)送緩沖區(qū)和滑動窗口增大的緣故。FTP服務器發(fā)送緩沖區(qū)為81920字節(jié)，客戶端最大滑動窗口為65535字節(jié)。調整發(fā)送緩沖區(qū)界面更改客戶端滑動窗口大小我們可以通過“Windows優(yōu)化大師”這款軟件來修改滑動窗口大小。如何更改發(fā)送緩沖區(qū)大小我們使用的FTP Server軟件為SERU version 。因此只要我們盡量往管道中填充報文，傳輸速率總會達到最大，哪怕傳輸時延大也不會影響最大的傳輸速率。當傳輸時延增大時，管道會變長，管道容積增加。我們可以把報文的傳輸過程想象為報文放在管道上傳輸。對于TCP傳輸能力大小，用帶寬時延乘積來描述比較合適。上面分析的例子可以看到，該下載過程中，F(xiàn)TP服務器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動窗口為8760字節(jié)。 增大滑動窗口和發(fā)送緩沖區(qū)的容量從前面的分析可以看出，服務器端處于等待發(fā)送狀態(tài)，直接原因是在等待對方的ACK確認報文。對于ADSL線路的下載，減小線路時延的方法可以改變ADSL的激活方式。 縮短線路時延根據(jù)前面的分析，線路時延大是造成單線程FTP下載速率低的主要原因。對抓包文件進行查看，客戶端和服務器端沒有丟包重傳的現(xiàn)象。為什么等待ACK相應的時間會比較長呢？這個時間等待就應產生在傳輸線路上。1400號報文確認了1395號報文，1401號報文確認了1397號報文，1402號報文確認了1399號報文，時延分別為6ms，3ms，1ms（注：如果是在客戶端上安裝抓包軟件抓包，會發(fā)現(xiàn)每收到2個FTP報文后就立刻回應ACK，時延在1ms內）。 FTP Client端流量模型摘取一段報文來進行分析。在等待31ms后接收到1446號ACK報文后，再繼續(xù)發(fā)送報文。如果再發(fā)送一個報文1460字節(jié)，也會超過滑動窗口大小8760。也就是在1445報文的時刻，共有6個報文段沒有被確認（143141441441441445號報文）。第二個較長等待發(fā)生在報文1445處，距離下一個發(fā)送報文時延約31ms。這時，服務器