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

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

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

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

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

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

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

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

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

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

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

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

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

13、t-1-2.cap。其中，對服務器端的抓包是在服務器上抓的。對客戶端PC1的抓包，是在PC2上運行抓包軟件抓的，PC1與PC2級聯(lián)了一個HUB（主要是避免PC1性能較低，運行抓包軟件影響下載速率；HUB帶寬為100Mbps，遠大于當時的實際下載速率，不會成為瓶頸）。FTP客戶端用PC1進行下載，下載速率為459.20Kbytes/sec。經(jīng)過多次下載，速率有少許變化，但都穩(wěn)定在450Kbytes/sec左右。很明顯，此速率遠小于ADSL端口的下行帶寬24456Kbps。本下載過程中，F(xiàn)TP服務器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動窗口為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ù)及時發(fā)送出來。通過分析FTP-SERVER-1-2.CAP文件中的數(shù)據(jù)，其數(shù)據(jù)流量發(fā)送模型如下圖。發(fā)現(xiàn)服務器端每一次突發(fā)后就會等待一段時間。分析數(shù)據(jù)，發(fā)現(xiàn)服務器端在等待客戶

15、端ACK報文確認。如果沒有被ACK確認的字節(jié)數(shù)加上一個報文長度（很可能是1460字節(jié)，請參考發(fā)送報文數(shù)據(jù)大小序列）大于對方的滑動窗口，此時服務器是不會發(fā)送報文的，因為再發(fā)送報文很可能會丟包。FTP Server端流量模型舉例1：抓包文件FTP-SERVER-1-2.CAP，第1427號報文開始。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此段報文中，第一個較長等待發(fā)生在1436號報文，此時等待的時間比較長，距離下一個發(fā)送報文時延約15ms。為什么會出現(xiàn)等待？我們往前面的報文分析。最近一次確認報文在1433號報文處，確認了1427號報文的數(shù)據(jù)，同時滑動窗口為8760。也就是在1436報

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

27、數(shù)為8192字節(jié)，正好等于發(fā)送緩沖區(qū)的大小。如果再發(fā)送一個報文1460字節(jié)，也會超過滑動窗口大小8760。這時，服務器肯定不會再發(fā)送報文了。在等待31ms后接收到1446號ACK報文后，再繼續(xù)發(fā)送報文?？梢钥闯?，服務器發(fā)送等待的原因主要是在等待對端的ACK報文。我們繼續(xù)分析客戶端的抓包文件ftp-client-1-2.cap。從圖形上看，客戶端接收的流量要平緩一些，這說明流量經(jīng)過網(wǎng)絡設備后被平滑處理了。 FTP Client端流量模型摘取一段報文來進行分析。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從報文段序列中可以看出，客戶端在收到FTP下載報文后很快就回應了ACK報文，沒有大的時延。1400號報文確認了1395號報文，1401號報文確認了1397號報文，1402號報文確認了1399號報文，時延分別為6ms，3ms，1ms（注：如果是在客戶端上安裝抓包軟件抓包，會發(fā)現(xiàn)每收到2個FTP報文后就立刻回應ACK，時延在1ms內(nèi)）。綜合客戶端和服務器端的分析，服務器端在等待客戶端的ACK確認，但客戶端也及時回應了ACK報文。為什么等待ACK相應的時間會比較長呢？這個時間等待就應產(chǎn)生在傳輸線路上。我們以前用SmartBits測試過AD

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

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

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

39、字節(jié)。調(diào)整發(fā)送緩沖區(qū)界面更改客戶端滑動窗口大小我們可以通過“Windows優(yōu)化大師”這款軟件來修改滑動窗口大小。調(diào)整接收滑動窗口界面驗證效果在同樣的組網(wǎng)和硬件配置下（把HUB去掉了，PC1直接連接在MODEM上），更改服務器端的發(fā)送緩沖區(qū)和客戶端的滑動窗口。FTP服務器發(fā)送緩沖區(qū)為81920字節(jié)，客戶端最大滑動窗口為65535字節(jié)。下載速率達到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.在服務器端的抓包分析模型如下圖：優(yōu)化后的FTP下載模型很明顯的看到，雖然服務器突發(fā)的間隔與以前相比差不多（線路時延沒有改變），但突發(fā)的流量大了很多（注意縱軸刻度有變化），這就是因為發(fā)送緩沖區(qū)和滑動窗口增大的緣故。5 佛山網(wǎng)通現(xiàn)網(wǎng)測試的結(jié)果佛山網(wǎng)通UA5000 ADSL/ADSL2+FTP下載速率測試參與測試人員：楊黎崗；呂江；冼康怡測試地點：華勝機房測試時間：2006-7-27測試環(huán)境：

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

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

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

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

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