进化的艺术——Hillstone山石网科SG-6000-G5150产品评测

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




金秋十月,产品发布的黄金季节,山石网科抢先推出了新一代SG-6000系列产品。经过测试、分析,我对新产品很满意,很认同。正文是如实发布在报纸、网站上的。身边不只一个朋友/同事说,我写得倾向性太强了,会让其他厂商不爽,敏感的读者肯定也认为我拿了好处。冤枉!声明山石网科没给我一分钱红包,也没给我一个字资料。我写的文字,完全是个人的所见所闻所想,如果还说有倾向性,那就当作第三方的观点吧。

事实上,我真的认为,就我了解的各家已发布产品的情况,安全圈里,山石网科在产品技术方面的水平已经不亚于华三、华赛。希望他们能保持高速发展的态势,做出真正意义上的精品,提升国内信息安全行业的技术形象。 

原文发布于《计算机世界》

  与信息安全行业内众多老牌厂商相比,Hillstone山石网科(以下简称“山石网科”)是个年轻的企业。短短几年内,该公司成功发布了SA、SR两大系列共十几款产品,可以提供企业级至电信级的全方位信息安全解决方案,取得了令人刮目相看的成绩。作为后来者,必须要有足够强大的核心竞争力,才能在激烈多变的市场竞争中站稳脚跟,而深厚的技术积累和具有前瞻性的产品设计思路,就是山石网科的制胜法宝。近日,该公司即将发布最新的SG-6000系列产品,再次将这一优势演绎的淋漓尽致。

  感谢山石网科在产品发布前为实验室提供了测试样机,让我们有机会在第一时间与读者朋友们分享最新鲜的测试感受。这是一台型号为SG-6000- G5150的产品(以下简称“G5150”),采用2U规格设计,定位于中高端。产品前面板设计得很漂亮,不过右侧4个扩展槽位更吸引人。G5150可以支持类型众多的扩展模块,用以增加整机接口数量或业务处理能力。面板左侧分布着4个千兆电口与8个千兆SFP接口,加上USB、AUX、控制口和状态指示灯,显得很紧凑。此外,该产品还配备了互为冗余的两组热插拔电源,以满足运营商、IDC服务提供商等电信级用户的需求。 

多核Plus G2:全新的系统平台

毫无疑问,模块化设计是SG-6000系列产品最吸引人的地方,而其基础则是改进后的多核Plus G2系统平台。该平台延续了上一代的设计理念,强化了以交换为中心的设计思路,在硬件体系架构方面继续保持领先。在多核Plus G2系统平台中,接口与处理器都是交换矩阵上的节点。理论上,只要交换矩阵的转发能力不成为瓶颈,就可以继续加入业务处理及接口节点,无缝拓展产品的整体处理能力。由此看来,新平台不但引领了山石网科产品线的升级,也为更高端的分布式产品开发打下坚实的基础。另一方面,该公司坚持采用这种在数据通信领域应用比较广泛的理念设计安全产品,在一定程度上也印证着数通与安全的融合趋势。

 

 

  而对于用户来说,这种模块化的设计思路允许其量体裁衣,根据自身业务需求选择合适的产品配置。就以G5150为例,如果用户需要更多的接口,那它可以额外再扩展出32个千兆口或4个万兆口。借助于强大的交换矩阵,用户甚至可以在接口间划分VLAN,实现三层交换机的功能;如果用户需要更强大的处理能力,可以选配AV应用处理模块,将病毒过滤的任务彻底卸载走,从而提升G5150的整体性能。这种解决方案的实际效果,在后面的测试中得到了很好的验证;如果用户需要的是严格的法规遵从,也可以选配存储扩展模块,在本地保存日志、访问记录及审计信息,从而节省架设外置服务器的高昂投资。

  先进的硬件架构必须配备有与之匹配的软件环境,才能稳定、高效地发挥出系统的整体处理能力。SG-6000系列产品内置了山石网科最新发布的StoneOS 4.0软件平台,为业务的分布式处理做好准备。我们注意到,防火墙、病毒过滤等功能模块在StoneOS 4.0上已经很好地做到并行处理,测试中处理器各个核的负载都比较平均。从整体测试结果来看,该系统对锁的处理无疑是很成功的,在保证业务高度并行的同时拥有比较优秀的性能。

UTM Plus:不仅仅是安全

与全新的多核Plus G2系统平台相对应,SG-6000系列产品的上层业务模块也有了较大规模的扩展,在原先防火墙、抗攻击、VPN、防病毒、流量管理的基础上增加了IPS与上网行为管理两大组件,形成一套完整的安全管理解决方案。在这套方案中,基于角色与行为的控管模式被发扬光大,很大程度上解决了传统IP+端口方式难于理解、配置的瓶颈。用户在使用网络资源时,可以通过静态关联、Web认证、VPN接入认证等方式与角色进行绑定,动态获得基于用户或用户组的访问控制及审计策略。管理员在进行日志审计时,也可以更直观地看到用户及其行为,大大简化了复杂的定位流程。这种控管模式,在一定程度上可以取代端点准入与事件管理两种功能。

  山石网科将整套解决方案中作用于应用层的组件集称为UTM Plus,也许就是想突出带宽管理、上网行为管理等对传统UTM功能补充的重要性。正所谓安全离不开管理,行为管理可能不属于安全范畴,但一定是达到安全目标的途径之一。UTM Plus中的上网行为管理功能完全基于应用层协议实现,目前支持包括网络游戏、即时通信、在线炒股、P2P、流媒体等在内的200多种应用。用户可以很方便地对应用流量进行整形,或是针对下载文件类型、页面关键字与URL制定访问策略,以达到提高生产效率及阻止用户访问不安全资源的目的。值得一提的是,UTM Plus中的上网行为管理模块还提供了一个包含39大类,超过2000万个域名信息的URL库。我们注意到,这个库中的数据显然进行过本地化工作,并按国内用户的习惯进行分类。山石网科为URL库与应用特征库提供了定期升级服务,这应该是保证管控准确性的唯一方法。

  对外发信息进行审计,防止机密外泄及不必要的法律纠纷,是UTM Plus中上网行为管理模块的另一大作用。该模块对HTTP、FTP、SMTP和主流即时通信类应用提供了由信令到内容层面的审计能力,莫说论坛发帖,就连163、Hotmail、Gmail、QQ邮箱等国内应用比较广泛的Webmail发信都被囊括在内。妄想使用Gmail等采用HTTPS登录的Webmail逃避检查也是徒劳的,UTM  Plus内置的SSL代理可以截断所有单向验证的SSL请求,对解密后的内容进行控制、审计。也就是说,利用这个代理,一切基于SSL隧道的应用协议都被纳入控管范围,不会再有漏网之鱼。不过,我们也注意到内容审计功能开启时,客户端并不会得到任何提示,山石网科称会在产品正式发布时以告警提示和法律免责申明的方式加以完善。

