近年来，边缘路由器的发展呈现出明显的ALL IN ONE趋势。在传统的路由、转发功能基础上，逐步融合了交换、安全、无线接入、语音等多种业务。随着功能的不断充实，边缘路由器在实际网络中扮演的角色也发生了变化，由传统意义上的网络互联设备，转变为集交换、安全、无线接入以及语音网关为一体的综合网关设备。传统的路由器性能衡量指标，重点关注单纯IP转发环境下单字节的转发性能，这种衡量指标和测试方法已经不能够准确地反映出多业务叠加环境下路由器的真实性能。本文主要结合边缘路由器多业务叠加的组网需求，讨论如何能够得到更贴近用户真实应用环境的性能指标和测试方法。帮助用户做设备选型时，选择更符合实际组网需求的设备款型。

从测试环境改进

路由、转发作为传统意义上路由器的主要功能，在衡量其性能时我们主要关注在单纯的IP转发环境下单字节的吞吐量（Throughput），测试环境相对简单，只需要在单台被测设备上配置接口IP地址即可。而多业务叠加环境下，多个业务对数据的处理会增加额外的系统开销，使用传统测试方法得到的性能测试结果，无法反映出这部分开销对性能的影响程度。

以边缘路由器的常用功能为例，我们分别测试单独配置交换、QoS、包过滤防火墙和NAT四种业务时的转发性能，并与所有业务叠加后的转发性能进行比较，对比结果如图1。

图1 不同业务对单字节转发性能的影响

以64字节为例说明：在单纯的IP转发环境下，被测设备的转发性能为线速的82%左右；当仅叠加包过滤防火墙时，被测设备的转发性能下降到63%左右；当仅叠加NAT、QoS或者VLAN时，被测设备的转发性能进一步下降到28%左右；当叠加所有上述业务时，被测设备的转发性能下降到10%左右。多业务叠加后的性能数据与单纯IP转发环境下得到的性能数据相比较，存在较大差距，这点在小字节的测试结果中体现的更为明显。

从测试流量改进

通过在测试环境中叠加多个业务模块，单字节的测试结果会出现明显的下降。然而在真实的网络环境中，流量组成是极其复杂的，各种长度的报文混合传输。多业务叠加环境下出现的单字节性能下降，只能反映出一个趋势，还不能够对真实环境下设备的性能表现给出准确的量化指标。

为了使实验室中的网络环境更加真实，我们在测试中引入概率分布和统计平均的机制。例如IMIX数据模型，其流量构成包括64字节、576字节以及1518字节三种长度的报文，三种报文在流量中的个数比例为7:4:1，报文平均长度为304.3字节，相对于实际Internet的流量的近似度为0.892。

【注：在VPN测试环境中（例如，GRE、IPSec），报文经过封装后往往会超过接口最大MTU导致分片，实际网络中丢包或者乱序的产生都会导致分片报文重组失败。实际应用中可以通过配置TCP MSS来改变客户端与服务器之间的TCP协商结果，缩小原始报文长度，避免封装后的报文再进行分片。因此在VPN环境下测试性能时，我们可以适当降低大字节报文的长度。】

使用前一节的多业务叠加性能测试环境，我们将测试流量改进成混合流量，以IMIX为例，可以得到如图2所示的性能对比结果。

图2 不同环境下的IMIX转发性能

在单纯的IP转发环境中，IMIX流量可以达到双向线速；叠加包过滤防火墙后，对转发性能没有影响，被测设备仍然可以达到双向线速转发；分别在NAT、VLAN以及QOS的环境中进行转发性能测试，测试结果会逐步下降到80Mbps左右；当所有业务叠加时，被测设备的转发性能为38.73Mbps。

使用IMIX数据流获得的性能数据是否真的更贴近真实流量下设备的性能表现？这一点，在后面的测试中会进一步得到证明。

从衡量指标改进

除了传统的Throughput（RFC2544）之外，我们需要引入更多的衡量指标。例如，并发TCP连接数（Concurrent TCP Connection Capacity）、最大TCP连接建立速率（Maximum TCP Connection Establishment Rate）以及HTTP最大事务传输速率（Maximum HTTP Transaction Rate）等防火墙性能测试指标，也同样适用测试多业务叠加环境下路由器的性能表现。

