FTP下載速率慢原因分析及處理指導(dǎo)書(華為)

1、FTP下載速率慢原因分析及處理指導(dǎo)書內(nèi)部公開目錄1背景描述22TCP相關(guān)知識(shí)點(diǎn)22.1TCP傳輸?shù)淖畲髨?bào)文段22.2TCP發(fā)送報(bào)文的確認(rèn)32.3滑動(dòng)窗口與接收緩沖區(qū)32.4發(fā)送緩沖區(qū)32.5慢啟動(dòng)與擁塞避免算法33ADSL模板中交織與快速的區(qū)別43.1Channel mode通道模式43.2Unit of interleaved delay交織延遲單位54一例FTP下載慢情況的分析64.1縮短線路時(shí)延104.2增大滑動(dòng)窗口和發(fā)送緩沖區(qū)的容量105佛山網(wǎng)通現(xiàn)網(wǎng)測(cè)試的結(jié)果135.1ADSL/ADSL2+FTP下載速率測(cè)試（突出改變時(shí)延帶來的影響）145.2ADSL下載速率測(cè)試（突出改變緩沖區(qū)帶來的

2、影響）155.3ADSL2+下載速率測(cè)試（同樣是突出改變緩沖區(qū)帶來的影響）166結(jié)論172022-3-9華為機(jī)密，未經(jīng)許可不得擴(kuò)散第18頁, 共18頁FTP下載速率慢原因分析及處理指導(dǎo)書1 背景描述在DSLAM的應(yīng)用中，經(jīng)常用到FTP下載來測(cè)試ADSL的帶寬。我們?cè)跍y(cè)試時(shí)經(jīng)常會(huì)發(fā)現(xiàn)FTP下載速率比ADSL的帶寬小很多，本文就是從原理入手逐步分析問題的原因。首先強(qiáng)調(diào)一點(diǎn)，F(xiàn)TP下載速率肯定不會(huì)大于通道的帶寬，因?yàn)锳DSL通道就好比運(yùn)載貨物的列車，我們只可能盡量的裝滿它，但絕不會(huì)超過它；甚至使用多個(gè)FTP同時(shí)下載，每個(gè)FTP下載速度的總和也不會(huì)大于通道的帶寬（測(cè)試標(biāo)準(zhǔn)中均建議使用多個(gè)FTP同時(shí)下載

3、）。其次，F(xiàn)TP下載是一個(gè)端到端的處理過程。下載速率涉及到端到端整個(gè)業(yè)務(wù)流程的每個(gè)環(huán)節(jié)，包括了硬件性能、線路帶寬、線路時(shí)延，緩沖區(qū)算法等。使用FTP下載是一種比較方便（或者說常規(guī)應(yīng)用中也沒有比它更好的）的方式來判斷帶寬的方法，不過我們要盡可能排除一切瓶頸，使FTP下載速度接近通道的帶寬。2 TCP相關(guān)知識(shí)點(diǎn)問題分析涉及到的TCP知識(shí)點(diǎn)介紹一下。熟悉TCP的人可以跳過此節(jié)，太不熟悉TCP的人請(qǐng)直接參考TCP/IP相關(guān)資料，此處不做過多的基本知識(shí)介紹。2.1 TCP傳輸?shù)淖畲髨?bào)文段TCP下載大文件時(shí)，需要把大文件切割為一系列報(bào)文段進(jìn)行發(fā)送。如果每個(gè)報(bào)文段的容量過小，則會(huì)影響到發(fā)送效率。在以太網(wǎng)上傳

4、輸時(shí)，以太網(wǎng)最大幀長(zhǎng)為1518字節(jié)，去除以太網(wǎng)幀頭及校驗(yàn)，以太網(wǎng)幀的凈荷為1500字節(jié)。IP報(bào)文頭最小字節(jié)數(shù)為20，TCP報(bào)文頭最小字節(jié)數(shù)為20，TCP報(bào)文最大凈荷就為1460字節(jié)了。在TCP連接建立時(shí)，協(xié)商出來的最大報(bào)文段為1460字節(jié)。假設(shè)FTP下載的發(fā)送緩沖區(qū)為8K bytes。在下載大文件時(shí)，發(fā)送報(bào)文數(shù)據(jù)大小序列一般為：1460，1460，1460，1460，1460，892或1460，1460，1176，1460，1460，1176，一般不會(huì)發(fā)送小數(shù)據(jù)的報(bào)文。2.2 TCP發(fā)送報(bào)文的確認(rèn)在一個(gè)TCP報(bào)文中包含有發(fā)送序列號(hào)和確認(rèn)序列號(hào)。發(fā)送序列號(hào)是對(duì)自己發(fā)送數(shù)據(jù)的一個(gè)編號(hào)，一次連接中發(fā)

