RFC2544测试指标

RFC2544测试指标

参考：https://wenku.baidu.com/view/3abbb5bf960590c69ec3769d.html  RFC2544性能测试介绍

参考：https://wenku.baidu.com/view/6556b31382c4bb4cf7ec4afe04a1b0717ed5b348.html   RFC2544以太网性能测试规程

参考：https://wenku.baidu.com/view/7ccbcb4b2b160b4e767fcf9e.html   关于防火墙性能测试(RFC2544)

网络数据包中，小包、中包、大包、分别指 64字节是小包，64~1518字节的是中包，大于1518的是大包。
网络中 Maximum Transmission Unit(最大传输单元)一般是1500

原文：https://blog.csdn.net/jane_rabbit/article/details/10140199

RFC2544提供了一个对网络设备测试的基准，它规定了一系列的测试过程和方法，使得服务提供商和用户间可以在同一个基准下，对测试的实施和结果达成共识。

RFC2544标准要求的帧长：64byte、128byte、256byte、512byte、768byte、1024byte、1280byte、1518byte

一、吞吐量（Throughput）

设备能够无丢失地传送接收到的帧信号的最大速率，简单的说就是从源发送方，到目的接收方，无丢包的情况下，单位时间内可传输的最大数据量。对于一个以太网系统，绝对的量大吞吐率应该等同于其接口的速率。实际上，由于不同的帧长度具有不同的传输速率，这些绝对的吞吐率是无法达到的，越小的帧由于前导码的帧间隔的原因，其传输效率就越低。

64byte的帧，其最大数据吞吐率（Data Throughput）是76.19MBit/s，每秒可传输148809帧。对于1518byte帧，则分别为98.69MBit/s和8127帧/s。

测试要求：一般把测试持续时间设定为20s，为了克服随机性的影响，每一个测试案例的测试次数设定为20次；测试粒度设定为不过理论速率的1%。

二、时延（Latency）

是指一个帧从源点到目的点的总传输时间，这个时间包括网络节点的处理时间和在传输介质上的传播时间。一般的测试方法是发送一个带有时间戳的帧，通过网络后，在接收方将当时的时间和帧所携带的时间戳比较，从而得出延时值。考虑到时间同步的问题，一般采用将发出的帧环回到发送方进行比较，因此也称为双程时延。

有两种定义方法：存储转发时延（store and forward latency,S&F）和直通交换时延（cut through latency,CT）。存储转发时延是指数据帧最后一个比特到达设备输入端口的时间与该数据帧第一个比特出现在设备输出端口的时间间隔，按后进先出的方法计算；直通时延是指数据帧第一个比特到达设备输入端口的时间与该数据帧第一个比特出现在设备输出端口的时间间隔，按先进先出的方法计算。

RFC2544要求对时延测试至少要重复20次，至少持续120s，结果取所有测试结果的平均值。

三、丢包率（Frame Loss Rate）

就是发送方发出但没有到达接收方的帧的数目。一般表示为帧丢失率。即相对于总发送帧数目的一个百分比。

计算公式：丢包率 = 接收方没有收到的包的个数/发包方的发包总数 * 100%

四、背靠背（Back to back）

属于边界值测试范畴，是向被测试设备连续发送具有最小帧间隔的N个帧（以太网标准规定最小帧间隔为0.96微秒），在不发生丢包的情况下，统计被测设备送出的帧的个数。如果和发送的个数相等，则增加N值，重复上述测试过程。直到被测设备送同的帧个数小于测试发送帧个数。反之则减少发送帧数，并减少发包时间，直至没有帧丢失发生。主要用于衡量具有存储转发能力的被测试设备的最大贮转发能力。

它主要和以下一些因素有关：网络设备内部缓冲的大小；网络设备入、出口之间的速率差；网络设备转发能力的大小；网络设备交换网络的调度算法等。

标准中要求发送时间不能小于2s，建议至少重复20次，结果取其平均值。

五 、系统恢复（System recovery）

用于测试设备在超负载情况下的系统恢复能力。测试过程为先按被测设备最大吞吐率的1.1倍发送至少60s的数据，然后将速率下除50%，统计速率下降到无帧丢失之间的时间，即为系统恢复时间。

六、复位测试（Reset）

用于测试系统从复位到恢复正常工作之间的时间。测试过程为先按最大吞吐率发送最小长度的帧，然后复位被测设备，统计复位前发出的最后一帧的时间戳和复位后收到的第一帧的时间戳的差值，即为复位测试时间。

Note: All performance values are “up to” and vary depending on system confguration. Antivirus performance is measured
using  Kbyte HTTP files. IPS performance is measured using  Mbyte HTTP files. IPsec VPN performance is based on
 byte UDP packets using AES-+SHA1. Firewall Throughput performance is measured using UDP  Bytes
based on RFC . Antivirus Throughput is measured in proxy mode.

http://sd.wareonearth.com/~phil/jumbo.html

Whether or not Gigabit Ethernet (and beyond) should support frame sizes (i.e. packets) larger than  bytes has been a topic of great debate. With the explosive growth of Gigabit ethernet, the impact of this decision is critically important and will affect Internet performance for years to come.

Most of the debate about jumbo frames has focused on local area network performance and the impact that frame size has on host processing requirements, interface cards, memory, etc. But what is less well known, and of critical concern for high performance computing, is the impact that frame size has on wide area network performance. This document discusses why you should care, and about the largely ignored but important impact that frame size has on the wide area performance of TCP.
How jumbo is a jumbo frame anyway?
Ethernet has used  byte frame sizes since it was created (around ). To maintain backward compatibility,  Mbps ethernet used the same size, and today "standard" gigabit ethernet is also using  byte frames. This is so a packet to/from any combination of // Mbps ethernet devices can be handled without any layer two fragmentation or reassembly.

"Jumbo frames" extends ethernet to  bytes. Why ? First because ethernet uses a  bit CRC that loses its effectiveness above about  bytes. And secondly,  was large enough to carry an  KB application datagram (e.g. NFS) plus packet header overhead. Is  bytes enough? It's a lot better than 1500, but for pure performance reasons there is little reason to stop there. At 64 KB we reach the limit of an IPv4 datagram, while IPv6 allows for packets up to 4 GB in size. For ethernet however, the 32 bit CRC limit is hard to change, so don't expect to see ethernet frame sizes above  bytes anytime soon.

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的转发速率，对比多款机型、平台看看是否存在一定的关系。

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

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

================ End