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

目录 1 背景描述 2 2 TCP相关知识点 2 2.1 TCP传输的最大报文段 2 2.2 TCP发送报文的确认 3 2.3 滑动窗口与接收缓冲区 3 2.4 发送缓冲区 3 2.5 慢启动与拥塞避免算法 3 3 ADSL模板中交织与快速的区别 4 3.1 Channel mode－通道模式 4 3.2 Unit of interleaved delay－交织延迟单位 5 4 一例FTP下载慢情况的分析 6 4.1 缩短线路时延 10 4.2 增大滑动窗口和发送缓冲区的容量 10 5 佛山网通现网测试的结果 13 5.1 ADSL/ADSL2+FTP下载速率测试（突出改变时延带来的影响） 14 5.2 ADSL下载速率测试（突出改变缓冲区带来的影响） 15 5.3 ADSL2+下载速率测试（同样是突出改变缓冲区带来的影响） 16 6 结论 17  FTP下载速率慢原因分析及处理指导书 背景描述 在DSLAM的应用中，经常用到FTP下载来测试ADSL的带宽。我们在测试时经常会发现FTP下载速率比ADSL的带宽小很多，本文就是从原理入手逐步分析问题的原因。首先强调一点，FTP下载速率肯定不会大于通道的带宽，因为ADSL通道就好比运载货物的列车，我们只可能尽量的装满它，但绝不会超过它；甚至使用多个FTP同时下载，每个FTP下载速度的总和也不会大于通道的带宽（测试标准中均建议使用多个FTP同时下载）。其次，FTP下载是一个端到端的处理过程。下载速率涉及到端到端整个业务流程的每个环节，包括了硬件性能、线路带宽、线路时延，缓冲区算法等。使用FTP下载是一种比较方便（或者说常规应用中也没有比它更好的）的方式来判断带宽的方法，不过我们要尽可能排除一切瓶颈，使FTP下载速度接近通道的带宽。 TCP相关知识点 问题分析涉及到的TCP知识点介绍一下。熟悉TCP的人可以跳过此节，太不熟悉TCP的人请直接参考TCP/IP相关资料，此处不做过多的基本知识介绍。 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，一般不会发送小数据的报文。 TCP发送报文的确认 在一个TCP报文中包含有发送序列号和确认序列号。发送序列号是对自己发送数据的一个编号，一次连接中发送的数据会连续编号，通过发送序列号对发送的数据进行标志。确认序列号用于通知对方，对方送过来的数据中小于此序列号的报文都被正确接收（包括不会乱序，不会丢失报文）。 滑动窗口与接收缓冲区 滑动窗口是数据接收方控制数据传输流量的重要手段，此值反映的也是TCP接收缓冲区的大小。数据接收方通过此值告知对方自己的接收缓冲区大小，让发送方根据此值调整发送策略。 发送方已经发送但还没有被确认的数据字节，加上即将要发送的数据字节数之和大于对方的滑动窗口，则发送方会停止发送报文。除非发送方收到了新的确认报文，或收到对方滑动窗口扩大后，前面所说的限制被打破，才可能继续发送报文。 滑动窗口会动态调整的。当应用层从接收缓冲区取走数据时滑动窗口就会扩大，接收缓冲区收到新的报文时滑动窗口会减少。当滑动窗口变化时，会依据一定的策略向对方发送滑动窗口更新通告，算法可参考TCP/IP相关文档。 发送缓冲区 发送缓冲区的大小会影响到发送策略。 在对方滑动窗口足够大的情况下，发送端发送的未被确认的数据大小不能超过发送缓冲区的大小。一旦到达发送缓冲区大小的临界点，则发送端停止发送。 这是因为已发送但还没有被确认的数据还会继续滞留在发送缓冲区中，占用了空间。只要是没有被确认的数据都可能会重传，发送缓冲区不会将这些数据从缓冲区中清除，否则需要重传时找不到这些数据。我们可以想想，应用层发送数据时只会send一次，TCP层的重传就靠自己了，所以原始的数据不会在TCP发送缓冲区中被清除掉。 慢启动与拥塞避免算法 如果发送缓冲区和接收缓冲区（滑动窗口）都足够大，那么发送端是否会尽量发送数据呢？如果中间网络出现拥塞或丢包，快速发送报文会造成不断的重传，传输效率会更低。 TCP会采用拥塞避免算法和慢启动来调整发送策略，避免传输线路上的数据拥塞。一旦发现有拥塞现象（超时或收到重复确认），发送方会降低发送速度。 ADSL