5、送的數(shù)據(jù)會(huì)連續(xù)編號(hào)，通過發(fā)送序列號(hào)對(duì)發(fā)送的數(shù)據(jù)進(jìn)行標(biāo)志。確認(rèn)序列號(hào)用于通知對(duì)方，對(duì)方送過來的數(shù)據(jù)中小于此序列號(hào)的報(bào)文都被正確接收（包括不會(huì)亂序，不會(huì)丟失報(bào)文）。2.3 滑動(dòng)窗口與接收緩沖區(qū)滑動(dòng)窗口是數(shù)據(jù)接收方控制數(shù)據(jù)傳輸流量的重要手段，此值反映的也是TCP接收緩沖區(qū)的大小。數(shù)據(jù)接收方通過此值告知對(duì)方自己的接收緩沖區(qū)大小，讓發(fā)送方根據(jù)此值調(diào)整發(fā)送策略。發(fā)送方已經(jīng)發(fā)送但還沒有被確認(rèn)的數(shù)據(jù)字節(jié)，加上即將要發(fā)送的數(shù)據(jù)字節(jié)數(shù)之和大于對(duì)方的滑動(dòng)窗口，則發(fā)送方會(huì)停止發(fā)送報(bào)文。除非發(fā)送方收到了新的確認(rèn)報(bào)文，或收到對(duì)方滑動(dòng)窗口擴(kuò)大后，前面所說的限制被打破，才可能繼續(xù)發(fā)送報(bào)文?；瑒?dòng)窗口會(huì)動(dòng)態(tài)調(diào)整的。當(dāng)應(yīng)用層從接收

6、緩沖區(qū)取走數(shù)據(jù)時(shí)滑動(dòng)窗口就會(huì)擴(kuò)大，接收緩沖區(qū)收到新的報(bào)文時(shí)滑動(dòng)窗口會(huì)減少。當(dāng)滑動(dòng)窗口變化時(shí)，會(huì)依據(jù)一定的策略向?qū)Ψ桨l(fā)送滑動(dòng)窗口更新通告，算法可參考TCP/IP相關(guān)文檔。2.4 發(fā)送緩沖區(qū)發(fā)送緩沖區(qū)的大小會(huì)影響到發(fā)送策略。在對(duì)方滑動(dòng)窗口足夠大的情況下，發(fā)送端發(fā)送的未被確認(rèn)的數(shù)據(jù)大小不能超過發(fā)送緩沖區(qū)的大小。一旦到達(dá)發(fā)送緩沖區(qū)大小的臨界點(diǎn)，則發(fā)送端停止發(fā)送。這是因?yàn)橐寻l(fā)送但還沒有被確認(rèn)的數(shù)據(jù)還會(huì)繼續(xù)滯留在發(fā)送緩沖區(qū)中，占用了空間。只要是沒有被確認(rèn)的數(shù)據(jù)都可能會(huì)重傳，發(fā)送緩沖區(qū)不會(huì)將這些數(shù)據(jù)從緩沖區(qū)中清除，否則需要重傳時(shí)找不到這些數(shù)據(jù)。我們可以想想，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)只會(huì)send一次，TCP層的重傳就

7、靠自己了，所以原始的數(shù)據(jù)不會(huì)在TCP發(fā)送緩沖區(qū)中被清除掉。2.5 慢啟動(dòng)與擁塞避免算法如果發(fā)送緩沖區(qū)和接收緩沖區(qū)（滑動(dòng)窗口）都足夠大，那么發(fā)送端是否會(huì)盡量發(fā)送數(shù)據(jù)呢？如果中間網(wǎng)絡(luò)出現(xiàn)擁塞或丟包，快速發(fā)送報(bào)文會(huì)造成不斷的重傳，傳輸效率會(huì)更低。TCP會(huì)采用擁塞避免算法和慢啟動(dòng)來調(diào)整發(fā)送策略，避免傳輸線路上的數(shù)據(jù)擁塞。一旦發(fā)現(xiàn)有擁塞現(xiàn)象（超時(shí)或收到重復(fù)確認(rèn)），發(fā)送方會(huì)降低發(fā)送速度。3 ADSL模板中交織與快速的區(qū)別3.1 Channel mode通道模式Fast：快速方式，糾錯(cuò)能力一般，但延遲較小，適用于那些對(duì)延遲敏感的業(yè)務(wù)，比如視頻點(diǎn)播、可視電話等。Interleaved：交織方式，糾錯(cuò)能力較強(qiáng)，

