华为赛门铁克USG9560评测报告
作者 老韩 | 2012-01-05 07:13 | 类型 网络安全, 行业动感 | 91条用户评论 »
|
如果USG9100和USG9300算是试水之作，USG9500就是华赛在高端安全领域的杀手锏。虽然它仍不完美（当然完美的产品也不存在），却也足够令人颤抖了。 原文发于《计算机世界》。
从底层网络的角度看，通信技术的发展构建了多个维度的高速通路，让一切变为现实。同样，用户也必须借助不断创新的安全技术，建立与网络规模相匹配的防护体系，为业务保驾护航。经过国内外安全厂商的不懈努力，目前顶级防火墙的处理能力已经达到百G级别。这并不是个宣传意义大于实际意义的噱头，因为用户的需求已经迫在眉睫。在今年国内运营商的安全产品招标中，对高端防火墙的性能要求达到了40G-80G，距离部署百G产品的日子已不再遥远。针对这一趋势，华为赛门铁克也于近期推出了全新的USG9500系列产品，再次升级了高端产品线。我们也在第一时间对USG9560这款产品进行了测试，亲身体会了新一代百G产品带来的与众不同的应用体验，在此与读者朋友们分享。 规格领先 功能全面 华为赛门铁克USG9500系列包含USG9520、USG9560、USG9580三款产品，均基于华为高端路由硬件平台打造。设备中所有部件均为冗余设计，其中单板、电源模块和风扇支持热插拔，符合电信级别的高可靠性要求。三款产品的区别主要体现在扩展槽位的数量与整机性能方面，最高端的USG9580提供了多达16个接口/业务扩展槽位，标称具有2.56T交换容量及240G接口容量，是新系列中的旗舰产品；最低端的USG9520则针对主流的万兆及多千兆接入环境设计，提供3个接口/业务扩展槽位，标称最大40G的整机处理能力，具有灵活的扩展性和相对较高的性价比。我们测试的这台中端定位的USG9560则需占用14U的机架空间，提供了11个扩展槽位，其中3个用于安装主控交换（SRU）及交换引擎（SFU）。SRU主要负责设备管理、系统监控与调度、路由计算等工作，同时内置一个交换引擎。当插满两个SRU与1个SFU时，两套主控系统会工作在主备状态，3个交换引擎工作在2主1备的状态，提供1.44T的交换容量。这种设计可以保证设备在任意一块SRU或SFU出现故障时还能正常工作，且性能不会出现瓶颈。
USG9560上剩余的8个槽位用于安装业务卡（SPU）与接口卡（LPU），考虑到未来接口容量与性能的升级，每槽位设计带宽达到双向200G。在SPU与LPU的设计上，华为赛门铁克采用了模块化的思路，显得非常独特。SPU板载了两颗1GHz主频的NetLogic XLR732处理器，具有10G的处理能力。该卡同时提供了一个子卡插槽，可安装同样配置的业务处理子卡（SPC），将单板处理能力提升至20G。而LPU也提供两个子卡插槽，可安装不同类型的接口模块子卡（包括以太网与POS），目前可实现单子卡两个万兆或20个千兆的接口密度。与我们去年测试过的USG9110不同的是，USG9500系列产品中的SPU和LPU之间没有任何强制性的对应要求，用户可根据需要进行灵活搭配。 在基本功能与安全业务方面，USG9500系列产品已经实现得相当全面。该产品可以支持NAT端口复用，能够有效减少海量用户使用互联网时对公网IP的依赖，对运营商、行业用户及园区网用户有很大的实际意义。除了防火墙，USG9500还具有VPN、应用流量识别控制、IPS和抗DDoS的能力（后两者使用单独的业务插板实现），以满足数据中心为代表的新应用场景的复杂需求。借助华为在数通领域的长期积累，USG9500系列产品在路由支持的种类、兼容性等方面有着先天优势，既能可靠地独立或参与组网，亦可在遭到DDoS攻击时与上下游网络设备联动，实现流量的牵引、清洗与回注。 架构灵活 性能强大 与USG9000家族中的其他产品一样，USG9500系列产品也采用了“两分布、一统一”的设计思路，即分布式处理、分布式转发与统一管理。由于集成了高性能的网络处理器，LPU可以实现基于多种策略的数据分发操作，将流量尽可能均衡地交给每个SPU上的每一颗处理器进行处理。这也意味着，该产品可以通过增加SPU数量的方式，线性提升整机的处理能力。
USG9560防火墙基准性能测试结果（路由模式/1条全通策略）
USG9560抗攻击测试结果（配备1块抗DDoS业务板，不含扩展子卡） 我们在随后的测试中使用了多至5块内置SPC子卡的SPU及3块具有4个万兆XFP接口的LPU，组成20G-100G规格的多种配置，对这一特点进行了验证。测试仪器为搭配了多个10G-LSM-XM4S网络层测试模块和Acceleron-NP应用层测试模块的IXIA Optixia XM12。当USG9560中只有1块SPU卡工作时，该系统（路由模式，1条全通策略，后同）在IMIX模型（UDP混合包，64Byte:594Byte:1518Byte=7:4:1）下的吞吐量为20G，平均延迟为85微秒。如果再增加一块SPU，IMIX吞吐量马上提升至40G，平均延迟保持不变。当5块SPU卡均处于工作状态时，系统的整机IMIX吞吐量达到100G，平均延迟则小幅上升至106微秒。在这个过程中，每颗CPU的使用率都保持一致，系统的负载均衡效果十分优秀。我们也试着在处理能力留有足够余量的情况下在线减少SPU卡的数量，USG9560会立刻自动对负载进行重新分配，达到新的均衡处理状态。 除了吞吐量与延迟，分布式处理、转发的优势在连接相关的性能指标上也有所体现。当使用1块SPU卡时，我们测得的整机HTTP新建能力（64Byte页面，后同）为每秒669463个连接，最大并发连接数为8340904，达到并超过50万/800万的标称值；两块SPU同时工作时，HTTP新建连接数提升至1360407，最大并发连接数也达到了16681108。由于测试仪器的限制，我们没有再对配备更多SPU卡时的性能进行测试，但仅从这两组数据中，已经可以看出整机的连接处理能力可以随着SPU板卡数量的增多而线性提升。 对于数据中心这样的应用场景来说，其可能受到攻击的规模之大、种类之复杂，是集成于UTM、NGFW等设备中的抗DDoS功能所难以抵御的。针对这种情况，华为赛门铁克将该功能独立出来，以专用业务卡的形式提供了高性能抗DDoS解决方案（单卡标称10G流量清洗能力，同样可以通过扩展子卡提升一倍）。我们也利用手头的测试仪器，对插入1块抗DDoS业务卡（不含扩展子卡）的USG9560进行了测试。面对测试仪分别生成的10G线速SYN-Flood、UDP Flood和DNS-Flood攻击流量（64Byte，后同），该设备可以将攻击流量完全阻断，同时保证后端服务器的正常访问，此时DDoS业务卡上的CPU使用率分别为87%、70%、83%；我们又按1:1:1的比例发起了包含三种攻击的混合流量，USG9560依然可以将攻击完全阻断，此时的CPU平均使用率为81%，仍留有部分余量。 TCAM：让天堑变通途 作为成本、查找速度均极为惊人的可寻址存储器，TCAM大多被用于核心路由器、数据中心交换机等高端数据通信产品，在安全设备中极少出现。不过，我们去年在USG9110产品测试中，已经注意到其业务板上配备有TCAM。如今，这一设计被USG9500系列产品所沿用，大有发扬光大之势。这是个令人费解的举动，因为厂商在设计产品时会本着“次优”和榨干硬件处理能力的原则，选择能满足需求的最简单、成本最低的解决方式。对于TCAM这种成本极高昂的器件来说，除非它能让产品性能产生革命性的变化，否则绝无使用的道理。那么，华为赛门铁克坚持在高端安全产品中使用TCAM意义何在？我们通过混合非法流量和访问控制列表（以下简称ACL）查找两个测试用例，进行了一系列的验证。 在合法数据流中混合非法流量，是安全产品测试中不可或缺的手段之一。目前，几乎所有状态检测防火墙都借助快速转发技术提升性能，当合法数据流建立后，流信息会被下发到防火墙状态表中，剩余报文可根据状态信息直接转发；非法流量则通常不会建立状态，这就意味着流中每一个数据包均要由处理器进行完整流程上的处理，其中就包括了资源开销非常大的ACL查找操作。当非法流量的比例达到一定程度的时候，防火墙就会因资源耗尽导致性能大幅下降。以我们去年测试过的一款64Byte UDP帧吞吐量达到8Gbps的防火墙为例，当测试流量由合法的8G变为6G合法流量+2G非法流量后，该设备的吞吐量竟然下降到100Mbps以下。 由于TCAM的存在，USG9560在处理非法流量时的性能开销大幅减小，处理能力也就得到了保证。我们在1块SPU处于工作状态的前提下，向设备的ACL中加入一条阻断特定流量的策略，再使用测试仪先后发起16G的正常流量与4G应被阻断的非法流量（均为UDP/386Byte帧长）。USG9560在只有正常流量通过的情况下，可以做到不丢包转发，此时的CPU使用率仅为21%；当加入4G非法流量后，正常流量的转发没有受到任何影响，非法流量则被完全阻断。此时SPU卡的CPU占用率上升至47%，仍有余力处理其他安全业务。从这个结果中可以看出，虽然TCAM没能让设备的理论性能得到进一步提升，却在处理非法流量时弥补了性能短板，在实际环境中体现了其存在的价值。 与混合非法流量的测试相比，ACL查找能力测试更偏向底层，但在园区网、骨干网和数据中心规模不断扩大的今天，许多用户需要借助防火墙实现更加复杂的访问控制，这个原本偏重理论层面的测试用例也就有了更多的实际意义。我们知道，大部分采用状态检测机制的防火墙会在启动时对用户设定的ACL进行预处理，将其转换为引擎可识别、查找的树或矩阵。转换算法的优劣决定了存储空间的占用、转换速度和查找性能，是厂商核心技术能力的体现。好的转换算法不但能以较低的资源代价实现较高的查找性能，还可以对ACL进行有效的优化合并。比如许多测试中使用的针对1个C段内连续IP而设定的策略，最优状态下可以被合并为1条等效策略，其测试数据显然不能代表设备在实际环境下的性能。 有鉴于此，我们在制定实验室安全产品测试规范的过程中，包含了基于复杂策略的测试用例。该用例中的ACL列表模拟部分用户的配置思路，包含了5000条不相关联的策略。它使用有针对性的算法生成，阻止主流转换算法对其进行优化，且令生成的树或矩阵变得极其复杂，显著提升了设备查找时的性能开销。一些产品在测试中无法正常加载此ACL，或会在加载后性能大幅下降。这样的产品如果被部署在实际环境中，会为用户带来无穷无尽的烦恼。某行业信息中心主管与我们交流时就曾谈到这样一个情况：当他们逐步将分散的服务器群组迁移至数据中心后，防火墙的ACL数量已接近3万条。此时设备从加电到进入正常工作状态需要长达40多分钟的时间，且设备每次在添加新的访问控制策略时，都会有1分多钟处于无响应状态。而他们先前使用的产品则在加载1万条左右的策略后直接罢工，严重影响了业务的正常开展。 不过，我们在对USG9560的测试中没有丝毫担心，因为TCAM的工作机制决定了其策略查找性能不受策略复杂度的影响。测试数据也很好地证明了这一点：在加载复杂策略的情况下，USG9560的开机时间仅由之前1条全通策略时的9分4秒增加到12分12秒。在此基础上使用测试仪发起命中第4999条策略的16G正常流量（UDP/386Byte），系统可实现不丢包转发，CPU占用率为33%；当另外加入命中第5000条策略的4G非法流量后，正常流量的转发没有受到影响，非法流量也被完全阻断，此时CPU占用率上升至55%。这样完美的测试结果，足以保证USG9560在海量策略的应用场景中保持应有的性能表现。 应用识别步入百G免费时代 从用户群体的需求角度出发，高端防火墙通常强调高性能、高可靠性，提供的安全业务并不像企业级产品那样全面。如果要增加特定功能，通常也会以专用业务插板的形式实现，尽可能减小对设备性能的影响。不过华为赛门铁克在USG9500系列产品中，将应用流量识别控制与防火墙、NAT、VPN等一同列为产品的基础特性，免费交付给用户使用，令人十分惊讶。众所周知，应用流量识别控制确实是一个快速增长的市场需求，以此为基础甚至诞生了下一代防火墙（NGFW）这一新产品形态，但因其需要消耗大量系统资源，对防火墙性能造成很大影响，罕有厂商会在最高端产品中加入该特性。华为赛门铁克此举，是为运营商及大型行业用户提供增值服务，还是为了迎合市场的推广策略？ 只有测试能给出答案。我们使用BreakingPoint提供的测试仪表，对配备1块SPU的USG9560进行了检测率与性能测试。该测试仪可以模拟多种互联网应用，实时生成近乎真实的测试流量，而不是简单地利用PCAP回放进行仿真。在开启防火墙与应用流量识别控制功能（路由模式，加载1条全通策略，只识别不做控制）的情况下，USG9560对测试仪发出的包含HTTP、BT、eDonkey、流媒体等业务的10G混合流量（预设并达到每秒10万新建连接/最大保持200万并发连接）可以做到完全识别与线速转发。此时SPU上的CPU占用率比单纯防火墙模式时略有小幅上升，数据包转发的平均延迟也仅增至160微秒。不过也许是为了减少大流量时的系统负载，设备并没有在内置的图形化界面中提供应用层流量的相关统计，而是通过eLog集中分析报表系统进行统一的挖掘与呈现。
作为USG9500系列产品的基础功能，应用识别特性以进程形式工作在SPU中，理论上性能可随SPU数量增加而线性提升。我们也在之前测试100G吞吐量的硬件配置下，对开启应用识别功能时的整机处理能力进行了考察。BreakingPoint测试仪此时已无法生成如此巨大的测试流量，所以我们改用IXIA Optixia XM12以发送双向UDP报文（IMIX模型，包含800个并发连接）的方式进行测试。在100G的UDP流量压力下，USG9560仍然顺利完成了测试，将数据报文正常识别为未知UDP流量，性能也如预期般达到线速转发。我们在测试过程中也注意了设备的资源占用情况，可以看到5块SPU上的20颗处理器基本保持着同样的负载，不存在单点瓶颈的隐患，并且开启应用流量识别后，CPU负载并没有上升很多，相信在错综复杂的现网环境中仍可保证线速处理。 集成高性能的应用识别引擎并免费交付给用户，无疑是USG9500系列产品的最大亮点之一。从华为赛门铁克公布的信息来看，该引擎目前已能鉴别超过1000种应用协议，且有专人对协议特征进行扩充与更新。对于运营商与行业用户来说，集防火墙、NAT、应用流量识别控制功能于一身的高端设备正是他们目前梦寐以求的产品形态。我们感觉华为赛门铁克的思路很清晰，即短期以免费流控和应用防火墙为卖点，增强产品的竞争力，争取更多的市场份额；长期来看，应用识别的价值绝不仅仅在于流控或应用防火墙，它是未来几乎所有安全业务的核心，以此为基础通过升级的方式增加新的安全业务，对供求双方来说都是双赢的结果。 测试后记：彪悍的产品不需要解释 “我们主要就是一条连教育网的万兆出口，高峰期上下行流量加起来也不过10G出头，厂商却建议我至少在防火墙上插三块标称20G处理能力的业务引擎，这到底是为什么？”面对不久前交流时某高校信息中心主管抱怨式的咨询，我们感到很难回答。客观原因是存在的，任何安全产品在真实环境中的性能都会低于实验室中测得的理论值，当应用场景非常复杂时，下降幅度甚至会超过50%。为保障业务的正常运行，厂商一般会建议用户部署时做性能预留，但即便如此，要求用户至少购买3块业务卡的做法也是难以理解的。分布式防火墙本身就有着按需配置的特点，用户凭什么要为用不着的性能买单呢？ 抛开技术上的因素，我们也许触及到一个比较敏感的话题，那就是性能标称值的准确性。它不像产品测试，有很多业界公认的评价标准，依据某一标准测得的性能，对任何产品都是公平有效的。而厂商在进行产品包装时的性能度量方法，是不存在任何统一标准的，也许吞吐量你标IMIX，我标1518Byte帧，或者新建连接你标HTTP，我标TCP。个别厂商甚至本着“人有多大胆、地有多大产”的思路，虚报出一个产品根本无法达到的性能。这种不负责任的做法给用户的选型工作增加了许多不必要的麻烦，也让用户对厂商宣称的性能指标产生了强烈的不信任感。所以我们看到，虽然越来越多的厂商开始在产品规格表中注明标称性能的测试环境，用户却完全不在乎了。他们怕了，他们伤不起了。 换个角度看，厂商即便给出了实实在在的性能参数，又有多大意义呢？用户买产品是要解决问题，他们没有兴趣研究为什么开启某功能后一块业务卡的性能就不再是20G，然后还得折算用多少块业务卡才能在理论上满足需求，最后再战战兢兢地通过测试去证明。彪悍的产品不需要解释，华为赛门铁克显然认识到了这一点，并成功地将其付诸实践。就像USG9560，不管我们怎么折磨，其单板性能永远等于标称值，包括本应属于下一代防火墙定义范畴的应用识别控制功能，你开，或者不开，20G的性能就在那里。这样的产品，才是对用户最大的尊重。 做到这一点真的很难。从产品角度看，华为赛门铁克为实际应用中的性能损耗做了充分的资源预留，这也是一块业务卡配备4颗NetLogic XLR732处理器的主要原因。在没明白这一点之前，我们甚至一度怀疑华为赛门铁克的研发实力，因为这样的处理器即便拿出一颗做业务卡，也完全有理由标称20G处理能力（实际上，大多数高端分布式防火墙也是这么做的）。该公司能顶住成本与研发上的压力，放低姿态去做“不需要解释”的产品，其魄力值得称赞。“千淘万漉虽辛苦，吹尽狂沙始到金”，任何用户都不会冷落这样一款实实在在的产品，这一点，不管你信不信，我反正信了。 | |||||||||||||||||||||||||||||||||||
  (5个打分， 平均：4.20 / 5) |