HTTP、FTP等常用网络应用都是基于TCP进行传输的，TCP连接的建立速率直接影响到上层业务的响应速率。因此，我们首先以最大TCP连接建立速率为例。在单纯的IP转发环境下，分别叠加包过滤防火墙、QoS、NAT、VLAN四个业务模块，使用测试仪模拟TCP建立过程，测试出设备能够支持的最大TCP连接建立速率。测试结果如图3所示。

图3 不同环境下的最大TCP连接建立速率

从上面的对比结果可以看出，交换模块的引入对于测试结果的影响最大，QoS和NAT对测试结果的影响居中，包过滤防火墙对测试结果的影响最小。当交换、NAT、QoS、Firewall四种业务叠加时，理想环境下（仅存在TCP连接建立报文）设备可以稳定响应每秒1400个TCP连接请求。

实际环境中的TCP应用流量除了TCP连接的建立与拆链，还会包括应用层报文的传输。应用层数据报文的加入，会进一步增加系统转发负担。最大TCP连接建立速率的测试结果与路由器对于应用层事务的处理能力相比，应该还存在一定的偏差，这个差距究竟还有多大呢？我们可以进一步对性能衡量指标进行改进，使用HTTP事务的处理速率来衡量设备的综合性能。

我们使用测试仪器分别模拟HTTP Client和HTTP Server，Client向Server GET页面内容为4K字节大小的网页。测试单纯IP转发环境下，分别叠加包过滤防火墙、NAT、QoS、交换以及所有业务叠加后的HTTP事务处理速率。测试结果如图4所示。

图4 不同环境下的HTTP事务处理速率对比

正如预期的那样，对比最大TCP连接速率的测试结果，叠加所有业务后的最大HTTP事务处理速率有所下降。设备在多业务叠加的环境下，对于GET 4K字节大小网页的HTTP事务处理能力稳定在每秒900个。

实际上，到了这一步，我们仍然可以进一步对测试指标进行改进。前一步得到的HTTP事务处理速率，其前提是稳定情况下，即HTTP事务处理速率在各时间点的采样近似一条直线。这个状态设备的负载还处于正常范围内，数据时延稳定。如果进一步增大HTTP事务的发起速率，会得到什么样的结果呢？

仍然以4K大小的页面为例。在叠加所有业务的测试环境中，从每秒900次页面请求开始逐步增大请求速率，可以得到如下的纪录：

注：Goodput：根据RFC2647中的解释，是除去丢弃或者重传的比特后单位时间内DUT转发的比特数。

Connect Time：TCP连接响应时延。

TTFB：Time to First Bytes，收到Response报文第一个字节的时延。

TTLB：Time to Last Bytes，收到Response报文最后一个字节的时延。

测试结果表明被测设备在Client每秒发送1300个事务请求时，仍然可以正常响应，并且用户对时延的主观感受在可以接受的范围之内。当请求速率上升到每秒1500个的时候，HTTP请求和TCP连接的失败记录开始增多，时延抖动明显，Goodput明显下降。每秒1300次的请求速率对于被测设备来说是一个临界点，此时的转发性能在45Mbps左右，这点与前面的IMIX性能测试结果比较接近（IMIX流量在多业务叠加时的性能为38.73Mbps，即当IMIX数据流超过38.73Mbps时，开始丢包，TCP出现重传）。

进一步测试，在Connect time小于等于100ms，TTFB小于等于50ms，且无TCP Failure和HTTP Failure的前提下，分别GET 8k、16k、32k、64k、128k、256k、512k以及1024k大小页面，并测量其最大HTTP事务处理速率，结果如下：

当用户做设备选型时，可以按照自己的业务模式参考近似的HTTP流量测试结果作为依据，选择符合实际组网需求的设备款型。

结语

随着边缘路由器功能的不断丰富以及测试技术的不断发展，会有更加合理的衡量指标与测试方法被进一步地发掘和采用，帮助客户需求得到及时满足。