性能:再攀高峰

  虽然G5150的性能看点在于AV应用处理模块和新加入的IPS功能组件,我们还是依照RFC 2544和RFC 3511规范,先对单纯开启防火墙时的系统性能做了考察。按惯例,测试分别在1条全通策略与199条阻断/1条全通策略的配置下进行。由于测试仪端口数的限制,在进行吞吐、延迟测试时只使用了4对千兆口发起双向线速流量。1条全通策略时, G5150的64Byte帧吞吐量超过2Gbps,此时延迟仅为7.2微秒;当帧长大于256Byte时,系统吞吐量就能够达到8Gbps线速,延迟最大时也低于30微秒。而在HTTP性能测试中, G5150每秒HTTP新建连接数高达104272TPS,并可同时维持400万个连接。即便加载200条策略,设备依旧可以保持原有性能,各项指标都没有明显变化。

  为了尽量模拟真实环境,防火墙在随后的测试中都保持加载200条策略的状态,带着业务进行测试。G5150集成的IPS模块基于多种协议,截至测试时最新版的特征库共包含了3187条规则。我们开启了针对双向流量的入侵防御功能,使用思博伦通信提供的Avalanche2900应用层性能测试仪模拟真实用户,生成不同类型的HTTP流量,考察此时系统的性能。G5150在这部分有着相当漂亮的表现,实测得的HTTP可用带宽高达3031Mbps。我们分析,IPS、上网行为管理与防病毒模块应该共享同一个协议分析引擎,这也是做到高性能的唯一途径。

   性能再次提升的奥秘来自于型号为FEC-AV-60的AV应用处理模块,它要占去两个扩展槽的空间。只要在G5150上安装好这个模块,病毒过滤功能就将自动切换到扩展卡上完成。为模拟更真实的负载流量,我们将Avalanche2900模拟的客户端行为改为使用HTTP下载一个1MB大小的EXE文件,此时测得的HTTP最大可用带宽为2125Mbps,这个成绩已经超越了去年同期测试的高端产品SA-5050。另一方面,当带宽稳定在最高值时,处理器占用率一直在40%左右抖动。也就是说,系统平台还有资源处理病毒过滤之外的业务。我们在此基础上打开了IPS模块进行验证,HTTP最大可用带宽维持在2106Mbps,与之前只开启病毒过滤和防火墙时基本一致。由此可见,AV应用处理模块的意义更多地在于提升平台的综合性能,而不仅仅是增加病毒过滤处理能力那么简单。

(山石网络SG产品系列一览)

 

(4个打分, 平均:3.00 / 5)

雁过留声

