作为防火墙来说, 最大的特点就是对4-7层的高层流量可以进行一定的控制。所以在一定程度上讲,性能是肯定要受到影响的。而这种影响有多大,会不会成为整个网络的瓶颈, 从而使用户难以忍受, 就成为人们所关心的问题。 由于大部分防火墙的结构是软硬结合的, 所以功能上的要求较容易满足――只要可以想得到, 基本上实现起来困难不大。 但是落实到性能上,才可以看到产品的真品质。下面我们就浅析一下这方面的性能测试。 我们可以大致分为以下两类: 基准测试和真实环境测试。
基准测试(Base Line Testing)
首先是在防火墙配置规则情况下的性能测试。
这个测试和上篇中的二层/三层的测试是比较接近的。 但是此时需要在防火墙上配置规则。在一些防火墙的结构中,设置规则与透明模式相比, 将调用另外的例程,从而表现得大相径庭。我们在测试中应该考虑到这一点,所以建议可根据自己的需要设置数量不等的规则,再进行性能比较。 例如, 可采用1, 50, 100, 500, 1000甚至更多的规则, 然后再重复进行二层/三层的测试。 在这其中又分两种情况: 1.将所有发送的流量设置为可以通过该设备,此时可以直接和透明模式测试结果做比较,查看规则对性能的整体影响。2.将流量配置成含有“阻塞/通过”的多样化, 这样就需要使用的测试仪表能够提供强大的数据流发送功能, 而且在接收时将不同数据流区分出来。 在检查了“通过数据流”的性能的同时,亦可验证“阻塞数据流”是否生效。 这种测试的优势在于同时检查了被测设备的功能和性能, 而且更加符合实际的情况。
防攻击性能测试(DoS/DDoS)
攻击测试是很重要的一部分。 此时我们可采用一些典型的攻击方式如:Syn Flood, Ping Flood，Smurf等。 主要的目的是看看防火墙是不是能够成功的将其挡住。 当我们将合法流量混合攻击流量时,我们更可以看到防火墙在处理攻击的同时,对于高速的合法流量如何处理。一般来讲, 攻击测试既可以使用测试仪表实现, 也可以使用软件实现, 如一些黑客程序等, 但是象Syn Flood这样的攻击则对速度要求很高, 故使用测试仪表发送才能测出有意义的结果。 使用仪表时, 应注意对将来不断涌现的攻击方式做通盘考虑。 最好是能够对包的填充内容做完全控制, 而且有较好的脚本编程的功能。 在使用软件做攻击模拟时最好有仪表同时模拟背景流量。
另外需要指出的是: 并非所有攻击都应该被全部挡在外面。 如Syn Flood的攻击至少用满足某个门限值才能够被防火墙确认, 然后实施拦截。 再如Tear Drop攻击也能够被防火墙发现然后重组转发出去。 所以要根据攻击类型特别注意加以分析。 为确保所下结论正确, 建议在内网旁路一个协议分析仪进行捕获和分析。
TCP连接性能测试
人们一提到L4-L7的测试, 就自然想到了TCP 连接(TCP Connection)。 关于连接的测试一般有两个方面。
1. 并发连接总数的测试。 并发连接是一个很重要的指标。 它主要反映了被测设备维持多个会话的能力。关于此指标的争论也有很多。一般来说,它是和测试条件联系紧密的。 但是这方面的考虑有时会被人们忽略。 比如,测试的时候采用的传输文件大小就会对测试结果有一定的影响。 可以这样考虑:如果在传输中高层流量很大的话, 被测设备将会占用很大的系统资源去处理包检查,导致无法处理新请求的连接，引起测试结果偏小。 反之则测试结果会大一些。 所以没有测试条件而只谈并发连接数是难以定断的。 从宏观上来看, 这个测试的最终目的是比较不同设备的“资源”。也就是说处理器资源和存储资源的综合表现。中国市场上出现了大家盲目攀比并发连接数的情况。事实上,并发几十万的连接数应该足可以满足一个电信级的数据中心服务网络了,对于一般的企业来讲, 甚至可能并发几千个连接数已经绰绰有余。 并发连接总数应能由仪表自动测试结果, 以减少测试所用的时间和人力。
2. 并发连接处理速率。这个指标主要体现了被测设备对于连接请求的实时反应能力。对于中小用户来讲,这个指标就显得更为重要。 可以设想一下,当被测设备每秒可以更快的处理连接请求,而且可以更快的传输数据的话,网络中的并发连接数就会倾向于偏小,从而设备的压力也会减小,用户看到的防火墙性能也就越好。所以并发连接处理速率的确是个很重要的指标。 理想的测试工具可以帮助使用者搜索到被测设备能够处理的峰值, 减轻其工作的负担。
有效吞吐量测试(TCP GoodPut)
当我们谈起吞吐量时,大多都是指二层/三层的测试结果。但是随着测试面向的流量转为四层以上, 有效吞吐量的概念就显得重要起来了。这个概念通俗点讲, 就是除掉TCP因为丢包和超时重发的数据, 实际的每秒传输有效速率。 计算的方式也很简单明了:用所传输的文件大小除以传完这个文件的时间, 得到一个平均速率, 称为“有效吞吐量”。 不难看出,这个概念实际上和前面所提到的“吞吐量”是完全不同的。请注意避免混淆。在RFC2647中也对此概念有所说明。那么通过这个测试我们能够得到什么信息呢?首先,我们可以知道测试中的延迟和丢包对最终用户的影响有多大。因为最终用户是不关心二层三层的。他们的大部分应用都是运行在四层以上。如果有效吞吐量性能不好(即使二/三层的转发性能不错),则会导致整个主机看起来运行缓慢。其次,这个测试也有助于帮助厂商定位问题及找到系统的未来可发展空间。可以将此结果和基准测试中的结果做一对比,确定是第三层的转发引擎还是第四层的状态检查影响了系统性能。在做此测试的时候, 应该注意采用多个模拟的主机进行混合测试。原因是由于TCP是采用“滑动窗口”的状态相关的协议,所以理论上讲, 模拟单个主机是无法使链路的最大性能发挥出来的。
TCP连接建立的延迟
RFC2647中提出了测量这个指标。 理想的情况是测量出每个连接从发起到确认连接建立的时间差, 给出最大、最小和平均的测试值。 事实上, 做到这点是相当困难的, 因为测试工具必须能够跟踪上万个连接, 而且能够实时的将它们的相应报文挑出来, 分别进行统计。 而目前来看还没有一个这么强大的工具能做到这点。 所以在多数情况下可采用几种方式代替, 如测量单位时间内实际建立的连接数(排除缓冲区的影响), 或测量客户端收到第一个字节数据的时间等等。
真实环境测试(Real World Testing)
限于篇幅, 本文将主要介绍一下所谓“真实环境测试”的概念。 这种测试是最近比较热门的一种提法。 其主要特点是尽可能地把测试的流量和测试的环境接近于真实, 甚至有可能就将真实的流量捕获之后重放到网络上面。为了区别前面讨论的“基准测试”, 我们举一个小例子: 当我们的防火墙在网上运行的时候, 在某一时间面内, TCP连接可能存在着三种情况: 有的正在建立, 有的正在传输数据, 有的正在关闭。 这是一个“真实”的情况。 但是我们在做“基准测试”的时候并没有考虑这样一个复杂而混乱的情况, 而选择了相对来说比较“纯净”的测试流量模型, 即不断的建立连接, 然后传输数据, 而后依此关闭连接。 从而我们得到一个好处: 测试结果比较稳定, 流量模型可控。
但是我们失去了一些真实性。 有可能会造成一些问题难以在测试中发现。 再举一个例子: 用户上网的时候都有各自的接入速率, 在到达网站的路径上都会有丢包, 在看网页的时候可能有自己的思考时间, 在网页下载缓慢的时候也有自己的容忍限度等等, 这些都是一些现实问题, 都可能对选择设备和网络设计产生影响, 而这些问题在“基准测试”中是被忽略的, 被认为是理想的, 而恰恰是“真实环境测试”需要考虑的。 从这两个例子中我们可以简单总结出一条结论: “真实环境测试”实际上是一种绝对测试, 即对测试个体在网络的真实运行状态的一个绝对的评价; “基准测试”则是一种稳定的相对测试, 侧重点在于不同产品之间的比对。 二者各有其优势。 而“真实环境测试”由于在以前的测试中重视不够, 所以目前发展空间比较大, 值得关注。 以后我们将另文深入探讨该测试, 但这里需要指出的是, 不要简单的认为使用真实的捕获的流量的测试就是“真实环境测试”。
