本篇是《给力吧，x86》专题的第9篇连载内容，也是截至目前最后一篇。其中性能评估从Atom N270到Sandy Bridge，涵盖了目前主流嵌入式平台（尚缺3420）。后面如果时间、精力、环境允许，会补充针对NIC的独立测试。再次感谢同事与厂商朋友们付出的努力，也感谢弯曲站务组和读者朋友们的支持。

本专题内容原文刊登于《计算机世界》。水平有限，文中定有偏颇之处，希望弯曲网友不吝赐教。

==============================================================

上一期连载内容中（见本报今年35期第36、37版），我们记录了上海交通大学网络信息中心的老师们通过严谨的测试，选择基于英特尔5520平台的x86服务器打造校园网流量分析与优化系统的全过程。那么，万众瞩目的英特尔新一代Sandy Bridge平台在网络通信应用中又会有怎样的表现？它是否可以将效能推进到一个新的高度？就让测试数据去证明一切吧。

价格越来越低、性能与可靠性越来越高，这就是x86平台在网络通信领域的发展现状。从之前的一系列测试中也可以看出，目前英特尔嵌入式产品解决方案已经很好地覆盖了百兆级、千兆级乃至准万兆级应用领域，并有着继续向上延伸的趋势。向上拓展的先锋自然是英特尔Sandy Bridge平台，基于该架构的桌面级产品自发布之日起就凭借超强的实力在市场上独领风骚，也大大增加了人们对其企业应用效能的期待。千呼万唤始出来，在经历了更多的设计与验证周期后，基于Sandy Bridge的网络通信硬件平台终于批量入市。本次我们测试的立华科技提供的FW-8865，就是首发产品中的优秀代表。

规格放大 体积缩小

FW-8865的核心是英特尔Cougar Point C200芯片组中最高端的型号C206，支持LGA1155接口的Sandy Bridge处理器，包括企业级的Xeon E3和桌面级的Core i3/i5/i7。理论上，LGA1155平台的Sandy Bridge处理器和芯片组可以混合搭配，但前提是使用正确的、高质量的BIOS，因此并不是所有的主板都能良好地兼容两种处理器。FW-8865在这方面显然不存在问题，因为测试中使用的就是一颗四核心、32nm工艺制造的Core i7 2600K。该处理器具有256KB L2缓存（每核）和共8MB容量的通过环形总线和CPU核心连结的共享L3缓存，主频为3.4GHz，最大Turbo Boost频率可以达到3.8GHz。不过从稳定性的角度考虑，该特性在测试中没有被启用。同样的道理，Core i7 2600也支持超线程技术，可以提供8个硬件线程，但在测试中也被关闭。

针对处理器内置PCIe 2.0 Lane数量的差异，FW-8865的主板也分为支持Core i系列的MB-8865A和支持Xeon E3系列的MB-8865B。对于后者来说，Xeon E3系列处理器额外的4个PCIe Lane也连接到左起第三个扩展接口模块，与C206提供的另外4个PCIe Lane共同工作，使接口带宽加倍；另外两个接口扩展模块的规格则没有区别，使用的都是处理器上16个PCIe Lane配成的两个x8接口。内存方面，MB-8865A/B都提供了4个ECC DIMM插槽，最大支持32GB的Unbuffered ECC/Non-ECC DDR-1333内存。而我们测试的这台设备配备了两条2GB容量的DDR3-1333内存，工作在双通道模式。FW-8865的标准配置还包括一个Mini-PCI插槽、一个x4的PCIe Riser（与OPMA远程控制模块复用）、一个CF卡插槽和4个SATA端口，并使用一颗Realtek出品的RTL8110SC千兆网络控制器作为管理配置接口。

作为最新一代的网络通信硬件平台，FW-8865提供了多种高速以太网接口扩展模块（甚至包括万兆电口的型号），可供用户灵活选配。对于这个目前最强大的x86平台来说，千兆级别的负载显然不能充分挖掘其性能，所以本次测试都在搭配双万兆接口扩展模块的FW-8865上进行（使用与处理器直连的槽位）。该模块基于英特尔82599ES打造，它是常见的82599EB的串行版本，主要区别是针对高密度/刀片应用增加了对串行背板总线的支持，功能、性能都极其强大。在T540尚未推出前，它们是英特尔万兆网络控制器产品线中最顶级的型号。82599ES/82599EB使用了5GT/s的PCIe 2.0 x8接口，支持32个PCIe并发请求和512字节的PCIe有效载荷，以及MSI和MSI-X（Extended Message Signaled Interrupt，扩展消息告知中断)特性。单芯片提供双万兆以太网接口是82599ES/82599EB的标准规格，每个接口可以支持128个TX/RX队列，并可根据需要最多划分为64个RSS（Receive Side Scaling，接收方扩展）队列。此外，它们还支持RSC（Receive Side Coalescing，接收方聚合）、低延迟中断等技术，以及包括基于L2 Ethertype、5元组、SYN标识以及英特尔Ethernet Flow Director在内的多种分类/过滤特性。

也许是因为英特尔在芯片层面就开始整合，基于Sandy Bridge平台的FW-8865在设计上显得并不复杂，2U规格的机箱内留有大量空间，对系统散热十分有利。而从最大300W的冗余电源的配置来看，该机的整体功耗也相对较低。有了这样的优势，立华科技也推出了接口数量略低的1U规格产品，在机架空间愈发宝贵的今天相信会有更强的竞争力。

40G：理想照进现实

我们依旧采用了NCPBench 0.8评估软件，依照RFC 2544标准对多达4个万兆接口进行了纯转发模式下的测试（NCPBench的功能介绍和使用方法见本报今年第16/17期51版）。起初我们曾怀疑这个发布已有一段时间的版本不能充分发挥最新硬件平台的性能，但事实证明这种担心是多余的。FW-8865在测试中的表现，足以用震撼二字来形容：当我们将一个扩展模块上的两个万兆接口配置为网桥进行测试时，64Byte帧的整体转发速率达到22.3Mpps，吞吐量达到14.98Gbps；换用128Byte帧时，吞吐量上升为19.37Gbps，已接近线速。有了这样的铺垫，FW-8865在使用256Byte-1518Byte帧的测试中做到线速转发就丝毫不令人惊讶了，这台基于Sandy Bridge架构的网络通信硬件平台就这样轻松刷新了x86平台的性能记录。

表1 FW-8865吞吐量测试结果（1组桥，1组双向流量，同模块）

一直关心本专题的读者朋友们可能记得，在上一篇关于英特尔5520平台的测试记录中，由上一代顶级至强处理器X5690搭配82599万兆网络控制器的系统在同样的测试条件下只达到整机10.24Mpps的64Byte帧转发能力。仅仅更新系统平台就能让性能翻倍，Sandy Bridge的火力未免也太过强劲。为了寻找系统瓶颈，我们开始人为地制造一些障碍。在以往的测试中，我们曾经遇到过一些产品，其跨模块测试时的性能要远低于同模块内测得的性能。为验证这种现象在FW-8865是否存在，我们将隶属不同模块的两个万兆口配置为网桥，重新进行了一次测试，结果不降反升：系统自128Byte帧起就已线速转发，64Byte帧时的整机转发速率更是达到了惊人的28Mpps，吞吐量接近19Gbps。我们猜测之前单模块时的接口资源有限，如PCIe接口的并发请求数量和重传缓冲都可能受到限制；跨模块测试时，可以调用的资源翻倍，从而提升了平台的整体性能。而两个万兆接口模块直接连接到CPU，其间没有了可能成为性能瓶颈的桥片，也许是性能提升的另一个因素。

表2 FW-8865吞吐量测试结果（1组桥，1组双向流量，跨模块）

看来20G已经无法阻止彪悍的Sandy Bridge平台了，感谢立华科技为我们提供了两个万兆接口扩展模块，能让压力测试继续上升到x86从未染指过的40G级别。在巨大的压力下，当同一模块上的两个万兆口分别配置为网桥进行测试时，整机64Byte帧的转发速率为23.3Mpps，较同模块1组桥时略有上升，但大大低于跨模块1组桥时的性能。但在使用128Byte帧的测试中，FW-8865的整机转发速率基本没有下降，吞吐量达到27.54Gbps。并且从256Byte开始，做到40G流量的线速转发。我们随后也在跨模块两组桥的配置下重复了测试，结果没有发生任何变化。老实说，有了之前的测试结果打底，本次测得的多个40G线速转发的结果并没太令人惊讶。照这种情况推断，只要接口带宽不成为瓶颈，Sandy Bridge平台的大包转发能力即便测到60G也不足为奇。相反，64Byte帧时的性能下降是个很意外的情况，在以往测试中很少出现，推断其瓶颈应出现在I/O层面。

