理性看待下一代防火墙

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




志不强者智不达。自从2009年Gartner定义下一代防火墙至今,国内外业界风起云涌,竞相角逐。但是下一代防火墙成为众家“香饽饽”之时,便可能成为跟风者邯郸学步之日。滚动着泡沫的一汪沸水,你能否看到水底蕴藏的那潜在力量?

相关阅读:

解惑下一代防火墙——《网络世界》下一代防火墙产品测试分析报告

2007年,Palo Alto Networks发布世界第一款下一代防火墙产品。此后,国际网络行业领导厂商诸如 Barracuda Networks、Cisco、Check Point、Dell SonicWALL、Fortinet、Juniper Networks等等公司也相继推出下一代防火墙。国内厂商自然不甘落后,2011年深信服发布中国第一款F代防火墙伊始,拉开了中国厂商开启下一代防火墙模式的序幕。一年来,国内厂商宣布推出“下一代”单品的已有迪普、东软、锐捷、深信服、天融信、网康、网神等。越来越多的厂商注意到了将设备与云相结合,使用云计算的优势来进一步提升下一代防火墙在未知威胁防护上的处理效能,但是在硬件设备方面却鲜见有亮点的升级,加之中国大部分厂商都只是今年才推出第一代NGFW产品,所谓有亮点的产品升级更新更无从谈起。诚然,下一代防火墙已经逐渐被市场所接受、认同,但这是否是因为夸大的市场宣传而“被接受”了呢?

从一年前的凤毛麟角到如今的满城尽是“下一代”,网络安全新产品的蓬勃发展是我们愿意看到的,但如果是厂商为了迎合“下一代”风潮而削足适履,这是我们不愿意看到的。当然,我们更不愿意见到的是无休止的炒作掩盖了产品的真正价值。

新技术应对新挑战

通过对多家安全厂商的走访,记者发现大家不约而同地指出网络活动急剧增加,也日趋复杂,安全攻击出现多样性,云计算、移动互联网、BYOD、Web 2.0等成为了新时代的网络安全挑战。

Web2.0时代带来爆炸式的应用增长,对传统防火墙造成了极大的挑战。在各式各样的Web应用潇洒地通过80端口时,基于“五元组”的传统防火墙无异于被蒙上双眼的士兵,不再能很好地守护网络的安全。

此外, APT攻击近年来分外活跃。Stuxnet病毒不仅使伊朗核计划遭到重创,也拉开了工控系统入侵的序幕。长久以来,工控系统被认为并不会受普通电脑病毒的影响。随着这一想法被颠覆,更多的网络攻击将会瞄准工控系统和物联网。在网关处,更深度的数据包检测、病毒入侵防护,以及工控系统协议的支持等需求也变得越来越迫切。

在谈及如何应对新时代带来的新挑战时,锐捷网络安全产品线经理王福光说:“云计算等新技术应用的发展,带来了三个方面的转化,即数据集中化;应用复杂化;边界多元化。数据的上收让云计算核心的数据中心承担着巨大的安全压力与挑战。如何在保障安全的同时满足高速、无瓶颈的性能要求,也成为了防火墙的基础要求。”

Check Point安全顾问吴航在采访中也表示,APT(高级可持续性威胁)攻击在近两年也愈演愈烈,Stuxnet病毒对于工控系统和物联网的影响已经改变了业界关于安全的观点,很多大的企业已经意识到威胁的形式发生着巨大的改变。因此对更加高效、多功能的网关防护设备的需求程度也在不断提高。

通过研究Gartner和NSS Labs对于下一代防火墙的定义发现,作为一个整合深度数据流检测、应用安全识别,以及攻击防护的安全平台,必须要具备传统企业级防火墙的全部功能。比如基础的包过滤、多层状态检测、NAT,以及面对一切网络流量时保持高稳定性和可用性。在此之上,下一代防火墙还必须要具备应用识别和控制、用户及用户组控制、完整的IPS功能、灵活的功能扩展选择和外在信息源。其实还有一点,也是业界一直在宣传的,在开启多个功能,甚至是全功能时,性能下降不明显,这也是区分UTM与NGFW的一个显著标志。

