“有关“一体化引擎和一体化的策略””有54个回复

1. 陈怀临 于 2009-12-29 9:44 下午

   太好了。苹果叶子，你放心。弓总不看，都会有人forward给他看。《弯曲评论》这个坛子上现在水深的比你想的再加一个Alpha，Delta。

   同学们，苹果叶子文章里说的首席是陈首席。别搞混了：–）

2. billy 于 2009-12-29 10:21 下午

   ×相信弓老师会很快看到，期待弓老师的点评…

   ×

   1.兼容遗留系统。系统往往不是一蹴而就的，新feature的加入要以不break已有功能为前提，否则必出血案。除非你能保证：
   a.被break模块owner的生命安全（Job Security）。
   b.引入的新bug你来负责。

   One JunOS, One World…One Wow…

   2.分割软件复杂度。

   复杂度…

   ×上帝让我们用自由意志决定我们的未来

   你相信上帝么？

   我相信

   你相信上帝万能么？

   我相信

   如果上帝是万能的，那么它一定知道未来，也知道我们的选择是什么？

   是的

   那么我们的自由意志还存在么？

   ……

3. Vincentxu 于 2009-12-29 10:59 下午

   上面这段点评精彩。
   作为一线工程师，最怕break别人的很久以前的功能，一来这种错误可能千奇百怪，二来你对人家的功能不熟悉，修改起来战战兢兢。
   BTW，看到这个点评为啥我脑子里冒出“分久必合，合久必分”呢。对于以前经历过无数风吹雨打的系统来说，破还是不破，这是个问题。

4. 老韩 于 2009-12-29 11:04 下午

   有苹果叶在，我等苟且于媒体圈者休矣。

5. 老韩 于 2009-12-29 11:10 下午

   明年打算做NGFW的内容。其实国内有厂商做类似产品，感觉这股风比当年UTM起得快多了。个人不太看好PAN能够壮大，他们各方面成本太高了。被Gartner点名不一定是好事。

6. appleleaf 于 2009-12-30 2:57 上午

   写东西能有人看，感觉真好啊。否则肚子里面的东西不是烂掉就是忘掉。

7. 陈怀临 于 2009-12-30 6:59 上午

   小韩，不要泄气。你的工作已经非常优秀了。苹果叶子，我和其他许多人，是工程师。基本上是两个世界的。工程师的缺点是视野比较窄。

8. 陈怀临 于 2009-12-30 7:15 上午

   据我所知，PAN自己做了一个FPGA。但是，Cavium Octane已经有了不少的DFA Lookup Engine。所以我目前不知道这个FPGA是做什么用的。我不认为是做VPN和FW Session的。I mean， after first packet。为啥？NS的ASIC Enginer并没有在PAN。

   我哪天琢磨一下PAN吧。。。

   听说PAN与Hillstone里以前NetScreen的高手都很多。没接触过。不知道哪拨人更牛叉一些。。。：-）

9. 老韩 于 2009-12-30 8:49 上午

   不是泄气，实为希望身边能有苹果叶这样的人物创作价值的内容而已。
   PAN和Hillstone虽然做着殊途同归的产品（NGFW），但骨子里的追求确是截然相反的。这就好比ASR和SRX，产品结构上看相似之处很多，但C和J谁都不承认二者是同一产品形态。

10. xscope 于 2009-12-30 4:28 下午

    Cavium的DFA引擎没出来多久，目前发布的只有一个系列(17XX)，另外一个按照之前的Roadmap，应该早就发布了，但是迟迟没有见到。很多细分应用，Cavium的DFA是替代不了FPGA的。

11. appleleaf 于 2009-12-30 5:14 下午

    “工程师的缺点是视野比较窄。”深感认同，工程师位居低位，了解信息的途径少且距用户远。好在现在有Google和弯曲。

12. droplet 于 2009-12-30 11:06 下午

    嵌入式的软件还是比较简单。比如Jave, .net之类的企业应用软件，可以做到即插即用。面向对象的设计模式很多了，也没见哪个人在c里面用用。OSGi的plugin model，如何用到嵌入式软件里面，或者在这个领域，有没有人在做这些东西？
    一体化是没错，但是什么东西都自己搞是不现实的，那么，自己做一个plugin framework，让别人的东西很容易加进来，又不损失功能和性能。不知道嵌入式领域有没有这样的实力和决心？
    工程师比较实在，不会瞎忽悠，懂就是懂，不懂就是不懂，不懂装懂的人，其实没啥意思。