表3 FW-8865吞吐量测试结果（两组桥，两组双向流量，同模块）

表4 FW-8865吞吐量测试结果（两组桥，两组双向流量，跨模块）

为了弄清造成这种情况的原因，我们又构造了一个新的测试用例。在刚才的环境中，我们去掉了1组桥中某个方向上的所有数据流，对FW-8865施加共30Gbps的测试流量（1组双向流量+1组单向流量）。这次的结果又高得令人感到意外，该平台在使用128Byte帧测试时吞吐量就基本接近线速；64Byte帧时的整机转发速率更是大幅增加至32.5Mpps，吞吐量达到21.86Gbps。并且无论将同模块还是不同模块中的两个接口配置为网桥，性能都保持一致。虽然这一结果依然无规律可寻，但我们确实是第一次在x86平台上见到64Byte帧转发能力超过20Gbps，就请记住这个由Sandy Bridge创造的里程碑吧。

表5 FW-8865吞吐量测试结果（两组桥，1组双向流量+1组单向流量，同模块）

表6 FW-8865吞吐量测试结果（两组桥，1组双向流量+1组单向流量，跨模块）

需要说明的是，以上所有测试结果都是在NCPBench中设定一个vcpu（即一个物理核）做管理、两个vcpu做I/O时得到的。我们也尝试着使用除了管理核外的其它所有3个vcpu做I/O，但测得的性能并没有像预期那样线性增长，反而会略有下降。但当NCPBench运行在“转发+简单业务”模式时，两个vcpu情况下的性能会有超过20%的下降，3个vcpu时的性能则不受影响。这至少说明在第二种情况下，处理器的负荷仍未达到100%，理论上可以在保证速度的前提下进行更加复杂的业务处理。

纵观所有测试数据，即便只使用一个万兆接口扩展模块，基于Sandy Bridge平台的FW-8865也能够达到接近15Gbps的64Byte帧转发性能。而在帧长度超过256Byte时，该平台在任何情况下均可做到线速转发，吞吐量最大可达40Gbps。根据经验，如果基于FW-8865打造传统的状态检测防火墙，在40G的现网环境中正常工作是毫无问题的。我们甚至认为，如果软件的效率足够优秀，使用该硬件打造40G规格的流控产品也是极有可能的。无论如何，英特尔最新的Sandy Bridge平台已经创造了历史，凭借革命性的性能表现开启了x86在网络通信领域的新篇章。

测试后记：x86，真的开始给力了

自从2月28日刊登第一篇内容开始，本专题已陆续进行了9期连载。我们与读者朋友们一起，回顾了x86平台在网络通信领域的应用历程，也分析了曾经活跃在市场上的一些产品解决方案。此后，我们开始了网络通信硬件平台的实际测试工作，对几款目前主流的x86解决方案进行了分析，亲眼见证了其规格与性能不断提高的过程。虽然它们与同级别的专用产品解决方案相比仍不占优，但差距已明显缩小，表现出一定的市场竞争力。而英特尔最新的Sandy Bridge平台在测试中表现出的超群实力，完全扭转了之前的被动局面，达到业界领先水平。在用户业务逐步由网络层转向应用层的今天，x86平台凭借I/O与计算能力方面的综合优势，也有机会去赢得更多的市场。如果说以前英特尔在网络通信领域处于追随者的位置，那么Sandy Bridge平台的横空出世，则意味着这个通用领域的巨擘已经站在了该领域的最前沿，抢占了云时代的先机。

链接：“企业级”价值何在？

今年4月，英特尔面向四路及四路以上服务器市场发布了代号为Westmere-EX的Xeon E7系列处理器。一同发布的还有Xeon E3，一类面向单路服务器/工作站市场的产品。实际上，Xeon E3就是1月份发布的Sandy Bridge-DT处理器的Xeon版本，它们非常相似，例如一样都是LGA 1155封装，使用的芯片组也同属Cougar Point PCH系列。甚至在价格上，英特尔官方给出的两类同级别产品的指导价也只有很小的差异。

英特尔Xeon E3-1200系列平台架构图

不过，面向企业市场的产品和面向桌面市场的终究还有一些不同。目前，大部分英特尔平台已经走向单芯片组方案，很多功能融合进CPU，因此差异也更多地体现在CPU上。与桌面版本一样，Xeon E3也集成了传统的北桥，提供PCI Express 2.0接口，但它提供了20个Lane，比桌面版本多出4个，较为明显地增强了其综合I/O能力。例如对工作站用户来说，可能需要使用一个x16接口或者两个x8接口连接单显卡/双显卡，同时还需要通过阵列卡连接磁盘系统，并使用高速网卡连接到局域网。这时，桌面级处理器的16个Lane就显得捉襟见肘，虽然设备也可连接到PCH上，但其带宽和延迟均无法与CPU直连的模式相提并论。而对于网络通信应用来说，PCIe Lane的数量直接决定了最大接口数量，自然是多多益善。

第二个差别体现在内存支持上，几乎所有的桌面级处理器都不支持ECC内存。而企业级应用通常都会长期持续运行，它们需要7×24的可靠性，因此所有的Xeon处理器都支持ECC技术。常见的可以检查多位错误并纠正单位错误的ECC内存会自动检测并纠正约99.99%的内存错误，可以消除约1/3的由数据破坏引发的系统出错事件，提升了系统长期运行时的稳定性。

Xeon E3还提供了无内置显卡的版本，这也是一个比较明显但不是所有情形下都能从中获益的区别。笔者在Sandy Bridge测试分析系列连载的第5篇（见本报今年11期第48版）中曾经介绍过，目前所有的桌面版Sandy Bridge处理器中均集成了显卡，它将会与CPU共享L3缓存。如果确定不使用内置显卡，可以通过屏蔽的方式提升CPU可以使用的L3缓存容量，从而提高性能。

Cougar Point PCH的桌面版本是为人所熟知的P67、H67、Z68等芯片组，而其服务器版本则称为C200系列，目前有C206、C204、C202三个型号。它们的区别主要体现在扩展性方面，例如最低端的C202仅能支持CPU提供的16个PCIe Lane，不支持CPU内置显卡，也不支持SATA 6Gb/s端口及Intel AMT 7.0特性。除此之外，C200系列芯片组能够支持更多的TACH/PWM风扇控制信号、PECI（Platform Environmental Control Interface）界面和SST（Simple Serial Transport）总线，C204还可以实现英特尔特有的Node Manager特性，可以监控管理每个节点的能耗。以上多种企业级特性，对提升网络通信产品的可靠性来说有着非常积极的意义。（文/计算机世界实验室 盘骏）

上一期连载内容中（见本报今年34期第28、29版），我们介绍了上海交通大学网络信息中心的老师们在流量分析与优化系统选型中面临的问题。那么，x86平台在万兆环境下能否稳定工作？现有平台的性能是否又能满足需求？针对种种疑虑，老师们对送测产品进行了长期、细致的测试验证工作。

在完成了基于戴尔PowerEdge R710服务器的安装调试工作后，实验室环境中的测试终于拉开了序幕。为了充分验证Panabit应用层流量分析与优化系统在高负载下的性能表现，上海交通大学网络信息中心的老师们设计了为数不多但极其复杂的测试用例。例如他们使用IXIA的专业测试仪表，分别在两个10G接口后端模拟了100个MAC地址和10万个IP地址，随机发送双向流量去测试设备的吞吐量。这是非常苛刻的测试手段，至少我们在平时的测试工作中不曾使用，因为根据以往经验，许多安全产品在这样的环境下都会死机或者重启。但老师们这样测试却无可厚非，上海交通大学校园网内有数万节点，网络边缘也没有执行任何NAT策略，Panabit上线后将面对的就是测试中模拟出的情况。真实的就是最好的，也只有这样的测试，才能更精准地体现出被测设备在特定应用场景下的性能。

性能初测通过

