以太网专线FTP/TCP实测带宽性能问题分析

2015-07-03郑吉妮黄河王方金

电信工程技术与标准化 2015年7期

郑吉妮，黄河，王方金

（中国移动通信集团广东有限公司，广州 510623）

随着通信网络IP化进程的迅速发展，传输网由早期的MSTP技术向PTN技术转型，现有PTN网络已具备带宽统计复用等多方面优势，可同时承载2G/3G/4G基站回传业务、集客业务及WLAN业务等。

IEEE 802.3x流控：全双工以太网数据链路层的一种流控方式，当一端设备向对端设备发出请求后,如自身系统缓存不够或网络产生拥塞时,便会向对端设备发出Pause帧,以延缓其发向自身的数据。流量控制可用于在端口阻塞情况下避免丢帧，可有效抵御瞬间大量数据对网络带来冲击，保证用户网络运行高效而稳定。

FTP文件传输协议：使用TCP生成一个虚拟连接用于控制的信息，再生成一个单独的 TCP连接用于数据传输，实现主机间文件共享。FTP客户机可给服务器发出命令，用于下载或上传文件、创建或改变服务器上的目录等。

中国移动为集团客户A公司开通一条跨省MSTP+ PTN大客户专线，命名为“北京-深圳300 Mbit/s”。电路开通后，传输挂表测试正常，但A公司客户使用该电路进行FTP等应用测试发现实际带宽不足，提出申告：“使用单线程FTP从北京服务器下载文件至深圳时，带宽能达到要求，但在深圳上载文件至北京服务器时，带宽达不到要求，最低只有约4Mbit/s左右”。

1 案例问题分析

1.1 TCP稳态速率的理论分析（如图1所示）

图1 TCP稳态速率影响因素

BDP（Bandwidth Delay Product，带宽时延乘积)即带宽×时延，其中时延指系统的环回时长RTT0，即TCP发出一个数据分组到收到对应ACK的时长，约等于Ping测时长。案例中北京-深圳的带宽为300 Mbit/s折合为37.5 MB，时延为40 ms，该BDP≈37.5×0.04×106=1 500 000 B。即理论上要求客户北京、深圳FTP服务器的TCP缓冲区不小于1 500 000 B。

TCP缓冲区大小设置原则：缓冲区大小需要略大于时延带宽乘积，否则吞吐量会因缓冲区太小而受限。其中吞吐量 = min｛发送窗口，接收窗口｝/ RTT。如果应用程序指定了缓冲区大小，则按应用程序指定大小分配缓冲区，否则操作系统按系统设置值进行TCP缓冲区分配。

1.2 FTP服务器的TCP缓存窗口分析

在A公司客户现场登陆北京、上海、深圳3地服务器，查看当前TCP缓存窗口配置，发现北京和深圳的服务器缓存设置足够，但上海服务器的缓存设置略小，通过TCP稳态速率分析，发现FTP服务器的TCP发送接收缓存不小于1 500 000 byte，当时查询的结果如表1所示。

表1 客户服务器缓存情况分析

最终分析结论为北京和深圳的FTP服务器TCP缓存窗口大于BDP，“北京—深圳300 Mbit/s”电路FTP吞吐量低，非客户FTP服务器的TCP缓存窗口设置不合理引起。

1.3 传输网络配置分析

由于TCP传输存在方向性，因此需要将此电路两端单独分析。

北京—深圳方向：如图2、3所示，从北京FTP文件至深圳方向，北京客户路由器与华为EGS4单板对接的端口速率为GE，MSTP网络带宽只有300 Mbit/s，北京SSN4EGS4单板处入口带宽（1 000 Mbit/s）大于出口带宽（300 Mbit/s），即存在瓶颈。由于SSN4EGS4单板与客户Juniper路由器端口是自协商模式，并且使用自协商流控（802.3x），当Juniper路由器出现突发流量时，SSN4EGS4单板与路由器端口之间的流控机制保证路由器突发数据不超过SSN4EGS4单板缓存大小，因此SSN4EGS4单板不会分组丢失。经测试，北京—深圳300 Mbit/s电路，从北京FTP文件至深圳方向的FTP速率稳定在33!35 Mbit/s左右。

深圳—北京方向：如图4所示，深圳FTP文件至北京方向FTP平均速度只有4!5 Mbit/s。从拓扑图看，深圳客户路由器与华为PTN950设备EG2单板对接的端口速率为GE，而PTN网络内Tunnel限速为300 Mbit/s，相当于深圳PTN950设备EG2单板处入口带宽（1 000 Mbit/s）大于出口带宽（300 Mbit/s），即存在瓶颈。由于PTN950设备产品规格不支持端口发送流控帧（只支持接受流控帧），并且PTN950设备EG2单板的Tunnel队列缓存规格较小。因此当存在出口带宽小于入口带宽，且单板缓存无法容纳突发数据时，就产生分组丢失引起TCP重传，从而降低了FTP传输速率。

图2 北京—深圳方向传输组网情况

图3 北京客户端传输设备以太网单板的接口配置

2 解决方案

修改深圳客户机房PTN950设备的限速模式由Tunnel限速修改为端口CAR限速，配置CAR限速的CIR/PIR（承诺信息速率/峰值信息速率）为300 000 kbit/s，配置CBS/PBS（承诺突发/峰值突发）为2 MB。修改后经测试，该电路从深圳至北京方向的FTP速率可稳定在33 Mbit/s以上。

3 结论及建议

此类问题一般发生在FTP等存在较大TCP突发数据流的应用场景下，建议对单线程与多线程两种FTP速率进行比较。如果多线程FTP速率（所有线程速率综合）能基本达到用户需求带宽，而单线程FTP速率远低于用户需求带宽时，说明吞吐量不够导致带宽瓶颈，从而引起分组丢失重传。类似问题可按照下述步骤进行排查和解决。

（1）检查用户FTP服务器和客户端TCP滑动窗口缓存大小是否满足要求，一般要求TCP滑动窗口缓存大小不小于BDP。

（2）上述条件满足后，检查电路配置是否存在误码和异常告警等影响业务的因素，并逐一排除，有条件的情况下可以使用SmartBit等以太网测试仪进行检测。

（3）检查电路路径是否存在瓶颈点，比如与用户设备对接的PTN或MSTP单板，它们与用户设备一般是以FE/GE/10 GE速率对接，但网络侧绑定的通道往往才是用户真正租用的带宽（如60 Mbit/s /200 Mbit/s/2 GE）。因此在入口处存在大管道向小管道的带宽收敛，当入口流量存在突发时便出现瓶颈，如果单板的缓存不足以存储突发流量，就会出现分组丢失，进而导致TCP数据发生重传，降低上传下载速率。

（4）如果用户设备和对接的移动PTN或MSTP以太单板之间存在如上瓶颈，首选方案是在用户设备发往移动PTN或MSTP以太单板方向的端口上进行流量整形（Shaping），整形后的数据流为用户租用带宽，从而消除用户设备发往移动PTN或MSTP以太单板方向的超SLA突发数据流，PTN或MSTP以太单板就能完全转发用户设备送来的数据分组。

（5）如果用户设备和对接的移动MSTP以太单板之间存在瓶颈，且用户设备无法做流量整形，则可尝试在用户设备和MSTP以太单板之间启动802.3x流控，采用Pause帧机制，当MSTP以太单板遇到突发数据流无法及时转发时，通知上游用户设备暂停发送数据，从而避免分组丢失现象。