13. 帅云霓 于 2009-12-31 12:33 上午

    [工程师比较实在，不会瞎忽悠，懂就是懂，不懂就是不懂，不懂装懂的人，其实没啥意思。]
    您说的那是做工程，或者工程师们打交道吧？生意场上，这样貌似不是很行得通……

14. appleleaf 于 2009-12-31 4:05 上午

    droplet兄，我对复杂通讯嵌入式系统软件常怀敬畏之心，听某华为工程师说过，VRP软件博大精深，可以学习一辈子，这点我是相信的。我的一个同学是顶尖工程师（coding水平和我不在一个档次），后来因为工程压力患病退出了，这一点对我警醒很大。

15. 理客 于 2009-12-31 4:45 上午

    路由器软件的复杂性主要是IP的变化太多太快导致，而IP的这个变化又是因为ALL OVER IP导致，所以根本原因是业务变化太快太多导致路由器系统复杂，这方面，AL/J做得比C/H可能要好一些
    从硬件来说，对NP/ASIC/FPGA/MULTI-CORE/TM/TCAM/VALUE-ADDED CARD等多种核心芯片的同步支持，带来系统架构设计的复杂度,从这个角度看,高端路由器的门槛其实是越来越高了,这和中低端安全产品的趋势有点相反,多核的成熟使此类安全产品的基础系统获得大大简化,设备商可以把精力主要放在软件上.高端路由器的的这个趋势也符合主流供应商的利益,太简单了就不值钱了,不值钱了怎么能有好的利润率,之前BT提出的PBT标准最后不得不选择自杀,这也是其中的一个原因

16. dasha 于 2009-12-31 6:00 上午

    To 15 理客,

    Could you please elaborate why British Telecomm suicide PBT eventually? Is it because of technical issue or business/internal political impact? Thanks a lot

17. appleleaf 于 2009-12-31 6:14 上午

    理客，同16楼问题，首次听到PBT这个东西，对相关故事比较感兴趣。

18. 阿来 于 2009-12-31 7:07 上午

    做过了路由器，也做过其他产品，发现路由器确实在硬件和软件架构上比一般的通信产品复杂了不止一个数量级，我想着也是一直为什么骨干网上C/J横行无忌的原因。

19. 理客 于 2009-12-31 7:32 上午

    PBT：Provider BackBone Traffic engineer就是用基于MAC IN MAC的纯以太转发，不做任何L2/3路由协议，集中式计算路由并下发到各个转发节点。基本技术上是可行的，但是在处理all services over IP/ETH时，包括组播等等并不成熟和完善，当然如果大家都支持，加以时日，也许可以成功。政治上，如果PBT成功拓展，则意味路由器将成为一种简单的傻瓜式转发设备，失去门槛的路由器很多人都可以做，那么思科将失去设备复杂带来的利润空间，所以思科是不可能支持PTB的，只有北电这个没落贵族才会支持，作为可以翻身的一个可能点。所以抛开技术问题，PBT本事是对社会有利的，但是在涉及利益问题上，大家都会站在自己的立场做动作，如果PBT成功的可能越来越大，当然大家也都会与时俱进，给予更多的关注和支持，商场对技术的态度是很势利和现实。当然PBT没能重演当年IP和ATM PK的结果，技术上应该也有很大的问题，这个东西复生的可能性很小，所以没有去仔细研究其中的细节

20. appleleaf 于 2009-12-31 4:36 下午

    多谢分享。看来BT越界了，干自己不该干的活。就像移动的Ophone一样，同iphone竞争，较难。

21. ABC 于 2010-01-01 5:42 上午

    PBT应该是完全死掉了, 即便是BT也对支持这东西心灰意冷的 .最后还是MPLS-TP的天下. 这次移动RAN中标PTN就是一个开始.

22. droplet 于 2010-01-01 5:23 下午

    MAC in MAC能支持多大规模的网络？或者说，二层网络，如何分隔，又如何管理？这个和VPLS有关系吗？

23. 理客 于 2010-01-02 1:17 上午

    很大，因为MAC IN MAC的的同时也兼容QINQ，在EDGE也可以和VPLS结合，但这会带来复杂性，和PBB初始的简化原则不符，会带来更多的问题