在吞吐量测试中，老师们只选择了64Byte和512Byte两种比较具有代表性的帧长。前者是对设备极限性能的考验，现网中绝少出现（个别DDoS攻击会在短时间内产生大量小包，对工作在4层以上的设备造成很大压力）；后者则比较接近现网中的平均包长（600-700Byte），测试结果具有比较强的参考价值。考虑到个别设备会在超过极限处理能力后性能大幅下降，丢包率远远超过理论值（通常丢包数量应等于测试流量减去极限处理能力），有着资深运维经验的老师们还特别考察了Panabit在过载时的性能表现。

表注：吞吐量、丢包率测试结果（4层，数据包有IP头/协议类型UDP）

从结果中可以看出，面对一系列苛刻的测试条件，由顶级英特尔5520平台所承载的Panabit应用层流量分析与优化系统还是表现出了不错的性能。在使用64Byte帧进行测试时，系统整体吞吐量达到20%，整体包转发速率为5.96Mpps；当使用512Byte帧时，系统整体吞吐量达到64%，整体包转发速率为3Mpps。测试结束后在Panabit提供的统计信息中可以看到，所有流量也被顺利识别为未知协议。而在使用略高于两个极限值的测试流量进行过载测试时，测试仪统计得到的丢包率也在预定范围内，系统整体运行稳定。

表注：吞吐量、丢包率测试结果（3层，数据包有IP头/协议类型None）

瓶颈究竟出现在哪个环节？是转发层面还是业务层面？老师们利用之前的环境，使用另一组测试用例进行了验证。这次测试仪发出的流量将不包含UDP头部，仅为带有IP头的3层报文。根据Panabit应用层流量分析与优化系统公布的运行逻辑，这样的流量从负责数据转发（I/O）的内核提交到做状态检测与应用协议识别控制的内核后，将只进行连接层面的处理，业务逻辑基本等同于工作在桥模式下的状态检测防火墙。在抛开繁重的应用协议识别的包袱后，系统的整体处理能力是否会有一个飞跃呢？测试得到的结果令人感到意外，当使用64Byte帧进行测试时，整机吞吐量仅比之前高出4个百分点；而当使用512Byte帧测试时，吞吐量没有发生任何变化。虽然目前无法判断状态检测引擎是不是瓶颈所在，但基本可以判定应用协议的识别控制并不是系统整体的瓶颈，x86处理器在计算能力方面的优势还是值得肯定的。而这一阶段的测试数据也让老师们相信，Panabit应用层流量分析与优化系统对于上海交通大学校园网目前的运行情况来说，也是能堪大任的。

5520平台深度分析

在征得老师们的许可后，我们在同样环境下使用久经考验的评估利器NCPBench 0.8进行了测试，得到了可以用做纵向对比的数据。在这个环节中，服务器上的两个万兆接口和每两个相邻的千兆接口被配置为网桥，在纯转发与简单业务两种模式下使用64Byte帧进行测试（NCPBench的功能介绍和使用方法见本报今年第16/17期51版）。

表注：NCPBench吞吐量测试结果

我们又得到了两组几乎一致的数据，无论是纯转发模式还是简单业务模式下，被测平台的吞吐量均为39.163%，包转发速率则接近14Mpps。还有一处值得注意：两种模式下，4个千兆接口间均能达到线速转发，两个万兆接口间则只能达到单向4Mpps、双向共8Mpps的转发速率。我们非常关注前者会对后者造成多大的影响，所以在最后单独对两个万兆接口进行了纯转发测试。此次得到的数据是单向5.12Mpps、双向共10.24Mpps，较之前有所上升，但与整机处理能力仍有不小的差距。需要说明的是，NCPBench允许测试者自行设定要使用处理器内核的数量，上述数据是在使用两个核情况下的测试结果。我们也尝试使用更多的内核数进行了测试，得到的数据基本相同，个别情况下还会略低。

这是个很有意思的现象，对瓶颈定位有着很大帮助。与Panabit“特定内核处理特定业务”的逻辑不同，NCPBench的业务模型采用SMP模式构建，每个内核都进行数据包转发与业务处理操作。理论上如果每个核都达到满负荷工作状态，纯转发模式时的性能会高于简单业务模式。所以我们从测试结果中只能得到这样的结论，即无论在哪种工作模式下，处理器内核的利用率都没有达到极限，即便只使用两个内核时也是如此。

在长期的测试工作中，处理器资源耗尽通常是系统整体瓶颈的惟一原因，而这种“喂不饱”处理器的情况，还是第一次出现。我们也曾怀疑性能瓶颈可能来自于NCPBench自带的网卡驱动，但在稍后进行的对英特尔Sandy Bridge平台的测试中，同样的驱动在一块同样基于英特尔82599EB网络控制器的网卡上带来了28Mpps的纯转发能力。所以，我们只能做出最遗憾的推测，即戴尔PowerEdge R710服务器的某个部分也许存在I/O方面的设计瓶颈。之所以不怀疑5520平台，是因为我们在另一个测试中，在一台采用E5550/4GB/82599EB配置的网络通信硬件平台上得到了两口间16Mpps、4口间超过22Mpps的测试数据。这也与我们经验中侧重于计算的服务器平台，在I/O方面逊于专注于通信业务的网络通信硬件平台的认识相吻合。

其实，即便是同样类型、同样配置的设备，在承载网络通信、安全这种时延敏感型业务时的表现也可能存在很大差异。在之前我们进行的基于Atom D525平台的评测过程中，就出现过来自不同厂商的配置完全一样的产品性能差异达40%的情况。我们无法对此做出更准确的解释，只能提醒广大用户和各厂商负责供应链的人员，在选型时一定要做更加细致的测试工作。

识别准确 稳定可靠

经过一系列测试，由英特尔5520平台承载的Panabit应用层流量分析与优化系统表现出了不错的性能水准，受到上海交通大学网络信息中心老师们的普遍认可。实际上，老师们对该系统在应用协议识别率及稳定性方面的测试早在去年底就已开始，他们使用另一台基于英特尔至强E5620处理器的服务器搭载Panabit，以旁路模式对两个万兆接口镜像而来的所有IPv4出口链路的上、下行流量进行了长期的监控分析。从老师们提供的统计资料中可以看出，未知协议所占流量在累计数据中所占的比重为2.8%，在10分钟统计数据中的所占比例也仅为3%，识别率堪称优秀。而在稳定性方面，资料显示该系统已连续运行超过168天，老师们也坦言没有出现过任何异常，只是在系统更新等人为操作时才会重启。

图注：旁路部署的Panabit系统运行截图

出于更加稳妥的考虑，老师们还是决定进行更长时间的旁路测试后，再讨论将其部署到网络边界。不过我们认为，在如此复杂的应用场景下长期稳定运行的事实，至少可以适当修正那些“x86架构产品稳定性不如专用系统”的论调。如果决定接入，硬件设备还要在可靠性方面满足更多的要求。例如现在工作在旁路模式下，可以不考虑接口的硬件Bypass，但当接入现网环境时，硬件Bypass特性就成为一条底线。服务器搭配多网卡的方式显然不能满足这一需求，我们建议老师们辅以专用的硬件Bypass设备，或直接选购支持该特性的x86网络通信硬件平台。

站在科研的角度，网络信息中心的老师们还提出了一些颇具价值的建议。例如针对前景被广为看好的OpenFlow，老师们建议Panabit增加在协议识别后输出Syslog信息的能力。这样一来，该系统就可以直接部署在一些基于OpenFlow搭建的网络环境中，为控制器提供基于应用层协议的策略配置能力。网络设备在并发连接方面的限制如今也需要突破，像本次测试版本中限定的600万并发连接数，仅用两台高性能服务器做端口扫描（模拟DDoS攻击）就可以打满，此时协议的正常识别就会受到影响。毫无疑问，这些来自科研领域兼一线用户的真知灼见，对产品的完善提高有着宝贵的指导意义。

测试后记