8、隨著深度越深，糾錯(cuò)能力越強(qiáng)，但相應(yīng)的延遲就越大，這種方式適用于那些對(duì)可靠性要求較高但不太在意延遲的業(yè)務(wù)。下面簡(jiǎn)單介紹一下快速、交織的處理過程；比如首先假定上層來的順序比特流如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1一般沒有交織的情況下（如快速方式），線路是按照上層來的比特流順序進(jìn)行傳送，這樣前面的比特先被傳送，并且先到接收端，相應(yīng)的時(shí)延較小，但誤碼的可能性就較大，比如如果線路上遇到脈沖干擾等，這些干擾持續(xù)的時(shí)間較短，但會(huì)致使連續(xù)的比特錯(cuò)誤，如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1由于以上是按照上層來的比特流順序進(jìn)行傳送的，這樣這些連續(xù)的比特錯(cuò)誤到達(dá)接收

9、端也是連續(xù)的，達(dá)到一定程度，線路本身的差錯(cuò)控制碼（如FEC）等也將無能為力，最終產(chǎn)生線路誤碼，只能由高層協(xié)議的重傳協(xié)議來保證了。在交織情況下，線路沒有按照上層來的比特流順序進(jìn)行傳送，而是按照碼字間隔的傳送它們的比特，這是通過一個(gè)交織器，讓比特流橫向進(jìn)、縱向出來完成的，如下為交織器的工作原理：橫向進(jìn)縱向出A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1經(jīng)過交織器處理后線路上傳送的比特流順序?qū)椋築5A5C4B4A4C3B3A3C2B2A2C1B1A1到達(dá)接收端后交織器以相反的方式處理，縱向進(jìn)、橫向出，最后結(jié)果如下：縱向進(jìn)橫向出A8A7A6A5A4A

10、3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1可以很明顯的看出，通過交織處理后，同樣的脈沖干擾引起的錯(cuò)誤現(xiàn)在分布在了不同的碼字當(dāng)中，這樣在各個(gè)碼字當(dāng)中自行進(jìn)行差錯(cuò)控制就容易多了；但從另外一方面也可以看出，在接收端，碼字A只有等三個(gè)碼字都到了才能接收到最后一個(gè)比特，才能算接收完畢，這明顯加大了延遲。這一延時(shí)對(duì)于不需要確認(rèn)的數(shù)據(jù)傳輸（比如UDP連接）是沒有影響的，僅最開始那一下，但是對(duì)需要對(duì)方應(yīng)答時(shí)（比如TCP連接），這種延時(shí)將會(huì)明顯降低了傳輸速率，因?yàn)榘l(fā)送一個(gè)報(bào)文經(jīng)過一段時(shí)延才能到達(dá)對(duì)方，而對(duì)方的確認(rèn)報(bào)文又要經(jīng)過一個(gè)時(shí)延才能達(dá)到，有時(shí)交織方式的FTP下載速率甚至?xí)档?/p>

11、到快速方式的1/3左右。3.2 Unit of interleaved delay交織延遲單位DMT：直接以深度為單位，叫做交織深度interleaved depthMS：直接以時(shí)間ms為單位，叫做交織延遲interleaved delay交織深度就是上面介紹的那個(gè)交織器的縱向深度，或者說同時(shí)有幾個(gè)碼字進(jìn)行交織處理；而交織延遲其實(shí)就是交織處理后體現(xiàn)的直接結(jié)果，以此來設(shè)置交織器的話，其實(shí)內(nèi)部還要通過速率、碼字長(zhǎng)度再來換算成交織深度；交織延遲與交織深度、碼字長(zhǎng)度以及線路速率有關(guān)。以前的線路模板中兩種單位都支持，后來因?yàn)镽FC標(biāo)準(zhǔn)中只支持ms為單位，線路模板中取消了對(duì)DMT單位的支持，只支持ms單位

