RFC2544测试

来源 https://blog.51cto.com/lyloveyou/1638483

吞吐量

吞吐量是衡量一款设备转发数据包能力的测试。这个数据是衡量一款防火墙或者路由交换设备的最重要的指标。

测试吞吐量首先根据标称性能确定被测试设备的可能吞吐量大小，这样来决定我们测试一款设备所需要的测试仪端口数量。如果一块设备标称性能达到8Gbps，那么通常我们需要8个1000Mbps的测试仪端口来测试。

吞吐量的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包长或者混合包长（IMIX）进行测试。IMIX流量通常是指用几种数据包混合流量来测试防火墙的吞吐量。我们测试用的比例为64Bytes*58%+570Bytes*34%+1518Bytes*8%，也就是7:4:1。如果需要测试***的吞吐量，不能使用1518Bytes，因为会分片，一般改用1400字节测试。

吞吐量一般采用UDP数据包进行测试。测试通常采用双向各一条流或者多条流的方式测试。测试流量通常是A<->B，C<->D双向对打的流量。使用单向流量测试的情况比较少见。

测试仪通常都会采用二分迭代法进行测试。比如测试仪会首先使用100%的流量发包（1st trial），如果发现丢包，则会采用50%((100%+0)/2)的流量进行测试（2nd trial），如果发现没有丢包，会采用75%((50%+100%)/2)的流量进行测试（3rd trial）。通过这种二分迭代的测试最终测试出设备的最大吞吐量数据。我们内部测试的时候每一个trial的时间设置为30秒，每个包长通常会进行8个trial的测试（取决于测试仪设置的精确度）。由于测试仪会严格判断是否有丢包，即使有一个包没有收到，都会用二分法往下降。但是这个丢包可能不是设备（网线质量，中间的交换机或者其他原因）造成。因此对于这种情况，测试仪都会有一个loss tolerance的设定，通过设定一个恰当的数值来避免其它原因造成丢包对测试结果的影响。

        在进行对一款设备的吞吐性能测试时，通常会纪录一组从64Bytes到1518Bytes的测试数据，每一个测试结果均有相对应的pps数。64Bytes的pps数最大，基本上可以反映出设备处理数据包的最大能力。仅仅从64Bytes的这个数我们基本上可以推算出系统最大能处理的吞吐量是多少。因为通常衡量一款网络设备的CPU/NP/ASIC的最大处理能力的极限就是64Bytes的pps数。很多路由设备的性能指标有一点就是宣称xxMpps，所指的就是设备处理64Bytes的pps数。比如64Bytes的pps为100000pps，吞吐量为100000*(64+20)*8/1000000= 67.2Mbps，拿这个结果计算1518Bytes的数据为100000*(1518+20)*8/100000=1230.4Mbps。其中的20Bytes是指12Bytes的帧间距（IPG）以及8Bytes的前导码（7Bytes同步+1Bytes起始），测试每一个字节的吞吐量都需要将这20字节计算在内。通过前面的算式可以看出，我们即使不测试1518Bytes的吞吐量也能够大致推算出设备最大的吞吐量是多少。而最终的结果只能<=这个结果。根据以往的测试经验，64字节测试结果的pps数与1518字节的pps数，相差在20%以内。

        测试注意项：1、防火墙接口的不同工作模式对性能的影响：路由、桥(ACCESS/TRUNK)、子接口、聚合接口等工作模式会对设备转发的性能有一定程度的影响，但是基本上不会偏差太大，当然个别的实例除外。2、网卡的型号会对转发的性能有一定程度的影响：a、部分网卡会网卡性能问题，例如测试过程当中遇到的82574L型号的网卡，千兆64字节的性能下载比数据只能测试到64.4%左右。网卡的驱动与防火墙的转发实现存在问题，例如中高端墙上的网卡的驱动e1000e只有一个队列，但是防火墙的转发进程存在多个，这样会导致网卡上的数据被转发进程获取的时候总有几个转发的队列是空闲的，导致最终的测试数据无法真实的反馈出我们设备的性能。

时延

时延所测试的是系统处理数据包所需要的时间。防火墙的时延测试的是其存储转发（Store and Forward）的性能（另一种是Cut and Through）。

时延的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包长或者混合包长进行测试。采用UDP数据包进行测试。测试通常采用双向多条流的方式测试。

时延的测试通常是建立在测试完吞吐量的基础上进行的测试。测试时延之前需要先测出每个包长得吞吐量大小，使用每个包长的吞吐量结果的 100%-90%作为时延测试的流量大小。一般时延的测试要求不能够有任何的丢包。因为如果丢包，会造成时延非常大，结果不准确。我们测试一般使用最大吞吐量的95%或者90%进行测试。测试结果包括最大时延，最小时延，平均时延，一般记录平均时延。

如果测试得比较精细，也可以测试在不同负载下的时延。比如可以测试在10%，20%…直到最大负载的结果下的时延。

测试时长通常是设置30秒的流量，然后测试几次取平均值最为最终结果。

丢包率

丢包率是测试系统在一定负载的情况下丢包数量多少的测试。这个测试实际上和吞吐量测试类似。测试的意义在于通过过载的流量来考查对设备正常转发性能的影响。

丢包率的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包长或者混合包长进行测试。采用UDP数据包进行测试。测试通常采用双向各一条流的方式测试。

