吉比特无源光网络业务测速不达标问题探讨

中国电信股份有限公司江苏分公司操作维护中心数据传输维护部 刘玉东

本次测速采用江苏电信公司测速网站系统进行下载测试，该系统的测速原理是基于TCP（传输控制协议）设计。

1 基于TCP的下载协议及下载特点

TCP下载大文件时，需要把大文件切割为一系列报文段进行发送。一个TCP连接建立需要3次握手，在连接建立的时候就确认了连接双方的最大报文段，数据在options字段中。而TCP又是承载在以太网上传输的，以太网最大帧长为1518byte，去除以太网帧头及校验，以太网帧的净荷为1500byte。IP报文头最小字节数为20byte，TCP报文头最小字节数为20byte，TCP报文最大净荷就为1460byte了。一般TCP连接协商的最大报文段就是1460byte，实际也协商为1460byte。

TCP下载的特点：

TCP进行数据传输时会进行自己的流量控制，流量控制可以从发送方和接收方两个方面。在数据接收方控制数据传输流量的重要手段就是滑动窗口的值，此值反映的也是TCP能够接收缓冲区的大小。数据接收方通过此值告知发送方自己的接收缓冲区大小，让发送方根据此值调整发送策略。

2 下载测试

某用户测试GPON（吉比特无源光网络）下载速率，见图1，做了 60 Mb/s、40 Mb/s、20 Mb/s、10 Mb/s四组数据的测试，发现在使用60 Mb/s的测试的情况下，下载速度只有32 Mb/s左右，未能达标（承诺带宽的80%）。

用户在上网时经常会遇到此类网速慢的问题，导致这种状况的原因很多，装维人员首先要主动找出网络瓶颈是发生在端到端网络中的哪一个环节，这才是至关重要的一步，同时也为最终解决问题提供了捷径。Internet之所以复杂，就是因为端到端的连接中间经过了无数的网络设备，而每一个设备节点的设置或则本身设备性能的问题，都可能导致网络瓶颈。所以找出网络瓶颈才是我们首先要关注的。

我们可以这么设想：一个立交桥上的车流量，是由这个立交桥上的入口处决定的。也就是说，入口每分钟能通过多少辆车，在立交桥中间不出事故的情况下，那么出口也就是这么多的车流量，而我们也可以通过这个思路来验证在接入网OLT（光纤线路终端）这个层面数据转发没有问题。

通过在华为OLT设备上反复查看命令的输出MA5680T（config-if-giu-0/17）#displayporttraffic 0，可以发现输出信息中“Thereceived traffic of thisport（octets/s）”提示上行口上在开放60Mb/s下载带宽的时候，只收到了32Mb/s的数据流：

MA5680T（config-if-giu-0/17）#displayporttraffic 0，

traffic of this port(octets/s)=4051330，

Downstream:40513.30KB/s×8=32426.4 Mb/s，达到上行口的报文流量就只有32 Mb/s。

证明数据流在达到MA5680T设备的上行口之前就已经丢包或则被限制了带宽。这就证明了网络的瓶颈不在OLT设备上，是上层网络设备或者是测速server问题造成的。

按照相同思路，排除ONU（光纤网络单元）丢包的可能性，那么就要把疑点锁定在两端。如前文所述，江苏电信测速网站是基于C/S（客户机/服务器）模型，测速原理也是基于TCP的应用层的协议，由于本身协议的特点，测速服务器的缓冲区必须针对不同的下载带宽来设置不同的值，才能达到预期的下载数值。

通过针对开放60Mb/s的下载带宽，在测速服务器上设置不同的缓冲区数值。经过反复测试，将缓冲区数值从10240 byte修改成6144 byte后，用户PC（个人计算机）端的平均下载速率可以达到56548.08 Mb/s。

3 结论

测速网站测速是一个端到端的处理过程。下载速率涉及到端到端整个业务流程的每个环节，包括了测速服务器和用户终端的硬件性能，传输线路的带宽和时延，TCP的算法（包括发送缓冲区大小），用户端的算法（包括滑动窗口大小）。本文提到的就是由于测速服务器的发送缓冲区大小设置不正确而导致用户端下载速率不达标的问题。

后续碰到这种问题时，建议在测速服务器上按照不同的下载带宽设置对应的缓冲区数值来解决，推荐缓冲区与带宽的值按照1∶1280即6144 byte∶60×1024×1024 byte/8的比例来设置。

由此可见，对于高带宽用户（GPON业务）只有在测速服务器上针对不同的下载带宽设置相应的缓冲区数值，才能保证用户下载带宽达标。