12、。老版本配置數(shù)據(jù)中可能存在以DMT為單位的線路模板，在數(shù)據(jù)升級(jí)過程中就有一個(gè)DMT向ms轉(zhuǎn)換的關(guān)系。根據(jù)G.992.1協(xié)議規(guī)定，轉(zhuǎn)換公式為：4 + (S-1)/4 +S×D/4，以前的線路模板配置數(shù)據(jù)都是針對(duì)ADSL單板的，而對(duì)于ADSL來說，S1，即ms4+DMT/4，DMT全部按這個(gè)公式轉(zhuǎn)換成ms。用交織延遲來描述，更直接地反映交織帶來的時(shí)延。4 一例FTP下載慢情況的分析測(cè)試場(chǎng)景1組網(wǎng)圖在上圖的組網(wǎng)方式下，F(xiàn)TP客戶端用PC1進(jìn)行下載。用ethereal抓包軟件對(duì)本次FTP下載過程在客戶端和服務(wù)器端分別進(jìn)行抓包，抓包文件為FTP-SERVER-1-2.CAP和ftp-clien

13、t-1-2.cap。其中，對(duì)服務(wù)器端的抓包是在服務(wù)器上抓的。對(duì)客戶端PC1的抓包，是在PC2上運(yùn)行抓包軟件抓的，PC1與PC2級(jí)聯(lián)了一個(gè)HUB（主要是避免PC1性能較低，運(yùn)行抓包軟件影響下載速率；HUB帶寬為100Mbps，遠(yuǎn)大于當(dāng)時(shí)的實(shí)際下載速率，不會(huì)成為瓶頸）。FTP客戶端用PC1進(jìn)行下載，下載速率為459.20Kbytes/sec。經(jīng)過多次下載，速率有少許變化，但都穩(wěn)定在450Kbytes/sec左右。很明顯，此速率遠(yuǎn)小于ADSL端口的下行帶寬24456Kbps。本下載過程中，F(xiàn)TP服務(wù)器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動(dòng)窗口為8760字節(jié)。ftp> get d9gwqg1x

14、200 PORT Command successful.150 Opening BINARY mode data connection for d9gwqg1x (16875520 bytes).226 Transfer complete.ftp: 16875520 bytes received in 36.75Seconds 459.20Kbytes/sec.我們先從數(shù)據(jù)的發(fā)送源端開始分析，看FTP SERVER是否把數(shù)據(jù)及時(shí)發(fā)送出來。通過分析FTP-SERVER-1-2.CAP文件中的數(shù)據(jù)，其數(shù)據(jù)流量發(fā)送模型如下圖。發(fā)現(xiàn)服務(wù)器端每一次突發(fā)后就會(huì)等待一段時(shí)間。分析數(shù)據(jù)，發(fā)現(xiàn)服務(wù)器端在等待客戶

15、端ACK報(bào)文確認(rèn)。如果沒有被ACK確認(rèn)的字節(jié)數(shù)加上一個(gè)報(bào)文長(zhǎng)度（很可能是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ì)丟包。FTP Server端流量模型舉例1：抓包文件FTP-SERVER-1-2.CAP，第1427號(hào)報(bào)文開始。No. Time Source Destination Protocol Info1427 27.359375 93 FTP-DATA FTP Data: 1176 bytes 1428 27.375000 93

16、 TCP 1217 > ftp-data ACK Seq=1 Ack=1100649 Win=8760 Len=0 1429 27.375000 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1103285 Win=8760 Len=0 1430 27.375000 93 FTP-DATA FTP Data: 1460 bytes 1431 27.375000 93 FTP-DATA FTP Data: 1460 by

17、tes 1432 27.375000 93 FTP-DATA FTP Data: 1176 bytes 1433 27.375000 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1105921 Win=8760 Len=0 1434 27.375000 93 FTP-DATA FTP Data: 1460 bytes 1435 27.375000 93 FTP-DATA FTP

18、 Data: 1460 bytes 1436 27.375000 93 FTP-DATA FTP Data: 1176 bytes 1437 27.390625 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1108841 Win=8760 Len=0 1438 27.390625 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1111477 Win=8760 Len=0 1439 27.3

19、90625 93 FTP-DATA FTP Data: 1460 bytes 1440 27.390625 93 FTP-DATA FTP Data: 1460 bytes 1441 27.390625 93 FTP-DATA FTP Data: 1176 bytes 1442 27.390625 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1114113 Win=8760 L

