网关类产品的性能测试之二：RFC2544四项指标测试方法

前面我们介绍了各性能指标项的含义，下面我们针对各性能指标项是如何测试的进行详细描述。
对于每家评测机构、客户和安全厂商，同一个性能指标在测试方法上可能有所区别。建议在测试之前首先了解客户的需求，了解客户的性能关注点在哪里，并根据实际的需求适当的调整测试方法。虽然RFC2544文档和RFC3511文档描述了相关的测试方法，但这样的测试方法并不一定能满足客户的需求，而且RFC 文档中对测试细节并没有太详细的描述。下面以我在实际测试中积累的经验和向业界学习到的知识，描述我理解的性能测试方法。

术语介绍

文章中会涉及到一些术语，现总结如下，供参考。

性能测试，对产品负载压力承受能力的测试。
RFC，互联网及软件等的一些标准，基本的互联网通信协议都有在RFC文件内详细说明。
网关类产品，部署作为网关的设备及软件。
IDS，入侵检测系统
IPS，入侵防御系统
UTM，对防火墙、IDS、IPS三个的综合，可以比较全面的进行管理。但是UTM通过一台物理设备集成大量功能，导致了应对大量数据的时候效率会下降，同时存在设备损坏导致全面崩溃的可能。
NGFW，下一代防火墙，安全设备类产品未来的发展方向。
被测设备，devices under test，测试设备。

RFC2544四项值测试方法

RFC2544文档对四项值的定义和测试方法描述还是比较全面的，但在细节上没有过多的描述。下面我将描述一下实际测试中总结的RFC2544四项值的性能测试方法。

吞吐量（Throughput）测试方法

吞吐量主要是反映设备的最大转发速率，在测试过程中需要明确测试条件。需要考虑的有：

测试周期：在恒定的速率下数据包的测试时长。为测试出被测设备的真实转发能力，建议测试周期不要太短，应在60秒以上，我们日常选用的是100 秒。在实际的测试中，也发现测试周期的长短对测试结果确实有一定的影响，特别是x86系统。
在测试周期上，RFC2544文档中指出测试周期不应少于60秒。
测试次数：增加测试次数以避免被测设备在数据转发中存在随机性或波动性，同时可以验证产品在数据转发中是否可靠。在实际测试中，确实也发现一些产品在进行多次测试时，每次的结果都不一样，这同时也反映了产品的可靠性。
测试粒度：可采用较大的变化粒度来测试吞吐量。一般多用二分查找算法或冒泡算法。
测试帧长：对以太网来说，一般测试帧长为：64B、128B、256B、512B、1024B、1280B、1518B。在评测机构或者客户选评时多采用上述的7 种单一帧长做为测试项。在实际测试中，除上述7种单一帧长以外，还应加入混合帧长的测试。
单双向测试：现在的网络设备的端口（接口）多数都是千兆起，而且工作模式基本都是全双工。测试过程中为了能更好的反映产品性能，多数测试过程中都会进行双向测试：端口上有TX流量也有RX流量。在测试方向上，RFC2544文档中的吞吐量介绍中没有明确的说明，因此单向还是双向取决于测试设计。但建议采用双向进行测试。
被测设备端口：吞吐量的测试都是反映被测设备的转发能力，往往一对接口无法满足测试需求，这时就要进行多端口测试。在RFC2544文档中描述了在多端口测试时，端口中最开始的一半被设计为输入端口，另一半则被设计为输出端口。这些端口应该被平均分配到测试设备结构中。这里我们建议一对一即可，前提是端口或网卡的芯片组应相同、驱动相同、在硬件设计中相同。如果任意配置有区别，都要遍历每个接口的吞吐量性能。
测试协议：在测试被测设备的吞吐量时，应明确数据包承载的协议。在RFC2544文档中没有明确说明在测试吞吐量时应选用哪种协议。评测机构和客户多选择UDP协议做为标准测试协议，但不排除选用IP协议或TCP协议。在实际测试中，多选择UDP协议，但也遇到过选择TCP协议的。所以，在测试开始前应沟通明确此项。
被测设备的转发模式：在测试时，我们需要知道被测设备是路由转发，还是透明转发。如果是路由转发在测试前要发送“学习帧”和路由更新信息等。一般这些动作不需要我们干预，测试仪表都能帮我们完成，我们需要做的是明确网关。

