《ftp下载速率慢原因分析及处理指导书(华为)》由会员分享，可在线阅读，更多相关《ftp下载速率慢原因分析及处理指导书(华为)（18页珍藏版）》请在金锄头文库上搜索。
1、FTP下载速率慢原因分析及处理指导书内部公开目录1背景描述22TCP相关知识点22.1TCP传输的最大报文段22.2TCP发送报文的确认32.3滑动窗口与接收缓冲区32.4发送缓冲区32.5慢启动与拥塞避免算法33ADSL模板中交织与快速的区别43.1Channel mode通道模式43.2Unit of interleaved delay交织延迟单位54一例FTP下载慢情况的分析64.1缩短线路时延104.2增大滑动窗口和发送缓冲区的容量105佛山网通现网测试的结果135.1ADSL/ADSL2+FTP下载速率测试（突出改变时延带来的影响）145.2ADSL下载速率测试（突出改变缓冲区带来的
2、影响）155.3ADSL2+下载速率测试（同样是突出改变缓冲区带来的影响）166结论17在能力与知识结构方面，要求学生应具有扎实的专业和日语语言基础，熟练掌握日语听、说、读、写、译的基本技能；了解日本社会及日本文化等方面的基本知识，熟悉日本国情，具有一定的日本人文知识及运用这些知识与日本人进行交流的能力。2019-9-6华为机密，未经许可不得扩散第17页, 共18页FTP下载速率慢原因分析及处理指导书1 背景描述在DSLAM的应用中，经常用到FTP下载来测试ADSL的带宽。我们在测试时经常会发现FTP下载速率比ADSL的带宽小很多，本文就是从原理入手逐步分析问题的原因。首先强调一点，FTP下载
3、速率肯定不会大于通道的带宽，因为ADSL通道就好比运载货物的列车，我们只可能尽量的装满它，但绝不会超过它；甚至使用多个FTP同时下载，每个FTP下载速度的总和也不会大于通道的带宽（测试标准中均建议使用多个FTP同时下载）。其次，FTP下载是一个端到端的处理过程。下载速率涉及到端到端整个业务流程的每个环节，包括了硬件性能、线路带宽、线路时延，缓冲区算法等。使用FTP下载是一种比较方便（或者说常规应用中也没有比它更好的）的方式来判断带宽的方法，不过我们要尽可能排除一切瓶颈，使FTP下载速度接近通道的带宽。2 TCP相关知识点问题分析涉及到的TCP知识点介绍一下。熟悉TCP的人可以跳过此节，太不熟悉
4、TCP的人请直接参考TCP/IP相关资料，此处不做过多的基本知识介绍。2.1 TCP传输的最大报文段TCP下载大文件时，需要把大文件切割为一系列报文段进行发送。如果每个报文段的容量过小，则会影响到发送效率。在以太网上传输时，以太网最大帧长为1518字节，去除以太网帧头及校验，以太网帧的净荷为1500字节。IP报文头最小字节数为20，TCP报文头最小字节数为20，TCP报文最大净荷就为1460字节了。在TCP连接建立时，协商出来的最大报文段为1460字节。假设FTP下载的发送缓冲区为8K bytes。在下载大文件时，发送报文数据大小序列一般为：1460，1460，1460，1460，1460，8
5、92或1460，1460，1176，1460，1460，1176，一般不会发送小数据的报文。2.2 TCP发送报文的确认在一个TCP报文中包含有发送序列号和确认序列号。发送序列号是对自己发送数据的一个编号，一次连接中发送的数据会连续编号，通过发送序列号对发送的数据进行标志。确认序列号用于通知对方，对方送过来的数据中小于此序列号的报文都被正确接收（包括不会乱序，不会丢失报文）。2.3 滑动窗口与接收缓冲区滑动窗口是数据接收方控制数据传输流量的重要手段，此值反映的也是TCP接收缓冲区的大小。数据接收方通过此值告知对方自己的接收缓冲区大小，让发送方根据此值调整发送策略。发送方已经发送但还没有被确认的
6、数据字节，加上即将要发送的数据字节数之和大于对方的滑动窗口，则发送方会停止发送报文。除非发送方收到了新的确认报文，或收到对方滑动窗口扩大后，前面所说的限制被打破，才可能继续发送报文。滑动窗口会动态调整的。当应用层从接收缓冲区取走数据时滑动窗口就会扩大，接收缓冲区收到新的报文时滑动窗口会减少。当滑动窗口变化时，会依据一定的策略向对方发送滑动窗口更新通告，算法可参考TCP/IP相关文档。2.4 发送缓冲区发送缓冲区的大小会影响到发送策略。在对方滑动窗口足够大的情况下，发送端发送的未被确认的数据大小不能超过发送缓冲区的大小。一旦到达发送缓冲区大小的临界点，则发送端停止发送。这是因为已发送但还没有被确
7、认的数据还会继续滞留在发送缓冲区中，占用了空间。只要是没有被确认的数据都可能会重传，发送缓冲区不会将这些数据从缓冲区中清除，否则需要重传时找不到这些数据。我们可以想想，应用层发送数据时只会send一次，TCP层的重传就靠自己了，所以原始的数据不会在TCP发送缓冲区中被清除掉。2.5 慢启动与拥塞避免算法如果发送缓冲区和接收缓冲区（滑动窗口）都足够大，那么发送端是否会尽量发送数据呢？如果中间网络出现拥塞或丢包，快速发送报文会造成不断的重传，传输效率会更低。TCP会采用拥塞避免算法和慢启动来调整发送策略，避免传输线路上的数据拥塞。一旦发现有拥塞现象（超时或收到重复确认），发送方会降低发送速度。3
8、ADSL模板中交织与快速的区别3.1 Channel mode通道模式Fast：快速方式，纠错能力一般，但延迟较小，适用于那些对延迟敏感的业务，比如视频点播、可视电话等。Interleaved：交织方式，纠错能力较强，随着深度越深，纠错能力越强，但相应的延迟就越大，这种方式适用于那些对可靠性要求较高但不太在意延迟的业务。下面简单介绍一下快速、交织的处理过程；比如首先假定上层来的顺序比特流如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1一般没有交织的情况下（如快速方式），线路是按照上层来的比特流顺序进行传送，这样前面的比特先被传送，并且先到接收端，相应的时延较小，但误码的可能性就较
9、大，比如如果线路上遇到脉冲干扰等，这些干扰持续的时间较短，但会致使连续的比特错误，如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1由于以上是按照上层来的比特流顺序进行传送的，这样这些连续的比特错误到达接收端也是连续的，达到一定程度，线路本身的差错控制码（如FEC）等也将无能为力，最终产生线路误码，只能由高层协议的重传协议来保证了。在交织情况下，线路没有按照上层来的比特流顺序进行传送，而是按照码字间隔的传送它们的比特，这是通过一个交织器，让比特流横向进、纵向出来完成的，如下为交织器的工作原理：横向进纵向出A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C
10、5C4C3C2C1经过交织器处理后线路上传送的比特流顺序将为：B5A5C4B4A4C3B3A3C2B2A2C1B1A1到达接收端后交织器以相反的方式处理，纵向进、横向出，最后结果如下：纵向进横向出A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1可以很明显的看出，通过交织处理后，同样的脉冲干扰引起的错误现在分布在了不同的码字当中，这样在各个码字当中自行进行差错控制就容易多了；但从另外一方面也可以看出，在接收端，码字A只有等三个码字都到了才能接收到最后一个比特，才能算接收完毕，这明显加大了延迟。这一延时对于不需要确认的数据传输（比如UDP连接）是没有
11、影响的，仅最开始那一下，但是对需要对方应答时（比如TCP连接），这种延时将会明显降低了传输速率，因为发送一个报文经过一段时延才能到达对方，而对方的确认报文又要经过一个时延才能达到，有时交织方式的FTP下载速率甚至会降低到快速方式的1/3左右。3.2 Unit of interleaved delay交织延迟单位DMT：直接以深度为单位，叫做交织深度interleaved depthMS：直接以时间ms为单位，叫做交织延迟interleaved delay交织深度就是上面介绍的那个交织器的纵向深度，或者说同时有几个码字进行交织处理；而交织延迟其实就是交织处理后体现的直接结果，以此来设置交织器的话
12、，其实内部还要通过速率、码字长度再来换算成交织深度；交织延迟与交织深度、码字长度以及线路速率有关。以前的线路模板中两种单位都支持，后来因为RFC标准中只支持ms为单位，线路模板中取消了对DMT单位的支持，只支持ms单位。老版本配置数据中可能存在以DMT为单位的线路模板，在数据升级过程中就有一个DMT向ms转换的关系。根据G.992.1协议规定，转换公式为：4 + (S-1)/4 +SD/4，以前的线路模板配置数据都是针对ADSL单板的，而对于ADSL来说，S1，即ms4+DMT/4，DMT全部按这个公式转换成ms。用交织延迟来描述，更直接地反映交织带来的时延。4 一例FTP下载慢情况的分析测试
13、场景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。经过多次下载，速率有少许变化，但都稳定在450Kbyt
14、es/sec左右。很明显，此速率远小于ADSL端口的下行带宽24456Kbps。本下载过程中，FTP服务器发送缓冲区为8192字节，客户端最大滑动窗口为8760字节。ftp get d9gwqg1x200 PORT Command successful.150 Opening BINARY mode data connection for d9gwqg1x ( bytes).226 Transfer complete.ftp: bytes received in 36.75Seconds 459.20Kbytes/sec.我们先从数据的发送源端开始分析，看FTP SERVER是否把数据及时发送出来。通过分析FTP-SERVER-1-2.CAP文件中的数据，其数据流量发送模型如下图。发现服务器端每一次突发后就会等待一段时间。分析数据，发现服务器端在等待客户端ACK报文确认。如果没有被ACK确认的字节数加上一个报文长度（很可能是1460字节，请参考发送报文数据大小序列）大于对方的滑动窗口，此时服务器是不会发送报文的，因为再发送报文很可能会丢包。FTP Server端流量模型举例1：抓包文件FTP-SERVER-1-2.CAP，第1427号报文开始。No. Time Source Destination Protocol Info1427 27.
