【正文】 FTPDATA FTP Data: 1176 bytes 1452 FTPDATA FTP Data: 1460 bytes 1453 FTPDATA FTP Data: 1460 bytes 1454 FTPDATA FTP Data: 1176 bytes 1455 TCP 1217 ftpdata [ACK] Seq=1 Ack=1125225 Win=8760 Len=0 1456 TCP 1217 ftpdata [ACK] Seq=1 Ack=1127861 Win=8760 Len=0 1457 FTPDATA FTP Data: 1460 bytes 1458 FTPDATA FTP Data: 1460 bytes 1459 FTPDATA FTP Data: 1176 bytes 1460 TCP 1217 ftpdata [ACK] Seq=1 Ack=1130497 Win=8760 Len=0 1461 FTPDATA FTP Data: 1460 bytes 1462 FTPDATA FTP Data: 1460 bytes 1463 FTPDATA FTP Data: 1176 bytes此段報文中，第一個較長等待發(fā)生在1436號報文，此時等待的時間比較長，距離下一個發(fā)送報文時延約15ms。第二個較長等待發(fā)生在報文1445處，距離下一個發(fā)送報文時延約31ms。對抓包文件進行查看，客戶端和服務(wù)器端沒有丟包重傳的現(xiàn)象。上面分析的例子可以看到，該下載過程中，F(xiàn)TP服務(wù)器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動窗口為8760字節(jié)。因此只要我們盡量往管道中填充報文，傳輸速率總會達到最大，哪怕傳輸時延大也不會影響最大的傳輸速率。ftp get D9GWQG1X200 PORT Command successful.150 Opening BINARY mode data connection for D9GWQG1X (16875520 bytes).226 Transfer plete.ftp: 16875520 bytes received in 在服務(wù)器端的抓包分析模型如下圖：優(yōu)化后的FTP下載模型很明顯的看到，雖然服務(wù)器突發(fā)的間隔與以前相比差不多（線路時延沒有改變），但突發(fā)的流量大了很多（注意縱軸刻度有變化），這就是因為發(fā)送緩沖區(qū)和滑動窗口增大的緣故。如上表，交織時延有6加大到16，速率降低不少。 測試結(jié)果線路模板（ADSL模板）ftp下載速率（KB/s）結(jié)論：同等條件下減小時延可以提高下載速率。使用不同線路模板并能正常激活，達到速率限制要求。但對內(nèi)存因素要求比較大，因為系統(tǒng)分配的緩沖區(qū)比較大。我們要找出導致下載速率慢的瓶頸所在，然后想辦法解決。贈語； 如果我們做與不做都會有人笑，如果做不好與做得好還會有人笑，那么我們索性就做得更好，來給人笑吧！ 現(xiàn)在你不玩命的學，以后命玩你。壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。一方面我們可以盡量降低線路時延，另一方面我們可以通過調(diào)整發(fā)送緩沖區(qū)和接收緩沖區(qū)的大小來規(guī)避解決。如果線路的時延比較大，那么線路設(shè)備的緩存就需要夠大，能夠?qū)鬏敼艿馈叭麧M”數(shù)據(jù)。下載速率涉及到端到端整個業(yè)務(wù)流程的每個環(huán)節(jié)，包括了FTP Server和Client終端的硬件性能，傳輸線路的帶寬和時延，F(xiàn)TP Server的算法（包括發(fā)送緩沖區(qū)大?。珻lient端的算法（包括滑動窗口大?。４颂幙梢允褂寐酚善鞯绕渌邆涔δ軛l件的設(shè)備。測試過程建立不同ADSL線路模版在測試終端上發(fā)起PPPoE呼叫，申請IP地址，訪問Internet。 測試結(jié)果線路模板參數(shù)ftp下載速率（KB/s）MODEM類型上行下行通道模式（上行交織時延，下行交織時延）Ping時延（ms）線路模板類型ADSLADSL2+5124096Interleave（6，6）14345363MT8805124096Interleave（16，6）252325124096Fast84524585124096Interleave（6，6）14340378MT8005124096Interleave（16，6）5124096Fast8421422測試說明應(yīng)用不同模板激活端口，進行FTP下載速率測試。FTP服務(wù)器發(fā)送緩沖區(qū)為81920字節(jié)，客戶端最大滑動窗口為65535字節(jié)。當傳輸時延增大時，管道會變長，管道容積增加。 增大滑動窗口和發(fā)送緩沖區(qū)的容量從前面的分析可以看出，服務(wù)器端處于等待發(fā)送狀態(tài)，直接原因是在等待對方的ACK確認報文。為什么等待ACK相應(yīng)的時間會比較長呢？這個時間等待就應(yīng)產(chǎn)生在傳輸線路上。在等待31ms后接收到1446號ACK報文后，再繼續(xù)發(fā)送報文。這時，服務(wù)器肯定不會再發(fā)送報文了。如果沒有被ACK確認的字節(jié)數(shù)加上一個報文長度（很可能是1460字節(jié)，請參考發(fā)送報文數(shù)據(jù)大小序列）大于對方的滑動窗口，此時服務(wù)器是不會發(fā)送報文的，因為再發(fā)送報文很可能會丟包。FTP客戶端用PC1進行下載。以前的線路模板中兩種單位都支持，后來因為RFC標準中只支持ms為單位，線路模板中取消了對DMT單位的支持，只支持ms單位。TCP會采用擁塞避免算法和慢啟動來調(diào)整發(fā)送策略，避免傳輸線路上的數(shù)據(jù)擁塞。當滑動窗口變化時，會依據(jù)一定的策略向?qū)Ψ桨l(fā)送滑動窗口更新通告，算法可參考TCP/IP相關(guān)文檔。發(fā)送序列號是對自己發(fā)送數(shù)據(jù)的一個編號，一次連接中發(fā)送的數(shù)據(jù)會連續(xù)編號，通過發(fā)送序列號對發(fā)送的數(shù)據(jù)進行標志。 TCP傳輸?shù)淖畲髨笪亩蜹CP下載大文件時，需要把大文件切割為一系列報文段進行發(fā)送。. . . .目錄1 背景描述 22 TCP相關(guān)知識點 2 TCP傳輸?shù)淖畲髨笪亩?2 TCP發(fā)送報文的確認 3 滑動窗口與接收緩沖區(qū) 3 發(fā)送緩沖區(qū) 3 慢啟動與擁塞避免算法 33 ADSL模板中交織與快速的區(qū)別 4 Channel mode－通道模式 4 Unit of interleaved delay－交