“下一代”不仅仅代表了多功能、高性能,更是对于传统设备软件和硬件技术的革新。对此观点,我们也独家连线了美国网络世界安全频道资深编辑Ellen Messmer。Ellen认为,下一代防火墙对于传统基于端口检测的防火墙来说是革命性的改变,它打破了以往UTM简单将各功能模块串联起来的基础架构模式。

对于设计架构方面,下一代防火墙从基础架构上解决了多功能开启时UTM性能急剧低下的问题。Palo Alto通过独家设计的单通道并行处理架构,紧密结合了软件与硬件,简化了管理工作,也提供了一个流畅的运行程序与最佳性能。这个架构的卓越之处在于,当数据流通过时,软件通过一次性的策略查找、应用程序的识别和解码、用户的识别,以及内容扫描(病毒,木马,入侵防护),而硬件平台使用特殊功能的处理器执行联网、安全、威胁防护与管理,使整个设备达到最大的性能与最小的延迟。因此,基础架构的革新决定了下一代防火墙能够解决UTM性能瓶颈的问题。

经过一段时期的发展,不论是防火墙市场的老牌劲旅,还是创建没几年的新兴公司都纷至沓来,推出下一代防火墙,欲求在市场中分一杯羹。通过对多家安全厂商的走访和产品调查,我们发现目前市场上普遍的下一代防火墙设计架构都趋向于单通道并行处理的一次拆分包技术。但是在实际的应用层处理性能、深度病毒检测性能等方面,国内产品与国际领先厂商的产品尚有一定差距,还需要提升自身技术实力,同时进一步接受市场的考验。

近两年,厂商和媒体的大力宣传,防火墙市场表现出蓬勃发展、百舸争流的态势,而下一代防火墙也被宣传成了一款“万金油”产品。然而我们是否需要冷静一下,还原一个真实的下一代防火墙呢?

新思维引领“下一代”

不论是对于产品还是概念的讨论,业界都有很多不同的声音。著名安全评测实验室NSS Labs在近期发表的评测报告中,对下一代防火墙表示出了担忧。报告中指出,当与传统防火墙和IPS的组合比较时,大部分的下一代防火墙解决方案不能提供很好的处理性能和安全性。研究人员认为,只有少数的NGFW产品能够符合当下的安全需求。在通过对八款下一代防火墙,或者是号称为下一代防火墙的产品测试过后,结果显示,只有一半的NGFW产品其安全性能评分达到90%以上,而且厂商对其产品处理性能的夸大也值得注意。八款产品中的五款产品吞吐量未能达到厂商所声称的数据,而全部八款产品的最大连接数测试均低于宣传数值。虽然我们并未能对国内更多的NGFW产品进行全面的测试,但是对于产品实际表现与性能的担忧也应该存在。

“我们的思维模式需要转变。下一代防火墙不应只是一个产品,更应该代表一种前瞻性的眼光。”天融信高级副总裁刘辉说。作为下一代防火墙的“异见”代表,他还认为,互联网飞速发展,如果安全厂商没有远见,不能看到“下一代”的安全需求,只是做到亦步亦趋,终将只能在市场竞争中扮演配角。对此,Gartner才用前瞻性和执行力作为其魔力象限的两个维度来衡量一个领域厂商的水平。如果只是把单一的产品称之为下一代,会对产品的发展产生不利的影响。下一代防火墙需要更智能,结合云计算充分发掘大数据的价值,通过对互联网中的海量数据(包括防火墙日志)进行数据挖掘和分析,将防火墙与整个体系深度结合,使防火墙更加智能、灵活,从而对防火墙下发更加准确的策略。对于网络防护设备来说,其主要功能还是网络层和传输层。因此,随着SDN成为网络发展趋势,作为更智能、更灵活的下一代防火墙也需要适应下一代网络的发展,对于SDN的支持可谓必不可少。