吞吐量其它注意事项

在同等带宽下，长度越小的帧，数量就越大，那么被测设备处理数据帧所花费的时间就越多；相反，帧长度越大，所处理的时间就越少。
在计算吞吐量结果时，需要注意帧与帧的间隔长度（12byte）和前导码（8byte）。在实际测试中，发现有些测试仪表在计算结果中没有计算帧间隔和前导码。这时得出的吞吐量结果为真实数据包的结果。举例，千兆接口在测试64B性能时，线速的pps为148.8万，计算成bytes为760Mbps 左右。所以，我们在查看和统计结果时，除了记录Mbps数据，也应注意pps结果和测试出的百分比。
（IXIA 的IxAutomate 软件在计算吞吐量，给出的是数据结果。）
在测试过程中，被测设备出现测试结果波动的情况下，应增加测试次数并计算波动范围。最高值与最低值的浮动不应超过平均值的5％。并且结果记录应取最低值。

延迟（Latency）

延迟（也叫做时延）的性能是反映被测设备在转发数据包时所耗用的时间。需要考虑的测试条件有：

测试周期：延迟的测试周期与吞吐量的测试周期概念上是一样的，建议与吞吐量的测试周期一致。
测试次数：延迟的测试次数在RFC2544文档中有明确的定义：至少要在20次以上，并取被记录的平均值做为结果。但建议取被记录的结果中与平均值最接近的值做为测试结果。
测试结果计算方法：在测试网关产品的延迟，特别是防火墙的延迟时包括两种计算方法，一种是直通交换转发（cut throughput latency,CT），另一种是存储转发（store and forward latency,S&F）：
- 直通交换转发：入口处输入帧第1个比特到达被测设备至出口处输出帧的第1个比特输出时所用的时间间隔。
- 存储转发：入口处输入帧最后1个比特到达被测设备至出口处输出帧的第1个比特输出时所用的时间间隔。
  建议在测试延迟时选择直通交换方式计算延迟。
测试帧长：延迟测试与吞吐量测试不同，不能在同一个测试中把所有被测帧长测试完成，我们知道延迟的发包速率与吞吐量有关。所以，在测试延迟时先要知道该字节的吞吐量。一次执行脚本只进行一种帧长度的延迟测试。测试帧的长度应与吞吐量的测试帧长一致。
单双向测试：与吞吐量测试方法及配置一致。
被测设备端口：在测试延迟时，一般为两个端口或接口的延迟结果，很少有测试多端口或接口的结果。这个与吞吐量的配置是一致的。
测试协议：与吞吐量测试方法及配置一致。
被测设备转发模式：与吞吐量测试方法及配置一致。

延迟其它注意事项

在测试延迟时准备的过程和内容与测试吞吐量时保持一致即可，比如数据包的协议类型、数据包帧长、被测设备的配置等。
在测试延迟的过程中出现丢包的话，可能导致延迟结果变得很大。所以测试延迟时不应出现丢包，否则严重影响测试结果的准确性。因此在测试延迟时先要知道吞吐量的结果。对于一些x86架构的平台，吞吐量一般都不是特别的稳定（特别是64字节的吞吐量），建议在测试延迟时发包速率使用吞吐量速率的95％。
在计算延迟结果时，RFC2544给出的方法是计算被记录结果的平均值。单这样计算出的结果很可能在被记录结果中找不到，建议测试结果采用被记录结果与平均值最接近的值。此外，测试次数上RFC2544要求20次以上，也建议在测试延迟时不少于20次。

丢包率（Frame Loss）

丢包率测试过程是以特定速率发送特定数量的数据包通过被测设备，并记录被测设备转发的数据包。
丢包率的计算公式：((输入量－输出量) * 100) / 输入量
需要考虑的测试条件：

