基于MSTP系统的以太网通道在用户使用中的吞吐率与系统理论带宽的差异一直是困扰着很多技术人员的一个棘手的问题。通常对于以太网通道都是以RFC 2544的四项（吞吐率、延时、帧丢失率、背靠背）测试指标作为衡量性能的标准。但在用户实际使用中，时常出现吞吐率远小于仪表测试值的现象。下面就通过一起典型案例来详细分析其中的原因。

　　RFC 2544的测试是以太网测试的一种常规手段，通过在网络的一端发出信息包然后在远端环回到收端进而分析得到网络的吞吐率、延时、帧丢失率、背靠背四项指标数据。在MSTP系统中的以太网链路通过RFC 2544这种测试得到的吞吐率一般都能达到理论值（配置的带宽值），比如由5个VC3的绑定的以太网通道的吞吐率测试值约为240M。按照理论计算，以太网速率等于一个VC3的净荷速率（9列×85行×8000祯×8比特＝48.96Mbit）乘以GFP封装比率（以太网包长/(以太网包长＋12字节开销)）。例如：以太网包长1500字节，则GFP封装比率为1500/1512，以太网速率是48.96×1500/1512；以太网包长64字节，则GFP封装比率为64/76，以太网速率是48.96×64/76；5个VC3 每个按照48M算，带宽是240M。实际值与理论值相当。

　　但用户在使用过程中，由于网络环境和应用软件的差异，再加上用户往往使用一些流量监测软件来测试网络吞吐率，因此常常会反映通道无法达到其租用链路的带宽。笔者就曾处理过这样一起故障。某客户租用我方一条200Mb/s带宽的以太网专线自A站至B站。我方按需求在MSTP系统中通过绑定5个VC3（240Mb/s）来给用户提供通道，并通过Exfo测试仪进行了RFC 2544的测试，吞吐率达到240Mb/s，符合用户的技术需求。但在交付使用后，用户一再反映其在使用过程中通过流量监测软件发现通道最大吞吐率只能达到约70Mb/s左右，并且用户在我方提供的通道两端脱离其他设备仅用两台PC来进行FTP测试也得到同样的结果，通道吞吐率最大只能达到约70M/s。

　　我方技术人员第一时间对用户租用的链路进行了测试，首先通过Exfo仪表进行RFC 2544测试，显示吞吐率依旧是240Mb/s。然后又通过Exfo测试仪对通道进行了误码测试，结果显示通道无误码。再接入用户的FTP应用，发现吞吐率依旧只能达到70Mb/s。更换用户测试PC后现象依旧。

　　影响MSTP以太网通道带宽的主要因素是误码和绑定时隙数，通过仪表的测试以及对网管数据的反复核对，确认通道无误码并且业务配置准确。与此同时，通过Exfo测试仪得到的吞吐率也与配置值相符（240Mb/s）。那么影响链路吞吐率的关键就应该在用户的应用环境上了。Exfo测试仪对于RFC 2544的测试是基于通道的，也就是说它的测试针对的是网络层以下的下三层。而用户使用的FTP软件—FlashFXP—是一款基于TCP（四层）的单线程软件。TCP服务的吞吐率除受到介质带宽限制外还将受限于发送窗口大小、往返延时RTT、丢包率这三个因素的影响。TCP服务是一项面向连接的服务，其发出的数据包必须在得到确认后才能进行后续包的传送，由于长距离传输，数据在传输过程中延时的增大是不可避免的，这样链路大部分时间都处于等待确认状态无法持续发送数据包从而导致链路吞吐率的大大降低。为了更有效的利用带宽资源，TCP服务引入了滑动窗口机制，通过对队列大小的合理设置可以更加高效的利用网络资源。

　　随后技术人员通过抓包软件对用户的测试情况进行了数据采集。得到如下一些数据。PC的发送窗口为65Kbyte（图一），链路往返时延RTT为7-8ms（图二），网络吞吐率为72.79Mb/s（图三）。

图一 —— 发送窗口

图二 —— 往返延时RTT

图三 —— 吞吐率

　　在进行FTP测试的同时也在传输设备上进行了数据采集，获取传输设备的运行状态。

A站方向：

　　B站方向：

　　采集的寄存器为丢包寄存器，当有丢包时寄存器的值会发生变化。从上述采集的数据没有发现寄存器的值发生变化，所以排除了传输丢包。排除了重传导致FTP下载速率低。

　　根据利托氏定理 (Little's Law) 中的等候理论，即

　　Lambda（吞吐量）= n（未决请求的数量）/ t（响应时间）

　　那么在链路没有丢包状况下TCP的吞吐率计算公式为：

　　TCP吞吐率＝发送窗口 / RTT

　　根据以上获取的数据计算得到当前链路在FTP应用下的吞吐率为：

　　计算值与实际测量值相当。

　　根据TCP吞吐率的计算公式，在网络延时无法改变的情况下，要想有效提升吞吐率就要增大发送窗口的大小。修改方法如下：

　　1.运行->regedit启动修改注册表。

　　2.在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AFD\ Parameters路径下增加如下键值（或修改，Parameters路径没有也可以手动增加）：

DefaultSendWindow：类型DWORD，值20000 (16进制)

DefaultReceiveWindow：类型DWORD，值20000 (16进制)

TransmitIoLength：类型DWORD，值20000 (16进制)

修改方法为点击后右键：

选择十进制，输入131072（即128kbyte的滑动窗口）

备注：输入值计算方法：目标带宽值*1024，即128*1024=131072

　　3.在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters路径下增加如下键值（或修改，Parameters路径没有也可以手动增加）：

GlobalMaxTcpWindowSize：类型DWORD，值20000 (16进制)

TcpWindowSize：类型DWORD，值20000 (16进制)

　　4.修改完成后重启计算机

　　重新测试后FTP的测试速率达到128Mb/s。据此方法设置可以将链路吞吐率调整到理论带宽值附近。

　　综上，基于RFC 2544的以太网测试通常都是面向下三层的测试，其测得的带宽即为链路实际下层链路有效带宽。TCP服务是一种面向连接的服务，由于滑动窗口机制的存在加上长距离传输带来的网络延时，不可避免的会出现链路吞吐率降低的问题，对于这样的情况通常的解决办法是调整两端系统的发送窗口值或者利用多线程技术来有效提升网络吞吐率。

    （文/陈姗姗）