雁过留声
“华为赛门铁克USG9560评测报告”有91个回复
国产版本的SRX
占坑，等看评论
不同意楼上。和SRX的架构还是有区别的
华赛的防火墙研发团队很踏实，高端防火墙的性能一直很好，Anti-DDoS功能也有很多亮点。
产品功能是不是太单薄了？不带IPS功能的单纯防火墙，市场空间已经很小了吧。
重点是xlr732*2实现spu，其余全是NE，产品角度毫无创新。
看着怎么那么眼熟哪？除了颜色不一样。
NE40E-X3/8/16!
用了ATCA的架构才100G，不觉得有点丢人么？
真砸钱啊
策略容量可以多加些测试
弱问一下，为什么开机需要10min左右的时间？
主要开销在什么地方？
是硬件平台初始化慢，还是OS启动慢，或者是控制平面初始化的逻辑比较复杂？
不好意思，没接触过大家伙，缺乏一些common sense.
怎么理解TCAM对异常流量的优化？
是否可以这么认为，一般情况下，fast path的flow table只转发合法流量，而slow path上又没有flow table，导致异常流量按per packet的频率执行ACL规则。
TCAM相当于在slow path上又增加了一个flow table，专门记录异常流量的控制动作，保证即使是异常流量在slow path上也只匹配一次ACL？
总之，系统上有两个flow table，fast path上处理正常流量，slow path上处理异常流量，可以这么理解吗？
系统都是vxworks 实时系统呀，要10min， 干毛呢
官网上40G的产品64字节小包15Mpps，也就是10G左右的小包。
han同学竟然能包20G的小包就测试到7/12×20=11G，神奇了:(
当USG9560中只有1块SPU卡工作时，该系统（路由模式，1条全通策略，后同）在IMIX模型（UDP混合包，64Byte:594Byte:1518Byte=7:4:1）下的吞吐量为20G
http://www.huaweisymantec.com/cn/Product_Solution/Product/Security/FW_UTM/Secospace_USG/Secospace_USG9500/#
@7：你说的是维护一个针对需要Deny的连接的表项，和TCAM实现的不是一回事。前者在现网环境会对连接表容量造成影响，甚至不用DDoS就可以搞垮设备，只是在测试环境中处理非法流量比较风光。TCAM的存在不改变传统处理机制，目的是减小Memory Access对性能造成的影响。现在TCAM在高端防火墙上的使用似乎是个趋势，我了解的Fortinet就也这么做了，华赛貌似是国内第一家采用这种方案的厂商。
当配置命令较多时，配置文件在系统启动后的执行架构和方式，对系统开始正常运行的时间有非常大的影响
你可以想象一些10个linux线性启动要多长时间，虽然有些东西可以并行启动，但是大部分还是线性有依赖关系。
官网上40G的产品64字节小包才15Mpps，也就是10G左右的小包。
而韩同学竟然能把20G产品的小包就测试到7/12×20=11.67G，真是太神奇了，请韩同学答复一下。
韩同学竟然能把20G产品的小包就测试到7/12×20=11.67G，真是太神奇了，请韩同学答复一下。
而官网上40G的产品64字节小包才15Mpps，也就是10G左右的小包。
业务板确定还是只有两个732？两个732就能达到10G的业务处理能力？好像听说已经做了4个cpu的板子了
还是技术太落后了， 说实在的， 这么多732堆起来才这点性能， 真的不说啥了。。。
不知道PanabitOS + sandybridge 一颗CPU能跑出多少性能？
小韩同学，建议做事情要严谨一些，
下面是吞吐量比呢？还是包个数比呢？
这个关键信息一含糊，结果可就是天壤之别了！
IMIX模型（UDP混合包，64Byte:594Byte:1518Byte=7:4:1
谢谢8~10楼的解答
是吞吐量比，没有标注清楚，我的问题。您在11楼的问题我没弄明白，请赐教。
如果是吞吐量比，11楼的计算应该是对的吧。20G中 64Byte的吞吐量占据了 7/(7+4+1)，远高于官方网站宣传5Gbps。
参考下面在连接：三种报文在流量中的（个数）比例为7:4:1
http://www.51testing.com/html/25/n-208925-2.html
乍一看觉得很牛X， 细细一想，楼主隐藏了最关键的信息，一点也不实在:)
为何不公布64byte，128byte，256byte…下的性能数据呢？这才是最实在的！还谈什么别整虚的呢？
如官网所示，如果20板块的小包才5Gbps的话，不信你拿到我们运营商出口测试一下，保证你在5G的真实链路下CPU就50%。
唉，又一噱头！
@15，@17，白天在外面回复的时候脑袋比较乱，回来仔细查了ixia仪器生成的报告，确定是包个数比为7:4:1，抱歉。
@18，我没按2544跑过，手头没有数据。不过你也不必太信他们官网的数据，新产品文档太少并且有很多不准确的地方，比如我测之前看文档说新建只有50万，后来测出来65万，找他们核实，他们说新版本在家测就是65万。这样的例子还有很多。
不知道您在什么规模的运营商，不过我觉得DPI是大势所趋，现在用FPGA达到很高性能的设备，在未来很难满足应用流量监控需求。指望FPGA实在应用级别的细节统计？反正目前我是没见过。
当然，如果现阶段FW和DPI均为独立部署，那就无所谓了。
@18，如果您觉得9560上现网时预计50%的CPU占用率很高，不妨测试下其他产品。据我了解的信息推测，您可能直接见到很多100%的情况。
re：确定是包个数比为7:4:1。
则20G板卡的小包性能为：
20× (64+20)*12/（64*7+512*5+1518*1+20*12）
还不到4.5Gbps。
了解下NE40-X启动需要多少时间你就知道为啥95XX需要那么长启动时间了。
别人要20分钟，你要9分钟就很牛了？你要是用户，特别是重要的数据中心，你吧不得不用1分钟。
明明是吹嘘产品，还貌似站在客户角度，不能说是软文了，都硬起来了
如果觉得这款产品不行，也许最大的原因是不了解其他厂商的产品，尤其是在大吞吐量复杂业务节点例如关口局部署时候的情况
看了这么多网友的评论，也来谈谈我对这篇文章的理解。
就事论事，不针对小韩也不针对华赛。
该篇文章的核心是一个关键词“实实在在，别整虚的”，给人的第一感觉是，只有华赛USG9560才是实在的，其它厂商都是噱头。
而恰恰在这个“实实在在”问题上，该文章范了致命的错误：
1、以IMIX 20G来作为“实实在在”的标杆，而懂行的都知道，这样的IMIX有何真实价值呢。就像有一位网友指出的，真想做“实实在在”的宣传，不妨大胆的给出64、128、256、512、1024、1518等包长下的测试值。楼主恰巧又在这个问题上犹抱琵琶半遮面，另有网友甚至通过IMIX包的组合，计算出64byte小包不过4.5G这个不争的事实。
2、一个“实实在在”的20G产品，只追求在5G真实流量下，CPU50%的目标？ 我知道其他厂商20G产品在我司5G链路上也不过80%左右的cpu处理。USG性能的确是提高了一些，也不过是50步笑百步而已。
总之，USG9500系列产品还不错，但整体宣传上是个败笔，楼主用华丽的辞藻和看起来确凿的数据绑架了读者的眼球，而恰恰倒了更细心观众的胃口。
也许文章标题就是个噱头，就是为了吸引用户。不管你信不信，反正我是不信:)
HS的高手估计该出场了：
1、为何用4快CPU，却设计出一个小包性能和新建能力极不匹配的板卡？
2、有无现网的使用数据？ 20G板卡到底能支持多少G的真实链路？
为什么不直接给出每秒包处理数pps来呢?bps和包长有关系，容易误导人.
@31、34，如果IMIX 20G的时候CPU占用率正好是100%，则推导成立；而实际情况是带宽达到最大而处理器有余量，所以这样推导是不成立的。
至于“实实在在”，是我个人感受，参照系是以前测试过的产品。4个732不是白码上去的，测试中能看到实效。我也觉得9500系列还不错，当然是相对而言。
韩童鞋还是很努力的，希望以后多发文章，技术上的问题，拿出来讨论，大家才能共同进步嘛。
@37，虽然CPU处理器有余量，不过，应该不大。官网上40G的产品64字节小包才15Mpps，也就是10G左右的小包。从这个可以看出，实际上这款产品64B的吞吐量真的不高。
咳。。。。。性能说实话感觉一般，用过XLR的532，目前在用OCT的，多核还是要用厂商提供的专用fast库好些，估计hs的没用Rmos，如果用了rmos，性能会提高很多。hs肯定只是将一些之前的应用+OS简单的跑在多核上了，不过话说回来要是基于RMOS开发类似的功能，又要麻烦不少。
顺便求份北美的工作，哪位仁兄能否帮着推荐下。想出去混下
@39，测吞吐延迟的时候我后悔没记录CPU占用情况，所以没法说清到底余量是多少。后面ACL和DPI测试中的CPU占用情况都有截图，所以数值都写到了文章里。至于官方文档，应该是还没更新，毕竟这个产品也还没正式发布，稍等下再看吧。
我现在只对平台的裸奔性能比较感兴趣，x86系列就比较关注2544的性能，后期甚至只关注64Byte性能；对完整的产品形态而言，IMIX的性能已经比较说明问题了，叠加安全业务后的性能才是关注重点。说来也怪，以前吞吐延迟都按2544测的时候，很多人都说国内产品就是傻快傻快，尽测些没意义的数据；如今多从用户角度去贴近应用场景测了，又来纠缠小包性能。
唉，真是窝囊。
我是很认可USG9500系列产品的，至少他让我能很爽地去测一些平时不敢测，测了又没法写出来的东西。比如ACL那个部分，如果把国内市场上各安全厂商的高端产品都拿来在按同样的方法做对比测试，USG9500的表现肯定是比较出色的。所以我才把基准性能作为一个小标题来写，ACL和DPI另用了文章一半篇幅去写。
不过这也是个很好的提醒，以后我会想办法多做些对比测试。同一个环境下用同样的测试方法，只要有根据，就是公平的。
欢迎对比测试。就感叹安全圈子为什么没有一个类似存储的第三方性能测试机构和网站？应该树立一些标准，不怕标准开始定的有问题，只要大家都来提合理意见，测试标准一定会越来越贴近用户实际。
纠结小包的，一般是J和F。因为用的是ASIC加速。小包性能确实好，但实际环境效果如何，自己最清楚。昨天看见一个厂商写指标，小包要14G，但并发只有100万，防病毒开启后，网络吞吐量不低于250Mbps。光是小包强有啥用？？
安全行业政策指导性强，行业用户花得又不是自己的钱，自然没有第三方测试生存的土壤
@43 弯曲是不是可以考虑做这个事？
还有一个疑问，IXIA仪表的报告一般都是以data rate的速率汇总的，也就是说1G的线速64字节小包，IXIA_PDF报告吞吐量是761Mbps左右，还是说pps或者贴一个简单的报告截图更好。
1, SRX是华赛高端墙在运营商市场最主要的竞争对手之一
2, 9500是支持IPS的，4楼放心
3, 基于NE-X平台实现，可以在上市时间和端到端成本上取得优势
4, 开机时间有待优化，但9500的可靠性，让这个改进点的驱动力较低
@31 楼你吓着老韩了，但是这个同官网发的5G的性能指标不矛盾的
为什么呢？这里面是个数学问题 ：
通过IMIX线速推测64字节小包性能的方法是不合理的；可以通过64字节小包性能推测出来IMIX一定线速，但是反之不一定成立
你明白的 …
了无新意，NE40E-X+新一代防火墙插卡，FW处理器依然是XLR732。
如果思科愿意，76/65+ASA插卡也可以算100G防火墙了
拿NE做机框，成本不低吧
C家ASR1000马上就100G咯
@49 C家65系列SW+新的ASA单板确实存在了
但是那时路由器加+FW插班,不是真正的FW
我是USG9500的产品经理，非常感谢各位对我们这款产品的关注，在这里我就前面一些大家比较关心的问题集中做一下解答。
1、 关于USG9500的架构：
硬件上USG9500没有采用ATCA的架构，而是采用高端分布式信元交换平台，也就是大家所说的华为NE-X系列的硬件平台，此平台采用了信元交换技术，无阻塞、低延迟、可靠性强（在现网大规模应用了）。USG9500在此硬件平台基础上，软件重构成了分布式防火墙，实现最佳的可靠性和真正的线性提升性能，我们没有采用路由器+FW插板这种简单的改造方法，这样就不会带来因为不同的管理平面带来的管理复杂性，流量也可以更精确的负载分担到各个业务处理单元上。
接上：2 关于性能问题：
我们64字节小包的实测性能是5.2Gbps（略高于官网5Gbps的），但现网里面跑的并不都是小包，根据IMIX（NLANR推荐）的流量模型，包结构的比例是64byte：128byte：256byte，其实可以看出小包比例占比比较大。在现在运营商和客户的测试里面我们碰到的也都是在用IMIX的流量模型，IMIX流量模型现在已经逐渐成了业界一个标准的测试方法方法；根据我们对客户流量模型的统计数据显示，IMIX的测试方法还是比较接近用户的流量模型，下面是我们对客户线网流量模型的一些简单统计，可以分享给大家
典型场景 平均包长 会话成分
企业网 457 TCP(15.1%),UDP(75.8),ICMP(0.1%),FTP(0.00%),HTTP(9.0%)
校园网 521 TCP(19.2%),UDP(67.3),ICMP(0.1%),FTP(1.6%),HTTP(11.8%)
IDC中心 302 TCP(25.2%),UDP(61.34%),ICMP(0.1%),FTP(0.16%),HTTP(13.2%)
运营商-城域网出口 525 TCP(16.8%),UDP(73.2%),ICMP(0.16%),FTP(0.0%),HTTP(9.9%)
运营商-3G网关 607 TCP(31.0%),UDP(56.0%),ICMP(0.0%),FTP(0.0%),HTTP(12.2%),SMTP(0.8%)
运营商-WAP网关 597 TCP(30.1%),UDP(57.3),ICMP(0.1%),FTP(0.16%),HTTP(12.34%)
其实关于防火墙，单纯的吞吐性能根本不能作为选型的参考，这一点很多客户也非常认可，在现网中，部署什么样的防火墙，不仅要看吞吐性能，还有新建能力，并发能力，还要考虑将来在FW上配置的策略，以及非法流量背景下的转发新建处理能力（防火墙毕竟不是交换机、路由器纯粹做转发，我们要有安全隔离的使命的），这都是需要考虑的重要因素。
如果只是各包的吞吐性能，我们在实验室里通过加速卡，一个CPU就能做到20G，但意义何在呢？
接上 ： 3、 关于启动时间的问题：
的确10分钟跟电脑比起来确实慢了些，但我们的硬件兄弟在启动优化方面已经做出了最大的努力，USG9500用到了NP、TCAM、RMI等N多种芯片，在启动的时候管理/监控平面会对每个芯片/CPU/风扇/电源等部件进行检测，确保整机启动正常。在这个设备上，我们确实无法做到像PC上面的软件一样做开机优化，我们把更多的精力投入到了如何保证设备的可靠性，我们的分平面控制，我们的双主控，我们多CPU负载分担，我们的板卡负载分担，我们的链路负载分担，我们双机热备倒换的时间可以控制在毫秒的级别，这些都是为可靠性做出的努力，我们的理想是这个设备被部署后不会因为我们的问题被迫重新启动了。
在这里，我代表USG9500团队再次感谢大家的关注，感谢小韩将我们的产品推荐到了弯曲论坛这个开放平台，我们真诚的希望，能利用好这个平台，跟大家探讨一下安全高端产品的发展之路。
@52 请教一下？
USG95多块SPU，能不能NAT到同1个公网地址？
@53,它不是路由器+FW插板,答案你晓得的…
@51,C的ASR1000不都开始卖了？不过安全特性好像同ASA5585相比有差距,还是以路由为主
@53,难道J、F、Hi等都不可以？
华赛USG的产品经理出来了。有N个比较具体的答复。另外，奇怪，为啥小样的答复到了pending approve的queue里了？
华为人就是实在，喜欢甩干货
企业网 457 TCP(15.1%),UDP(75.8),ICMP(0.1%),FTP(0.00%),HTTP(9.0%)
校园网 521 TCP(19.2%),UDP(67.3),ICMP(0.1%),FTP(1.6%),HTTP(11.8%)
–不太理解为啥这么列场景。开始以为HTTP应该是包含在TCP里，后来发现不是，独立出来了。
@62 是对产品所在场景一个抽象总结(我们如此定义,可能其它厂商有自己的定义方式),协议作了简单汇总,鉴于http应用比较广泛就拿出来单独说了一下,当然我们内部的资料信息肯定不这个详细,信息安全不能全部拿出来,望能理解,THX
to HS－USG9500，一点疑惑：
3G的流量构成好理解，GTP导致。
但为啥其它网络UDP占大头，都是些什么应用呢？
UDP主要是P2P，上面列出的场景中，一般在城域网中，但也就是50%左右（我看过同样是HS发布的运营商现网数据报告）
除开3G和城域网，数据中心，企业王，校园网，wap网关，不好理解为啥UDP占大头啊？
而且城域网数据感觉和实际也不太符合。我看过的另一份HS报告，觉得里面的数据比较和直觉一致：HTTP和P2P大体差不多，加起来占了70－80%（好像一个30多一个40多），这和直觉是吻合的（因为目前视频之类的大头基本都呈现为http和P2P）
@53的解答看不懂，既然是基于NE-X，又没采用路由器+FW的方式，那到底做了什么大的改动？
to HS-USG9500:
您一直在拿模型说事情，不妨举一个真实的案例。
USG9500一块20G的板块到底能承担多少现网流量？
看完han的忽悠，我还以为20G流量随便折腾呢:(
众口难调，只有不断改进的产品，没有永恒的完美，对于产品性能指标标注的真实性应当加以关注，虽然大家对虚假的东西习以为常，但还是希望
能回归到一个真实可信的世界。
@63\64 ,首先非常感谢您对HS的关注,这些数据是FW产品所在部署位置的收集，同我司安全分析报告统计分析是整体统计分析；再说说为什么UDP多？举个例子：学校的大学生每天上网干什么的最多？打游戏、看电影呗~~~现在的迅雷看看、搜狐高清、土豆只要用加速器都使用UDP，所以…其他的不一一举例了
@66，很简单呀，路由器用的是路由器平台软件，FW除了路由用的HW的软件平台外，还用来FW的软件平台，所以结果就不一样了
@67 ，我们确实查看了一下现网FW的流量以及CPU利用率，IDC/校园网/广电（抱歉不能将客户信息暴露了），真实流量在10G左右的我们CPU利用率为20%左右，那您觉得真实环境20G如何呢？
谢谢答复！
校园网可能的确如此，比城域网还夸张，都是使用加速器的P2P视频应用。
但是wap网关，数据中心，企业网很难理解啊？
华为除了会杀低价，还能干些啥。
真实流量在10G左右的我们CPU利用率为20%左右。
问：10G是指5G链路双向10G呢？ 还是10G链路？
小包5G的设备在现网10G中CPU20%， 40G也才80%CPU。太牛叉了。。。，干嘛不直接宣传一个板块40G啊。
难以置信，不妨贴图为证:)
USG9500的产品,小弟有幸在现网中使用,目前来看,效果还不错; 也给HS的同学提了不少改进意见; 现实中的产品,都会或多或少有些不完美的地方,如果把自己放在设计者的角度,会发现有很多的无奈,会有很多的折衷; 看起来指标方面,性价比方面未必最优;但一款稳定的产品,能解决客户遇到的问题就是好的产品;不一定要追求技术上的最优
@75，V，又不一定是线性的，可能有衰减点，跃迁点之类的
@75 ,之前我说模型,你开始质疑我的模型;现在我贴出来我们的CPU利用率,你又要质疑我的数据,要贴原图;如果我贴出来原图(又不能暴漏我们客户信息),你会不会质疑我的图片的真实性?所以我觉得贴图的必要性不大了,信不信自在人心了~~~
@76,非常感谢!~~~我们希望我们产品能够给客户真正的带来价值!我们也一直在努力~~~
同74楼疑问：
10G是指5G链路双向10G呢？ 还是10G链路？
@74 & @80 : Througput的定义很明确得，不是路由器交换机的全国双工的概念
竟然还在讨论，有意思。
HS永远的痛就是没有自己的硬件设计与实现能力。
to julang3：
不妨介绍一下您网络的大概规模，申请了多少链路，承载了多少用户呢？
to cloud ;
旁路布署，用于ANTI-DDOS；具体数据不方便透露，不好意思
40G 的DDOS 防御还真算不了什么，而且DDOS 防御用USG 真的是浪费。胡乱的设计
感觉@8&@50就是俩小白，啥也不懂，就瞎JJYY。@8你从哪看出来ATCA架构的，太葱白你了，@50你更NB，照你这样来看，干嘛要把ASA插到76/65里，干脆摆上10台堆在那就行了呗，76/65能把很好的将负载分摊到每个插卡上吗，多个插卡是统一的设备吗？
为啥那么多人都不仔细看文章，看了下图片就觉得自己很了解了，就开始评论了。
DDOS功能模块对CC的防护效果如何？有没有测试过！
请问这款设备的售价是多少？
@88,感谢您对我们的关注和支持!专业DDoS防护是USG9500的主打场景之一,不光在实验室测试过，现网也已经在应用，客户反馈效果良好，所以诸如CC攻击\https攻击、DNS服务器的各类型攻击均能很好的防范
@89,如有相关采购需求，价格可详询我们的销售人员。