工控防火墙测试之性能篇

1.构造大量的UDP报文，包长为512字节。在发送前开启实体机（Windows操作系统）wireshark抓包，在发送过程中把构造的报文都抓取下来并保存为test1.pcap文件。

这个操作可以利用我在《工控防火墙测试之功能测试》中介绍的报文构造方法，注意，在发送报文时，可以在脚本中使用 interval来指定发送报文的频率，即pps.

在实际的工作实践中，PC机抓取200万数量级的报文并保存出来是没有问题的，当然，这取决于具体PC的硬件配置。工作中使用的笔记本配置为内存4G,CPU Intel(R) i5-4200 @1.60GHZ，供参考。

2.把抓取的pcap文件使用tcpreplay进行回放，为了避免有突发流量对性能测试造成影响，要使用 -p 参数指定发送的pps。

如：tcpreplay –i eth0 test1.pcap -p 5000

3.以上只是实现了一个方向的流量灌入，为了测试设备接口工作在全双工时的报文转发能力，还需要同时在对端有对等流量灌入。

即重复上面的步骤1和步骤2的过程，然后在两台主机上同时回放报文如：tcpreplay –i eth0 test2.pcap–p 5000

1.两台pc在使用tcpreplay回放完报文后，会显示如下信息：

1)发送了总共多少个报文

2)发送用时多少秒

3)发送速率，包括Mbps, pps

4)发送多少条流

5)发送在哪个网卡

6)发送结果是否成功。

我们将两台发包机发送的报文数分别记为a1、a2,然后将a1、a2相加，计算出的值记为A。

2.在被测试设备上可以看到cpu总共处理了多少个报文,该数字记为B。如果是多核处理，会分别显示出每个核处理了多少报文,也可以清晰地看出不同核对报文的转发处理是否均衡，是否还有调优的空间。

将B与A的值相对比，如果B与A相等，就说明没有丢包，被测试设备能够达到当前的吞吐值；反之，B不等于A,则说明被测试设备不能达到当前的吞吐值，需要降pps再次试验，直至不丢包。

3.如果被测试设备没有丢包，就把当前的pps换算成Mbps（整机吞吐换算成Gbps）得到具体的吞吐值即可。注意，pps的值为两台主机发送报文时的pps之和。

1.我们先分别测试6对口，确保每对口的吞吐性能都能达到线速。

2.把6对接口从左到右依次排序为1，2，3，4，5，6.把pc1与第1对接口的入接口相连，把pc2与第6对接口的出接口连接，剩余的接口分别用1根网线依序连接，即把12个端口串起来打流量。

3.分别抓取用于回放的测试“整机吞吐”的流量报文，与测试1对口性能不同是的，此处为UDP双向12条流,包长512字节。

4.在两台pc上同时发送对等流量。

1.成功之处：在深刻理解硬件测试仪工作原理的基础上，使用等价法找到替换测试仪的替代方法。

2.重点：报文构造及获取，发包速率及匀速回放。

3.难点：匀速回放。

解决方法:

1)发送报文时指定发送频率

2)回放报文时指定回放频率

4.缺点：本文中构造的发包环境是依赖于软件，内存只有4G,而且是在虚拟机中发包，发包速度无法与硬件测试仪的发包速度相比。也就是说瓶颈在于PC机的性能。所以测试性能吞吐时会有5.8%的误差。如果是在一台有8G内存的真实电脑上安装Linux操作系统作为发包机，一定会再次提高测试精度，减小误差！

5.改进方案：两台配有8G内存，性能好的CPU的真实电脑上安装Linux操作系统作为发包机.

6.约束：该性能测试方法要求被测试设备具备可测试性和排障接口，这也是软件工程中必须具备和满足的要素。比如，CPU收发报文数及每个核各自处理多少报文数的查看接口，流表内容及总条目数查看接口等。