20、en=0 1443 27.390625 93 FTP-DATA FTP Data: 1460 bytes 1444 27.390625 93 FTP-DATA FTP Data: 1460 bytes 1445 27.390625 93 FTP-DATA FTP Data: 1176 bytes 1446 27.421875 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1117

21、033 Win=8760 Len=0 1447 27.421875 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1119669 Win=8760 Len=0 1448 27.421875 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1122305 Win=8760 Len=0 1449 27.421875 93 FTP-DATA FTP Data: 1460 bytes 1450 27.

22、421875 93 FTP-DATA FTP Data: 1460 bytes 1451 27.421875 93 FTP-DATA FTP Data: 1176 bytes 1452 27.421875 93 FTP-DATA FTP Data: 1460 bytes 1453 27.421875 93 FTP-DATA FTP Data: 1460 bytes 1454 27.421875 10.11.123

23、.7 93 FTP-DATA FTP Data: 1176 bytes 1455 27.437500 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1125225 Win=8760 Len=0 1456 27.437500 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1127861 Win=8760 Len=0 1457 27.437500 93 FTP-DATA F

24、TP Data: 1460 bytes 1458 27.437500 93 FTP-DATA FTP Data: 1460 bytes 1459 27.437500 93 FTP-DATA FTP Data: 1176 bytes 1460 27.437500 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1130497 Win=8760 Len=0 1461 27.437500 10.11.130.

25、193 FTP-DATA FTP Data: 1460 bytes 1462 27.437500 93 FTP-DATA FTP Data: 1460 bytes 1463 27.437500 93 FTP-DATA FTP Data: 1176 bytes此段報(bào)文中，第一個(gè)較長(zhǎng)等待發(fā)生在1436號(hào)報(bào)文，此時(shí)等待的時(shí)間比較長(zhǎng)，距離下一個(gè)發(fā)送報(bào)文時(shí)延約15ms。為什么會(huì)出現(xiàn)等待？我們往前面的報(bào)文分析。最近一次確認(rèn)報(bào)文在1433號(hào)報(bào)文處，確認(rèn)了1427號(hào)報(bào)文的數(shù)據(jù)，同時(shí)滑動(dòng)窗口為8760。也就是在1436報(bào)

26、文的時(shí)刻，共有6個(gè)報(bào)文段沒有被確認(rèn)（1430、1431、1432、1434、1435、1436號(hào)報(bào)文）。這6個(gè)報(bào)文段字節(jié)總數(shù)為8192字節(jié)，正好等于發(fā)送緩沖區(qū)的大小。如果再發(fā)送一個(gè)報(bào)文1460字節(jié)，也會(huì)超過滑動(dòng)窗口大小8760。這時(shí)，服務(wù)器肯定不會(huì)再發(fā)送報(bào)文了。在等待15ms后接收到1437號(hào)ACK報(bào)文后，再繼續(xù)發(fā)送報(bào)文。第二個(gè)較長(zhǎng)等待發(fā)生在報(bào)文1445處，距離下一個(gè)發(fā)送報(bào)文時(shí)延約31ms。1442號(hào)報(bào)文確認(rèn)了1436號(hào)報(bào)文的數(shù)據(jù)，同時(shí)滑動(dòng)窗口為8760。也就是在1445報(bào)文的時(shí)刻，共有6個(gè)報(bào)文段沒有被確認(rèn)（1439、1440、1441、1443、1444、1445號(hào)報(bào)文）。這6個(gè)報(bào)文段字節(jié)總

27、數(shù)為8192字節(jié)，正好等于發(fā)送緩沖區(qū)的大小。如果再發(fā)送一個(gè)報(bào)文1460字節(jié)，也會(huì)超過滑動(dòng)窗口大小8760。這時(shí)，服務(wù)器肯定不會(huì)再發(fā)送報(bào)文了。在等待31ms后接收到1446號(hào)ACK報(bào)文后，再繼續(xù)發(fā)送報(bào)文。可以看出，服務(wù)器發(fā)送等待的原因主要是在等待對(duì)端的ACK報(bào)文。我們繼續(xù)分析客戶端的抓包文件ftp-client-1-2.cap。從圖形上看，客戶端接收的流量要平緩一些，這說明流量經(jīng)過網(wǎng)絡(luò)設(shè)備后被平滑處理了。 FTP Client端流量模型摘取一段報(bào)文來進(jìn)行分析。No. Time Source Destination Protocol Info1393 27.358204 93