测试方法通常是采用10%–100%的流量分别测试被测系统的丢包情况。当测试100%负载的情况事，对于NP/ASIC架构的防火墙来说，丢包率=1-吞吐量(%)。因为NP和ASIC转发更依靠硬件的性能，而硬件的性能通常比较稳定。而对于多核和x86架构的防火墙来说，转发依靠CPU的计算，性能相对硬件转发来说相对较弱，所以100%负载的丢包率>1-吞吐量(%)。比如我们测试出NP墙的吞吐量是80%，那么100%的丢包率基本上可以推算出等于20%，而多核和x86架构的防火墙的丢包率大多数情况>20%。所以，丢包率的测试对于我们产品的测试不是很有利。不过丢包率的测试在一般的对外测试中并不常见。

背靠背缓冲测试

背靠背缓冲测试主要测试被测设备缓冲处理burst数据的能力。考验的是被测设备处理突发数据流缓存数据并快速处理的能力。这个测试在一般的测试中并不常见。

测试方法和结果和吞吐量有很多相似的地方。测试仪向背测试设备发送一定流量大小的数据包，发送时间通常为1-2秒，然后看接收端能够收到多少的数据包。通常线速转发的设备的背靠缓冲能力和吞吐量的pps相一致。比如，一台设备能够线速转发双向2Gbps的流量，那么背靠背缓冲性能（发送时间为2秒）基本上可以确定是148万*2*2 pps。

网络层吞吐性能测试方法简介

    在之前已经写一篇RFC2544性能测试内容，此篇内容是接着RFC2544的性能测试项吞吐来继续深入一些阐述网络层吞吐性能应该来如何测试。

    吞吐性能数据最终要反馈给的目标人群有：自己、开发人员、产品人员、以及用户。那首先就要考虑各类人群如何从哪个角度来衡量产品的性能，这里我们从对内，以及对外给出两种测试方法。

    以下是笔者在对外的测试项目遇到的用户选择的测试方法：其中必有不足，欢迎各位补充：

a、常规的RFC 2544测试，64、128、256、512、1024、1280、1518等七种字节包长的udp双向对称数据包测试

b、常规的RFC 2544测试，64、128、256、512、1024、1280、1518等七种字节包长的udp单向数据包测试

注：a、b的测试方法在一段时间内，很受欢迎、认可。如：资质测试、入围测试、项目测试都用以上的标准做为网络层测试的标准，但是随着时间的推移，测试的方法慢慢熟知、普及，人们想到了更多的测试方法如：

c、常规的RFC 2544测试，64、67、128、256、512、1024、1280、1517、1518等九种字节包长的udp双向数据包测试

d、常规的RFC 2544测试，64、67、128、256、512、1024、1280、1517、1518等九种字节包长的udp单向数据包测试

e、64、512、1518一定比例混合测试

f、64、128、256、512、1024、1280、1518的ip报文测试

对于以上几种的客户测试方法，我们需要明确我们当前产品的支持情况。拿防火墙做个简单的举例，不同厂家对自己转发实现的方式不一致。

1、传统包过滤防火墙：所有数据包都需要进行没有选择的过滤，所以以上这几种方法转发都不存在问题，对性能的结果也基本影响不大。

2、无状态连接防火墙：以上f这种测试方法可能会造成转发与性能问题。此类防火墙要建立连接，连接建立的前提是五元组，但是此时测试的报文是ip报文，连接应该如何建立？转发的过程当中是否还需要每次都进行route、nat、acl等逻辑，是否又会影响到性能？

3、有状态连接防火墙：通过有状态连接的防火墙，都会为了性能的提升做出快速转发模式与默认转发模式。针对这两种模式，大部分的厂家实现想要进入快速模式，都是需要连接上有双向的数据包，所以当此两种条件限制，测试方法b、d、f是否会表现出异常？额外再加点料：进入到快速转发模式的连接上再来了分片包，转发是否存在问题？

4、下一代防火墙：众所周知，下一代防火墙前提要基于应用识别，而且要高性能、云特征分析等，那以上的测试方法又会带来哪些问题呢？大家都来分析一下。

    接下来为对内测试：在以上a、b、c、d、f、g的测试方法前提下，通常都会增加不同的工作模式测试如：二层（vlan、bridge、bond、旁路等）、三层（路由、bond、子接口等）、在不同的工作模式下，分别验证快速转发模式、默认转发模式的性能，以及性能的差别，并明确差别的合理性；基于以上的测试，再扩展功能如路由、nat、策略，测试各项功能对转发的影响。此外在过往的经验中对吞吐性能的影响还有一个比较大的影响参数：并发连接数。测试不同的并发连接数下吞吐的性能，很有可能会发现并发连接数导致的性能问题。对于以上的测试请记录详细的测试过程数据，方便查看以及日后追踪、回忆。

测试点记录如下：（只简单的列了2大项）

二层：

vlan+快速转发模式  

1、测试结果：如：package转发速率、延时

2、测试过程：如：cpu使用率、内存使用率、并发连接数、perf记录等有利对性能分析的数据

vlan+快速转发模式+功能（路由、nat、策略等）

vlan+默认转发模式

vlan+默认转发模式+功能（路由、nat、策略等）

三层：

路由+快速转发模式

1、测试结果：如：package转发速率、延时

2、测试过程：如：cpu使用率、内存使用率、并发连接数、perf记录等有利对性能分析的数据

路由+快速转发模式+功能（路由、nat、策略等）

路由+默认转发模式

路由+默认转发模式+功能（路由、nat、策略等）

结合上一篇查看快速转发模式与默认转发模式在不同字节package的转发速率，对比多款机型、平台看看是否存在一定的关系。

另外请注意测试出来的数据一定要反思，为什么会是如此个数据，是如何来的，这样才能提高。

对内测试列了很多需要测试的数据，就是为了更完整的反应产品的性能，但是这么多的性能数据，这么多的工作量在紧张的测试资源条件下，该如何进行呢，请大家来思考。