本次测试时间久、项目多，我们认为其中最有价值的内容当属老师们使用的测试方法。被测设备两端模拟大量MAC及IP地址后随机发送流量，可以快速制造出大量的新建连接和并发连接，对一切基于状态检测机制的设备造成较大的压力。即便是传统防火墙，也可能在连接的建立和拆除过程中遭遇性能瓶颈，其直接表现就是系统假死机（CPU占用率100%导致失去响应）或真死机/重启（如果系统架构有缺陷的话）。当连接信息足够多时，CPU在处理中也不得不频繁更新Cache中的数据，会对性能造成非常大的影响，许多高端x86架构产品选择Cache较大的至强处理器就是为了规避这一瓶颈。此外，如果使用比较少的流进行测试，业务处理时通常会走快速路径，而随机多流测试可以更好地模拟现网模型，充分评估设备处理慢速路径时的性能。根据我们以往的测试经验，不少安全设备在这种测试环境下性能会有数量级上的下降。

另一方面，我们在之前的下一代防火墙专题中曾经讨论过，使用UDP数据包进行吞吐量测试，不太适合于IPS、WAF等设备的评估，却很容易对流控、上网行为管理等一切基于应用层协议识别技术的设备造成极大的压力。因为目前来看，对UDP包的检测通常是应用协议识别引擎中的最长路径，而测试时构造出的UDP包又必然会被判断为未知协议类型，后继流量没有快速路径可走，设备应对其进行逐包分析。这一环节对硬件处理能力的需求，理论上远远超过状态检测，所以用户即便没有很强悍的测试仪表，也可以通过高性能PC/服务器加发包软件的方式自行测试。惟一需要注意的，是一定要在测试前验证协议识别的效果，保证协议识别引擎处于正常工作的状态。

在之前两期连载内容中（见本报今年第21期、29期），我们分别测试分析了目前英特尔面向中低端网络通信市场推出的G41、D525嵌入式解决方案。它们已经被证明在目标市场中有很强的竞争力，被不少通信、安全厂商所使用。但在数据中心、骨干网等万兆网络环境中，x86平台的效能与稳定性仍然有待验证。本期我们就与上海交通大学的老师们一起，对英特尔5520平台在万兆环境下的应用效果进行一次测试分析。

上海交通大学是教育部直属、教育部与上海市共建的著名高等学府，也是国家 “七五”、“八五”重点建设、全国首批7所“211工程”和首批9所“985工程”建设的高校之一。该校在信息化建设方面始终走在前列，率先建成了采用WDM技术的跨城域校园网，为数万名师生提供高质量的网络接入服务。随着学校规模的不断扩大，上海交通大学在徐汇、闵行、七宝三个校区之间部署了带宽达10Gbps的校园网主干环路；三个主要校区和上中、法华校区间也采用了1Gbps链路构成网状拓扑结构，使每个校区与其他校区之间存在两条以上的冗余链路，保证了各个校区间互连互通；徐汇、闵行校区内主要汇聚点之间也分别实现了环状连接，保证了校园网运行的稳定、可靠。

做为中国教育和科研计算机网络(Cernet)华东南地区网、上海教育与科研计算机网(Shernet)和校园网(SJTUnet)的建设、管理单位，上海交通大学网络中心拥有很强的科研实力，长期担负着三大网络运营维护的艰巨任务。在此过程中，该中心充分发挥科研能力上的优势，独立自主地解决了许多难度较大的运维问题。我们在连载中就曾经提到，该校两年前在对校园网出口入侵检测系统的选型中，遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下，网络中心的老师选择了带领团队自行研发的方式，以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这样的方式，不仅构建了一个开放的、可以承载多业务的科研平台，更将科研成果转化为实际的安全服务，为校园网的稳定运行提供了保障。

虽然上海交通大学校园网目前拥有多条出口链路、总计超过10Gbps的带宽，但在愈发丰富、模式愈发复杂的网络应用面前，也不是永不拥塞的高速路。目前，流量的可视化与可控性已成为网络中心老师们重点关注的问题，他们需要一个强大的应用流量分析管理系统，为运营维护乃至下一步网络建设规划提供准确的参考依据。经过细致地评估，老师们初步选定了连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统。不过，与大多数同级别通信、安全产品不同，该系统运行在x86而非MultiCore-MIPS或NP平台上，而老师们（或者说是大多数人）对于x86平台在万兆环境中稳定工作都没有太多信心。

来吧，就让测试去证明一切。

规格全面提升的5520平台

上海交通大学网络中心的老师们为这次测试准备了一台戴尔PowerEdge R710服务器，它是戴尔为第一代Nehalem-EP处理器平台及其后续Westmere-EP处理器平台设计的2U机架式产品。PowerEdge R710基于英特尔5520 IOH芯片（代号Tylersburg-36D）设计，提供了36个PCIe 2.0信道，最多支持两颗英特尔Xeon 5500/5600系列处理器，可以搭配英特尔ICH9或者ICH10使用。在英特尔尚未明确推出Sandy Bridge嵌入式解决方案的今天，基于5520芯片组的产品仍然是目前设备制造商与用户能够获取到的最高端x86平台。

得益于戴尔灵活的定制化销售模式，测试使用的这台PowerEdge R710配置了一颗英特尔Xeon X5690处理器。它支持SMT超线程技术（测试中关闭），具有6个核心、12个硬件线程，主频达到3.46GHz，最大的Turbo Boost频率高达3.73GHz，属于英特尔32nm Westmere-EP处理器家族中的最高端产品。这颗处理器中的每个核心都具有32KB的L1指令缓存和L1数据缓存及256KB的L2缓存，所有核心共享12MB的L3缓存。此外，Xeon X5690还通过两个6.4GT/s的QPI总线和另一颗处理器以5520/5500 IOH芯片通信，QPI总线为一个双向的并行总线，在X5690上，单向带宽为12.8GB/s。

由于集成了较高规格的内存控制器，单颗Xeon X5690可以支持3通道R-ECC DDR3内存，每通道又支持最多3个R-ECC DIMM。在使用能够支持的最高规格的16GB内存条的时候，每颗处理器可拥有144GB的总内存容量，整个系统（双路配置）则可达到288GB的最大容量。X5690支持的最大内存频率规格为DDR3-1333，不过当所有DIMM插槽都插满内存的时候，运行频率将会降低至1066。而本次测试使用的这台PowerEdge R710服务器配置了3条4GB容量的内存，运行在3通道模式。

英特尔Xeon X5690处理器通过6.4GT/s的QPI总线连接到5520 IOH上，而IOH目前主要的功能就是提供更多的PCIe总线连接，这正是网络通信产品所需要的。英特尔5520 IOH提供了36个PCIe 2.0信道和一个连接ICH芯片的ESI总线接口，这个ESI总线就是桌面级IOH芯片常用的DMI总线，其实质是一个x4的PCIe信道。而36个PCIe信道则以10个端口的形式提供，分别为8个x4的端口以及两个x2的端口。其中8个x4的端口可以聚合为4个x8或者两个x16端口，另外两个x2的端口则可以聚合为一个x4端口，但是不能与其余8个x4端口进一步聚合。我们知道，PCIe 2.0的每个信道可以提供5.0GT/s的单向传输速率（500MB/s），因此5520 IOH提供了巨大的IO带宽。在不需要这么多带宽的场合，英特尔也推出了一个简化版的5500 IOH产品，将PCIe信道数量减为24个。它的代号是Tylersburg-24，这一命名就体现出了PCIe信道的数目。

与时俱进的网络子系统

和桌面级与嵌入式产品不同，在服务器上，所有的高速设备都直接连接到IOH芯片上，而不是相对低速的ICH芯片，理论上减少了性能瓶颈。测试使用的PowerEdge R710服务器上提供了1条PCIe v2.0 x16插槽和两条PCIe v2.0 x4插槽，分别连接到3组顶级网络控制器。其中一组是一块基于英特尔82599EB芯片的英特尔X520双口万兆网卡，另两组是基于英特尔82576EB芯片的双口千兆网卡，一共提供了两个万兆接口和4个千兆接口。实际上，戴尔PowerEdge R710还板载了4个基于Broadcom网络控制器的千兆接口，但在测试中并未用做业务处理。

英特尔X520双口万兆网卡使用的82599EB是一个强大的网络控制器，是目前英特尔在万兆级产品中最顶级的型号。该芯片原生两个万兆接口，每个接口都可以支持128个TX/RX队列，并可以根据情况最多划分为64个RSS（Receive Side Scaling，接收方扩展）队列。此外，82599EB还支持MSI和MSI-X（Extended Message Signaled Interrupt，扩展消息告知中断)特性和一些与数据中心应用密切相关的高级功能。由于万兆环境下的数据传输需要巨大的带宽，82599EB推荐使用PCIe v2.0 x8或以上规格接口进行连接，否则可能会出现瓶颈。