24. zeroflag 于 2010-01-02 3:48 上午

    PBT的东西其实不是太懂，但是挺过一个老大评论过这个东西，他认为这就是一帮子搞传输的人死抱着传输体系不放搞出来的东西，除了还是IP的报头，整个转发都是传输的思路。

    顺便说说安全，通用的安全产品其实没什么技术，无非是两条：状态转发＋特征匹配，这两个技术的组合应用几乎可以把网络上部署的所有安全产品（除抗DOS/DDOS的以外的）做出来。从这个角度说，安全产品比网络产品做起来简单多了。

    至于说多功能融合，根本上的问题还是性能。至于体系架构，L4～7层的架构是比较好设计的，复杂的是对交换和路由的处理，加上这两层就很麻烦了。

25. 海螺沟 于 2010-01-02 7:37 下午

    相对于PBT,mpls-TP更象传输,在TDM和时钟能力上更强。
    首席一直在讨论数通和安全,其实传输对数通的冲击是很大的,未来的城域网上巳经没有以太网交换机的空间。
    从xPoN到pTN,都是传输设备。
    未来数据产品只有两块焦点地盘,一个是骨干路由,一个是DC

26. 理客 于 2010-01-02 8:24 下午

    这个观点还是第一次听说，我倒是觉得不久的将来，传输只有PON和WDM，上面加一个路由器/交换机处理所有业务，SDH退役，传输被数通冲击下，不要数通话，要不收缩到只处理波长

27. 陈怀临 于 2010-01-02 10:17 下午

    安全的人都觉得Forwarding简单；Forwarding的人觉得Routing简单；Routing的人觉得安全简单。

    都不简单。关键是你能否做到scale，high performance。

    其实许多东西就是tunnel protocol来回搞。。。概念清楚了，都一眼看穿。

28. ASR1k 于 2010-01-03 2:09 上午

    其实都挺简单的. 做到balance很难. forwarding做高速, 找几个ASIC就行了. Routing要做好, 控制平面CPU快点多几个核就行了, 然后转发平面上也同样加快provision的速度. 安全, 加密解密Nitrox 作为协处理器放几块…

    但最后呢, 要么做出一个功耗大的吓死人的东西, 要么做出一个价格高的吓死人的东西. 所以做好都不简单.

    另外关于PTN的问题, MPLS-TP实际上已经成为标准, 中移动已经开始部署在RAN上了, MAN上的部署估计也会很快. 主要是1588和Sync-E的功劳. 当然OAM也功不可没. 数通相对于原来的传输网而言, 总体来说是更难维护. 2000个MPLS VPN 估计得花10多个人来维护, 而2万条TDM专线, 估计2~3个人就能搞的定.

29. aaa 于 2010-01-03 2:13 上午

    Forwarding的人觉得Routing简单
    差不多了，routing协议本身出问题很少，反正我遇到路由的问题都是forwarding的问题

30. ASR1k 于 2010-01-03 2:16 上午

    事实上, 如果NP架构比较好的话, 做这些也容易. 就像CRS-1, SPP上把cell self-routing的头写好, 然后交给S1/2/3这样的ASIC自己处理就行了. 路由/转发两不误. 至于加密解密, 如果在LC上的NP做, code量应该会比较大, 而DPI这些业务, 对于NP的片上缓存要求很高, 所以通常的做法是路由到一个业务卡上处理完了扔回来, 或者LC上放nitrox来做协处理器.

31. 理客 于 2010-01-03 3:01 上午

    PTN做包处理，支持PW，已经L3VPN，这应该算传输设还是数通设备？
    基于静态配置+网管GUI，还是动态为主辅以网管GUI，两种各有利弊，传输建网的喜欢PTN方式，IP建网的喜欢路由方式，目前看，似乎是IP的人正在占优

32. droplet 于 2010-01-03 7:00 上午

    搞传输和搞ip的人分别都是哪些公司为代表？IETF是搞ip的，ITU是搞传输的？ISO哪？Cisco是搞ip的，华为是搞什么的，华为的光网络好像不错，是搞传输的？哪位老大能理一理这里面的关系，否则外行看起来是一头雾水。当年的ATM是怎么凋零的，是不是也是这种斗争的结果？