28、 TCP 1217 > ftp-data ACK Seq=1 Ack=1138689 Win=8760 Len=0 1394 27.373573 93 FTP-DATA FTP Data: 1460 bytes 1395 27.374804 93 FTP-DATA FTP Data: 1460 bytes 1396 27.375820 93 FTP-DATA FTP Data: 1176 bytes 1397 27.377042

29、 93 FTP-DATA FTP Data: 1460 bytes 1398 27.378278 93 FTP-DATA FTP Data: 1460 bytes 1399 27.379279 93 FTP-DATA FTP Data: 1176 bytes 1400 27.379343 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1141609 Win=8760 Len=0

30、1401 27.379410 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1144245 Win=8760 Len=0 1402 27.379477 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1146881 Win=8760 Len=0 1403 27.397655 93 FTP-DATA FTP Data: 1460 bytes 1404 27.398861

31、93 FTP-DATA FTP Data: 1460 bytes 1405 27.399864 93 FTP-DATA FTP Data: 1176 bytes 1406 27.401096 93 FTP-DATA FTP Data: 1460 bytes 1407 27.402324 93 FTP-DATA FTP Data: 1460 bytes 1408 27.403328 93 FT

32、P-DATA FTP Data: 1176 bytes 1409 27.403397 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1149801 Win=8760 Len=0 1410 27.403466 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1152437 Win=8760 Len=0 1411 27.403532 93 TCP 1217 > ftp-data ACK Se

33、q=1 Ack=1155073 Win=8760 Len=0 1412 27.422744 93 FTP-DATA FTP Data: 1460 bytes 1413 27.423975 93 FTP-DATA FTP Data: 1460 bytes 1414 27.424976 93 FTP-DATA FTP Data: 1176 bytes 1415 27.426206 93 FTP-DATA FTP Da

34、ta: 1460 bytes 1416 27.427437 93 FTP-DATA FTP Data: 1460 bytes 1417 27.428441 93 FTP-DATA FTP Data: 1176 bytes 1418 27.428510 93 TCP 1217 > ftp-data ACK Seq=1 Ack=1157993 Win=8760 Len=0 1419 27.430209 93 T

35、CP 1217 > ftp-data ACK Seq=1從報(bào)文段序列中可以看出，客戶端在收到FTP下載報(bào)文后很快就回應(yīng)了ACK報(bào)文，沒有大的時(shí)延。1400號(hào)報(bào)文確認(rèn)了1395號(hào)報(bào)文，1401號(hào)報(bào)文確認(rèn)了1397號(hào)報(bào)文，1402號(hào)報(bào)文確認(rèn)了1399號(hào)報(bào)文，時(shí)延分別為6ms，3ms，1ms（注：如果是在客戶端上安裝抓包軟件抓包，會(huì)發(fā)現(xiàn)每收到2個(gè)FTP報(bào)文后就立刻回應(yīng)ACK，時(shí)延在1ms內(nèi)）。綜合客戶端和服務(wù)器端的分析，服務(wù)器端在等待客戶端的ACK確認(rèn)，但客戶端也及時(shí)回應(yīng)了ACK報(bào)文。為什么等待ACK相應(yīng)的時(shí)間會(huì)比較長(zhǎng)呢？這個(gè)時(shí)間等待就應(yīng)產(chǎn)生在傳輸線路上。我們以前用SmartBits測(cè)試過AD

36、SL的線路時(shí)延，這個(gè)時(shí)延值是比較大的。對(duì)抓包文件進(jìn)行查看，客戶端和服務(wù)器端沒有丟包重傳的現(xiàn)象。所以，對(duì)于本次FTP下載過程而言，造成下載速率低的主要原因是線路時(shí)延比較大。4.1 縮短線路時(shí)延根據(jù)前面的分析，線路時(shí)延大是造成單線程FTP下載速率低的主要原因。如何減少線路的時(shí)延呢？對(duì)于不同的網(wǎng)絡(luò)設(shè)備解決方法不一樣，技術(shù)也更專業(yè)一些，在本文中不做重點(diǎn)的介紹。對(duì)于ADSL線路的下載，減小線路時(shí)延的方法可以改變ADSL的激活方式。把Interleave交織方式更改為fast快速方式，線路時(shí)延能夠提高一些，下載速率能相對(duì)提高一些。4.2 增大滑動(dòng)窗口和發(fā)送緩沖區(qū)的容量從前面的分析可以看出，服務(wù)器端處于等待

