ftp下載速率慢原因分析與處理指導(dǎo)書(華為)-全文預(yù)覽
【正文】 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此段報(bào)文中，第一個(gè)較長(zhǎng)等待發(fā)生在1436號(hào)報(bào)文，此時(shí)等待的時(shí)間比較長(zhǎng)，距離下一個(gè)發(fā)送報(bào)文時(shí)延約15ms。發(fā)現(xiàn)服務(wù)器端每一次突發(fā)后就會(huì)等待一段時(shí)間。很明顯，此速率遠(yuǎn)小于ADSL端口的下行帶寬24456Kbps。其中，對(duì)服務(wù)器端的抓包是在服務(wù)器上抓的。轉(zhuǎn)換公式為：4 + (S1)/4 +SD/4，以前的線路模板配置數(shù)據(jù)都是針對(duì)ADSL單板的，而對(duì)于ADSL來(lái)說(shuō)，S＝1，即ms＝4+DMT/4，DMT全部按這個(gè)公式轉(zhuǎn)換成ms。這一延時(shí)對(duì)于不需要確認(rèn)的數(shù)據(jù)傳輸（比如UDP連接）是沒有影響的，僅最開始那一下，但是對(duì)需要對(duì)方應(yīng)答時(shí)（比如TCP連接），這種延時(shí)將會(huì)明顯降低了傳輸速率，因?yàn)榘l(fā)送一個(gè)報(bào)文經(jīng)過(guò)一段時(shí)延才能到達(dá)對(duì)方，而對(duì)方的確認(rèn)報(bào)文又要經(jīng)過(guò)一個(gè)時(shí)延才能達(dá)到，有時(shí)交織方式的FTP下載速率甚至?xí)档偷娇焖俜绞降?/3左右。3 ADSL模板中交織與快速的區(qū)別 Channel mode－通道模式Fast：快速方式，糾錯(cuò)能力一般，但延遲較小，適用于那些對(duì)延遲敏感的業(yè)務(wù)，比如視頻點(diǎn)播、可視電話等。我們可以想想，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)只會(huì)send一次，TCP層的重傳就靠自己了，所以原始的數(shù)據(jù)不會(huì)在TCP發(fā)送緩沖區(qū)中被清除掉。在對(duì)方滑動(dòng)窗口足夠大的情況下，發(fā)送端發(fā)送的未被確認(rèn)的數(shù)據(jù)大小不能超過(guò)發(fā)送緩沖區(qū)的大小?；瑒?dòng)窗口會(huì)動(dòng)態(tài)調(diào)整的。 滑動(dòng)窗口與接收緩沖區(qū)滑動(dòng)窗口是數(shù)據(jù)接收方控制數(shù)據(jù)傳輸流量的重要手段，此值反映的也是TCP接收緩沖區(qū)的大小。在下載大文件時(shí)，發(fā)送報(bào)文數(shù)據(jù)大小序列一般為：1460，1460，1460，1460，1460，892或1460，1460，1176，1460，1460，1176，一般不會(huì)發(fā)送小數(shù)據(jù)的報(bào)文。在以太網(wǎng)上傳輸時(shí)，以太網(wǎng)最大幀長(zhǎng)為1518字節(jié)，去除以太網(wǎng)幀頭及校驗(yàn)，以太網(wǎng)幀的凈荷為1500字節(jié)。2 TCP相關(guān)知識(shí)點(diǎn)問(wèn)題分析涉及到的TCP知識(shí)點(diǎn)介紹一下。首先強(qiáng)調(diào)一點(diǎn)，F(xiàn)TP下載速率肯定不會(huì)大于通道的帶寬，因?yàn)锳DSL通道就好比運(yùn)載貨物的列車，我們只可能盡量的裝滿它，但絕不會(huì)超過(guò)它；甚至使用多個(gè)FTP同時(shí)下載，每個(gè)FTP下載速度的總和也不會(huì)大于通道的帶寬（測(cè)試標(biāo)準(zhǔn)中均建議使用多個(gè)FTP同時(shí)下載）。我們?cè)跍y(cè)試時(shí)經(jīng)常會(huì)發(fā)現(xiàn)FTP下載速率比ADSL的帶寬小很多，本文就是從原理入手逐步分析問(wèn)題的原因。使用FTP下載是一種比較方便（或者說(shuō)常規(guī)應(yīng)用中也沒有比它更好的）的方式來(lái)判斷帶寬的方法，不過(guò)我們要盡可能排除一切瓶頸，使FTP下載速度接近通道的帶寬。如果每個(gè)報(bào)文段的容量過(guò)小，則會(huì)影響到發(fā)送效率。假設(shè)FTP下載的發(fā)送緩沖區(qū)為8K bytes。確認(rèn)序列號(hào)用于通知對(duì)方，對(duì)方送過(guò)來(lái)的數(shù)據(jù)中小于此序列號(hào)的報(bào)文都被正確接收（包括不會(huì)亂序，不會(huì)丟失報(bào)文）。除非發(fā)送方收到了新的確認(rèn)報(bào)文，或收到對(duì)方滑動(dòng)窗口擴(kuò)大后，前面所說(shuō)的限制被打破，才可能繼續(xù)發(fā)送報(bào)文。 發(fā)送緩沖區(qū)發(fā)送緩沖區(qū)的大小會(huì)影響到發(fā)送策略。只要是沒有被確認(rèn)的數(shù)據(jù)都可能會(huì)重傳，發(fā)送緩沖區(qū)不會(huì)將這些數(shù)據(jù)從緩沖區(qū)中清除，否則需要重傳時(shí)找不到這些數(shù)據(jù)。一旦發(fā)現(xiàn)有擁塞現(xiàn)象（超時(shí)或收到重復(fù)確認(rèn)），發(fā)送方會(huì)降低發(fā)送速度。在交織情況下，線路沒有按照上層來(lái)的比特流順序進(jìn)行傳送，而是按照碼字間隔的傳送它們的比特，這是通過(guò)一個(gè)交織器，讓比特流橫向進(jìn)、縱向出來(lái)完成的，如下為交織器的工作原理：橫向進(jìn)↑縱向出→→→A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1經(jīng)過(guò)交織器處理后線路上傳送的比特流順序?qū)椋築5A5C4B4A4C3B3A3C2B2A2C1B1A1→→到達(dá)接收端后交織器以相反的方式處理，縱向進(jìn)、橫向出，最后結(jié)果如下：縱向進(jìn)↓橫向出A8A7A6A5A4A3A2A1→→→B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1可以很明顯的看出，通過(guò)交織處理后，同樣的脈沖干擾引起的錯(cuò)誤現(xiàn)在分布在了不同的碼字當(dāng)中，這樣在各個(gè)碼字當(dāng)中自行進(jìn)行差錯(cuò)控制就容易多了；但從另外一方面也可以看出，在接收端，碼字A只有等三個(gè)碼字都到了才能接收到最后一個(gè)比特，才能算接收完畢，這明顯加大了延遲。老版本配置數(shù)據(jù)中可能存在以DMT為單位的線路模板，在數(shù)據(jù)升級(jí)過(guò)程中就有一個(gè)DMT向ms轉(zhuǎn)換的關(guān)系。用ethereal抓包軟件對(duì)本次FTP下載過(guò)程在客戶端和服務(wù)器端分別進(jìn)行抓包。經(jīng)過(guò)多次下載，速率有少許變化，但都穩(wěn)定在450Kbytes/sec左右。，其數(shù)據(jù)流量發(fā)送模型如下圖。FTP Server端流量模型舉例1：，第1427號(hào)報(bào)文開始。也就是在1436報(bào)文的時(shí)刻，共有6個(gè)報(bào)文段沒有被確認(rèn)（141431431431431436號(hào)報(bào)文）。在等待15ms后接收到1437號(hào)ACK報(bào)文后，再繼續(xù)發(fā)送報(bào)文。這6個(gè)報(bào)文段字節(jié)總數(shù)為8192字節(jié)，正好等于發(fā)送緩沖區(qū)的大小?？梢钥闯?，服務(wù)器發(fā)送等待的原因主要是在等待對(duì)端的ACK報(bào)文。No. Time Source Destination Protocol Info1393 TCP 1217 ftpdata [ACK] Seq=1 Ack=1138689 Win=8760 Len=0 1394 FTPDATA FTP Data:
規(guī)章制度相關(guān)推薦
鄂ICP備17016276號(hào)-1