英特尔82576EB也是比较强大的网络控制器，使用PCIe v2.0 x4接口进行连接，是82580出现前千兆级产品中的顶级型号。该芯片原生两个千兆接口，每个接口支持16个TX/RX队列，最多可划分16个RSS队列。和82599EB一样，82576EB也支持MSI和MSI-X，并支持VMDq、VMDc等虚拟化功能。在与英特尔服务器级Tylersburg IOH芯片搭配时，82576EB和82599EB可以通过I/O AT技术加速其DMA的传输性能。

在上一期连载内容中，我们测试分析了目前主流的G41网络通信硬件平台。结合其价格定位与性能表现来看，该平台比较适合用来打造中低端产品。而在更低端一些的，也是出货量最大的领域，来自英特尔的Atom平台才是毫无疑问的王者，堪称x86架构真正的杀手级解决方案。

在本系列第三篇连载内容中，我们曾经提到协助北京市某学校信息中心的老师们进行过一次选型测试。当时，该校供应商提供了一款基于Atom N270的网络通信硬件平台，在部署为流控服务的情况下达到小包接近900Mbps、大包超过2Gbps的处理能力（使用4个英特尔82574L提供的千兆接口进行测试）。而本次我们的测试对象，是汇尔科技提供的一款基于Atom D525的网络通信硬件平台。与N270相比，D525平台处理器主频更高、计算能力更强，成本却没有太多增加，已成为时下低端领域最主流的选择。

架构精简 配置合理

IEC-516P采用1U规格设计，前面板提供了6个千兆电口（其中两组支持硬件ByPass）、两个USB 2.0接口和一个DB9或RJ45形态的串口。该产品采用了英特尔Atom平台，基于45nm的Atom D525处理器，隶属于PineTrail架构。比起第一代Atom平台，PineTrail从三芯片改进为双芯片设计，在CPU中集成了北桥芯片的部分功能。Atom D525处理器主频为1.80GHz，采用双核四线程设计，集成2 x 512KB L2 Cache，提供了不错的处理能力。其实Atom处理器内核采用的顺序执行机制对于网络业务处理来说并不太合适，双核四线程的D525处理器比起上一代单核双线程的N270会有更大的优势。D525处理器还内置了内存控制器，支持单通道的DDR3-800或DDR2-800内存，最大容量可达4GB。IEC-516P提供了两条DDR3 SO-DIMM插槽，送测样机配备了1条1GB的DDR3内存。

按照英特尔PineTrail平台的规划，D525应该搭配NM10芯片使用，然而NM10仅提供4个PCIe Lanes，限制了通信产品的整体处理能力和部署的灵活性。所以在嵌入式产品线中，英特尔给出了D525与ICH8M的推荐配置。ICH8M可以提供6个PCIe Lanes，以及PCI、IDE、SATA等丰富周边I/O接口。和上一代产品ICH7相比，ICH8比较明显的区别是它支持PCIe v1.1，因此可以支持包括MSI-X在内的一系列新特性。而和面向桌面应用的ICH8相比，面向低功耗移动应用的ICH8M将支持的SATA端口数减少到3个，功耗也有所降低。其实ICH8M内部还整合了1个千兆网络控制器的MAC部分，但其性能无法满足压力较大的网络业务处理，所以包括IEC-516P在内的许多网络通信硬件平台都对其进行了屏蔽处理，转而使用功能、性能更强的独立网络控制器。

IEC-516P通过ICH8M南桥的6个PCIe v1.1信道分别连接到6颗82574L芯片。82574L是沿用已久的嵌入式/服务器千兆以太网控制器，支持两个TX/RX队列和两个RSS队列，是一个成熟稳定、性能尚佳的产品。该芯片使用PCIe v1.1 x1接口，能支持MSI-X等技术，在规格上正好与ICH8M相匹配。ICH8M和Atom D525通过DMI总线连接，实际上就是一个x4的PCIe总线，其单向信号速率/双向信号速率为10Gbps/20Gbps，数据速率则为8Gbps/16Gbps。

在机箱内部，IEC-516P为TDP并不高的Atom D525配备了一个小风扇，并将其安置在机箱出风口的两个风扇附近，因此散热方面完全不成问题。由于整机功耗较低，该产品使用1个180W功率的电源为系统供电，整机功耗不会高于100W，因此180W已经绰绰有余。可靠性方面，IEC-516P内置了支持可编程控制的WatchDog，完善了x86平台的监控机制。存储方面，主板上提供了1个IDE接口和3个SATA接口，可以使用DOM、CF及其他常见的存储介质。送测样机配备了CF接口、IDE界面的1GB DOM，用于安装NCPBench。此外，主板边缘还设计有1个PCI插槽和1个PCIe x1接口的金手指，提供了符合产品定位的扩展性。

性能卓越 低端通吃

考虑到性能数据的可比性，我们依旧使用了NCPBench 0.8对IEC-516P进行测试。按照该软件设定的评估方法，我们将每两个相邻接口配置为桥模式，分别多次考察了1组、2组、3组桥时的整体转发性能，取得稳定后的性能数据（NCPBench的功能介绍和使用方法见本报今年第16/17期51版）。由于IEC-516P只提供了6个千兆接口且不可扩展，在测试3组桥性能时，我们直接将显示器、键盘鼠标插在主板上引出的接口上进行操作。

表格：IEC-516P吞吐量测试结果（百分比形式，NCPBench 0.8/转发模式）

表格：IEC-516P吞吐量测试结果（带宽形式，NCPBench 0.8/转发模式）

表格：IEC-516P吞吐量测试结果（pps形式，NCPBench 0.8/转发模式）

从测试结果中可以看出，当NCPBench运行在转发模式时，IEC-516P的64Byte帧整机最大转发速率超过3.6Mpps，吞吐量达到2.42Gbps；采用1518Byte帧进行测试时，整机的最大转发速率为0.31Mpps，吞吐量达到3.76Gbps。由此可见，Atom平台虽然在网络通信领域被英特尔定位为低端嵌入式解决方案，却也有着不小的潜力。能在纯转发情况下达到这样的性能，也就意味着D525平台在运行一般的防火墙业务时，可以满足高端百兆乃至低端千兆产品的设计需求。或许，我们印象中“低端产品”的概念需要更新了。

通过挖掘，我们还能从有限的测试数据中捕捉到更多的信息。在1组桥和2组桥的测试中，除了前者在1280Byte、1518Byte时达到100%的极限值外，64Byte-1024Byte帧长有着基本相同的百分比数据（蓝色部分）。当我们将其转化为以带宽和pps为单位的数值时，可以看到2组桥时的处理能力基本是1组桥时的两倍，呈线性增长的关系。而在3组桥的测试中，64Byte-1024Byte帧长时的吞吐量数据并不存在这一规律，反倒是在1280Byte和1518Byte两种帧长时，3组桥的性能与2组桥基本保持一致，整体转发能力均为3.7Gbps左右（红色部分）。

要弄清造成这种情况的原因，我们必须深入了解D525平台做数据包纯转发时的业务流程。以IEC-516P为例，D525处理器通过4x DMI通道连接到ICH8M，后者再通过6条PCIe v1.1 1x通道连接板载的6颗英特尔82574L千兆以太网控制器。通常在进行数据包转发操作时，网络控制器先发起DMA请求，将接收缓存中的数据直接传输到内存；CPU经过软件处理定位到目的网络控制器，通过DMA引擎将数据传输到它的发送缓存中，或是让网络控制器自行将数据从内存中取走（82574L整合了DMA引擎）。这是一个逻辑上简单、实现起来复杂的流程（如果要达到高性能），内存子系统、DMA引擎、DMI、ICH8M、PCIe 1x通道、82574L和软件、驱动程序都有可能成为影响整体性能的因素。