37、發(fā)送狀態(tài)，直接原因是在等待對(duì)方的ACK確認(rèn)報(bào)文。但另一方面，如果我們?cè)龃蟀l(fā)送緩沖區(qū)和接收方的滑動(dòng)窗口，則服務(wù)器可以繼續(xù)發(fā)送報(bào)文，減少等待。上面分析的例子可以看到，該下載過程中，F(xiàn)TP服務(wù)器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動(dòng)窗口為8760字節(jié)。從理論上說，時(shí)延因素并非是影響TCP下載速率的唯一因素。對(duì)于TCP傳輸能力大小，用帶寬時(shí)延乘積來描述比較合適。Capacity (bit) = bandwidth (b/s) × round-trip time (s)Capacity即TCP下載的傳輸能力，bandwidth即線路帶寬，round-trip time即報(bào)文的傳輸時(shí)延。我們可

38、以把報(bào)文的傳輸過程想象為報(bào)文放在管道上傳輸。帶寬時(shí)延乘積與傳輸管道如果想增加傳輸速率，必須盡量用報(bào)文把管道塞滿，最大可能的傳輸速率就是管道被占滿時(shí)的傳輸速率。當(dāng)傳輸時(shí)延增大時(shí)，管道會(huì)變長(zhǎng)，管道容積增加。這時(shí)傳輸同樣數(shù)量的報(bào)文管道占有率就會(huì)變稀疏，管道利用率下降。因此只要我們盡量往管道中填充報(bào)文，傳輸速率總會(huì)達(dá)到最大，哪怕傳輸時(shí)延大也不會(huì)影響最大的傳輸速率。我們通過增大發(fā)送緩沖區(qū)和接收方的滑動(dòng)窗口，就可以讓服務(wù)器盡量向管道填充數(shù)據(jù)，從而達(dá)到傳輸?shù)淖畲笏俾?。如何更改發(fā)送緩沖區(qū)大小我們使用的FTP Server軟件為SER-U version 4.0。如下圖，把Send buffer更改為81920

39、字節(jié)。調(diào)整發(fā)送緩沖區(qū)界面更改客戶端滑動(dòng)窗口大小我們可以通過“Windows優(yōu)化大師”這款軟件來修改滑動(dòng)窗口大小。調(diào)整接收滑動(dòng)窗口界面驗(yàn)證效果在同樣的組網(wǎng)和硬件配置下（把HUB去掉了，PC1直接連接在MODEM上），更改服務(wù)器端的發(fā)送緩沖區(qū)和客戶端的滑動(dòng)窗口。FTP服務(wù)器發(fā)送緩沖區(qū)為81920字節(jié)，客戶端最大滑動(dòng)窗口為65535字節(jié)。下載速率達(dá)到1442.35Kbytes/sec，下載速率有很大的提高。ftp> get D9GWQG1X200 PORT Command successful.150 Opening BINARY mode data connection for D9GWQG

40、1X (16875520 bytes).226 Transfer complete.ftp: 16875520 bytes received in 11.70Seconds 1442.35Kbytes/sec.在服務(wù)器端的抓包分析模型如下圖：優(yōu)化后的FTP下載模型很明顯的看到，雖然服務(wù)器突發(fā)的間隔與以前相比差不多（線路時(shí)延沒有改變），但突發(fā)的流量大了很多（注意縱軸刻度有變化），這就是因?yàn)榘l(fā)送緩沖區(qū)和滑動(dòng)窗口增大的緣故。5 佛山網(wǎng)通現(xiàn)網(wǎng)測(cè)試的結(jié)果佛山網(wǎng)通UA5000 ADSL/ADSL2+FTP下載速率測(cè)試參與測(cè)試人員：楊黎崗；呂江；冼康怡測(cè)試地點(diǎn)：華勝機(jī)房測(cè)試時(shí)間：2006-7-27測(cè)試環(huán)境：

