【正文】 織延遲單位 54 一例FTP下載慢情況的分析 6 縮短線路時延 10 增大滑動窗口和發(fā)送緩沖區(qū)的容量 105 佛山網通現(xiàn)網測試的結果 13 ADSL/ADSL2+FTP下載速率測試（突出改變時延帶來的影響） 14 ADSL下載速率測試（突出改變緩沖區(qū)帶來的影響） 15 ADSL2+下載速率測試（同樣是突出改變緩沖區(qū)帶來的影響） 166 結論 17學習參考FTP下載速率慢原因分析及處理指導書1 背景描述在DSLAM的應用中，經常用到FTP下載來測試ADSL的帶寬。熟悉TCP的人可以跳過此節(jié)，太不熟悉TCP的人請直接參考TCP/IP相關資料，此處不做過多的基本知識介紹。 TCP發(fā)送報文的確認在一個TCP報文中包含有發(fā)送序列號和確認序列號。當應用層從接收緩沖區(qū)取走數據時滑動窗口就會擴大，接收緩沖區(qū)收到新的報文時滑動窗口會減少。 慢啟動與擁塞避免算法如果發(fā)送緩沖區(qū)和接收緩沖區(qū)（滑動窗口）都足夠大，那么發(fā)送端是否會盡量發(fā)送數據呢？如果中間網絡出現(xiàn)擁塞或丟包，快速發(fā)送報文會造成不斷的重傳，傳輸效率會更低。 Unit of interleaved delay－交織延遲單位DMT：直接以深度為單位，叫做交織深度interleaved depthMS：直接以時間ms為單位，叫做交織延遲interleaved delay交織深度就是上面介紹的那個交織器的縱向深度，或者說同時有幾個碼字進行交織處理；而交織延遲其實就是交織處理后體現(xiàn)的直接結果，以此來設置交織器的話，其實內部還要通過速率、碼字長度再來換算成交織深度；交織延遲與交織深度、碼字長度以及線路速率有關。對客戶端PC1的抓包，是在PC2上運行抓包軟件抓的，PC1與PC2級聯(lián)了一個HUB（主要是避免PC1性能較低，運行抓包軟件影響下載速率；HUB帶寬為100Mbps，遠大于當時的實際下載速率，不會成為瓶頸）。分析數據，發(fā)現(xiàn)服務器端在等待客戶端ACK報文確認。如果再發(fā)送一個報文1460字節(jié)，也會超過滑動窗口大小8760。這時，服務器肯定不會再發(fā)送報文了。綜合客戶端和服務器端的分析，服務器端在等待客戶端的ACK確認，但客戶端也及時回應了ACK報文。把Interleave交織方式更改為fast快速方式，線路時延能夠提高一些，下載速率能相對提高一些。帶寬時延乘積與傳輸管道如果想增加傳輸速率，必須盡量用報文把管道塞滿，最大可能的傳輸速率就是管道被占滿時的傳輸速率。調整接收滑動窗口界面驗證效果在同樣的組網和硬件配置下（把HUB去掉了，PC1直接連接在MODEM上），更改服務器端的發(fā)送緩沖區(qū)和客戶端的滑動窗口。使用不同線路模版并能正常激活，達到速率限制要求。此處可以使用路由器等其它具備功能條件的設備。BAS是具有PPPoE終結功能的接入服務器，且配置有PPPoE帳號和IP地址池。6 結論FTP下載是一個端到端的處理過程。傳輸時延比較大可能會超成數據發(fā)送等待，線路帶寬不能盡量利用。如果我們多開幾個FTP下載進程，發(fā)現(xiàn)總的下載速率明顯大于單FTP下載速率，這時可以判斷是時延導致下載速率慢。我不知道年少輕狂，我只知道勝者為王。首先看傳輸線路的帶寬有多大。從ACK確認報文的效率看，WinXp的算法會高一些，因為少量的ACK報文確認了更多的接收報文。 測試結果線路模板（ADSL2+模板）ftp下載速率（KB/s）結論：同等條件下減小時延可以提高下載速率。不過隨著緩沖區(qū)的極大化，減少時延能帶來的速率提升變得不明顯上行下行通道模式（上行交織時延，下行交織時延）傳輸單元緩沖區(qū)TcpWindowSizeByte81922555525122048Interleave（6，6）2162295122048Fast2172325124096Interleave（6，6）2794625124096Fast3704635126144Interleave（6，6）2826955126144fast415696測試說明應用不同模板激活端口，進行速度測試。變化的量級和前文分析的吻合 解釋為什么前一天測試ADSL和ADSL2+同樣是交織模式，會有很大差異。5 佛山網通現(xiàn)網測試的結果佛山網通UA5000 ADSL/ADSL2+FTP下載速率測試參與測試人員：楊黎崗；呂江；冼康怡測試地點：華勝機房測試時間：2006727測試環(huán)境： ADSL/ADSL2+FTP下載速率測試（突出改變時延帶來的影響）驗收目的驗證PPPoE業(yè)務下載速度預置條件測試終端安裝有PPPoE撥號軟件。我們通過增大發(fā)送緩沖區(qū)和接收方的滑動窗口，就可以讓服務器盡量向管道填充數據，從而達到傳輸的最大速率。從理論上說，時延因素并非是影響TCP下載速率的唯一因素。所以，對于本次FTP下載過程而言，造成下載速率低的主要原因是線路時延比較大。從圖形上看，客戶端接收的流量要平緩一些，這說明流量經過網絡設備后被平滑處理了。1442號報文確認了1436號報文的數據，同時滑動窗口為8760。為什么會出現(xiàn)等待？我們往前面的報文分析。本下載過程中，F(xiàn)TP服務器發(fā)送緩沖區(qū)為8192字節(jié)，客戶端最大滑動窗口為8760字節(jié)。用交織延遲來描述，更直接地反映交織帶來的時延。Interleaved：交織方式，糾錯能力較強，隨著深度越深，糾錯能力越強，但相應的延遲就越大，這種方式適用于那些對可靠性要求較高但不太在意延遲的業(yè)務。一旦到達發(fā)送緩沖區(qū)大小的臨界點，則發(fā)送端停止發(fā)送。數據接收方通過此值告知對方自己的接收緩沖區(qū)大小，讓發(fā)送方根據此值調整發(fā)送策略。IP報文頭最小字節(jié)數為20，TCP報文頭最小字節(jié)數為20，TCP報文最大凈荷就為1460字節(jié)了。其次，F(xiàn)TP下載是一個端到端的處理過程。下載速率涉及到端到端整個業(yè)務流程的每個環(huán)節(jié)，包括了硬件性能、線路帶寬、線路時延，緩沖區(qū)算法等。在TCP連接建立時，協(xié)商出來的最大報文段為1460字節(jié)。發(fā)送方已經發(fā)送但還沒有被確認的數據字節(jié)，加上即將要發(fā)送的數據字節(jié)數之和大于對方的滑動窗口，則發(fā)送方會停止發(fā)送報文。這是因為已發(fā)送但還沒有被確認的數據還會繼續(xù)滯留在發(fā)送緩沖區(qū)中，占用了空間。下面簡單介紹一下快速、交織的處理過程；比如首先假定上層來的順序比特流如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1→→一般沒有交織的情況下（如快速方式），線路是按照上層來的比特流順序進行傳送，這樣前面的比特先被傳送，并且先到接收端，相應的時延較小，但誤碼的可能性就較大，比如如果線路上遇到脈沖干擾等，這些干擾持續(xù)的時間較短，但會致使連續(xù)的比特錯誤，如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1→→由于以上是按照上層來的比特流順序進行傳送的，這樣這些連續(xù)的比特錯誤到達接收端也是連續(xù)的，達到一定程度，線路本身的差錯控制碼（如FEC）等也將無能為力，最終產生線路誤碼，只能由高層協(xié)議的重