FTP下载速率慢原因分析及处理指导书(华为).doc

目录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下载速率测试（突出改变缓冲区带来的影响）155.3ADSL2+下载速率测试（同样是突出改变缓冲区带来的影响）166结论17FTP下载速率慢原因分析及处理指导书1 背景描述在DSLAM的应用中，经常用到FTP下载来测试ADSL的带宽。我们在测试时经常会发现FTP下载速率比ADSL的带宽小很多，本文就是从原理入手逐步分析问题的原因。首先强调一点，FTP下载速率肯定不会大于通道的带宽，因为ADSL通道就好比运载货物的列车，我们只可能尽量的装满它，但绝不会超过它；甚至使用多个FTP同时下载，每个FTP下载速度的总和也不会大于通道的带宽（测试标准中均建议使用多个FTP同时下载）。其次，FTP下载是一个端到端的处理过程。下载速率涉及到端到端整个业务流程的每个环节，包括了硬件性能、线路带宽、线路时延，缓冲区算法等。使用FTP下载是一种比较方便（或者说常规应用中也没有比它更好的）的方式来判断带宽的方法，不过我们要尽可能排除一切瓶颈，使FTP下载速度接近通道的带宽。2 TCP相关知识点问题分析涉及到的TCP知识点介绍一下。熟悉TCP的人可以跳过此节，太不熟悉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，892或1460，1460，1176，1460，1460，1176，一般不会发送小数据的报文。2.2 TCP发送报文的确认在一个TCP报文中包含有发送序列号和确认序列号。发送序列号是对自己发送数据的一个编号，一次连接中发送的数据会连续编号，通过发送序列号对发送的数据进行标志。确认序列号用于通知对方，对方送过来的数据中小于此序列号的报文都被正确接收（包括不会乱序，不会丢失报文）。2.3 滑动窗口与接收缓冲区滑动窗口是数据接收方控制数据传输流量的重要手段，此值反映的也是TCP接收缓冲区的大小。数据接收方通过此值告知对方自己的接收缓冲区大小，让发送方根据此值调整发送策略。发送方已经发送但还没有被确认的数据字节，加上即将要发送的数据字节数之和大于对方的滑动窗口，则发送方会停止发送报文。除非发送方收到了新的确认报文，或收到对方滑动窗口扩大后，前面所说的限制被打破，才可能继续发送报文。滑动窗口会动态调整的。当应用层从接收缓冲区取走数据时滑动窗口就会扩大，接收缓冲区收到新的报文时滑动窗口会减少。当滑动窗口变化时，会依据一定的策略向对方发送滑动窗口更新通告，算法可参考TCP/IP相关文档。2.4 发送缓冲区发送缓冲区的大小会影响到发送策略。在对方滑动窗口足够大的情况下，发送端发送的未被确认的数据大小不能超过发送缓冲区的大小。一旦到达发送缓冲区大小的临界点，则发送端停止发送。这是因为已发送但还没有被确认的数据还会继续滞留在发送缓冲区中，占用了空间。只要是没有被确认的数据都可能会重传，发送缓冲区不会将这些数据从缓冲区中清除，否则需要重传时找不到这些数据。我们可以想想，应用层发送数据时只会send一次，TCP层的重传就靠自己了，所以原始的数据不会在TCP发送缓冲区中被清除掉。2.5 慢启动与拥塞避免算法如果发送缓冲区和接收缓冲区（滑动窗口）都足够大，那么发送端是否会尽量发送数据呢？如果中间网络出现拥塞或丢包，快速发送报文会造成不断的重传，传输效率会更低。TCP会采用拥塞避免算法和慢启动来调整发送策略，避免传输线路上的数据拥塞。一旦发现有拥塞现象（超时或收到重复确认），发送方会降低发送速度。3 ADSL模板中交织与快速的区别3.1 Channel mode通道模式Fast：快速方式，纠错能力一般，但延迟较小，适用于那些对延迟敏感的业务，比如视频点播、可视电话等。Interleaved：交织方式，纠错能力较强，随着深度越深，纠错能力越强，但相应的延迟就越大，这种方式适用于那些对可靠性要求较高但不太在意延迟的业务。下面简单介绍一下快速、交织的处理过程；比如首先假定上层来的顺序比特流如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1一般没有交织的情况下（如快速方式），线路是按照上层来的比特流顺序进行传送，这样前面的比特先被传送，并且先到接收端，相应的时延较小，但误码的可能性就较大，比如如果线路上遇到脉冲干扰等，这些干扰持续的时间较短，但会致使连续的比特错误，如下：B6B5B4B3B2B1A8A7A6A5A4A3A2A1由于以上是按照上层来的比特流顺序进行传送的，这样这些连续的比特错误到达接收端也是连续的，达到一定程度，线路本身的差错控制码（如FEC）等也将无能为力，最终产生线路误码，只能由高层协议的重传协议来保证了。在交织情况下，线路没有按照上层来的比特流顺序进行传送，而是按照码字间隔的传送它们的比特，这是通过一个交织器，让比特流横向进、纵向出来完成的，如下为交织器的工作原理：横向进纵向出A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1经过交织器处理后线路上传送的比特流顺序将为：B5A5C4B4A4C3B3A3C2B2A2C1B1A1到达接收端后交织器以相反的方式处理，纵向进、横向出，最后结果如下：纵向进横向出A8A7A6A5A4A3A2A1B8B7B6B5B4B3B2B1C8C7C6C5C4C3C2C1可以很明显的看出，通过交织处理后，同样的脉冲干扰引起的错误现在分布在了不同的码字当中，这样在各个码字当中自行进行差错控制就容易多了；但从另外一方面也可以看出，在接收端，码字A只有等三个码字都到了才能接收到最后一个比特，才能算接收完毕，这明显加大了延迟。这一延时对于不需要确认的数据传输（比如UDP连接）是没有影响的，仅最开始那一下，但是对需要对方应答时（比如TCP连接），这种延时将会明显降低了传输速率，因为发送一个报文经过一段时延才能到达对方，而对方的确认报文又要经过一个时延才能达到，有时交织方式的FTP下载速率甚至会降低到快速方式的1/3左右。3.2 Unit of interleaved delay交织延迟单位DMT：直接以深度为单位，叫做交织深度interleaved depthMS：直接以时间ms为单位，叫做交织延迟interleaved delay交织深度就是上面介绍的那个交织器的纵向深度，或者说同时有几个码字进行交织处理；而交织延迟其实就是交织处理后体现的直接结果，以此来设置交织器的话，其实内部还要通过速率、码字长度再来换算成交织深度；交织延迟与交织深度、码字长度以及线路速率有关。以前的线路模板中两种单位都支持，后来因为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下载慢情况的分析测试场景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 get d9gwqg1x200 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.我们先从数据的发送源端开始分析，看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.359375 93 FTP-DATA FTP Data: 1176 bytes 1428 27.375000 93 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 bytes 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 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.390625 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 Len=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=1117033 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.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 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 FTP 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 93 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此段报文中，第一个较长等待发生在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。从图形上看，客户端接收的流量要平缓一些，这说明流量经过网络设备后被平滑处理了。 FTP Client端流量模型摘取一段报文来进行分析。No. Time Source Destination Protocol Info1393 27.358204 93 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 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 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 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 FTP-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 Seq=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 Data: 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 TCP 1217 ftp-data ACK Seq=1从报文段序列中可以看出，客户端在收到FTP下载报文后很快就回应了ACK报文，没有大的时延。1400号报文确认了1395号报文，1401号报文确认了1397号报文，1402号报文确认了1399号报文，时延分别为6ms，3ms，1ms（注：如果是在客户端上安装抓包软件抓包，会发现每收到2个FTP报文后就立刻回应ACK，时延在1ms内）。综合客户端和服务器端的分析，服务器端在等待客户端的ACK确认，但客户端也及时回应了ACK报文。为什么等待ACK相应的时间会比较长呢？这个时间等待就应产生在传输线路上。我们以前用SmartBits测试过ADSL的线路时延，这个时延值是比较大的。对抓包文件进行查看，客户端和服务器端没有丢包重传的现象。所以，对于本次FTP下载过程而言，造成下载速率低的主要原因是线路时延比较大。4.1 缩短线路时延根据前面的分析，线路时延大是造成单线程FTP下载速率低的主要原因。如何减少线路的时延呢？对于不同的网络设备解决方法不一样，技术也更专业一些，在本文中不做重点的介绍。对于ADSL线路的下载，减小线路时延的方法可以改变ADSL的激活方式。把Interleave交织方式更改为fast快速方式，线路时延能够提高一些，下载速率能相对提高一些。4.2 增大滑动窗口和发送缓冲区的容量从前面的分析可以看出，服务器端处于等待发送状态，直接原因是在等待对方的ACK确认报文。但另一方面，如果我们增大发送缓冲区和接收方的滑动窗口，则服务器可以继续发送报文，减少等待。上面分析的例子可以看到，该下载过程中，FTP服务器发送缓冲区为8192字节，客户端最大滑动窗口为8760字节。从理论上说，时延因素并非是影响TCP下载速率的唯一因素。对于TCP传输能力大小，用带宽时延乘积来描述比较合适。Capacity (bit) = bandwidth (b/s) round-trip time (s)Capacity即TCP下载的传输能力，bandwidth即线路带宽，round-trip time即报文的传输时延。我们可以把报文的传输过程想象为报文放在管道上传输。带宽时延乘积与传输管道如果想增加传输速率，必须尽量用报文把管道塞满，最大可能的传输速率就是管道被占满时的传输速率。当传输时延增大时，管道会变长，管道容积增加。这时传输同样数量的报文管道占有率就会变稀疏，管道利用率下降。因此只要我们尽量往管道中填充报文，传输速率总会达到最大，哪怕传输时延大也不会影响最大的传输速率。我们通过增大发送缓冲区和接收方的滑动窗口，就可以让服务器尽量向管道填充数据，从而达到传输的最大速率。如何更改发送缓冲区大小我们使用的FTP Server软件为SER-U version 4.0。如下图，把Send buffer更改为81920字节。调整发送缓冲区界面更改客户端滑动窗口大小我们可以通过“Windows优化大师”这款软件来修改滑动窗口大小。调整接收滑动窗口界面验证效果在同样的组网和硬件配置下（把HUB去掉了，PC1直接连接在MODEM上），更改服务器端的发送缓冲区和客户端的滑动窗口。FTP服务器发送缓冲区为81920字节，客户端最大滑动窗口为65535字节。下载速率达到1442.35Kbytes/sec，下载速率有很大的提高。ftp get D9GWQG1X200 PORT Command successful.150 Opening BINARY mode data connection for D9GWQG1X (16875520 bytes).226 Transfer complete.ftp: 16875520 bytes received in 11.70Seconds 1442.35Kbytes/sec.在服务器端的抓包分析模型如下图：优化后的FTP下载模型很明显的看到，虽然服务器突发的间隔与以前相比差不多（线路时延没有改变），但突发的流量大了很多（注意纵轴刻度有变化），这就是因为发送缓冲区和滑动窗口增大的缘故。5 佛山网通现网测试的结果佛山网通UA5000 ADSL/ADSL2+FTP下载速率测试参与测试人员：杨黎岗；吕江；冼康怡测试地点：华胜机房测试时间：2006-7-27测试环境：5.1 ADSL/ADSL2+FTP下载速率测试（突出改变时延带来的影响）验收目的验证PPPoE业务下载速度预置条件测试终端安装有PPPoE拨号软件。BAS是具有PPPoE终结功能的接入服务器，且配置有PPPoE帐号和IP地址池。此处可以使用路由器等其它具备功能条件的设备。测试过程建立不同ADSLADSL2+线路模版在测试终端上发起PPPoE呼叫，申请IP地址，访问Internet。使用不同线路模版并能正常激活，达到速率限制要求。 测试结果线路模板参数ftp下载速率（KB/s）MODEM类型上行下行通道模式（上行交织时延，下行交织时延）Ping时延（ms）线路模板类型ADSLADSL2+5124096Interleave（6，6）14345363MT8805124096Interleave（16，6）252325124096Fast84524585124096Interleave（6，6）14340378MT8005124096Interleave（16，6）5124096Fast8421422测试说明应用不同模板激活端口，进行FTP下载速率测试。客户代表签字：杨黎岗 华为督导签字：冼康怡 日期：2006.7.27测试地点：华胜机房测试结论：1、 交织方式会带来的时延，测试数据与交织时延设置吻合2、 较大的交织时延设置引起FTP下载速率有所降低。如上表，交织时延有6加大到16，速率降低不少。变化的量级和前文分析的吻合3、 解释为什么前一天测试ADSL和ADSL2+同样是交织模式，会有很大差异。通过比较了ADSL模板以及ADSL2+模板配置的差异，找出由于交织时延在ADSL模板上默认的上下行时延为6，6；ADSL2+模板上默认的上下行时延为16，6，由于上行设置时延值的不同，直接影响了ftp下载速度。参与测试人员：杨黎岗；廖晓锋；冼康怡测试地点：岭南雅居接入通信机房测试时间：2006-7-26测试内容：选取了岭南雅居接入通信机房的MA5605设备进行ADSL/ADSL2+速率测试，此次利用windows优化大师在同一台电脑上分别将传输单元缓冲区（TcpWindowSize）改为8192bytes和255552bytes进行测试，测试结果如下表：5.2 ADSL下载速率测试（突出改变缓冲区带来的影响）验收目的验证PPPoE业务下载速度预置条件测试终端安装有PPPoE拨号软件。BAS是具有PPPoE终结功能的接入服务器，且配置有PPPoE帐号和IP地址池。此处可以使用路由器等其它具备功能条件的设备。测试过程建立不同ADSL线路模版在测试终端上发起PPPoE呼叫，申请IP地址，访问Internet。使用不同线路模版并能正常激活，达到速率限制要求。 测试结果线路模板（ADSL模板）ftp下载速率（KB/s）结论：同等条件下减小时延可以提高下载速率。不过随着缓冲区的极大化，减少时延能带来的速率提升变得不明显上行下行通道模式（上行交织时延，下行交织时延）传输单元缓冲区TcpWindowSize-Byte81922555525122048Interleave（6，6）2162295122048Fast2172325124096Interleave（6，6）2794625124096Fast3704635126144Interleave（6，6）2826955126144fast415696测试说明应用不同模板激活端口，进行速度测试。客户代表签字：杨黎岗 华为督导签字：冼康怡 日期：2006.7.26测试地点：岭南雅居接入通信机房测试结论：1、 同等条件下减小时延可以提高下载速率。2、 随着缓冲区的极大化，减少时延能带来的速率提升变得不明显3、 下行速率模板越