在对于网络安全未来的看法上,思科高级安全顾问徐洪涛认为,传统意义的网络边界已经越来越模糊,给网络安全也带来了新的挑战。因此,防火墙技术也必须随之做出改变。云计算技术的发展,需要安全平台更好地去识别最新的网络威胁。移动互联网和智能终端的发展,需要安全平台更好地去识别用户身份和终端。而新应用的出现,则需要安全平台去更好地识别新的应用。只有这样,才能真正地起到防火墙安全防护和控制的作用。保证网络安全的前提是对网络的终端和使用有全面的可见性,并且能提供足够的控制能力。全网可见性的提高和可控性的增强,目前来看已经成为用户做网络安全建设的核心思想。在未来的一年中,网络安全市场也将会以此为主导,专用安全产品的授权因素需要丰富,而大量部署的网络设备的安全特性与识别功能也会得到更多的使用。网络安全技术本身会更加全面和动态,而网络安全技术与网络技术的结合也将会更为明显。

对于下一代防火墙的看法,我们或许真的应该突破盒子本身。硬件设备须与云平台进行整合,基于云的分布式计算环境不仅可以提升识别效率,还能有效地降低硬件部署成本。Gartner也提到,对于延时敏感的企业建议使用下一代防火墙。已知威胁的处理效率会对网络出口产生延迟影响。而对于未知威胁的检测效率和准确度不够,也应算作延时的一种。对于已知威胁的扫描、检测、隔离并不是竞争的重点,通过有效的手段进行高速的未知威胁识别才是未来竞争的主战场。高效而准确的识别未知威胁,才能真正保护网络的安全。

未知威胁的识别必须依托背后强大的云平台。Palo Alto的Wild Fire(野火)安全平台,基于云计算,有效地解决了未知恶意软件威胁。一小时之内,野火会返回对于一个新发现的恶意软件的识别报告,并自动下发给防火墙。这一切都是由云自动完成的。而一年前,这件事还需要一天的时间来完成。网康科技营销副总裁左英男说:“下一代防火墙将不再是孤立的硬件产品,必须依托于强大的外在安全服务来构建实时的安全防护体系。”网康科技的下一代防火墙采用了基于云的URL过滤功能,可以主动扫描预防和在线内容识别,快速发现并识别可疑网站。

前路漫漫 道阻且长

尽管不断变化的威胁环境,以及业务流程使企业在安全系统更新换代时必将考虑下一代防火墙,然而Ellen在承认NGFW带来技术革新的同时,也对市场表示了一定程度上的担忧。他向记者解释道,从整个企业级防火墙市场来说,有这样一种假设,就是在我们当前的网络环境中和我们即将步入的移动互联、云计算时代中,处处都需要下一代防火墙。事实上它很难实现,尤其是对于大型企业来说。企业用户曾明确表示他们不希望将反病毒功能集成在下一代防火墙中,而NGFW中的IPS功能也鲜有人问津。另外,企业客户也不愿意因为适应不必要的下一代防火墙而增加他们现有防火墙策略的复杂度。

传统防火墙和UTM短期之内不会被下一代防火墙完全取代。网神科技产品运营总监陈超认为,我们无须对于一款产品的名字过于纠结,最重要的是能够满足客户的需求和该企业在未来一段时期内的发展,扩容需求。下一代防火墙确实解决了传统防火墙和UTM的种种问题,但是在某些特定领域还是更倾向于保守地选择传统产品。比如对于大型IDC来说,核心需求就是超高速的转发,所以可能需要百G的吞吐。在这种情况下,传统防火墙无疑比下一代防火墙更具竞争力。

对于UTM来说,情况也是如此。东软网络安全营销中心产品策划部部长于江在采访中表示,UTM能够获得如此大的成功,也证明了其满足当前客户对于安全保障的需求。在一些小型企业,对于吞吐和性能的要求并不高,已有的UTM设备已经完全满足日常所需。这也是在下一代防火墙起步初期,产品渗透率不高的原因之一。在未来一到两年内,随着互联网的进一步发展、安全需求更加复杂多样,下一代防火墙的渗透率会有很大的提升。未来几年内,会出现NGFW、传统防火墙、UTM三足鼎立的情况,直至随着设备的自然更替,NGFW完全替代传统防护设备。