33. FlyBy 于 2010-01-03 5:35 下午

    ASR1000研发过程中， 从RP1用Freescale 8548转到RP2 用Intel CPU, 技术， 功能和性能的考虑只是一部分，Freescale 当时在频率性能和多核roadmap的不明朗，是决策过程中的一个重要因素。 思科供应链对Freescale从来不是那么感冒，设计团队内部的政治斗争也是选用Intel的一个因素。

    8548的IO集成度非常高， 功耗低， 而且内部数据总线是SPI4, 与思科内部交换背板芯片的连接非常顺畅。

    Intel CPU用三片芯片， 加上PCI-E到SPI4 Bridge 芯片, 对IO系统， 供电， 热散的冲击蛮大。 软件上从big endian 到little endian的转换， 也造了不多不少的麻烦， 更别提schedule一再的延后。

    不过总的来说我认为选用Intel还是正确的。从思科内部看来， 高端控制平面用Freescale越来越少， 用intel越来越多。

34. aaa 于 2010-01-03 5:41 下午

    反正我见过的一种芯片方面的说法是ATM的SAR速率实在很难做上去，2.5G基本到头了

35. 弓峰敏 于 2010-01-05 4:22 下午

    多谢老韩提醒。你们有这麽多的有意思的话题（谢谢陈首席：），有那麽多好的见解。新环境下很多杂事却忙得我晕头转向，真是惭愧。
    苹果叶子地分析很准确。UTM 的引入是冲着低设备购买费，易部署 （单箱和多箱之差），以及易用性，来的。这是对的，但是他实现的方法仅停留在公用硬件平台+统一用户界面的层次上。这就是原定义的UTM后患所在。
    我谨对利弊分析方面做几点补充。
    1。引擎一体化的目的是高性能，低时延为主，同时提供一体化策略的有效基础。 对架构设计的要求确实比较高，要有网流处理，协议分析，威胁检测，各种恶意软佳绩动向的积累。同时要有对用户管控需求有清楚地了解和判断。话又说回来，你无法预言所有的需求，但是出一个好的产品也不需要这莫做。 另外，不要忘了，引擎不光是支持signature的，或者用句玩笑话，外婆的引擎和外孙的引擎可不一样。寿命就不一样喽。
    2。统一的策略更重要的是为了提供更好的可用性。举几个例子就清楚了。有些设备HTTP的检测，URL过虑是通过代理模块做的，而其他协议的入侵检测是用另外的引擎。 用户必须明白这些模块间的依耐关系，分别做出正确的购置才能达到需要的功能。 另外，在NAT和IPS共存的盒子上，不同的UTM风格的耦合，IPS模块看到的包的IP地址可能是NAT之前或者之后，用户要面对这层复杂性才可能正确设置自定义的使用IP抵制的规则。 这些事同一策略框架的用途。当然，在没有一体化引擎得了件下，是可以再UTM上提供统一策略框架的，所不能达到的是效率。
    3。关于模块切割，实现复杂性等，如果你是从零开始，这不是个问题。你的架构最后还是落实到不同的模块，所不同的是每个模块做什麽，它们的接口是啥样的。

    Billy,你的自由意志不能因为上帝可以预测而不再是自由意志啊。如果你相信上帝，就不能那样和他比啦。你一定看过Matrix.不然的话，更让你费脑筋的可能是 “上帝让我们觉得我们在用自由意志决定我们的未来” ：-）

36. appleleaf 于 2010-01-05 6:52 下午

    多谢弓总百忙之中的回复。
    “引擎不光是支持signature的，或者用句玩笑话，外婆的引擎和外孙的引擎可不一样。寿命就不一样喽。”
    我的理解是引擎的主要功能是模式匹配，为了达到该功能的前置功能就是Normalization，这包括协议解析，各种编码方式的标准化，文件解码，解压缩，嵌套文件提取等等。这些概念应该适用于AV,Anti-Spam,应用识别, DLP, IDS,以及URL filter等web安全功能。其他还有不少辅助的和模式匹配并列的检测手段，例如按照协议或标准的异常检测，但大多重要程度还无法和模式匹配相提并论。

    “在NAT和IPS共存的盒子上,不同的UTM风格的耦合，IPS模块看到的包的IP地址可能是NAT之前或者之后，用户要面对这层复杂性才可能正确设置自定义的使用IP抵制的规则。”.这一点我从未想到，我觉得应用安全同NAT基本无关系，UTM设备在设计机构上就应该保证IP对于应用安全是透明的，也就是说应用安全模块仅仅需要看到一侧的IP。我还真的无法想象出在什么情况下要看到两侧的IP。

    “关于模块切割，实现复杂性等，如果你是从零开始，这不是个问题。”我的理解是对于PAN这样从零开始建构系统不是问题。对于One Junos这样的也不是问题，因为已经“病入膏肓了”根本无法实现NGFW了:-)

    真是希望看看PAN的设计实现，估计功力可以提高好几年。