测试周期：在进行丢包率的测试时，可以选择数据包总量或者时间两种方式进行测试。数据包总量是指在测试过程中发送的数据总数，是一个恒定的值，建议数据总数不应少于10万个。测试时间这个概念与吞吐量和延迟的测试周期一样。
测试次数：丢包率的测试与吞吐量或延迟有所区别，一般只需要进行一次测试即可。
测试过程：丢包率在测试开始前，无论选择是数据包总量方式还是时间方式，在第一次测试时，都是以100％的速率进行发送数据包到被测设备上，并且记录输入量与输出量；第二次测试时，再以90％的速率发送数据包；然后以80％，每次递减10%的间隔测试速率。直到出现输入量与输出量相等，没有丢包时即为最终测试结果。
测试帧长：测试帧的长度应与吞吐量的测试帧长一致。
单双向测试：与吞吐量测试方法及配置一致。
被测设备端口：在测试丢包率时，一般都是测试两个端口（或接口）的延迟结果，很少有测试多端口的结果。这个与吞吐量的配置是一致的。
测试协议：与吞吐量测试方法及配置一致。
被测设备的转发模式：与吞吐量测试方法及配置一致。

丢包率其它注意事项

在测试丢包率时准备的过程和内容与测试吞吐量时保持一致即可，比如数据包的协议类型、数据包帧长、被测设备的配置等。
在测试丢包率时，可在选择以总量方式或者时间方式进行测试。选择总量方式时数据包不应少于10万个；选择时间方式时应与吞吐量的测试周期一致。
丢包率的报告格式有别于吞吐量和延迟，应以图形方式标出。
RFC2544文档中给出了报告格式的标注方法，设定X轴是输入帧速率，Y轴是输入帧速率下的丢失百分比。X轴的左端点和Y轴的底部必须是零，X轴的右端点和Y轴的顶底必须是100％。图形上的多线条可以用于报告不同帧长、协议、数据流类型的帧丢失率。

背靠背（Back-to-Back）

背靠背的测试过程是使用最小的数据帧间隔发送一串帧序列到被测设备，记录被测试设备转发的帧数量。背靠背的值是测试设备可以不带任何帧损失处理的帧流量串的最大长度。

测试周期：背靠背的测试周期在RFC2544中规定，周期必须在2秒以上。建议测试周期与测试吞吐量的周期一致。
测试次数：背靠背的测试次数在RFC2544中规定，必须重复至少50次以上。取被记录的平均值做为结果。在这里同样建议取被记录的结果中与平均值最接近的值做为测试结果。同时建议测试次数可以适当減少，如果不够充足，至少要测试3次或3次以上。
测试计算方法：背靠背的测试方法与吞吐量的有些类似，如果记录的发送帧数量与转发的帧数量相同，帧流量串的长度被增加，并重新运行测试。如果转发的帧数量小于发送的帧数量，突发帧流量串的长度被减少，并重新运行测试。背靠背的值是在不丢帧情况下被测设备所能处理的最长突发数据帧量。
测试帧长：测试帧的长度应与吞吐量的测试帧长一致。
单双向测试：与吞吐量测试方法及配置一致。
被测设备端口：与吞吐量的配置一致。
测试协议：与吞吐量测试方法及配置一致。
被测设备的转发模式：与吞吐量测试方法及配置一致。

背靠背其它注意事项

在测试背靠背时准备的过程和内容与测试吞吐量时保持一致即可，比如数据包的协议类型、数据包帧长、被测设备的配置等。
测试背靠背主要是测试被测试设备缓冲处理突发（Burst）数据的能力，考验的是被测试设备处理突发数据流缓存数据并快速处理的能力。

总结

RFC2544四项值是当前网络互联设备性能测试的普遍使用标准，包括吞吐量、延迟、丢包率和背靠背。其中多数厂商或评测机构将吞吐量和延迟做为重要指标进行测试，但并不是说丢包率和背靠背不重要，而是制定了一种快速测试的策略。所以当我们想了解一个产品的基本性能，就可以优先测试吞吐量和延迟。
RFC2544四项值的测试是被运用最广泛的测试指标项，而且也是最基本的测试指标项。在测试过程中，多数的厂商或客户都会选用UDP 协议做为承载协议进行测试，很少有用TCP协议或者只用IP层进行测试。
RFC2544文档是定义四项值的测试方法，RFC1242文档中定义了四项值的名词解释。