“进化的艺术——Hillstone山石网科SG-6000-G5150产品评测”有125个回复

  1. washion 于 2009-09-25 5:52 上午

    只谈性能问题:
    1.图示中说(Multicore-MIPS64,up to 16 cores),假设是现代主流的MIPS处理器。
    2.按表中的最大吞吐量计算:8Gbps*26.4%*1.488Mpps = 3.14Mpps

    这么高档的处理器,这么低的性能,我实在不敢恭维。(莫非它的“路由模式+策略”另有蹊跷)

    :-)

  2. 李克 于 2009-09-25 6:53 上午

    这个一点都不奇怪,这就是多核CPU正常的性能。所有CPU类转发引擎的性能,都取决于一个报文的完整处理流程所使用的指令周期数(注意不仅仅指令数,指令数只是影响指令周期数的一个因素,还有cache,外部处理部件,IO等)
    在实际应用中,线路带宽不会跑满的,在跑满前,客户就会升级自己的带宽,并且实际网络中小包的业务主要是一些协议报文,HTTP TXT报文和语音报文,这类报文所占的带宽是比较少的,大量的下载和视频占领了大量带宽,但是他们主要是1500字节,所以256字节下86%的性能,已经完全满足客户的需要。
    有一点奇怪的是有时候200条策略比1条策略的性能还好那么一点点,对于vendor,会解释为,是硬件部件处理,和策略条数无关,才有这个现象。实际上这取决于其用了什么类型的硬件查找算法

  3. 老韩 于 2009-09-25 7:04 上午

    那个图只是多核Plus G2的架构示意图,不代表任何一款产品。
    200条策略比1条策略延迟小,是测试出来的结果。不光是这一款产品,也见过其他厂商的产品有类似情况,原因不详,请高人指点。

  4. wh1oo 于 2009-09-25 8:01 上午

    对于1条Rule和200条rules 有点交错的怪异结果可以笨笨的理解为产品不稳定。这样的结果说实话确实有点尴尬。宣称可以接4个10GE,看来仅仅是端口密度还算可以。但是实际整机PPS基本不敢写出来,314W PPS这样的转发,就算你有100个10G端口又有啥意思?作秀产品!
    不是作者和山石有仇,就是不大明白主流安全产品性能指标。

  5. uc berkeley 于 2009-09-25 8:49 上午

    HTTPS/SSL部分有点误导,需要用户客户端添加证书或者忽略浏览器警告,因为UTM不可能提供真正服务器的证书.
    SSL本身是没有问题的,man-in-the-middle attack并不存在.
    现有的设备一般都是建立两段SSL,然后on-the-fly decrypt/encrypt

  6. 陈怀临 于 2009-09-25 9:47 上午

    嘿嘿嘿,小韩不要灰心。。。。山石的读者不要泄气呀。。。加油。

    如果可能,你替大家把山石6000的机箱打开,照几张照片发出来。对于我们这些人,一看就清楚了:–)。

    出来混,都是要还的:–)。机箱一打开,许多事情都清楚了:–)。咔咔咔咔。。。

  7. mpc8240 于 2009-09-25 2:10 下午

    1 rule does not necessarily mean it’s one entry in hardware; 100 rules does not mean all entries will be hit in hardware.
    It also depends on the nature of the rules.

  8. mpc8240 于 2009-09-25 2:14 下午

    two-section SSL explains it.
    I guess users have to accept it or they can’t establish any SSL connection.
    This sucks. Is it in wide use overseas?

  9. 子曦 于 2009-09-25 3:09 下午

    那完全没有隐私了。

  10. CNJ 于 2009-09-25 4:54 下午

    请教,“主流安全产品”都是哪些?

  11. 大雁之行 于 2009-09-25 5:44 下午

    山石的发展还是比较快的,其产品设计架构和设计方向都比较好,但是不知其销售水平怎么样,相对传统的安全厂商,其产品在更细分的市场上,凭借其多年的销售渠道的积累,山石恐怕还难以撼动其主流地位。

  12. 清华土著 于 2009-09-25 8:55 下午

    3Mpps应是cavium芯片跑linux环境下对64B小包的正常处理速度,跟处理器无关,速度慢是linux的问题。

    换成Simple executive作转发, 8Gbps很轻松。

    关于这个,打开箱子就能看出来吗? 真有这么神? 好奇ing

  13. 陈怀临 于 2009-09-25 9:02 下午

    小土著,是这样的。一个系统其实是可以算出理论数据的。什么芯片,型号一曝光。许多interconnect,interface等等就知道了。

    然后,有经验的人就能猜出其软件布局了。。。。

    唉,其实没啥意思。

  14. 于 2009-09-25 11:44 下午

    一个从hillstone跳出来的哥们对我说,山石很强,他一直认为自己不错,到了山石才觉得自己很渺小,原来总想着要干一番事业,从山石出来后,观念大为改变,天天说的一句话就是:我不过是个打工的,把工作做好就好,不要想太多。唉!

  15. droplet 于 2009-09-26 3:32 上午

    曾经碰到过一个问题,同样的rule查找,用软件算法查的速度在某些条件下比硬件查的速度快,比如1条rule,缺省是用硬件查,而200条rule就用软件查。硬件查表的速度不一定比软件快,这取决于rule的特性。如果都是用软件查,1和200应该是没什么大的差别才对,不过也不能排除是个BUG。现在软件优化的rule查找,对rule的数目应该不会太敏感。

  16. 黄岩 于 2009-09-26 4:25 上午

    上面那个圆圆的、像个烧饼样的图比较好看,配色很协调:)

  17. 水煮 鱼 于 2009-09-26 4:53 上午

    可惜对安全产品没啥研究,但是还是顶一下

  18. 李克 于 2009-09-26 5:25 上午

    软件查找比硬件快,那绝对是不能通用的特例,只适用特别场景

  19. 陈怀临 于 2009-09-26 7:48 上午

    Hardware acceleartion有时确实不一定快。原因通常如下:FPGA或者ASIC挂的DRAM大小,查找的Pattern,例如正则表达式等。通信代价(类比是:曹操要通过一个华容道,才能去一个Inter-state高速公路逃跑。所以系统的问题不是高速公路的问题,而是华容道的毛病。但对外人而言,就觉得这高速公路太差了:–))

  20. 李克 于 2009-09-26 10:16 上午

    通讯代价比的是通讯的速度,不是查找引擎本省的速度
    如果是软件直接实现,也就是转发引擎本身做查找算法,直接访问memory,这种转发引擎只能是CPU类型的,包括多核CPU,而不是NP和ASIC。
    这种情况下,如果是线性表,那么是可能的,但是复杂的匹配和查找,CPU做的算法要达到专用查找引擎的性能,那成本一般肯定要更高,所以一般不会采用这样的系统方案

  21. 李克 于 2009-09-26 1:21 下午

    有个失误,线性查找NP和ASIC也可以做,但一般我们所说的查找,不会指这种最简单的查找,这不是查找的核心,复杂的匹配和查找,NP/ASIC的代码空间不够的,而内置的查找器一般性能有限,和专用的查找芯片不是一个数量级
    此类性能评估,除了做黑盒测试外,常用的方法就是做基于TICK的仿真,估算处理流程使用的TICK数(这里是系统处理的TICK,是包含IO等所有资源相关性能瓶颈点),就能大体估算出性能,并能发现瓶颈,这不是什么高级的东西,陈主席对系统研究很深,这方面肯定是高手

  22. vpn 于 2009-09-26 7:18 下午

    其实两次性能测试的结果很难完全一致,操作系统的进程调用的情况不是完全一样,cache的情况也不是完全一样。所以在一定范围内浮动是完全正常的。

  23. 李克 于 2009-09-26 8:14 下午

    这对于基于软件,包括CPU和多核CPU,尤其是CPU的情况下的确如此,多核CPU看系统设计,但是,一般来讲,测试评估是要基于多次稳定测试的结果,而不是一两次,所以统计的来看,如果不是在系统设计上有些特别的处理,是不会出现200个policy性能高于1个的

  24. wh1oo 于 2009-09-26 8:36 下午

    请问清华土著,上文说的是只是简单的RFC2544和RFC3511。这个应该是没有开启AV和IPS的。为啥还要经过Linux处理?本人不大清楚山石的结构,但是从上面来看绝对应该仅仅只是开启包过滤的。如果你是山石的可以给解释一下,让大家开开眼界。这个现象肯定是多核的问题。产品每次测量结果都不一样,至少能说明系统依赖软件调度很大,要么就是系统的处理分配资源的方式可能还有欠缺。否则200条Rules优于1条Rule这样的情况,真是出不来。

  25. wh1oo 于 2009-09-26 8:40 下午

    换成Simple executive作转发, 8Gbps很轻松??
    难道BPS是衡量转发的??那PPS是干啥的??
    你1518B的帧8G都转不了还卖啥啊??如果64B的可以转8G,那挺厉害的。如果走了安全流程还能走8G那更加的厉害,肯定比远远胜于RMI 732了。

  26. niels 于 2009-09-26 9:52 下午

    这种防火墙设备,每个流都建session。做RFC2544测试时,在测试设备做learning的时候session应该都建好了,后续包是不会再查policy的,所以200条和1条差不多或者快一点应该都是测试误差,因为这时候policy是多少条都没有关系。

  27. niels 于 2009-09-26 9:57 下午

    To wh1oo: 可能土著认为山石采用的架构是16个core全跑的linux(确实有不少厂商是这么做的,包括用RMI某些国际大厂)。如果山石用的是cavium的38xx或58xx,那全跑linux不开IPS, AV 64B差不多就是这个速度。如果是SE实现的不开IPS, AV 64B转8是没什么问题的

  28. 李克 于 2009-09-26 9:59 下午

    防火墙基本都是基于流的,首包或者首N包建流,不知道是否有非基于流的防火墙?
    那是测试涉及的问题,这种情况下好侧policy的性能,就要不停的用新流来测试,而不是建好流后测试,这个是基本的测试常识,我们是基于这个常识做得推断

  29. niels 于 2009-09-26 10:14 下午

    实际测试是怎么样的呢?至少RFC 2544没有你说的这个要求。另外policy lookup的算法如果好,200条可能也就比1条多1次memory access,所以这结果也可以理解。

  30. 李克 于 2009-09-26 10:21 下午

    许多东西不是都有RFC的或者都可能有RFC的。
    你说的是可能的,如果使用硬件芯片做查找,那么其性能规格是由这个芯片决定的,比如这个芯片规格是200条一下,时间是一样的,没有区别,在1000条的时候才有区别,我不知道是否有对容量对数量不敏感的查找引擎,包括TCAM,对于黑盒测试者,如果设计得好,就要测试这个拐点

  31. niels 于 2009-09-26 10:56 下午

    恩,有道理。

    另外求教,现在这类设备有厂商用专门的硬件芯片做policy lookup吗?性价比上是否值得?

  32. 李克 于 2009-09-26 11:10 下午

    我理解的policy是基于关键字查询的,主要是TCAM类,在DPI中复杂的基于内容和应用层多种组合的策略查询,我不是很清楚是否有专用芯片,一般使用多核CPU的软件算法

  33. kk 于 2009-09-26 11:24 下午

    # 李克 于 2009-09-26 11:10 pm

    我理解的policy是基于关键字查询的,主要是TCAM类,在DPI中复杂的基于内容和应用层多种组合的策略查询,我不是很清楚是否有专用芯片,一般使用多核CPU的软件算法
    ——————————-
    我知道的策略查找有ASIC基于IPCAM查找的,软件基于遍历的,条件匹配执行target,不匹配继续下一条,其他的没见过

  34. kk 于 2009-09-26 11:48 下午

    # 李克 于 2009-09-26 10:21 pm

    许多东西不是都有RFC的或者都可能有RFC的。
    你说的是可能的,如果使用硬件芯片做查找,那么其性能规格是由这个芯片决定的,比如这个芯片规格是200条一下,时间是一样的,没有区别,在1000条的时候才有区别,我不知道是否有对容量对数量不敏感的查找引擎,包括TCAM,对于黑盒测试者,如果设计得好,就要测试这个拐点
    ———————————
    目前好多测试机构测试防火墙性能基本上都是64小包吞吐、最大并发连接、每秒新建、延迟、HTTP吞吐,一般不会考虑的像你说那么有针对性和细腻 :-)

  35. 李克 于 2009-09-27 12:02 上午

    测试机构不会考虑如此细,他们一般用测试仪或者固定的测试套。因为测试机构是同时为供应商和运营商服务的,至于更愿意为谁服务,那看测试机构的利益点更倾向于哪了,这年头,没有永远的朋友,只有永远的利益

  36. kk 于 2009-09-27 12:32 上午

    不完全是那个原因,防火墙和客户很多不是大批量购买的运营商,大多数防火墙的客户是普通企业、金融机构、政府机构、零散客户、运营商企业内部网等,运营商骨干网上用的并不多,不会像路由设备动辄上亿的订单,因此并不多见客户会专门请评测机构来评测,很多仅仅是参考一下评价机构的结果,然后自己组织自己的技术力量去评测对比进入他们选型备测的缠上产品。也就说评测机构想通过这种方式两头吃,在防火墙领域是机会很少的。

    大部分时候评测机构是通过对不同厂商产品的对比评测出报告,这时候对很多竞争厂商会有很大压力。

  37. kk 于 2009-09-27 12:36 上午

    前面错别字太多,重新更正一下 ^_^
    ——————–
    不完全是那个原因,防火墙的客户很多不是大批量购买的运营商,大多数防火墙的客户是普通企业、金融机构、政府机构、零散客户、运营商企业内部网等,运营商骨干网上用的并不多,不会像路由设备动辄上亿的订单,因此客户专门请评测机构来评测防火墙的现象并不多见,很多仅仅是参考一下评价机构的结果,然后客户组织自己的技术力量去评测对比进入他们选型备测的厂商产品。也就说评测机构想通过这种方式两头吃,在防火墙领域是机会很少的。

    大部分时候评测机构是通过对不同厂商产品的对比评测出报告,这时候对很多竞争厂商会有很大压力。

  38. 李克 于 2009-09-27 12:55 上午

    我说的也是这种评测,我不知道供应商是否会对这些评测结构做一些动作,所以我的评论未必正确

  39. kk 于 2009-09-27 1:00 上午

    我说的也是这种评测,我不知道供应商是否会对这些评测结构做一些动作,所以我的评论未必正确
    ————————
    一般来讲,很多FW厂商都会在送测前对自己的产品做性能调整和开发专用于评测的模块,至于是否对评测机构做一些动作…..呵呵,这个就不多说了,因为我不知道。

  40. wahaha 于 2009-09-27 1:25 上午

    niels的评论是正解,现在的FW吞吐和policy数目没什么关系,1和200的偏差完全是测试的误差造成的,1%的偏差不用这么分析来分析去的吧

  41. kk 于 2009-09-27 1:50 上午

    # wahaha 于 2009-09-27 1:25 am

    niels的评论是正解,现在的FW吞吐和policy数目没什么关系,1和200的偏差完全是测试的误差造成的,1%的偏差不用这么分析来分析去的吧
    —————-
    按照我目前的认知能力,我觉得在正常情况下(不包括那种做了手脚的和特殊硬件FW),软件FW给它设置5000条policy和1条policy还是有关系的吧,为什么没关系呢,能否给我们讲一下基本原理?谢谢

  42. 李克 于 2009-09-27 2:01 上午

    1%本身不是目的,主要是其背后的设计架构,如果是随机的,那么为什么会随机?如果是有规律的,为什么是这个规律?做过产品系统维护的会知道,这背后都是不好说的秘密:)并且一些大客户是真的会问的

  43. ilovebgp4 于 2009-09-27 5:42 上午

    想看看山石是不是真的有960Gbps的fabric,这个不是很容易做到的事。

    不知楼主有没有测过几个跨板卡的10GE接口打full mesh流量的数据?打1518帧长的流量即可,不需要PPS数据

  44. 李克 于 2009-09-27 6:18 上午

    不难,做一个蛇形连接的测试就可以了,只要两个测试仪端口就可以了

  45. 李克 于 2009-09-27 6:20 上午

    it can be called snake test or inline pin

  46. 陈怀临 于 2009-09-27 6:24 上午

    是的。小韩,请照几张照片上来。打开机箱。这没有什么的。我最敢兴趣的是想看他们的fabric 芯片。。。。

  47. 老韩 于 2009-09-27 6:49 上午

    我不能违反保密协议的规定,要负法律责任的。再说,目前也没有你们想的那么复杂。
    感觉发言的人搞技术研究的居多吧,好像不是很了解公开测试、第三方测试、媒体测试等。我记得David Newman介绍Networktest的时候说的第一句话就是,我做的测试只有不到1/3是公开的,其他大量都是配合厂商做的。

  48. 黄岩 于 2009-09-27 6:55 上午

    防火墙的一般做法是,先做流分类,再做高层应用检测。

    流分类的方法有两种:(1)基于TCAM的;(2)基于RFC算法。

    注意,此RFC非彼RFC,这里说的RFC是:Recursive Flow Classification,在google上用RFC classification搜一搜,可以搜出一大堆相关文章。

    基于RFC算法的流分类,基本思想就是用空间换时间,其查找速度跟流数量多少,以及规则数量多少都没有关系。其速度只跟CPU性能以及RAM访问速度相关。但是规则设置不好,可能会占用很多内存。

    基于TCAM算法的流分类,查找速度也与流数量、规则数量没有关系。其缺点是成本高,要求包处理器有专门的TCAM接口,并且功耗大。

    根据流分类结果,再做高层应用检查,这个基本上硬件帮不上什么忙了,最多有可以用一些串正则表达式引擎来帮助查找字符串,比如:MPC8572里面就有这种引擎,以前IDT还专门生产过这种片子。大部分工作还是靠CPU+软件去做的。

    至于上面评论中提到的线性算法,不知道是不是指“受到报文之后,从第一条规则开始批配,直到找到一条能够批类的规则为止”,当然,如果是,那么匹配速度是跟规则数量有关系。不过专业的放火墙厂家,一般都不会这么作。这种算法,只能在本科生C语言课程的练习题中找到其身影:)

    至于960G的switch fabric,我认为夸大宣传的可能性很大,因为这个防火墙的有两个10G接口,根本用不到这么大交换容量。至于这个交换容量怎么计算出来的,只有他们自己才知道。如果你是用户,就不要理会这个指标,只看处理能力,对防火墙来说,最考验其性能的指标也许是256字节的小包,而不是64B。关注这个指标,多加一些应用检测规则,比如P2P检测等。

    一般来说,多核CPU更适合防火墙,当然,也有用FPGA+X86的,也有用NP+X86的,FPGA和NP的作用就是作流分类,X86的作用是作应用检测。

    我很早就注意到了hillstone这个厂商,他们的宣传指标一般不作假,都是测试结果,包扩这个产品的指标,看起似乎也没有很多水分。他们市场工作做的也不错,上面那个像上烧饼一样的市场宣传图片花的就很好看:)

    唉,不过无论怎么说,都是还是一个小厂商,投资小,资源不足,积累也不多,从其产品上可见一般。如果在国内市场跟华赛硬拼,恐怕占不到什么优势。

  49. wh1oo 于 2009-09-27 7:21 上午

    楼上确实分析的很有道理。
    上面有人说防火墙是基于Session的,这话不假。而且如果有了TCAM之后5000条Rule确实性能没有影响,据说也能到达一个指令周期返回索引,但是如果是分布式的,线卡上面做流分类,那么所有报分仍然要全部查找所有的Rule.流程上的问题。因为,你不可能把所有的Session搞到TCAM里面,成本问题。所以如果在线卡上面分流的话,那么就不会有那种报文只查一次TCAM,但是如果都走到了FW处理流程那么肯定是先查会话了~~

  50. kk 于 2009-09-27 7:44 上午

    至于上面评论中提到的线性算法,不知道是不是指“受到报文之后,从第一条规则开始批配,直到找到一条能够批类的规则为止”,当然,如果是,那么匹配速度是跟规则数量有关系。不过专业的放火墙厂家,一般都不会这么作。这种算法,只能在本科生C语言课程的练习题中找到其身影:)
    ———————-
    建session之前,首包不遍历policy你能怎么处理呢,你能否举个例子?按照你的说法,那netfilter不过是本科生作业的作品了,国外的W,F,国内的T,L,A都是本科生的作品喽?

  51. kk 于 2009-09-27 7:48 上午

    我很早就注意到了hillstone这个厂商,他们的宣传指标一般不作假,都是测试结果,包扩这个产品的指标,看起似乎也没有很多水分。他们市场工作做的也不错,上面那个像上烧饼一样的市场宣传图片花的就很好看:)
    ———————
    我不知道你是否经常写ppt,写好ppt的一个重要要素就是配色和配图,那个大饼图用ps和word做出来算是PM的基本功了,你看看T、L、A的宣传手册,这样的图太普遍了

  52. 陈怀临 于 2009-09-27 7:57 上午

    感觉山石的产品将会是我大宋长城防火墙的得力干将。。。SSL的session都要被整一整。我大宋复兴有望呀。长城防火墙千秋万代!

  53. kk 于 2009-09-27 8:01 上午

    算了吧,我就来举个例子,黄岩你给我解释下下面这些policy,你怎么建session及相应状态:

    policy1, sip , other condition, 地址组(1.1.1.1 – 1.1.1.2) accept
    policy2, dip , other condition, 地址组(3.3.3.3 – 4.4.4.4) drop
    …..
    policy19999,nexthop < 122 , other condition, sip (1.1.1.1 – 1.1.1.2) dip 地址组 (222.222.222.222,121.1.1.1,133.3.3.3, 253.223.223.223) 认证

    你现在来了一个tcp syn,其符合19999条 policy,你如何跳过前面的那些规则找到该条规则,不要告诉我你就整了一堆hash表哦?

  54. kk 于 2009-09-27 8:36 上午

    唉,不过无论怎么说,都是还是一个小厂商,投资小,资源不足,积累也不多,从其产品上可见一般。如果在国内市场跟华赛硬拼,恐怕占不到什么优势。
    ————
    说实话,HS/H3在FW领域无论是技术还是市场连前三名都进不去,HILLSTONE也许从来就没把HS当成对手

  55. 陈怀临 于 2009-09-27 8:40 上午

    黄岩弟,Hillstone的背景有点复杂。要看看。。。

  56. kk 于 2009-09-27 8:44 上午

    to 老韩:
    我知道几款绝对主流产品,但实在是不方便公开说,

  57. kk 于 2009-09-27 8:46 上午

    老韩,我的email: abc27865121@126.com

  58. 老韩 于 2009-09-27 8:49 上午

    怎么感觉越来越复杂了……

  59. 陈怀临 于 2009-09-27 8:52 上午

    kk,你别吓人,好不好。你是3K,还是2K?

  60. wh1oo 于 2009-09-27 8:53 上午

    唉,不过无论怎么说,都是还是一个小厂商,投资小,资源不足,积累也不多,从其产品上可见一般。如果在国内市场跟华赛硬拼,恐怕占不到什么优势。
    ————
    说实话,HS/H3在FW领域无论是技术还是市场连前三名都进不去,HILLSTONE也许从来就没把HS当成对手
    ——-
    说实话,山石可以不把任何人当做对手。每个行业,在每个国家的每个用户的群体里面运行是不一样的。特别是在中国~~
    北电个人认为技术相当出色!结果呢?仅仅得到的是尊重。
    H3和HS都有自己优势和劣势。
    请KK把国内的几个厂商的市场份额公布一下好吗?让我们也见识见识前三都是谁。翘首啊~~

  61. kk 于 2009-09-27 8:59 上午

    请KK把国内的几个厂商的市场份额公布一下好吗?
    ———————-
    我没指明国内吧?

  62. kk 于 2009-09-27 9:00 上午

    # 陈怀临 于 2009-09-27 8:52 am

    kk,你别吓人,好不好。你是3K,还是2K?
    ——————–
    首席,我……我也是睡不着,就技术论技术了,就是产品论产品了

  63. kk 于 2009-09-27 9:03 上午

    说实话,山石可以不把任何人当做对手。每个行业,在每个国家的每个用户的群体里面运行是不一样的。特别是在中国~~
    北电个人认为技术相当出色!结果呢?仅仅得到的是尊重。
    H3和HS都有自己优势和劣势。
    ————————
    也没有啦,我就随口一说啦,呵呵,我觉得juniper,fortinet,checkpoint等都可以成为hillstone的目标啊,为什么只提hs呢,想让大家不要忘记了还有这些公司哈,呵呵。

    另外hs的产品也随着hw的方案行销全球,也算是国际厂商了,又为什么把hs定位在国内市场呢?有些糊涂。

  64. 陈怀临 于 2009-09-27 9:25 上午

    华赛的优势是其母公司的市场。。。

  65. kk 于 2009-09-27 9:27 上午

    # 陈怀临 于 2009-09-27 9:25 am

    华赛的优势是其母公司的市场。。。
    ———————-
    去年欧洲军团的白送,某老大还要亲自拜访客户

  66. 李克 于 2009-09-27 12:53 下午

    对于VIP客户,有多少供应商想送进去?求着别人送进去都不行,这些大客户主要看产品和vendor的真正实力,实力不够,倒给钱都不让进,能送进去也不算丢人,并且老板还要赏你呢,当然,这只限于市场开拓期,如果你成了业界前三,还白送,如果不是特殊情况,老板肯定把你给炒了

  67. 李克 于 2009-09-27 1:05 下午

    不同类型的测试结果肯定是不同的,最恐怖的是你的竞争对手买了你的产品,拿回去测试,那才是真正的往死里测,对敌人总是最很的嘛:)至于其他类型的测试,过得去就可以了,不必较真

  68. KK 于 2009-09-27 4:58 下午

    哈哈,白送还有理?送不出去还会被开了,好吓人哦。JCF会白送?

  69. wahaha 于 2009-09-27 5:57 下午

    JCF不一定会白送,但是Ericsson拿着J的router放到自己的GSM扩容方案里,然后就白送给人家。

  70. wahaha 于 2009-09-27 6:01 下午

    kk 于 2009-09-27 1:50 am
    按照我目前的认知能力,我觉得在正常情况下(不包括那种做了手脚的和特殊硬件FW),软件FW给它设置5000条policy和1条policy还是有关系的吧,为什么没关系呢,能否给我们讲一下基本原理?谢谢
    ———————–
    测试性能的时候基本就是UDP打一个流,等到稳定的时候出性能指标,这个时候早就过了查找policy的阶段了,具体的测试方法老韩可以说说。

  71. wahaha 于 2009-09-27 6:06 下午

    李克 于 2009-09-27 2:01 am
    1%本身不是目的,主要是其背后的设计架构,如果是随机的,那么为什么会随机?如果是有规律的,为什么是这个规律?做过产品系统维护的会知道,这背后都是不好说的秘密:)并且一些大客户是真的会问的
    ———————-
    我的意思是这个是测试过程中的随机,随便一个性能的测试,不管被测仪器和测试仪器是谁家的,稳定的时候曲线也是有一定的波动的。3%以上的差别肯定不是误差,但是1%以内的一般可以忽略。

  72. kk 于 2009-09-27 6:15 下午

    # wahaha 于 2009-09-27 5:57 pm

    JCF不一定会白送,但是Ericsson拿着J的router放到自己的GSM扩容方案里,然后就白送给人家。
    ——————————-
    哦,路由器方面的市场不懂啊,防火墙这么做的真的很少听说 ^_^

    测试性能的时候基本就是UDP打一个流,等到稳定的时候出性能指标,这个时候早就过了查找policy的阶段了,具体的测试方法老韩可以说说。
    ——————————–
    恩,谢谢,我本意是想讨论新建连接兼吞吐的,论题没看清,导致我们讨论的不是同一个问题,sorry。

  73. 清华土著 于 2009-09-27 7:10 下午

    关于新建连接的问题:
    ×讨论TCAM没有任何意义,对于multi-core的架构下,软件算法足够解决问题。HiCuts/HyperCuts做到M级pps的packet classification,基本不是问题。
    ×软件算法通常具备O(logN)的性能,因此无论规则多少,memory access变化不大。
    ×如果流的个数很少,那么大多数查找过程中遍历的数据结构将被有效cache在L2中,因此分类速度极快。
    ×新建连接的速率,很可能不再classification这里,而更多的是建立session entry本身的消耗。

    关于throughput:
    ×若采用linux架构,无法避软硬中断等硬伤,因此pps会受到软件架构制约,小包跑3Gbps应是cavium38xx极限。
    ×若采用SE stand-alone,那么小包跑8G会很轻松。因为SE程序采用polling而非中断来get work
    ×对于此类中端设备,最可能和最方便的实现是采用linux+SE-usermode方式。 linux能够提供良好的处理架构,解决相当多管理层面的问题,同时利用SE-usermode作为fast-path加速。

    还是很好奇,如果看了芯片型号就有性能功能预期,那软件架构师是做什么用的?

    请达人解惑。

  74. kk 于 2009-09-27 7:38 下午

    恩,以后不来弯曲了…….牛人太多,自觉汗颜!嘿嘿!

  75. Panabit 于 2009-09-27 8:22 下午

    清华土著说得很好。不过Linux + SE不是最好的方式,还有纯Linux的方式,性能同样可以达到SE的性能。如果采用SE来做FAST PATH,那么很多GDB方面的特性就需要自己实现,这个工作没有必要重新做一遍。另外在内存SHARE方面也不是那么方便。

  76. 陈怀临 于 2009-09-27 8:44 下午

    2K,别灰心。不过这个清华土著好像是比较狠。感觉有点厉害。。。他的评论也是让我倒吸几口凉气。。。

  77. 老韩 于 2009-09-27 10:38 下午

    讨论慢慢开始有点意思了,期待更多吗猛人出现

  78. 无名 于 2009-09-27 11:31 下午

    山石整天吹嘘性能,64B的性能真的太低了,对不起这么高的处理器呀,我们都可以实现64B 8Gbps的转发性能!

  79. abc 于 2009-09-28 1:21 上午

    http://www.yqdown.com/wangluojishu/luyoujiaohuan/9146.htm
    Fortinet收购Woven高端系列增添交换功能
    ——————-
    增加交换容量和背板带宽???

  80. 大雁之行 于 2009-09-28 1:29 上午

    清华土著说到点子上了,对中小公司或中端产品,linux+SE-usermode已经是足够灵活,开发成本相对较低的一种方式。但是usermode带来于linux协议栈交互的性能开销,这得看设计者的选择了。

  81. 帅云霓 于 2009-09-28 1:56 上午

    78F,你们用的是RMI那个处理器?

  82. 老韩 于 2009-09-28 2:03 上午

    我现在都收不到Fortinet的新闻稿了,混成这样……真可悲

  83. vpn 于 2009-09-28 2:51 上午

    to 78楼无名
    你们是用的什么架构?
    如果单纯是一个OCTEON的16核处理器,那你们可牛大发了?750M*16/(8*1.448)M = 1035 cycle,你们的处理都做了什么工作,呵呵?

  84. aaa 于 2009-09-28 4:42 上午

    to 78楼无名
    你们是用的什么架构?
    如果单纯是一个OCTEON的16核处理器,那你们可牛大发了?750M*16/(8*1.448)M = 1035 cycle,你们的处理都做了什么工作,呵呵?

    答案在这里:
    《《测试性能的时候基本就是UDP打一个流,等到稳定的时候出性能指标,这个时候早就过了查找policy的阶段了,具体的测试方法老韩可以说说。》》

    进来的数据包简单转发一下,1000多个cycle足够了吧。要是每个包都做重组,内容过滤,那就不知道了。

  85. 黄岩 于 2009-09-28 6:04 上午

    此帖比火:)

    to kk, Linux的iptables实现,目标不是专业防火墙设备。国内安全市场比较混乱,的确很多杂牌厂家会Linux的iptables加上自己实现的web界面冒充专业防火墙设备。但最近几年这样场上越来越少了,混不下去了:)

    这样一些类防火墙的专用设备,也许能够满足一些局部市场的特殊需求,比如:可以检测出某种国内的专用的股票软件的报文。但很难成为主流。另外,一些家用的wireless router,可能也是这么用的,不关心性能。

  86. 帅云霓 于 2009-09-28 6:21 上午

    用RMI的8Core 32Thread,1GHz,也可以做到小包8Gbps。当然是打UDP稳定以后的数据。业务的话只能做NAT。其他分片、深度检测等一概不支持。
    实际上Octeon的16Core性能和RMI的32 Thread应该差不多。据说现在RMI出了1.5GHz的。性能应该又增加不少。

  87. 帅云霓 于 2009-09-28 6:23 上午

    还是很好奇,如果看了芯片型号就有性能功能预期,那软件架构师是做什么用的?

    显然,软件架构师是让系统做出来真正能达到这个预期的:—)
    这么说吧,如果是个我这样水平的人软件架构师,那什么性能功能预期都是白扯,系统能跑起来就谢天谢地了,哈哈哈哈。

  88. kk 于 2009-09-28 7:10 上午

    to黄岩
    Linux的iptables实现,目标不是专业防火墙设备。国内安全市场比较混乱,的确很多杂牌厂家会Linux的iptables加上自己实现的web界面冒充专业防火墙设备。但最近几年这样场上越来越少了,混不下去了:)
    ——————————-
    既然你没见过,那我和你争也没用,目前防火墙牛B厂商无非cisco,juniper,fortinet,checkpoint,watchguard等,其中就有netfilter优化的,如果你认为他们中某些是杂牌厂商,那我无话可说。

    这样一些类防火墙的专用设备,也许能够满足一些局部市场的特殊需求,比如:可以检测出某种国内的专用的股票软件的报文。但很难成为主流。另外,一些家用的wireless router,可能也是这么用的,不关心性能。
    ————————————–
    这些话我觉得有些好笑,更不用提股票了,CPU和ASIC结合用,首包走CPU,netfilter建session,后续报文走ASIC的用法还是很多的,优化改善netfilter多的很。

    我觉得不应该在不了解的情况下贬低另一种实现方式。

    PS:有空把我前面那个首包查找策略的算法,也就是你所称之为本科生习题的问题给大家讲讲

  89. 老韩 于 2009-09-28 7:21 上午

    我比较关心XLR732做FW小包到8G的情况,在真正销售的产品中可能出现么?

  90. 清华土著 于 2009-09-28 8:02 上午

    To 大雁之行:对中小公司或中端产品,linux+SE-usermode已经是足够灵活,开发成本相对较低的一种方式。但是usermode带来于linux协议栈交互的性能开销,这得看设计者的选择了。
    // 对高端,L2~L4用SE-stand-alone, SE-usermode仅仅负责SE-linux通信和shared-memory管理。。。诚然,这是为了高端:)如您所说,设计选择很重要,需要远见卓识。

    To 帅云霓:用RMI的8Core 32Thread,1GHz,也可以做到小包8Gbps。当然是打UDP稳定以后的数据。业务的话只能做NAT。其他分片、深度检测等一概不支持。实际上Octeon的16Core性能和RMI的32 Thread应该差不多。据说现在RMI出了1.5GHz的。性能应该又增加不少。
    // 这样的讨论有意义,谢谢指教!

    To 老韩:我比较关心XLR732做FW小包到8G的情况,在真正销售的产品中可能出现么?
    // 我了解到的,还没有,或许不是做不到,而是没有必要。

    To 老韩:讨论慢慢开始有点意思了,期待更多吗猛人出现
    // 猛人一般只看热闹,估计不会出来说话。Hillstone, huawei, juniper的高手们或许都看我们帖子乐呢。不过无妨,虚心向学,探索真理,这或许时弯曲存在的目的吧。相信我们自己,国人可以做出出色的东西!

  91. 老韩 于 2009-09-28 9:27 上午

    To 清华土著:希望你走之前有机会聊聊,我已通过管道找你了。

  92. 清华土著 于 2009-09-28 9:52 上午

    管道? 厉害!
    清华土著不是一个人,玩的不是寂寞,欢迎来访:)

  93. 老韩 于 2009-09-28 9:58 上午

    倾慕已久,我看的第一篇hillstone产品测试报告就是你做的。

  94. 清华土著 于 2009-09-28 10:06 上午

    作为第三方测试,我遵循的原则和你一样,客观公正,结果完全可以复现。很看好hillstone的技术,希望更多的这样企业能成长在中国!

  95. 陈怀临 于 2009-09-28 10:21 上午

    你们可真逗。清华小土著还是一个团队了。。。
    小韩,你别把人家吓着了。你这种80后,。。。要注意点:–)

  96. 李克 于 2009-09-28 10:23 上午

    一等高手会说能做,二等高手能做不说,三等低手会说不做,四等低手不说不做

  97. 老韩 于 2009-09-28 10:25 上午

    有了弯曲评论,IT圈变小了很多,建议弯曲团队直接上线SNS,考虑怎么赚钱吧……
    从媒体角度看,弯曲评论是一潜在竞争对手啊……我已打入敌人内部了

  98. 陈怀临 于 2009-09-28 10:29 上午

    小韩,我如果发达了,第一个就是把你挖角过来。
    BTW,别太熬夜,要注意身体。。。

  99. 陈怀临 于 2009-09-28 1:41 下午

    思科,Juniper,A-L都与我联系,希望能在弯曲评论投放广告。但在强烈的爱国主义情怀下,我都义正言辞的痛斥他们。。。。。。

    我目前只考虑中国的企业投放广告:-)。希望尽快联系。目前排队很长。。。。。。

  100. 帅云霓 于 2009-09-28 4:51 下午

    To 老韩:告诉我你的E-mail,我私下跟你说:)

  101. KK 于 2009-09-28 5:04 下午

    靠,原来这里都是一帮吹水高级架构师啊?牛逼

  102. lte 于 2009-09-28 5:32 下午

    TO vpn:
    我们的确使用Octeon处理器,用的是SE架构,诚如清华土著所说SE实现64B 8Gbps 很轻松。 32K routes,1 Million flows 8个Core 就可以达到10.5Gbps

  103. billy 于 2009-09-28 5:36 下午

    陈怀临:
    思科,Juniper,A-L都与我联系,希望能在弯曲评论投放广告。但在强烈的爱国主义情怀下,我都义正言辞的痛斥他们。。。。。。
    我目前只考虑中国的企业投放广告:-)。希望尽快联系。目前排队很长。。。。。。

    队伍不好带…

  104. droplet 于 2009-09-28 7:40 下午

    SE-usermode是什么东西,没听说过,能不能扫扫盲?
    kernel mode写程序比较麻烦一点,可用的资源太少了,usermode可以有很多东西用,copy-paste起来也方便。
    Usermode直接access driver,这个应该能做到吧。

  105. 老韩 于 2009-09-28 8:14 下午

    我的E-mail是
    han_xu$ccw.com.西恩
    欢迎赐教

  106. wahaha 于 2009-09-28 8:59 下午

    lte 于 2009-09-28 5:32 pm
    TO vpn:
    我们的确使用Octeon处理器,用的是SE架构,诚如清华土著所说SE实现64B 8Gbps 很轻松。 32K routes,1 Million flows 8个Core 就可以达到10.5Gbps
    ——————-
    1000cycle如果只是做做hash查找改个包就扔出去是够了,但是总要做计数吧,在多核系统上多加几个个计数器,在加上各种没有配置的功能(AV、reassemble啥的)也要判断一下才能略过,1000个cycle感觉比较难。

  107. ilovebgp4 于 2009-09-28 9:00 下午

    很感兴趣104楼提出的问题,有没有高手解答一下?

  108. 帅云霓 于 2009-09-28 9:08 下午

    104楼的问题我也想知道,觉得可能会被piss off,就先问了Google,Google说了一堆没用的

  109. aaa 于 2009-09-29 7:08 下午

    放个板凳

  110. 陈怀临 于 2009-09-29 7:46 下午

    我也没听说过SE这个术语。当然,不是网络安全这个圈子的,估计不懂。我猜说的是:Session Engine或者Security Engine。我想说的估计是工业界常说的术语flow。如果我的猜想正确的话,清华土著的意思是flow做在user mode下。。。。

    清华土著好像是清华象牙塔的精英。。。

  111. Panabit 于 2009-09-29 9:52 下午

    他这个SE我估计是Simple Executive,就是Cavium开发包中强调的一种软件运行模式,一个概念而已。用SE模式,实际上就是一个没有任何操作系统干预的FAST PATH模式。

  112. 陈怀临 于 2009-09-30 6:40 上午

    谢谢Panabit。换言之usermode或者system call开放了,没有任何overhead了。清华土著,为何打一枪就消失了?

  113. 李克 于 2009-09-30 7:19 上午

    Simple Executive这种模式把多核CPU做NP用,代码全部在内核中,还有部分数据,不存在指令cache命中的问题,数据也基本没有这个问题。在实际产品设计时是有用的,比如把几个核只做SE,做告诉转发处理,其他核做复杂业务计算处理,比如在安全产品中,用部分核做首N包建流,其他核专做转发,这样的架构可能比大家都执行相同的功能性能要高,因为普通CPU模式下,任务切换和缓存命中,会浪费CPU的很多性能,这和生产流水线与个人小作坊的工作模式比较是类似的

  114. droplet 于 2009-09-30 5:06 下午

    一般multicore编程,都是pipeline和parallel共用的,没有一个单纯的用pipeline和parallel的。piple太长,消息传递的代价都太多,但是如果都是parallel,每个线程又太复杂。结合起来用,最好。

  115. 阿来 于 2009-09-30 5:19 下午

    一直都很佩服这种充满了梦想和激情的公司。通信领域一直都是一个创造了奇迹,并且一直不断创造着奇迹的地方,这也是毕业的时候选择了这个行业的原因。

  116. Harry 于 2009-09-30 11:31 下午

    完全是耸人听闻,SSL攻击时,客户端怎么会没有提示?除非能够拿到每个HTTPS服务器的private key。

    所以,SSL是绝对安全的

  117. 幸福感幸福 于 2009-10-09 11:01 上午

    协议本身并没有漏洞,因此浏览器的安全设计和用户的安全意识就成了最受考验的部分。第三类攻击要生成不合法的证书,当今的浏览器在遇到该类证书时都会提示错误,但信息的表达方式各不相同,误导用户接受非法证书也时常发生。绳子又勒紧了一些,但对我不好使

  118. 真奇怪 于 2009-10-22 2:12 上午

    讨论防火墙,居然没有人提到天融信和网御,国内防火墙市场好像他们才是大佬吧。

  119. 宝界李想 于 2009-10-30 7:25 上午

    山石也能跟华为比?如果你去参观过华为,我觉得你就不会这么说了

  120. CNJ 于 2009-10-30 6:50 下午

    “如果你去参观过华为,我觉得你就不会这么说了”

    这个说法很有意思。是指华为的楼多,壮观,还是人多,高手如云,还是。。。?因为不是华为的人很难进去,非常向往哪天能开放参观。

  121. 陈怀临 于 2009-10-30 8:18 下午

    目前的山石与华为没有什么交集。与华赛有一点点。但目前都没有正面交锋。。。

  122. ilovebgp4 于 2009-12-19 8:40 上午

    to 113楼李克

    多谢讲解,另外还想问一下SE模式是不是对平台依赖性太强而不好移植到新平台上?

  123. 理客 于 2009-12-19 8:55 上午

    to ilovebgp4,是有移植的问题,当然多核CPU都支持C编程,这种情况下移植会比较容易,但对于用于高速转发的核,一般还是用汇编效率更高,在做性能优化时直接做基于指令级的优化,对于高速处理,比如10G,提高10%就是1G。汇编中大多数指令都可以移植,但具体到一些寄存器的和专用指令使用,就有些麻烦了,也许开发一个这个级别的软件平台工具会有一定的市场,只是在使用这种汇编编程的公司,都是大公司,人力资源支撑比较充分,所以不太考虑这个问题

  124. ilovebgp4 于 2009-12-19 9:14 下午

    多谢理客

  125. ABCDE 于 2009-12-25 5:43 下午

    高手如云,围观中