FTP下载速率慢原因分析及处理指导书华为.docx
《FTP下载速率慢原因分析及处理指导书华为.docx》由会员分享，可在线阅读，更多相关《FTP下载速率慢原因分析及处理指导书华为.docx（23页珍藏版）》请在冰点文库上搜索。
FTP下载速率慢原因分析及处理指导书华为
1背景描述2
2TCP相关知识点2
2.1TCP传输的最大报文段2
2.2TCP发送报文的确认3
2.3滑动窗口与接收缓冲区3
2.4发送缓冲区3
2.5慢启动与拥塞避免算法3
3ADSL模板织与快速的区别4
3.1Channelmode－通道模式4
3.2Unitofinterleaveddelay－交织延迟单位5
4一例FTP下载慢情况的分析6
4.1缩短线路时延10
4.2增大滑动窗口和发送缓冲区的容量10
5网通现网测试的结果13
5.1ADSL/ADSL2+FTP下载速率测试（突出改变时延带来的影响）14
5.2ADSL下载速率测试（突出改变缓冲区带来的影响）15
5.3ADSL2+下载速率测试（同样是突出改变缓冲区带来的影响）16
6结论17
FTP下载速率慢原因分析及处理指导书
1背景描述
在DSLAM的应用中，经常用到FTP下载来测试ADSL的带宽。
我们在测试时经常会发现FTP下载速率比ADSL的带宽小很多，本文就是从原理入手逐步分析问题的原因。
首先强调一点，FTP下载速率肯定不会大于通道的带宽，因为ADSL通道就好比运载货物的列车，我们只可能尽量的装满它，但绝不会超过它；甚至使用多个FTP同时下载，每个FTP下载速度的总和也不会大于通道的带宽（测试标准中均建议使用多个FTP同时下载）。
其次，FTP下载是一个端到端的处理过程。
下载速率涉及到端到端整个业务流程的每个环节，包括了硬件性能、线路带宽、线路时延，缓冲区算法等。
使用FTP下载是一种比较方便（或者说常规应用中也没有比它更好的）的方式来判断带宽的方法，不过我们要尽可能排除一切瓶颈，使FTP下载速度接近通道的带宽。
2TCP相关知识点
问题分析涉及到的TCP知识点介绍一下。
熟悉TCP的人可以跳过此节，太不熟悉TCP的人请直接参考TCP/IP相关资料，此处不做过多的基本知识介绍。
2.1TCP传输的最大报文段
TCP下载大文件时，需要把大文件切割为一系列报文段进行发送。
如果每个报文段的容量过小，则会影响到发送效率。
在以太网上传输时，以太网最大帧长为1518字节，去除以太网帧头及校验，以太网帧的净荷为1500字节。
IP报文头最小字节数为20，TCP报文头最小字节数为20，TCP报文最大净荷就为1460字节了。
在TCP连接建立时，协商出来的最大报文段为1460字节。
假设FTP下载的发送缓冲区为8Kbytes。
在下载大文件时，发送报文数据大小序列一般为：
1460，1460，1460，1460，1460，892或1460，1460，1176，1460，1460，1176，一般不会发送小数据的报文。
2.2TCP发送报文的确认
在一个TCP报文中包含有发送序列号和确认序列号。
发送序列号是对自己发送数据的一个编号，一次连接中发送的数据会连续编号，通过发送序列号对发送的数据进行标志。
确认序列号用于通知对方，对方送过来的数据中小于此序列号的报文都被正确接收（包括不会乱序，不会丢失报文）。
2.3滑动窗口与接收缓冲区
滑动窗口是数据接收方控制数据传输流量的重要手段，此值反映的也是TCP接收缓冲区的大小。
数据接收方通过此值告知对方自己的接收缓冲区大小，让发送方根据此值调整发送策略。
发送方已经发送但还没有被确认的数据字节，加上即将要发送的数据字节数之和大于对方的滑动窗口，则发送方会停止发送报文。
除非发送方收到了新的确认报文，或收到对方滑动窗口扩大后，前面所说的限制被打破，才可能继续发送报文。
滑动窗口会动态调整的。
当应用层从接收缓冲区取走数据时滑动窗口就会扩大，接收缓冲区收到新的报文时滑动窗口会减少。
当滑动窗口变化时，会依据一定的策略向对方发送滑动窗口更新通告，算法可参考TCP/IP相关文档。
2.4发送缓冲区
发送缓冲区的大小会影响到发送策略。
在对方滑动窗口足够大的情况下，发送端发送的未被确认的数据大小不能超过发送缓冲区的大小。
一旦到达发送缓冲区大小的临界点，则发送端停止发送。
这是因为已发送但还没有被确认的数据还会继续滞留在发送缓冲区中，占用了空间。
只要是没有被确认的数据都可能会重传，发送缓冲区不会将这些数据从缓冲区中清除，否则需要重传时找不到这些数据。
我们可以想想，应用层发送数据时只会send一次，TCP层的重传就靠自己了，所以原始的数据不会在TCP发送缓冲区中被清除掉。
2.5慢启动与拥塞避免算法
如果发送缓冲区和接收缓冲区（滑动窗口）都足够大，那么发送端是否会尽量发送数据呢？
如果中间网络出现拥塞或丢包，快速发送报文会造成不断的重传，传输效率会更低。
TCP会采用拥塞避免算法和慢启动来调整发送策略，避免传输线路上的数据拥塞。
一旦发现有拥塞现象（超时或收到重复确认），发送方会降低发送速度。
3ADSL模板织与快速的区别
3.1Channelmode－通道模式
Fast：
快速方式，纠错能力一般，但延迟较小，适用于那些对延迟敏感的业务，比如视频点播、可视等。
Interleaved：
交织方式，纠错能力较强，随着深度越深，纠错能力越强，但相应的延迟就越大，这种方式适用于那些对可靠性要求较高但不太在意延迟的业务。
下面简单介绍一下快速、交织的处理过程；
比如首先假定上层来的顺序比特流如下：
B6
B5
B4
B3
B2
B1
A8
A7
A6
A5
A4
A3
A2
A1
→→
一般没有交织的情况下（如快速方式），线路是按照上层来的比特流顺序进行传送，这样前面的比特先被传送，并且先到接收端，相应的时延较小，但误码的可能性就较大，比如如果线路上遇到脉冲干扰等，这些干扰持续的时间较短，但会致使连续的比特错误，如下：
B6
B5
B4
B3
B2
B1
A8
A7
A6
A5
A4
A3
A2
A1
→→
由于以上是按照上层来的比特流顺序进行传送的，这样这些连续的比特错误到达接收端也是连续的，达到一定程度，线路本身的差错控制码（如FEC）等也将无能为力，最终产生线路误码，只能由高层协议的重传协议来保证了。
在交织情况下，线路没有按照上层来的比特流顺序进行传送，而是按照码字间隔的传送它们的比特，这是通过一个交织器，让比特流横向进、纵向出来完成的，如下为交织器的工作原理：
横向进
↑
纵向出
→→→
A8
A7
A6
A5
A4
A3
A2
A1
B8
B7
B6
B5
B4
B3
B2
B1
C8
C7
C6
C5
C4
C3
C2
C1
经过交织器处理后线路上传送的比特流顺序将为：
B5
A5
C4
B4
A4
C3
B3
A3
C2
B2
A2
C1
B1
A1
→→
到达接收端后交织器以相反的方式处理，纵向进、横向出，最后结果如下：
纵向进
↓
横向出
A8
A7
A6
A5
A4
A3
A2
A1
→→→
B8
B7
B6
B5
B4
B3
B2
B1
C8
C7
C6
C5
C4
C3
C2
C1
可以很明显的看出，通过交织处理后，同样的脉冲干扰引起的错误现在分布在了不同的码字当中，这样在各个码字当中自行进行差错控制就容易多了；但从另外一方面也可以看出，在接收端，码字A只有等三个码字都到了才能接收到最后一个比特，才能算接收完毕，这明显加大了延迟。
这一延时对于不需要确认的数据传输（比如UDP连接）是没有影响的，仅最开始那一下，但是对需要对方应答时（比如TCP连接），这种延时将会明显降低了传输速率，因为发送一个报文经过一段时延才能到达对方，而对方的确认报文又要经过一个时延才能达到，有时交织方式的FTP下载速率甚至会降低到快速方式的1/3左右。
3.2Unitofinterleaveddelay－交织延迟单位
DMT：
直接以深度为单位，叫做交织深度interleaveddepth
MS：
直接以时间ms为单位，叫做交织延迟interleaveddelay
交织深度就是上面介绍的那个交织器的纵向深度，或者说同时有几个码字进行交织处理；而交织延迟其实就是交织处理后体现的直接结果，以此来设置交织器的话，其实部还要通过速率、码字长度再来换算成交织深度；交织延迟与交织深度、码字长度以及线路速率有关。
以前的线路模板中两种单位都支持，后来因为RFC标准中只支持ms为单位，线路模板中取消了对DMT单位的支持，只支持ms单位。
老版本配置数据中可能存在以DMT为单位的线路模板，在数据升级过程中就有一个DMT向ms转换的关系。
根据G.992.1协议规定，转换公式为：
4+（S-1）/4+S×D/4，以前的线路模板配置数据都是针对ADSL单板的，而对于ADSL来说，S＝1，即ms＝4+DMT/4，DMT全部按这个公式转换成ms。
用交织延迟来描述，更直接地反映交织带来的时延。
4一例FTP下载慢情况的分析
测试场景1组网图
在上图的组网方式下，FTP客户端用PC1进行下载。
用ethereal抓包软件对本次FTP下载过程在客户端和服务器端分别进行抓包，抓包文件为FTP-SERVER-1-2.CAP和ftp-client-1-2.cap。
其中，对服务器端的抓包是在服务器上抓的。
对客户端PC1的抓包，是在PC2上运行抓包软件抓的，PC1与PC2级联了一个HUB（主要是避免PC1性能较低，运行抓包软件影响下载速率；HUB带宽为100Mbps，远大于当时的实际下载速率，不会成为瓶颈）。
FTP客户端用PC1进行下载，下载速率为459.20Kbytes/sec。
经过多次下载，速率有少许变化，但都稳定在450Kbytes/sec左右。
很明显，此速率远小于ADSL端口的下行带宽24456Kbps。
本下载过程中，FTP服务器发送缓冲区为8192字节，客户端最大滑动窗口为8760字节。
ftp>getd9gwqg1x
200PORTCommandsuccessful.
150OpeningBINARYmodedataconnectionford9gwqg1x（16875520bytes）.
226Transfercomplete.
ftp:
16875520bytesreceivedin36.75Seconds459.20Kbytes/sec.
我们先从数据的发送源端开始分析，看FTPSERVER是否把数据及时发送出来。
通过分析FTP-SERVER-1-2.CAP文件中的数据，其数据流量发送模型如下图。
发现服务器端每一次突发后就会等待一段时间。
分析数据，发现服务器端在等待客户端ACK报文确认。
如果没有被ACK确认的字节数加上一个报文长度（很可能是1460字节，请参考发送报文数据大小序列）大于对方的滑动窗口，此时服务器是不会发送报文的，因为再发送报文很可能会丢包。
FTPServer端流量模型
举例1：
抓包文件FTP-SERVER-1-2.CAP，第1427号报文开始。
No.TimeSourceDestinationProtocolInfo
142727.35937510.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
142827.37500010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1100649Win=8760Len=0
142927.37500010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1103285Win=8760Len=0
143027.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
143127.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
143227.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
143327.37500010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1105921Win=8760Len=0
143427.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
143527.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
143627.37500010.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
143727.39062510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1108841Win=8760Len=0
143827.39062510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1111477Win=8760Len=0
143927.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
144027.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
144127.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
144227.39062510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1114113Win=8760Len=0
144327.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
144427.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
144527.39062510.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
144627.42187510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1117033Win=8760Len=0
144727.42187510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1119669Win=8760Len=0
144827.42187510.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1122305Win=8760Len=0
144927.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145027.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145127.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
145227.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145327.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145427.42187510.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
145527.43750010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1125225Win=8760Len=0
145627.43750010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1127861Win=8760Len=0
145727.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145827.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
145927.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
146027.43750010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1130497Win=8760Len=0
146127.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
146227.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
146327.43750010.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
此段报文中，第一个较长等待发生在1436号报文，此时等待的时间比较长，距离下一个发送报文时延约15ms。
为什么会出现等待？
我们往前面的报文分析。
最近一次确认报文在1433号报文处，确认了1427号报文的数据，同时滑动窗口为8760。
也就是在1436报文的时刻，共有6个报文段没有被确认（1430、1431、1432、1434、1435、1436号报文）。
这6个报文段字节总数为8192字节，正好等于发送缓冲区的大小。
如果再发送一个报文1460字节，也会超过滑动窗口大小8760。
这时，服务器肯定不会再发送报文了。
在等待15ms后接收到1437号ACK报文后，再继续发送报文。
第二个较长等待发生在报文1445处，距离下一个发送报文时延约31ms。
1442号报文确认了1436号报文的数据，同时滑动窗口为8760。
也就是在1445报文的时刻，共有6个报文段没有被确认（1439、1440、1441、1443、1444、1445号报文）。
这6个报文段字节总数为8192字节，正好等于发送缓冲区的大小。
如果再发送一个报文1460字节，也会超过滑动窗口大小8760。
这时，服务器肯定不会再发送报文了。
在等待31ms后接收到1446号ACK报文后，再继续发送报文。
可以看出，服务器发送等待的原因主要是在等待对端的ACK报文。
我们继续分析客户端的抓包文件ftp-client-1-2.cap。
从图形上看，客户端接收的流量要平缓一些，这说明流量经过网络设备后被平滑处理了。
FTPClient端流量模型
摘取一段报文来进行分析。
No.TimeSourceDestinationProtocolInfo
139327.35820410.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1138689Win=8760Len=0
139427.37357310.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
139527.37480410.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
139627.37582010.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
139727.37704210.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
139827.37827810.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
139927.37927910.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
140027.37934310.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1141609Win=8760Len=0
140127.37941010.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1144245Win=8760Len=0
140227.37947710.11.130.19310.11.123.7TCP1217>ftp-data[ACK]Seq=1Ack=1146881Win=8760Len=0
140327.39765510.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
140427.39886110.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
140527.39986410.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
140627.40109610.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
140727.40232410.11.123.710.11.130.193FTP-DATAFTPData:
1460bytes
140827.40332810.11.123.710.11.130.193FTP-DATAFTPData:
1176bytes
140927.40339710.11.130.19310.11.123.7TCP12
升级会员 