再回到我们刚才注意到的两个情况，既然1组桥和2组桥时，64Byte-1024Byte在带宽和pps测试结果上呈线性增长，说明瓶颈不在内存子系统、DMA引擎和DMI。而我们在测试其他更高规格的平台时，基于82574L也得到过更高的性能数据，说明这款网络控制器和PCIe v1.1 1x通道也不是瓶颈。只有在进行3组桥的64Byte-1024Byte帧长测试时，得到的数据才有可能是系统整体的极限。而2组桥与3组桥在1280Byte、1518Byte帧长测试中表现出来基本一样的吞吐量数值，显然是在带宽方面遇到了瓶颈，但可能与DMA引擎、ICH8M、PCIe v1.1 1x通道和82574L关系不大。我们暂时无法再对性能短板做更加精准的定位，不过从完整的测试数据来看，DMI、内存控制器与软件处理逻辑有可能是造成D525平台整体性能瓶颈的关键因素。

无论如何，目前D525平台在NCPBench的驾驭下，已经有着十分优秀的性能表现。随着厂商研发的继续深入和软件技术的不断发展，该平台的性能一定会得到更充分的挖掘，在低端网络通信、信息安全领域有着很好的应用前景。

子曰：工欲善其事，必先利其器。在上一期连载中，我们介绍了新兴的网络通信平台评估软件NCPBench。从本期开始，我们将陆续测试一批网络通信硬件平台，看看在优秀系统软件的支撑下，x86架构究竟有着怎样的性能，以及不同硬件配置对网络处理能力造成的影响。

价格不是最高也不是最低，规格不前卫但也不落伍，这就是G41，我们今天的主角，英特尔嵌入式产品线中在网络通信市场上拼杀的绝对主力。而它的载体，是台湾伯昇科技股份有限公司推出的一款网络通信硬件平台，代号NSP-1096。这款产品采用1U规格设计，前面板提供了6个千兆电口、2个USB 2.0接口和一个9针串口。接口左侧设有附带按钮的液晶屏，右侧空间则留给了扩展槽位。伯昇科技为NSP-1096准备了多种规格的扩展卡，用户可以用来为硬件平台添加多达4个千兆接口。

合理的配置与设计

打开NSP-1096的机箱上盖，可以看到处理器所在位置做了有针对性的设计。NSP-1096没有使用处理器散热风扇，而是采用了一个较大型的铜质散热器，通过特别制作的导流罩，配合机箱风扇形成一个专门风道，给CPU、内存条以及北桥芯片散热。风道两侧是磁盘悬挂位和电源，该产品配备了全汉的80Plus电源，让NSP-1096在所有的工作负载时间内都能维持较高的电能转换效率，降低了发热量以及其散热需求。

NSP-1096采用了专门为嵌入式平台设计的英特尔G41芯片组，和ICH7/ICH7R南桥芯片搭配使用。作为系统的核心，G41连接着处理器、内存和PCIe总线。它支持1333MT/s的FSB，可以兼容嵌入式产品列表内LGA775接口的各种赛扬、酷睿处理器；内存规格则支持到DDR2-800和DDR3-1333，且拥有两个内存通道，最大容量达到8GB。I/O方面，G41提供了16个PCIe v1.1信道，可以配置为1×16或者2×8；此外，通过DMI 1.0总线和G41连接的ICH7R南桥还能提供6个PCIe v1.0a信道。在NSP-1096上，这6个信道连接了6颗英特尔82754L网络芯片（对应前置接口，其中2组支持硬件ByPass）；G41提供的PCIe v1.1 x16则连接到扩展槽位，用以连接使用了82576、82580等中高端网络控制器的扩展模块。

NSP-1096内置的6颗82574L芯片是沿用已久的嵌入式/服务器千兆以太网控制器，支持2个TX/RX队列和2个RSS队列，是一个成熟稳定、性能尚佳的产品。该芯片使用PCIe v1.1 x1接口，能支持MSI-X等技术。不过由于连接在支持PCIe v1.0a的ICH7R上，它仅能使用传统的MSI模式。扩展模块上应用较多的82580则是英特尔最新推出的单芯片四网口千兆以太网控制器，采用了支持5GT/s速率的PCIe v2.1 x4接口，支持包括LTR、TPH、DCA等在内的诸多特性。面向网络通信、主流服务器和高密度刀片的82580是十分强大的芯片，其规格甚至比上一代的王者82576还要强一些。

测试使用的这台NSP-1096还配备了一颗主频为2.66GHz的英特尔Q9400处理器，该处理器使用45nm工艺设计制造，具有4个核心和6MB二级缓存。内存使用了2根DDR3-1333规格、1GB容量的产品，工作在双通道模式。网络接口方面，除了板载的6个千兆铜口，我们还在扩展槽位安装了一块编号为BEM-580-F4的扩展卡。该卡使用了一颗英特尔82580网络控制器，提供4个额外的SFP接口。不过，理论上该芯片在连接到G41的PCIe v1.1后速率将降为2.5GT/s，功能特性也只有包括MSI-X模式在内的v1.1部分可以使用。

整体性能超越预期

在CF卡中安装了NCPBench 0.8后，我们将每两个相邻接口配置为桥模式，进行纯转发性能与带简单业务情况时的测试（NCPBench的功能介绍和使用方法见上一期连载内容）。对于NSP-1096来说，BEM-580-F4扩展模块在很大程度上左右着整机的处理能力，我们也对其进行了重点考察。考虑到是第一次在这样的配置场景中进行测试，每个项目在使用测试仪表进行测试后，都再使用NCPBench进行一次自测试。我们可以对比两组数据的差异，用以评估NCPBench测试结果的准确性。

从测试结果中可以看出，当NCPBench运行在纯转发模式时，BEM-580-F4扩展模块上的4个接口转发64Byte帧的速率超过4Mpps，其他帧长时均接近或达到线速。这个结果虽然出色，却使人略感遗憾。我们曾经在一台采用5520芯片组的硬件平台上，测得过82580的4个接口间所有帧长均线速转发的结果，也就是说瓶颈不在网络控制器。而对NSP-1096全部10个千兆接口的测试结果表明，该产品对64Byte帧的整机转发能力接近9Mpps，这又意味着，之前测试中的性能瓶颈也不应该在处理器。经过排除分析，我们推测问题很可能来自I/O方面，理论上G41与82580协商后只能使用PCIe v1.1规格进行连接，在传输速率和效率上都大打折扣。此外，硬件平台在缓存和内存等方面的差异，也可能会对数据包转发能力造成一定影响。不过总体来说，NSP-1096的设计已经最大地发挥了G41芯片组的潜能，表现出来的整体性能也超越预期，足以满足其目标市场的需求。

本次测试中，测试仪与NCPBench得到的两组结果保持高度一致，我们只在高负载情况下观察到pps统计数值略有不同，没有出现往常几个百分点级别的差异；加载简单业务后，性能数据也没有发生很大变化，只在使用128Byte帧长测试时有所降低。我们认为，造成这两种情况的主要原因是处理器本身有性能余量，接口带宽也限制了极限数据的出现。单就NCPBench来说，其自测试结果还是比较准确的，可以满足用户的常规测试需求。

表格：NSP-1096吞吐量测试结果（针对BEM-580-F4扩展模块）

x86网络通信硬件平台的迅猛发展，已经吸引了许多厂商、用户的关注。在进行评估测试时，如何才能准确、便捷地了解硬件平台的整体性能，是所有人都关心的问题。本期，就让我们聚焦于新兴的评估软件NCPBench，感受一下它诸多与众不同的特性。

在上一期连载中，我们介绍了与北京市某学校信息中心合作进行的一次硬件平台选型测试，并以此为依据，证实了x86平台在网络业务处理方面的潜力。随后一段时间内，我们收到了许多来自厂商、用户的咨询；个别用户甚至愿意提供更完善的环境，希望我们将这一系列测试长期进行下去，持续公开更详细的测试结果。对于来自读者的热情关注，我们表示感谢，并将在后续连载中安排更多平台的测试分析。同时，我们也在这里介绍一款经常使用的网络通信平台评估软件NCPBench，供读者进行独立的性能评估。

以互联网的名义

NCPBench是近期兴起的一款测试软件，用于评估x86硬件平台做网络业务处理时的性能。在我们看来，该软件融入了大量的互联网基因，与日常使用的诸多软硬件评估产品有着明显的不同。众所周知，用户参与是互联网产品成功的基本要素，NCPBench显然抓住了这个要点，在产品发展的方向性上与用户需求保持着高度一致。该软件采用了十分开放的构建模式，版本升级比较迅速。与之对应的，在主要功能保持稳定的情况下，再根据用户反馈需求的迫切性，逐步完善产品的细节功能。而互动的效果则取决于用户数量与质量，所以NCPBench本着“让更多人使用”的理念，采用了免费的许可授权模式，允许甚至鼓励被用于包括商业在内的各类评估环境。