37. 老韩 于 2010-01-05 9:22 下午

    昨天刚给客户部的人发过陈老师归纳的思科各业务部门介绍的文章，大家都受益匪浅啊。谁说弯曲评论只是技术讨论平台？这个平台很广阔，能量很大，什么时候一转型，我们都玩完。

38. 清华土著 于 2010-01-05 9:40 下午

    没有工程经验的不会随便乱说的。
    老韩的测试我见过，他的虚心求索精神，和探索真谛的理念确实值得赞赏。摸过的盒子，老韩应当在众人之上了，虚心的精神，更是少见。

    融合处理，真正提出来的是方院士吧，协议分析和signature的统一处理，实现起来，就要靠session的融合了。

    ASIC这种东西，名字吓人，但电路集成度就那样了，除了L2~L4的处理，走个L7试试？

    测评是最容易发现问题的，国内很多厂家的问题都显而易见，只是没说罢了。测评的难度，深不可测，只有高手来为之，只有高手敢为之。

    主张实践，讨论拿出数字，谢谢

39. 清华土著 于 2010-01-05 10:08 下午

    只讨论技术行么？

    老韩的测试我经历过的，实打实的数据。
    他的郁闷也源于实打实。。。

    媒体和众人没啥区别，真正的理论，谁能知多少？
    弄个计算几何出来解决session creation? 是人都行么？

    关于弓的回复，国内的，e.g.启明，都做到了罢：
    1）一体化处理：这个方院士反复强调过，IPS和AV的处理要在一起进行。不难实现，但取决于规则。自己制定的规则我可以一体化，换个第三方的，ok，测评吧！

    2)统一策略：相关问题是管理问题，这个没人能解决。你说防火墙管理员权限大还是IDS的人权限大？这个有明确答案么？策略融合的前提是明晰了从属关系，UTM是个整体没错，但整体就有等级制度，需要明确的。

    3）modular的问题，取决于系统工程师，软件架构师。芯片的任何改进，都有可能改变module的部署。比如PAN，真的需要ezchip和fpga么？multicore不能解决么？增强版的PIP/PKO不能解决么？Octeon2不能解决么？

    时势造英雄，英雄亦须趋于时势。。。

    欢迎来搞。

40. 陈怀临 于 2010-01-05 10:19 下午

    在工程技术里面，媒体最好的就是陈叔了:-). 另外，谁是方院长?共青团员从不怕不知道，就怕不虚心。我应该比较八卦了，但还真不知道谁是方院士。

    >昨天刚给客户部的人发过陈老师归纳的思科各业务部门介绍的文章，大家都受益匪浅啊。

    那可是我自己靠一个Google，靠一个脑袋。利用黎曼积分，求极限，整出来的。花了不少时间。基本上是倒退，反证。
    很高兴对你们（社会）有帮助。这就是我最大的selfish。我可不是脑残：–）。我所有的文章都是GNU License。你们自己考虑好了。。。：-）

41. appleleaf 于 2010-01-05 11:05 下午

    查到了，应该是方滨兴院士。有的时候还是要在同一语境内讨论。我以后也会关注一下方院士的研究成果。

42. 老韩 于 2010-01-06 1:09 上午

    土著过誉了，只不过是做好自己的工作，混口饭吃。干这行，没有准确的数据就没有用户和厂商的认可，那就等着喝西北风了。
    苹果叶同志请联系我一下吧
    han_xu￥ccw.com.cn