41、5.1 ADSL/ADSL2+FTP下載速率測(cè)試（突出改變時(shí)延帶來的影響）驗(yàn)收目的驗(yàn)證PPPoE業(yè)務(wù)下載速度預(yù)置條件測(cè)試終端安裝有PPPoE撥號(hào)軟件。BAS是具有PPPoE終結(jié)功能的接入服務(wù)器，且配置有PPPoE帳號(hào)和IP地址池。此處可以使用路由器等其它具備功能條件的設(shè)備。測(cè)試過程建立不同ADSLADSL2+線路模版在測(cè)試終端上發(fā)起PPPoE呼叫，申請(qǐng)IP地址，訪問Internet。使用不同線路模版并能正常激活，達(dá)到速率限制要求。 測(cè)試結(jié)果線路模板參數(shù)ftp下載速率（KB/s）MODEM類型上行下行通道模式（上行交織時(shí)延，下行交織時(shí)延）Ping時(shí)延（ms）線路模板類型ADSLADSL2+512

42、4096Interleave（6，6）14345363MT8805124096Interleave（16，6）252325124096Fast84524585124096Interleave（6，6）14340378MT8005124096Interleave（16，6）5124096Fast8421422測(cè)試說明應(yīng)用不同模板激活端口，進(jìn)行FTP下載速率測(cè)試?？蛻舸砗炞郑簵罾鑽?華為督導(dǎo)簽字：冼康怡 日期：2006.7.27測(cè)試地點(diǎn)：華勝機(jī)房測(cè)試結(jié)論：1、 交織方式會(huì)帶來的時(shí)延，測(cè)試數(shù)據(jù)與交織時(shí)延設(shè)置吻合2、 較大的交織時(shí)延設(shè)置引起FTP下載速率有所降低。如上表，交織時(shí)延有6加大到16，速率

43、降低不少。變化的量級(jí)和前文分析的吻合3、 解釋為什么前一天測(cè)試ADSL和ADSL2+同樣是交織模式，會(huì)有很大差異。通過比較了ADSL模板以及ADSL2+模板配置的差異，找出由于交織時(shí)延在ADSL模板上默認(rèn)的上下行時(shí)延為6，6；ADSL2+模板上默認(rèn)的上下行時(shí)延為16，6，由于上行設(shè)置時(shí)延值的不同，直接影響了ftp下載速度。參與測(cè)試人員：楊黎崗；廖曉鋒；冼康怡測(cè)試地點(diǎn)：嶺南雅居接入通信機(jī)房測(cè)試時(shí)間：2006-7-26測(cè)試內(nèi)容：選取了嶺南雅居接入通信機(jī)房的MA5605設(shè)備進(jìn)行ADSL/ADSL2+速率測(cè)試，此次利用windows優(yōu)化大師在同一臺(tái)電腦上分別將傳輸單元緩沖區(qū)（TcpWindowSize

44、）改為8192bytes和255552bytes進(jìn)行測(cè)試，測(cè)試結(jié)果如下表：5.2 ADSL下載速率測(cè)試（突出改變緩沖區(qū)帶來的影響）驗(yàn)收目的驗(yàn)證PPPoE業(yè)務(wù)下載速度預(yù)置條件測(cè)試終端安裝有PPPoE撥號(hào)軟件。BAS是具有PPPoE終結(jié)功能的接入服務(wù)器，且配置有PPPoE帳號(hào)和IP地址池。此處可以使用路由器等其它具備功能條件的設(shè)備。測(cè)試過程建立不同ADSL線路模版在測(cè)試終端上發(fā)起PPPoE呼叫，申請(qǐng)IP地址，訪問Internet。使用不同線路模版并能正常激活，達(dá)到速率限制要求。 測(cè)試結(jié)果線路模板（ADSL模板）ftp下載速率（KB/s）結(jié)論：同等條件下減小時(shí)延可以提高下載速率。不過隨著緩沖區(qū)的極大

45、化，減少時(shí)延能帶來的速率提升變得不明顯上行下行通道模式（上行交織時(shí)延，下行交織時(shí)延）傳輸單元緩沖區(qū)TcpWindowSize-Byte81922555525122048Interleave（6，6）2162295122048Fast2172325124096Interleave（6，6）2794625124096Fast3704635126144Interleave（6，6）2826955126144fast415696測(cè)試說明應(yīng)用不同模板激活端口，進(jìn)行速度測(cè)試?？蛻舸砗炞郑簵罾鑽?華為督導(dǎo)簽字：冼康怡 日期：2006.7.26測(cè)試地點(diǎn)：嶺南雅居接入通信機(jī)房測(cè)試結(jié)論：1、 同等條件下減小時(shí)延可以提高下載速率。2、 隨著緩沖區(qū)的極大化，減少時(shí)延能帶來的速