对于有意愿引进下一代防火墙的企业来说,只须根据企业网络情况,以及未来发展规划,合理部署下一代防火墙即可保障其在整个网络中的正常使用。不仅可以提升企业网络的安全性,也可以让企业在未来升级网络时更加流畅。深信服市场行销部技术总监殷浩表示,如果原有的传统安全产品处于正常使用周期内,建议只启用下一代防火墙的应用层安全防护功能和原有的产品及方案形成互补。当原有传统安全产品超出正常使用周期,可以启用下一代防火墙的其他安全防护功能进行替换。如果企业需要新建一个网络,则建议直接选择下一代防火墙构建安全防护体系。对于安全要求更高的金融、运营商单位,建议采用两种下一代防火墙品牌进行异构部署。

在本次采访过程中,记者发现各家厂商产品的研发和设计理念有三点是共通的:即易用性、全面可视化和用户需求。这三者即是相互独立,又是相互联系的。在这个越来越强调人机交互的时代,安全产品也需要做到好的用户体验。网络管理人员对于产品熟悉的程度越快,就越能更好、更快地将其发挥到最大功效。全面可视化可以让用户更好地对通过防火墙的流量进行分析。只有获取的信息足够充分,才能做出更为合理的分析、对防火墙部署更有效的策略。产品的设计和研发最终目标是销售给客户,因此产品必须要满足用户的需求。安全威胁每时每刻都在发生、更新,也会随着安全防御技术的发展而变化,互相抑制、互相刺激。作为厂商来说,用户需求的满足不单只是当前需求的满足,更要看到更长远的未来需求。只有这样才能让自己的残酷的市场竞争中立足,最终成为领导行业风向的企业。

非淡泊无以明志,非宁静无以致远。在当今瞬息万变的快餐时代,我们不仅需要接受新事物,迎接新挑战,寻求新突破。也需要我们拥有一颗坚守的心,一份不为世俗所打扰的魄力。网络安全需要你我共建,网络新时代等待我们共创。只要心中有梦想,哪怕山重水复,哪怕道阻且长。

(2个打分, 平均:2.50 / 5)

雁过留声