NCPBench与其他软硬件评估产品的第二个不同，体现在操作的便捷性方面。一般来说，网络通信、信息安全等领域的测试解决方案都比较复杂，使用时需要较高的专业素养，配置过程也相对麻烦。NCPBench则很好地简化了用户端的工作，使用时只需对网络接口、业务模式等几个必要环节进行设置，即可进行性能测试。一键式安装也是非常实用的功能，我们拿到新的硬件平台，用几分钟时间就可以将NCPBench安装到本地或USB存储设备上，而不必经历从磁盘分区到编译的诸多步骤。该软件还内置了常见的硬件驱动，在多数平台上可以直接发挥出硬件的所有潜力。

利用NCPBench，我们可以评估任何x86平台的网络业务处理能力。现阶段该软件提供了“转发”与“业务”两种应用模型，前者不对数据包进行任何处理，考察的是硬件平台的数据包转发极限；后者将建立数据流的概念，其业务复杂度与NAT、状态检测引擎类似。通常，我们会测试x86硬件平台在两种模型下的吞吐量与延迟，当然这些结果都是理论值，仅供评估参考。根据经验来看，设备在真实流量下的综合效能，如果能达到模拟测试环境中的50%，就已经相当难得了。不过“转发”模型下的性能还是很重要的，毕竟对于没有任何加速逻辑的x86平台来说，数据包纯转发的性能是一个极限标杆。没有高性能转发做支撑，任何上层业务都将是纸上谈兵。

高性能的诱惑

众所周知，目前x86平台用做网络业务处理时，首先要解决的就是多个处理器内核间的调度与资源分配问题。如果使用传统的处理模型，很可能导致资源使用的不平衡，无法发挥出硬件平台的整体性能；而多核并行处理的模式，虽然在理论上可以提升性能，实际使用时的效果却大多难令人满意。NCPBench在这方面就显得非常灵活，用户可以人为设定用做转发及业务处理的内核数量，并且转发与业务在每个独立内核上也都是并行处理，系统呈纯SMP形态。该软件也不像某些同类产品那样必须人为地将网络接口与处理器内核进行绑定，而是根据硬件平台配备的接口种类及数量，自动建立关联关系。

经过多次测试，我们已经确认NCPBench在x86平台上可以做到非常强悍的数据包转发性能。现有测试数据中，64byte UDP数据包的最大转发速率接近30Mpps，是在英特尔Sandy Bridge搭配i82599万兆网卡的平台下测得。此时使用RFC 2544规定的7种帧长的数据包测试转发延迟，时间也均在10微秒以内。这意味着，x86平台用做20G/40G环境中的业务处理，并非是遥不可及的目标。需要注意的是，x86平台所能达到的的数据包转发能力与处理器、桥片、网卡芯片等都有很大关系，如果在硬件规格上无法很好地匹配，性能瓶颈就会过早地出现。我们发现，网络通信硬件平台大多经过有针对性的定制，硬件搭配相对合理；服务器的配置则大多是计算远强于网络，很可能要另行采用高性能网卡以达到更快的转发速度。

为了让用户更方便地了解x86硬件平台的网络处理性能，NCPBench还内置了一个自评估工具。该工具的使用极其简单，只需用网线将要测试的接口两两互联，就可以在环路内生成指定帧长、方向、强度的UDP测试流量，对硬件平台自身进行测试。我们注意到，在多数情况下，使用自评估工具得到的性能值都较测试仪得到的略低，但观察到的最大一次误差也仅在3%以内，还是具有比较强的参考价值。

弯曲评论现在的影响力很大，甚至能吸引到一些行业用户的关注（潜水居多）。本文就是《给力吧，x86（1）——11月10日测试记录》一文刊登后，用户直接与我们沟通进行的一次测试合作的副产品。这是一个良好的开端，后续还有与其他用户联合进行的更大、更深入、更给力的测试，敬请关注。

==============================================================

前两期连载中，我们简单回顾了x86平台在网络产品中的应用历程，又逐一分析了其面向不同用户群体的硬件供应模式。实践是检验真理的唯一标准，本期就让我们走进现实中，借助近期的一次测试，看看在网络技术及应用高速发展的今天，x86平台对业务的承载能力究竟如何。

虽然一些业内人士已经看到x86平台的发展，认为其将在网络领域有所斩获，但对于普通用户来说，再次接受x86平台有着很大的难度。一方面，这个曾经不太适合做网络业务处理的硬件平台为许多用户留下过不好的应用体验；另一方面，一些厂商长期对x86架构并不客观的宣导，也加深了其在用户心中的负面印象。

先入为主的误会

我们在之前的调研中发现，抱有这种看法的用户并不在少数。北京市某学校信息中心负责人李老师就是一个典型代表，虽然他在目前进行的流控产品选型中比较中意连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统，却因其运行在x86平台上而犹豫不决。

“我们一直用着一台x86架构的UTM产品，效果越来越不好。”李老师介绍说，“以前网络负载不大时，设备运行没有任何问题；现在越来越多的教学、科研任务要通过网络进行，学校网络出口的百兆带宽经常被占满，UTM运行也变得不稳定。”令人没有想到的是，他紧接着又说出一个令我们很难理解的结论，“看来，x86平台也就是这个样子了。”

x86架构与网络运行不稳定有直接关系？实验室工程师习惯以量化的数据去看待问题，自然无法认同李老师的推断。在他的协助下，我们走进该校信息中心，对网络运行情况进行了实地考察。经过分析，我们发现造成学校网络出口拥塞的主要原因大致有三：其一是在线课件播放系统产生的数据流量，由于学生分布在不同校区，远程教学会在上课时段对网络造成比较大的压力。其二是学校周边视频监控的数据上传流量，根据教委要求，为加强校园安全工作，各学校的视频监控数据需实时汇总到教委信息中心，以便对突发事件做到事前预警、事中监控及事后取证。李老师所在的学校需要实时上传4路监控视频，这也是该校网络上行带宽占用率居高不下的原因之一。其三则是P2P、在线视频等非业务应用产生的流量，此类应用会无限制地占用网络带宽，是每一个网络管理员都非常头疼的问题。我们在分析报表中看到，以迅雷为代表的下载应用在网络使用高峰期一度抢占了70%左右的带宽，严重影响了该校教学工作的正常开展。

根据分析得到的数据，我们建议李老师对UTM上的安全策略进行了调整，不再对远程教学与视频监控相关的流量进行应用层面的安全防护。由于它们都是可信流量，修改过的访问控制策略非但不会造成安全隐患，还能有效降低UTM的负载。很快，我们看到设备的CPU占用率显著下降，内网用户访问网络的延迟也回到相对合理的水平，x86“不行”的误会也就此得到解除。但对于非业务流量的控制需求，该校主出口使用的这台国外某品牌的UTM产品并没有足够的本土化保障，对国内主流应用的支持力度相对薄弱，无法进行有效的控制。可以说，流控产品的部署势在必行。

标前测试：大放异彩

虽然解决了UTM运行不稳定的问题，李老师所在的信息中心管理团队还是对x86架构产品存有疑虑，不愿直接将设备接入实际环境进行测试。这一点大家都能理解，毕竟学校网络承担着大量的教学、科研任务，万一出现意外，后果将不堪设想。在我们看来，李老师所在团队目前所需要的，是一次客观、严谨的标前测试。实际上，这一环节已经被国内越来越多的用户所认可，因为是否选购产品，或者是否再接入实际环境测试，都可以用标前测试得到的量化数据作为决策依据。

在实验室合作伙伴思博伦通信的支持下，我们与李老师所在团队合作，于近日测试了他们关注的Panabit应用层流量管理系统。该产品运行在x86平台上，拥有优秀的协议识别率及性能。商务模式方面，Panabit可以通过软件授权或服务的形式进行交付，给用户自行选择硬件的自由，还可以节省大量开支。李老师这次带来的硬件，就是供应商基于该校网络实际情况，推荐的一款带有6个千兆电口的基于Atom N270的x86网络通信硬件平台。