43. 弓峰敏 于 2010-01-06 5:03 下午

    提前抱歉,有些细节和对具体产品的评价,我将不便参与.
    Appleleaf 和我对引擎的解释都是超出模式匹配的，这点我们有共识， 不过仅仅协议异常检测确实是不够的。应该想急于内容的启发式的检测，行为模拟， 等等。没有这些方法的辅助，许多当今的威胁都难以检测。 有效地融合多个方法是好的引擎的一个重要标志。

    说安全或者应用安全和NAT没有关系真有些不妥，尤其是在UTM构架讨论的前提下。我们不能排除有些IDS/IPS产品可能非常单一，但是，好地IPS都支持用户定义规则，去实现基于内容匹配的ACL功能。例如，block 从a.b.c.d 的 WEBDAV HTTP 访问。如果用户不清楚NAT购置与a.b.c.d的关系，ACL的效果无法预测。还有，当一个公司关心对外的攻击/泄漏时，日志里拿到的是哪个IP地址就有关了。

44. appleleaf 于 2010-01-06 10:38 下午

    我的提法是有些不妥，任何绝对的提法都是不妥的，以后接受教训：-）

    “例如，block 从a.b.c.d 的 WEBDAV HTTP 访问。如果用户不清楚NAT购置与a.b.c.d的关系，ACL的效果无法预测。”我的理解是，这个例子是Applicaition FW的概念。要做的事情是APP ACL。对于APP FW，我总是习惯分层的考虑policy，对于Network层部分的policy以及相关的NAT，我没有把他当做UTM的policy：-）。不过，如果真的需要过滤应用层payload的IP，那NAT就要考虑了。这种例子较少，ALG中需要单独care这个问题。

    “还有，当一个公司关心对外的攻击/泄漏时，日志里拿到的是哪个IP地址就有关了”
    日志中确实要考虑NAT的问题，NAT前后的地址信息都要记录，尽量全面的反应现场信息。

45. appleleaf 于 2010-01-06 10:39 下午

    笔误“我没有把他当做UTM的policy：-）。”应该是“APP FW的policy”

46. 帅云霓 于 2010-01-07 2:48 上午

    思科业务部门跟算黎曼积分有什么关系……

47. ASR1k 于 2010-01-07 4:49 上午

    现在还是比较流行ZBF的概念吧? 不管nat inside outside , 定义两个zone . 之间定一个流量走向的policy, 然后policy中做classfication(可以借用QoS的引擎并配合QoS功能) 到7层. 然后 app-layer 过滤, 结构会清晰很多,

    似乎很多厂商都这么在做吧?

48. metal1011 于 2011-05-21 5:48 上午

    APP-FW IPS DPI 都检测到了7层 区别是啥

49. multithreaded 于 2011-05-21 7:47 上午

    >查到了，应该是方滨兴院士。有的时候还是要在同一语境内讨论。我以后也会关注一下方院士的研究成果。

    对应该多关注，多扔鞋子和鸡蛋！

50. 陈怀临 于 2011-05-21 8:04 上午

    我都不知道这个方滨兴还有么有基本的对耻辱的感觉？为虎作伥。丧失了中国知识分子的基本尊严。

51. multithreaded 于 2011-05-21 8:18 上午

    从技术较多来说，就是一条流水线的设计而已。
    比如：
    L2/L3 + TCP + Protocol Identification + HTTP Parser + TM based APP ID

    难点是：
    1。如果是多条流水线，如何解决out of order?
    2. 流水线上是否可以容易的加入新的pipeline Stage 应对新的应用。

    这就是陈首席常讲的 scalability! 把系统设计成一个能扩展、稳定的系统是最关键的。目前还没有见到能达到10Gbps的系统。 一般是features都打开，性能力可下降！

52. multithreaded 于 2011-05-21 8:26 上午

    我到觉得方滨兴是功底不够，误杀率太高，引起公愤而已。

    每个国家都应该有FW,但对科学研究应该是畅通无阻的！如果影响到了正常的科学研究，这样的墙应该拆！

53. kevin 于 2011-05-21 11:27 上午

    尽管他功底很差，但是这个与功底没关系，是policy的问题。
    宁肯错杀一千，不能放过一个。

54. tom 于 2011-05-25 8:55 下午

    pan的资料看了半天，也没整明白，到底和utm相比强在哪里？应用可视，细粒度控制，单一策略，基于用户控制等等，这些有些UTM都可以做到，说性能高吧最大5G而已，而crossbeam的那种模式，app的最高性能可不止5G