“理性看待下一代防火墙”有46个回复

  1. 小韩 于 2013-02-26 12:05 上午

    友情支持下

  2. multithread 于 2013-02-26 12:37 下午

    >>硬件设备须与云平台进行整合,基于云的分布式计算环境不仅可以提升识别效率,还能有效地降低硬件部署成本。

    不太认同这一观点。 为了高性能的NGF再用几百台服务器打造一个防火墙专用云平台, 经济上是不合算的。

  3. 随便看看 于 2013-02-27 1:40 上午

    可以由设备厂商或者第三方负责完成基于云的的特征识别,然后定期或实时提供更新,就像很多软件防火墙干的那样,如360,诺顿,windows更新一样

  4. SOSO 于 2013-02-27 7:08 下午

    还能攒的再乱点吗?

  5. softwind 于 2013-02-28 12:26 上午

    multithread ,你孤陋寡闻了吧,,看下这个公司,http://www.commtouch.com/

  6. multithread 于 2013-03-06 11:30 上午

    像这样提供云服务的公司,满大街都是,可能有重大的商业价值。 但不知要我从技术角度上看什么?

  7. softwind 于 2013-03-06 5:14 下午

    multithread,你想从技术上看什么?

  8. multithread 于 2013-03-06 9:19 下午

    If a cluster of firewalls can be implemented in which a sub-partitioning can be licensed separately.

    In theory this idea can easily be implemented in VM. However, what about performance????

  9. softwind 于 2013-03-06 10:52 下午

    multithread, perfect Chinglish!

  10. easy 于 2013-03-11 7:51 下午

    该不是锐捷的软文吧。。。。锐捷在这一块的研发实力可以是最弱的

  11. Ellery Cen 于 2013-03-11 10:27 下午

    您好,并不是哪一家厂商的软文。只是觉得对于锐捷的采访中某句话比较有道理,便摘出来用了。对于其他厂商的态度也是一样的。

  12. softwind 于 2013-03-12 7:25 上午

    不知攻,焉知防——用做家具的理念作乐器,必然无法把握住NGFW的精髓。

  13. multithread 于 2013-03-12 8:21 上午

    什么是NGFW的精髓呢? 我来提第一点:

    1。 要内功强大,能防得住10Gbps小包下的攻击; 否则大的数据中心不会用的;

    2。 You fill the rest …

  14. softwind 于 2013-03-13 12:46 上午

    精髓只有一点:
    识别:
    应用识别,用户识别

    至于性能,这些不是NGFW也会有,这是硬件发展带来的自然结果

  15. softwind 于 2013-03-13 12:47 上午

    还有安全服务能力,安全研究积累,,,这是识别后要做的事

  16. Howtimefly 于 2013-03-13 11:25 上午

    [见云性起的幻觉] “下一代防火墙依托云平台实现内容过滤,主动预防恶意访问” 云上存些什么?云下动态增删?

    [永不过气的趋势] “在不远的几年内,NGFW将替代传统防火墙,UTM等防护设备”巧了!“下一代防火墙”正是我的名字。

    [一进一停的重逢] “下一代防火墙与原有产品方案互补使用,可先启用需要的选项” 意思是说后上的设备先做分析得了。

    [花公家钱的智慧] “关键系统前建议采用两种下一代防火墙品牌进行异构部署” 这个的提法的关隘是”品牌异构”!

    BTW:10Gbps小包线速转发14.88Mpps,要Keep Session的状态防火墙哪能处理这个?

  17. multithread 于 2013-03-17 7:50 上午

    所以国内的厂家要先把“内功”练好,争取做到14.88Mpps的TCP状态处理和跟踪, 再来谈NGFW。

  18. 44491119 于 2013-03-17 9:13 下午

    写得太虚了,你要表达个啥?

  19. 小韩 于 2013-03-19 12:20 上午

    To 17:
    现在国内安全厂商的纯转发性能普遍都不错,单向10G没啥问题,何况还有DPDK。

  20. multithread 于 2013-03-19 10:17 上午

    IP纯转发 L3
    TCP状态处理和跟踪 L4
    DPDK RX/TX (L1/L2)

    If one can process L1 and L2 at 10Gbps, it doesn’t mean it can process TCP at 10Gbps.

    Firewall is at the TCP layer.

  21. Panabit 于 2013-03-19 6:38 下午

    基于状态跟踪,做到10Gbps,很多都可以做到了,这个是小菜,别弄得那么神秘。

  22. sailing 于 2013-03-19 6:59 下午

    Multithread,3年前我用FPGA已经实现你说的这个了,比这个性能好得多,据我所知,国内实现这个需求的也是多年之前的事情。

  23. 新手0 于 2013-03-19 7:59 下午

    请教大家一个问题,当讨论基于状态跟踪的10Gbps的时候,是针对Http等简单应用(跟踪TCP的状态,检查窗口等),还是指SIP/H323等复杂应用(跟踪控制连接和数据连接)?

  24. cdtits 于 2013-03-20 7:23 上午

    貌似说的是64字节小包吧,10G线速?

  25. multithread 于 2013-03-20 4:00 下午

    to #21 and #22:

    Have you tried the number of TCP flows:

    1M, 2M, 4M, and so on …????

  26. Panabit 于 2013-03-20 7:01 下午

    1M以上没有试过,但是测试的时候,是按照设计,要挤满CACHE的,测试的时候,大概100K吧。因为挤满CACHE,所以在访问FLOW的时候,需要至少LOAD两个CACHE LINE。然后再加上其他的,处理一个包总共要TOUCH到4~5个CACHE LINE(快速路径)

  27. 新手2 于 2013-03-20 7:50 下午

    to @panabit:
    如果是两次load,估计后面一个是load flow entry,前面一个应该是存放hash bucket的吧?
    四/五元组本身(hash-key)就占12/16-byte,那么一个cache line放不下几个bucket?
    这是不是就要求hash算法必须能够把10K-flow的hash冲突减少的越小越好?

  28. MLL 于 2013-03-20 9:44 下午

    举报佘浩宇涉嫌拒不执行法院裁定并受贿举报人:范永青。电话:13107314296 举报事由:湖南望城县靖港镇人民政府佘浩宇拒不执行法院裁定、并受贿。主要事实及理由:我与邓尚辉经济纠纷一案,望城县人民法院于2008年4月审理并制作了调解书。调解书规定:邓尚辉在2008年9月12日之前分三次支付我资本金及利息1003437元。(2008望民初字第498号)靖港镇人民政府认可法院裁定书。调解书生效后,邓尚辉仅向我支付10万元。2008年8月,我向望城县人民法院申请强制执行。望城县人民法院向建设工程的发包方靖港镇人民政府发出了协助执行的通知书和裁定书,要求该镇政府只能向我支付资金,在邓尚辉还清对我的债务之前,不得对邓尚辉付款。靖港镇政府签收了该通知书和裁定书,告知了佘浩宇、黄海文,同时没有表示异议。靖港镇人民政府对法院裁定和协助执行通知书视同废纸。靖港镇政府接到法院裁定和通知书后,对法院裁定和协助执行通知书置之不理,仍分三次向邓尚辉支付工程款达235多万元,仅向我付款10万元。2009年1月10日,靖港镇政府再次向邓尚辉支付工程款30余万元。我多次要求靖港镇政府等人停止违法行为,靖港镇政府对我的要求不予理睬。至今,靖港镇政府以各种名义非法向邓尚辉支付工程款250多万元,超过工程款总额的65%。受贿部分:第一,在工程施工过程中,楼房电梯市场价格仅18万元,邓尚辉报价58万元,虚报40万元,电梯房基层钢材数量未达设计数量要求,存在重大安全隐患;第二,建筑工程没有经过公开招标,工程开工时2007年12月开工,开工时没有建设许可证,没有开工许可证,合法证件是在2008年6月份才取得。第三,没有公开招投标,是议标,存在暗箱操作;第四,违反会计管理法,付款没有直接打入建筑公司账户,而是直接付给个人。第五,在跟邓尚辉合作期间,邓尚辉多次在我处要钱去行贿;第六,大楼附属工程总价超过50万元,但靖港镇政府佘浩宇、黄海文不对工程公开招标,不与邓尚辉签订正式书面合同,不做造价预算,迳行委托邓尚辉施工,仅凭邓尚辉的申请付款。第七、在2008年靖港镇古镇综合开发项目3个多亿工程没有公开招标,而是也议标给施工方。第八、在2009年初靖港投资4000多万的船厂大道建设也没有公开招投标以及在靖港今年开工建设的政府大楼也都存在暗箱操作。国家法律规定,国家任何工程项目建设开工都必须公开招投标。种种迹象显示,靖港镇政府佘浩宇、黄海文有行政不作为、渎职和重大经济犯罪行为。佘浩宇作为镇党委书记多次威胁法院执行人员:带领民工冲击法院。靖港镇政府接到法院的裁定和协助执行通知书后,无视法院裁定和通知书的法律效力,公然违背法律对被执行人邓尚辉付款,悖离了司法公平正义,损害了法院的权威和我的合法权益。是对法律的极端藐视,符合《中华人民共和国刑法》第313条的规定,涉嫌构成拒不执行判决裁定罪。佘浩宇作为地方行政领导人与不法商人串通、内外勾结,破坏当地投资环境、谋取私利。佘浩宇以地痞、无赖、流氓的手段来对抗法院,打击外来投资者。佘浩宇狐假虎威:时常拿他认识的上级领导压制、威胁我和他人。佘浩宇蔑视人大,公然说人大算什么,只要我与我们的县委书记关系铁就能摆平一切。公然说你们老百姓告我,我的职位由正科到付处。 佘浩宇、黄海文其行为已涉嫌犯罪。 2009年6月18日

  29. sailing 于 2013-03-20 10:38 下午

    To Multithread. 1千万个连接。当时我记得这个级别的防火墙至少也是5M个连接才能卖吧。

  30. multithread 于 2013-03-21 2:15 上午

    是的, 要求是1千万的连接。

    目前据我所知,用多核能做到处理7-8MPPS的最小包就已经很好了。

    请问一下, session的timeout如何用FPGA来做?

  31. sailing 于 2013-03-21 6:32 下午

    Session单独放到一个单独DDR通路中,FPGA另起一个模块轮询,当然还有一堆乱七八糟的同步方面的细节要做,颇做了一阵。

    Multithread,你怎么那个难问那个,呵呵。下次gtalk聊得了,说来话长。

  32. sailing 于 2013-03-21 7:14 下午

    是Session的Timeout单独放。一个Session要放到不同的DDR通路中。

  33. multithread 于 2013-03-22 1:45 下午

    “狗熊所见略同“。在多核上,我们也用另外一个线程作轮询。但发现有个难点:

    轮询的频率不好掌握,太快了session进程的cache locality就被破坏了!你的实现大概没有用到CACHE:-(
    越做越觉得能把TCP搞定就很不容易了。

  34. Panabit 于 2013-03-22 4:40 下午

    在实际中那么多SESSION的情况下,就要假定CACHE基本上不起作用,所以cache locality不必要考虑太多。

  35. sailing 于 2013-03-23 12:36 上午

    估计Multithread考虑的是轮询Timeout时,对Cache的污染。轮询太快,估计和把Cache做一个全面的Invalidate操作也相差不了多少了。

    实际上最好是Cache有个QoS参数,为不同种类的进程提供不同的服务。Haswell中有这些考虑,貌似网上依然公开这些东西。

    只是x86依然不是为网络量身定制的,不要迷信DPDK,这个东西没有考虑到的,网络上的实际问题稍微多了点。我司的几个哥们看了几眼,和我嘿嘿了几声,就没有下文了。

    我一直认为10GE以上的网络报文的处理,在不过于关注价格时,目前就是x86+FPGA方案,不太看好一些公司的Multicore。

    对这些东西提不起兴趣已经有好多年了。

  36. Panabit 于 2013-03-23 12:48 上午

    有个问题我一直没想明白,FPGA里访问内存,和CPU里访问内存到底有什么性能上的差别。CPU里访问内存,还多了一个CACHE的可能性,在多核里,我将一个或者多个CORE当做FPGA的CORE,有何不可?

  37. multithread 于 2013-03-23 7:13 下午

    Sailing深得我意, 不愧是“缓存”的高手。 是的, 这里的主要问题是如何减少CACHE的Invalidate。

  38. ayvuir 于 2013-03-25 5:28 上午

    大容量的session直接设置成uncacheable会更好吧,可以把cache用在其它利用率更高的地方,减少被无效替换的概率

  39. ayvuir 于 2013-03-25 5:30 上午

    FPGA访问的内存是和CPU独立的,可以减少CPU的内存带宽使用量

  40. multithread 于 2013-03-26 3:50 下午

    Cache不一定就不好,设置成uncacheable不如设置成 NTA(non-temporal aligned)的好。

    这里有两个需求要满足:

    1. the number of ACTIVE TCP flows
    2. the number of LIVE TCP flows

    这两个在大数据下很难同时满足!

  41. ayvuir 于 2013-03-28 9:04 下午

    Non-temporal不知道编译器怎么支持的
    Non-temporal in this context means the data will not be reused soon, so there is no reason to cache it. These non-temporal write operations do not read a cache line and then modify it; instead, the new content is directly written to memory.

  42. ayvuir 于 2013-03-28 9:06 下午

    TCP流的数量不就是内存吗,LIVE和ACTIVE没有看出来有什么冲突

  43. Panabit 于 2013-03-28 9:30 下午

    他的意思应该是ACTIVE的数量直接影响到CACHE使用效率。在实际中连接数的宏观和CACHE的使用这种微观的东西很难比较。所以对于连接数据的访问,针对每个包而言,其处理过程都要假定是从内存LOAD的,要优化的话,也只能尽量将后续访问这个数据结构的内容尽量在CACHE中,让一次LOAD CACHE做到可以反复使用,避免CACHE乒乓。

  44. ayvuir 于 2013-03-29 7:18 下午

    CACHE优化的水很深呀

  45. kevint 于 2013-03-30 12:41 上午

    我最近有一事整不明白
    为毛amd的哥们都喜欢2-way cache,好像从opteron出来之后就没变过
    然后intel的各种花样,L1都做到8-16way,还玩出了trace cache什么乱七八糟的
    ibm自己一套,sun的就更奇葩了
    按理说,计算机这玩意相当straight forward,真相只有一个,都是同一本教材念出来的最后的结论咋都差这么大呢

  46. matrix 于 2013-03-30 6:44 上午

    硬件简单,功耗低,速度快呗,哈哈,就是效率不怎样