Atom N270？实验室工程师们感到难以置信。要知道，流控引擎是在DPI（Deep Packet Inspection，深度包检测）的基础上结合多种技术发展而来，属于处理模型相对复杂的一类业务应用，对硬件平台的计算能力有着相当高的要求。而Atom N270是什么级别的产品？放在上网本里也算是两代之前的配置了，它真能满足百兆级别应用层流量管理的需求？

诸多疑问化作动力，催使我们立即开始了测试。被测设备预装了Panabit 10.10专业版，开启了应用层流量分析，作用于4个千兆口绑定成的两组桥。根据联合制定的测试方案，我们首先对带业务情况下的吞吐量、延迟进行了测试。虽然常用的UDP测试流量对于IPS、WAF等应用层安全设备来说意义不大，对流控产品测试却有着十分现实的意义——据统计，目前互联网中占流量比例最大的是在线视频应用（在教育、网吧等行业中比例数字更为惊人），它们其中大多数都使用了UDP传输，且数据包偏小。测试结果令人震惊，当我们单独测试1组桥的性能时，该平台64Byte帧的吞吐量达到41%，也就是800多兆的处理能力。当帧长逐渐增加时，吞吐量也呈线性增长，并在1518Byte时达到线速。此时最大的平均延迟，也仅为68微秒。而在同时对2组桥的测试中，设备的整体吞吐量又有所增加，在256Byte时就已拥有接近2G的性能。我们也利用全部4个接口测试了该产品的链接处理能力，当链接的Timeout时间设为0时，Avalanche测得的稳定值在90000左右，峰值为90014CPS（HTTP）。这一次的数据体现出了设备的极限性能，根据以往经验，其表现完全可以胜任普通千兆接入环境中的应用。

有了这些测试数据，老师们基本放下心来，将设备接入实际环境中进行了长时间的测试。对于流控设备上线后的效果，李老师给予了充分的肯定：“业务流量控制住了，学校网络出口的流量也就下来了，UTM的负载就更小了。”而在稳定性方面，他也坦言没有遇到过任何异常情况，不过我们仍然建议做更长时间的测试，以便进一步考察x86网络通信硬件平台长期不间断运行的效果。

后记：广阔天地 大有作为

从测试结果中可以看出，x86平台的网络业务处理能力确实有了长足的进步。目前，在英特尔面向网络应用的嵌入式产品线中，Atom N270是最低端的一款产品，都有着如此强大的处理能力。随着网络通信和信息安全业务的关注点逐步向应用层迁移，x86平台的优势将会越来越明显。当然，现有基于x86架构的产品仍不足以在高端市场和基于专用网络通信处理平台的产品竞争，但在其他诸多领域内，x86已经表现出了一定的竞争力。对开源系统良好的支持、海量的软件资源、较低的开发难度、价格优势和易获取性，这些都是其取胜的砝码。是否有点眼熟？没错，如果哪天基于x86架构的网络通信和信息安全产品（至少是中低端）开始山寨化，大可不必感到奇怪。

上一期，我们系统地回顾了x86平台在网络产品中的应用历程，得出了其目前处于高速发展中的结论。越来越多的设备制造商也认识到这一点，开始在产品的研发中考虑x86平台。那么，自主研发硬件与定制网络通信硬件平台，究竟哪条路更适合设备制造商？x86服务器缘何又受到最终用户的青睐？

得不偿失的自主研发

自主研发是产品核心竞争力的基础，网络领域也不例外。对于网络设备的硬件部分来说，自主研发意味着差异化、定制化和成本的可控性。这既可以与业务高度匹配，又能取得技术、规格与价格上的优势，是每个厂商都梦寐以求的局面。

但真要做到全部自主研发，却也未必就是好的选择，甚至不太可能。自主研发需要投入大量人力物力，且有着相对较长的时间周期，这是大量初创企业乃至市场规模较小的安全厂商很难接受的。如果自主研发的硬件平台存在瑕疵，其代价将更为惨重，厂商损失的不再只是前期投入，而是转瞬即逝的市场机会。所以，通常只有通信行业的巨头才会去押宝硬件平台的自主研发，更多地体现技术上的壁垒，且在预研阶段不会拘泥于某种特定的方案。

此外，x86平台一些不可磨灭的消费类特性，也是阻碍网络设备制造商实现自主研发的关键因素。虽然嵌入式范畴内的x86平台也拥有了较长的生命周期，CPU、桥片、网络控制器的种类却偏多，更新换代的速度又比较快，且不同时代、不同桥片对应的CPU针脚都不是100%兼容。相信没有一个网络设备制造商可以跟得上这种更新速度，我们在长期的测试工作中，也确实没有见到过哪款通信或安全产品是采用自主研发的x86平台（少量定制型号与CheckPoint除外）。大家共同的选择，还是定制化服务器或由工控机衍生而来的x86网络通信硬件平台。

服务器：近水楼台先得月

既然x86平台以通用性为主打，那么注定其在市场等非技术层面更具竞争力。以服务器为例，采用x86体系架构的产品在价格、性能和易获取性方面都有着明显优势，占据了绝对主流的市场地位。近几年来，x86架构服务器在网络处理能力和I/O特性方面有着显著提升，标配4个千兆网口的产品也屡见不鲜。更有甚者，一贯拥有良好前瞻性的英特尔将于今年发布标配2个万兆网口的新服务器平台，会将网络应用效能提升到一个新的高度。

基于以上多种原因，越来越多具有一定研发能力的用户开始采用唾手可得的x86服务器来打造适合自身应用的网络设备。尤其在电信、金融、教育等行业，用户业务本身存在比较强的定制化需求，性能要求又相对较高，故此类情况时有发生。在我们的调研中，就出现了一些具有代表性的案例。上海交通大学网络信息中心的姜开达老师曾坦言，两年前该校在对校园网出口入侵检测系统的选型中，就遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下，姜老师选择了带领团队自行研发的方式，以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这一举动，不仅构建了一个开放的、可以承载多业务的科研平台，更将科研成果转化为实际的安全服务，为校园网的稳定运行提供了保障。

许多数据都表明，面向网络应用的x86硬件平台的市场需求处于不断扩大的阶段，而服务器因其易获取性成为了用户的首选。网络产品本身也有着互联网化的倾向，以软件授权、服务为代表的商业模式剥离了传统软硬件一体化的产品形态，开始赋予用户自行选择硬件平台的权利。来自学术界的激进看法甚至认为，未来无论互联网还是数据中心，都将只由交换机和服务器两种硬件产品构成。

工控机的反击

x86服务器在网络领域的无心插柳，也刺激了传统的网络通信硬件平台提供商。他们开始推出有针对性的产品及商业模式，直接面向最终用户。我们在调研中发现，原本对新硬件方案不甚敏感的他们也逐步加速产品研发流程，主动接纳较新的x86平台，积极拓展产品线。对于用户在存储子系统方面比较普遍的应用需求，许多网络通信硬件平台提供商也开始在产品中增加硬盘位及相应的RAID特性。某些厂商还针对x86平台在硬件狗等方面的先天不足，以板载CPLD芯片等方式实现了强大的监控与联动能力。用户及设备制造商可以通过软件接口读取、调用这些功能，甚至基于CPLD自行开发其他监控手段，增强x86平台的可靠性。

与服务器相比，网络通信硬件平台有着一些无法被超越的优势。首先，它从内到外都可以由用户深度定制，无论是接口种类或数量，CPU、网络控制器的型号，还是PCB的板型及工艺，机箱规格及面板设计，都可以根据设备实现的业务进行最合理化的搭配。这种裁剪还降低了整机成本，也减小了系统功耗及散热难度。其次，可靠性在网络通信硬件平台的设计中至高无上，诸如网口的硬件Bypass等特性是绝大多数服务器产品无法提供的。而在元器件规格方面，多数网络通信硬件平台也都采用了比服务器更专业化、寿命更长、对工作环境要求更宽松的产品，使系统的稳定性有了更多的保障。虽然这一切都增加着硬件整体成本，所改善的却是网络产品必须具备的特性。所以，虽然销量巨大的服务器有着相对低廉的价格，但标准化的产品形态和对网络业务并不十分友好的支持，都使其在短时间内无法替代x86网络通信硬件平台。在网络通信硬件平台提供商逐步走向前端的今天，用户不妨在选型时也多给予一些关注。