说到 SASE,新的安全范式有哪些

前言

本系列目录:

对于SASE,当前可能存在两类看法:

  • 又瞎扯淡:感觉SASE没啥,和SD-WAN一样,炒作成分居多;
  • 不明觉厉:感觉SASE重要,但又说不上来哪里好,了解一些相关技术。

一个可能的原因是:诸如Gartner之类的高大上权威,在定义完SASE后,一上来就谈SASE有12点优势,“巴拉巴拉”小魔仙,非常感人。Gartner作为一家顶级咨询机构,客户都是花了大笔订阅费的,这也决定了必须要专业严肃一些。

作者没背景,没负担,无束缚,可以不按套路,会按一贯风格,侧重分析:

  • 散点知识如果没法融入知识体系,早晚都会是过眼浮云。
  • 更重要的一点,作者也不懂什么高深的安全技术,还得继续学习。
  • 一个人不可能全心投入他不认可的领域。所以,即便是为了跨界学习,也需要尽可能理解SASE,这也是整理本文*原始的初衷。

%title插图%num

什么是范式

In science and philosophy, a paradigm is a distinct set of concepts or thought patterns, including theories, research methods, postulates, and standards for what constitutes legitimate contributions to a field. — Wikipedia

什么是范式?在科学和哲学中,范式是一组独特的概念或思维模式,包括构成一个领域的一套自洽的理论,研究方法,假设和标准。

范式有什么用?范式会自带世界观,会引导人们带着其特有的倾向和思路去析构世界,认知/分析/解决问题

可能还是有些抽象,举一个*直接的范式例子:地心说和日心说。

%title插图%num
图2-1:日心说与地心说;来源:http://www.malinc.se/math/trigonometry/geocentrismen.php

  • 上图的右半部分,是地心说下的太阳系;
  • 上图的左半部分,是日心说下的太阳系。

推荐点击图片链接,可以看到动态轨迹图;地心说其实是挺精妙的。

以上,地心说是一种范式,日心说是另一个范式。

同一个世界,在不同范式的析构下,会呈现出巨大的复杂性差异,这就是范式的作用

作者认为,和SD-WAN类似,SASE也不是一种产品,不是一种技术,而是一种新的安全范式,这也意味着SASE可能会进一步衍生出不同的技术、工具和产品。

SASE至少提供了两个范式:

  • 一个是产品形态方面的,这里可能会卡一卡传统设备商;
  • 一个是业务建模方面的,这里可能会拼一拼产品架构。

%title插图%num

产品形态的范式

3.1 为什么产品形态重要

先回到一个经典例子:“客户不是要买电钻,而是要买墙上的那个洞”

%title插图%num 图3-1:客户要的是电钻吗;来源:互联网

假设你要挂一幅画:

  • 产品形态:你花了200元钱,在京东上买了一把电钻,京东很牛逼,次日达。次日,你叠起了两个凳子,晃晃悠悠,勉强打了两个洞,挂上了画。
  • 服务形态:你给物业打了个电话,物业报价20元/洞,15分钟内上门。物业带了一些列电钻钻头和折叠梯,30分钟完成挂画,还帮你清理了钻墙的粉屑。
  • 高级的服务形态:物业上门后,查看了一下画和墙,直接推荐挂钩方案,既不破坏墙体,也没有噪音灰尘。你认可了,物业也更方便,只收了20元。说这更高级,是因为“听用户说,但没有照着用户说的去做,而是在洞悉之后售卖了更为专业的服务”。
  • 更高级的服务形态:物业上门后,发现画风与墙饰风格不符,现场说出了三点原因,给出了完整建议。你一听还挺受用,购买了物业的装饰服务,收费200元。你很高兴,因为在亲友面前提升了品味;物业也很高兴,因为不但成了更大的单,而且因为准确挖掘了客户的根本诉求,客户的满意度和忠诚度也更高。说这更高级,是因为这项服务过渡到了“售卖标准”,在这个例子里,就是“审美标准”。售卖标准,长期是西方国家的优势领域,当前很多中国产品,正在试图突破这个阶段

为什么服务形态比产品形态更加高级?这个问题搜不到答案,以下是一些作者理解:

  • 更容易接近真实需求:产品是硬的,服务是软的。社会进步的标志就是分工越来越细,这也意味着需求越来越多样化,软性的服务相对更容易匹配用户的真实需求。以上例子,“打洞”就要比“电钻”更接近用户的真实需求:不同的客户有着不同的墙体,不同的孔径,不同的深度,“打洞”显然更要比“电钻”更容易匹配各种真实需求。一个更加宏大的例子:哪怕是*硬梆梆的制造业,在推的概念也是“柔性制造”,本质上就是“软件定义产线”,尽可能去快速逼近细分客户的特定需求。
  • 用户界面更简单:产品离满足需求,还差了一个“集成”。在这个例子里,集成比较简单,就是业主自己去操作打洞,但其实也是有一定门槛的;在很多2B产品的例子里,集成往往会更加困难,一个直接表现就是存在着大量的集成商;不过羊毛出在羊身上,这些都会增加客户的广义拥有成本。
  • 更快满足需求:客户,大多都会把时间留给自己,把难题留给供应商:下单之前,货比三家,磨磨叽叽;下单之后,立刻就要,拼命催单。这是客观存在的事实,很难改变客户的心理,那就只能改变自己的交付形态了。

3.2 产品形态的串联

SASE在产品形态方面的范式革新,已然比较明显:客户要的不是设备,也不是功能,而是服务

  • *好这个服务足够全,能涵盖我的所有相关需求,不用让我再去考虑多供应商和多供应商之间的集成问题;
  • *好这个服务刚刚好,可以调整到刚好涵盖我的所有相关需求,不用让我多花一分冤枉钱;
  • *好这个服务够专业,可以成标准成体系地从根本上解决相关顾虑,可以让我在老板面前更专业更得力。

前文提到,产品形态的范式,可能会卡一卡传统设备商,那我们就来稍微展开一下。

一个设备虚拟化了,就成为服务了吗?当然不是。虚拟化了的,还只是功能。功能和服务差在哪?功能是偏静态的,偏供给侧视角的;服务是偏动态的,偏需求侧视角的。这两者又有什么区别?偏静态的供给侧视角:我有这这这功能,超级牛逼,你来用用啊;偏动态的需求侧视角:客户发现,在他想睡觉的时候,路上出现了一个枕头;在他想打怪的时候,路上出现了一个耙子,他甚至不需要“懂”,只需要会“用”。

在客户随时需要时能随时满足,“敏捷、弹性、按量付费”,这样才叫云化服务;或者翻译成那句大白话:“不求天长地久,但求要时能有,随时要随时有”。所以,

  • 需要齐全的网络栈和安全栈,足以匹配各种场景的网络和安全需求;
  • 需要高度的虚拟化和模块化,足以刚刚匹配所需的场景;
  • 需要高效的建模能力和快速的投送能力,足以应对VUCA的用户和需求。

这方面,再啰嗦估计就要被嫌弃了,这个系列也已经铺垫很久了,可以参考前面几篇,不再赘述。

3.3 大道无形

本章*后,做个大胆预测:与SD-WAN类似,SASE可能也会分成“名义市场”和“无形市场”;会有一些更大的玩家去玩“无形市场”,即直接服务一个更大的产品或产品体系,不以“SASE”的名头直接出现在市场上,拭目以待。

%title插图%num

业务建模的范式

4.1 为什么业务建模重要

之前提到,范式能帮助我们析构世界,引导我们去认知/分析/解决更广更深的问题。

产品形态的范式,解决了用户界面复杂度的问题;业务建模的范式,解决了产品架构复杂度的问题。

2B产品,本质上是强化了某种生产关系。这就意味着,2B产品必须要解决具体的现实问题,而解决问题的效能和效率,取决于产品本身对现实世界的建模能力:模型越逼真,方案越匹配。

%title插图%num
图4-1:问题域与解决方案;来源:互联网

4.2 范式与技术

在进一步析构业务建模的范式之前,有必要先澄清一下范式与技术之间的关系,因为两者在SASE里,都会是重要的存在。

范式和技术是两个层面的词,先进的范式,不代表先进的技术。还是以地心说和日心说为例,反倒是地心说可能需要更高深的技术功底才能掌握,而日心说,初中物理水平就已足够理解。回望历史,往往正是旧范式的建模能力有限,为了逼近真相,才被迫发展出很多“高深”的技术来“代偿”

这也是为什么不建议直接投身技术而是先来研究一下范式背景:技术容易成为深深的竖井,贸然进去短时间可能爬不出来,反而就容易忽略新技术所代表的新范式本身的力量。一个*简单的例子,比如C和C++的区别在哪?

  • 表面上,两者的语法确实有区别,但这不是本质区别。
  • C++蕴含的是一种面向对象的编程范式(Object-oriented Programming Paradigm),语法变化只是为了落地新范式的手段之一。见语法而不见OOP,就容易有点知乎所以,不入门道。
  • 面向对象编程范式,与指令式编程范式、过程式编程范式相比有什么好处?并非后者无用,它们至今都仍在各自领域发挥重要作用;旧范式的问题,往往在于不适合构建复杂系统,难以适应快速变化的商业需求。需要用*趁手的工具,解决*迫切的问题,仅此而已。

其实,中国人理解范式与技术,应该是有些独特的优势的:

  • *、先哲智慧:君子不器。“形而上者谓之道,形而下者谓之器”。道是系统,器是工具;道有主动性,器为被动性。
  • 第二、武侠文化:范式和技术,有点像武侠中的心法和招式,两者都很重要。
    • 一直在夸范式,也得扶一扶技术:赵志敬只教杨过心法,不教招式,杨过空有心法但没法用招式使出来,就容易被胖道士欺负。
    • 此外,招式具有外在性,相对容易模仿习得,反而是心法,一般是不外法门。这么说,本文的价值更大一些。:-)

4.3 业务建模的串联

如果阅读过一些相关材料,可能已经可以看出一些相关端倪了,以下摘录一段CATO的表述:

Solving emerging business challenges with point solutions leads to technical silos that are complex and costly to own and manage. Complexity slows down IT and its response to these business needs. SASE changes this paradigm through a new networking and security platform that is identity-driven, cloud-native, globally distributed, and securely connects all edges (WAN, cloud, mobile, and IoT).

这段文字很精彩,逻辑非常清晰,大意如下:

  • 用当前点状的解决方案,去解决当下涌现的业务挑战,会导致一个个技术竖井,它们的获取和管理,都很复杂且昂贵。请对照一下地心说,如果拿地心说去析构太阳系,就会有这个特点,需要定义什么“本轮”、“均轮”、“恒星天”等概念,这些概念就像是一个个技术竖井——你还是可以去逼近世界,但是会发现越来越散,越来越累,直到开始怀疑人生:“如果我是上帝,会不会弄出这么复杂的宇宙”。
  • 复杂性会降低IT对业务需求的响应速度。请结合一下SASE的大背景:你理解成VUCA的延续也行,或者分解成云计算、移动计算、边缘计算、全球化等等也行。更快的需求响应速度,正是为了解决一个一个更加挑战的现实问题;所有的2B产品,都是生产工具性质的延伸,延伸了真实世界的逻辑关系。旧工具面对新问题,已经不再趁手了。
  • SASE通过一个新的身份驱动的,云原生的,全球分布的,安全连接所有边缘的网络和安全平台,改变了当前的范式。这是在一句话总结SASE,很精彩:
    • “云原生的”,“全球分布的”,“安全连接所有边缘的”,“网络和安全平台”,这些内容涵盖在“产品形态的范式”中,以及在本系列的前期铺垫中,这里不再赘述。
    • 以下会重点析构一下“业务建模的范式”的四个基础。

4.3.1 基于身份驱动

范式还有一些有意思的特点:

  • 初阶范式*符合人类的直觉。日心说如此,*符合人们仰望天空所得的直觉;基于边界的安全模型也是类似:大到国家冲突,小到同桌别扭,千百年来人们一直都是这么直接认知的,见下表。
  • 新范式一旦被发明之后,人们会觉得新范式是多么的自然,自然到“不值一提”。翻译成不太雅的话,有点像:许久便秘的憋屈,如今一气呵成,太特么舒服了;通了就好,鬼才想回忆过往,对比分析呢。例如,日心说发明之后,一切都是那么畅快那么自然那么不值一提,你很难再理解地心说在科学精英中发展了1000多年的事实。所以,以下析构新范式的四个基础时,可能也会让你觉得“这特么不是废话”么;如果有这种效果,作者就很高兴,认为达到了初衷。

表4-1:现实世界与网络世界安全模型对比

现实世界 网络世界
安全区域 内网区域
非安全区域 外网区域
缓冲区(例如莱茵河、外蒙古) DMZ, Demilitarized Zone

SASE摒弃了传统的基于边界的安全模型,确立了“身份”这一概念的重要性:身份是所有访问决策的中心,边界退化成了至多是某种需要参考的上下文之一

%title插图%num
图4-2:基于身份驱动;来源:Gartner

本章重点要谈的就是新范式逼近现实世界的能力,所以就找一些现实世界的映衬。这一条,翻译成大白话,就是:

  • “边界”模糊了,基于边界防守的安全模型不再可靠了;
  • “你是谁”才真正重要,边界退化成了至多是某种动态上下文——因为你在哪,边界可能就需要动态地跟到哪:基于“你是谁”,配合着“什么时间”,“什么场地”、“什么工具”,“什么任务”,等等动态上下文,才是现代安全的基础。

以上是什么?活脱脱就是以海湾战争为标志的现代战争理念的变迁啊。海湾战争改变了传统的作战模式,对二战以来形成的传统战争观念,产生了强烈的震撼:

  • “边境”?在现代化的打击手段面前,想捅破时不是比纸还薄吗?
  • “身份”到哪,依托现代化的快速投送能力(软件定义网络),迅速动态地构建针对作战对象的立体防御体系(软件定义安全),完成一个VUCA时代的业务目标,不是更像“软件定义边界”么。

%title插图%num
图4-3:沙漠盾牌与沙漠风暴行动,名字都起得那么有软件定义边界感;来源:互联网

在这里特别提起海湾战争,是因为海湾战争这种现代化的“战争范式”,让人们惊掉过一回下巴,包括兔子。尼玛老美当年还通过调整卫星网络(软件定义网络),对现代战争进行了人类历史上的首次电视直播,好好“教育了一回市场”;海湾战争后,海湾地区的军火市场,直接翻番——基于传统边界建立的政权,在现代战争面前,太特么脆弱了。

“兵者,国之大事,死生之地,不可不察也”,很多革命性的理念和技术,基本全部源于军事,在解决成本问题之后,民用跟进。民用市场,不知道会不会出现一次“海湾战争式的市场教育”。

海湾战争之后的另一个战争理念变迁,是以911为代表的反恐战争,进一步崩塌了传统边界。这方面,普京大帝给出过一个精彩回答。

%title插图%num
图4-4:不受边界束缚的反恐战争;来源:互联网

普京大帝事后后悔了,觉得自己在媒体面前太冲动了,不过这更加说明了这个答案的内心真实性。

本节*后,重新回到Gartner对SASE的定义:SASE是一种基于实体的身份、实时上下文、企业安全/合规策略,以及在整个会话中持续评估风险/信任的服务。实体的身份可与人员、人员组、设备、应用、服务、物联网系统或边缘计算场地相关联。

SASE按需提供所需的服务和策略执行,独立于请求服务的实体、场所和所访问的服务。

%title插图%num
图4-5:基于身份和动态上下文的功能栈;来源:Gartner

一些「基于身份驱动」的段子,活跃一下提到高大上机构之后的肃穆气氛:

我妈挖了一勺西瓜没拿稳掉地上了,她捡起来就要往我嘴里塞,看见我很诧异地盯着她,突然反应过来笑着说:“不好意思,我还以为你还是小时候呢!” 我突然感觉胸口有点疼。

身份+时间上下文:只核实了身份,没有留意时间上下文。

昨晚在路边停车等人,有个脑袋探到窗边问:“走吗?” 我心想:我TM又不是来拉客的黑车,于是头也不抬地说:“不走!” 过了一会儿,他递进来一张罚单。

身份+场地上下文:只留意到了位置上下文,没有核实身份。

一位北方的朋友去重庆吃火锅,问:“有麻酱吗?” 服务员说:“麻将要开包间才有。”

身份+场地上下文+访问信息的敏感程度:只核实了身份,没有留意位置上下文,以及访问信息的敏感程度。

以上段子,并不能直接套在SASE上,只是用来说明:用“基于身份驱动+动态上下文”,比“基于边界+隐含身份”,是更容易写出清晰易懂的规则去逼近真实世界的。

4.3.2 基于动态信任

可能有点残酷,但是现实世界里,可能不存在*对信任,信任是一个动态过程。以下两位大佬,对此颇有心得。

%title插图%num
图4-6:动态信任;来源:混子曰

两位大佬虽然签订了《苏德互不侵犯条约》,但都在之后疯狂瓜分夹在其中的国家作为缓冲区(基于边界的安全模型);结果已经明了了,谁信的更多一些谁倒霉。

不了解历史也没关系,回顾一下我们自己认识新朋友的心路历程,也可以足够明了:刚认识一个人时,信任是比较模糊的;随着“听其言观其行”,慢慢会对不同的人发展出不同的信任程度;但是无论到哪种程度,信任总是有范围的,不是*对的。

不知道孩子的初始状态是否有*对信任,不过长大之后都慢慢被教会了动态信任,说残酷也行,说成熟也行,这就是现实。动态信任,更能逼近现实世界。

「基于身份驱动」和「基于动态信任」是什么关系?觉得前者是信任的动态载体,后者是信任的动态过程。

活跃一下气氛,一些「基于动态信任」相关的段子:

朋友说他的媳妇儿特别懒,我问咋了,他说他家住三楼,他媳妇儿每次在网上买东西的时候都在备注上写:“孕妇,行动不便,请送货上门!” 前些天,快递小哥终于忍不住了,在楼下大喊:“三年了!我忍了你三年了!你怀的是哪吒吗!!”

这位快递小哥,具备了人性的初始信任,*后被迫学会了动态信任。

长官问花木兰:“听说你在出征前,先到东市买了骏马,再去西市买了鞍鞯,然后去南市买了辔头,*后,又到北市去买了长鞭,是不是这样?”

木兰说:“确实如此。”

长官接着问:“你是女人吧。”

木兰感觉十分吃惊:“将军你是如何得知我是女人?”

长官缓缓说道:“如果是男人,*对是不会跑去逛了四个市集,而就为了买这些东西的。”

这位长官很老道,已然具备了初级的态势感知能力,至少是全流量分析的能力。

以上两个段子,也在侧面说明:

  • 身份还是静态的,相对容易伪造;行为模式等是动态的,相对更难隐藏。
  • 在身份被突防之后,通过动态信任机制建立起的安全模型,更容易逼近现实世界。

4.3.3 基于分层设计

分层,是人们简化世界,理解世界的必须。网络原本就存在分层,例如广为人知的OSI七层模型。

%title插图%num
图4-7:OSI模型;来源:互联网

但问题是,从架构角度而言,这里的网络层,存在着较大问题。倒不是作者狂妄到敢批判协议,而是这与历史有关:还是那句话,哪怕是顶级专家,都容易低估未来,当时互联网规模*小,安全性并非设计时的首要考虑因素。网络层,顾名思义负责网络连接,这意味着它要面临整个世界的攻击面,但自身却缺乏有效的安全机制。活脱脱一个傻白甜,“傻白甜”只是一种昵称,另一个说法叫“坑爹”。

一个典型的例子就是DDoS类中的SYN Flood攻击:“爹在家中坐,祸从天上来”。

简单介绍一下SYN Flood攻击:TCP是面向连接的传输层协议,大量的应用都基于TCP协议;因为是面向连接的协议,所以建立一个TCP连接需要经历一个三步握手过程,以下选了一张比较直白的原理图。

%title插图%num
图4-8:TCP三步握手;来源:https://github.com/jawil/blog/issues/14

SYN Flood攻击者,操作一批肉鸡向服务器喊话:“喂,你在吗,伸出手来咱握一握呗”,然后玩消失,留着服务器在那伸手后傻等,直到超时。这种方式会消耗服务器大量的连接资源,进而没有能力去服务合法用户。

%title插图%num
图4-9:SYN Flood攻击;来源:AllOT

SYN Flood为什么能成功,是因为攻击者的喊话,在协议层面是完全合法的,服务器无法区分,只能做应答。作为家中端坐的爹(TCP层),心中定是一万头草泥马,丫的老子的手是谁都可以摸的吗?你丫龟儿子(IP层)能不能认清了再往家里带!

IP层说儿做不到啊!事实上,IP层确实做不到,因为“认人”这事,带了点语义层面的逻辑,IP层就一个负责通道的,哪管得到语义层面的事。那该怎么办呢?“网络革命的一声炮响,给我们送来了SDN主义”。SASE在这方面的革新,更进一步,采用了零信任的理念,例如CSA(Cloud Security Alliance, 云安全联盟)的SDP(Software-Defined Perimeter, 软件定义边界)实现方式:通过独立的认证中心,隐藏网络基础设施;通过SPA(Single Packet Authorization, 单包授权认证)技术,隐藏认证中心自己。结果就是在网络层,形成了一朵近乎零攻击面的暗云(Dark Cloud),从根本上解决了网络层自身的安全问题。

为什么说这也是SASE的范式基础,是因为长期以来,我们其实已经躺平接受了:网络层搞不定的安全问题,就蔓延到其他地方去转移解决。

可能会有人觉得,你SASE不也把问题转移到其他地方去了吗?对,不过这种转移,在架构上有着本质区别:这不是在纵向的层级之间转移,而是横向转移给了更加专业的管控平面或者认证平面,逻辑清晰,平面隔离。

继续拿现实世界做类比,你是否会把任何对象先领进家门,让家长先握握手保持联系?不会,家长有家长要负责的头疼事,你会先委托专业的第三方检查对方身份并开介绍信,比如具有国家信用背书的公安部门,有问题的对象,聪明如你,肯定连家门都不会让他找到。

注意,通过以上分析,希望也可以理解到,包括零信任、包括SASE,其实也解决不了全部的安全问题,理论上只能解决可管控范围内的部分问题。

4.3.4 统一开放架构

统一开放架构,可能是个隐藏的范式基础,但是已经比较好推导了:

  • 基于身份驱动,意味着认证中心需要独立于业务网络,这样才能独立完成初始验证。
  • 基于分层设计,意味着控制中心需要独立于业务网络,这样才能在完成初始验证后,控制整个网络基础设施的基于*小授权原则的闭合(先验证再*小授权再开放再连接),以及集中控制网络功能和安全功能的动态投放。
  • 基于动态信任,意味着评估中心需要独立于业务网络,评估中心采集包括认证中心、控制中心、网络基础设施等在内的全貌信息,这样才有可能通过记录、分析,态势感知等,保持动态信任。

以上,外加SASE需要较为完备的网络栈和安全栈,很难由一家独自完成,都意味着需要一个统一开放架构,去持续探索相关行业*佳实践。这方面,已经跟主流SD-WAN产品紧密相关了,而且更能体现出SD-WAN作为广域网云化这一生产方式变迁的发酵作用;此外,统一开放架构也还会进一步与其他相关领域综合演进,诸如云原生、NFV等。这些方面,稍后分析MEC时,会尽量做些力所能及的说明。

本节*后,回应一下一个潜在问题和一个潜在趋势:

  • 潜在问题:传统的安全功能还有用吗?当然有用,C语言不是也还至今顽强么;只不过在很多场合,可能需要适配到包括统一开放架构在内的范式框架中。
  • 潜在趋势:产业互联网可能会与SASE有什么样的关系?直接以5G为例,原文引用5G架构协议中的一些架构原则:
    • “Separate the User Plane (UP) functions from the Control Plane (CP) functions, allowing independent scalability, evolution and flexible deployments e.g. centralized location or distributed (remote) location.” 俗称的CUPS(控制平面与数据平面彻底分离),带来在独立伸缩性、演进性以及灵活部署方面的诸多优势。可以看作是基于分层设计以及基于统一开放架构方面的表现。
    • “Enable each Network Function and its Network Function Services to interact with other NF and its Network Function Services directly or indirectly via a Service Communication Proxy if required.” 每个网络功能和网络功能服务与其它网络功能和网络功能服务之间的交互,通过直接方式,或者以服务通信代理的方式间接完成。可以看作是基于统一开放架构方面的表现。
    • “Support a unified authentication framework.” 支持统一的身份验证框架。可以看作是基于身份驱动,基于分层设计,以及基于统一开放架构方面的表现。
    • 基于动态信任,作者当前暂未在协议层面找到,但可以理解,因为当前协议更多是在基础设施层面做规范,而基于动态信任有点偏向于业务建模方面。但即便如此,还是倾向于预测:在5G的各个层面,逐步都会有更多基于动态信任的体现。

SASE系列至此完结,下一话题会过度到5G MEC。如果要从事ICT行业,离不开参考协议,但协议可能比字典还厚,所以会侧重于对协议的导读和分析。听到过一些对通信行业的误解,觉得相对较大的一个就是“通信行业是协议驱动”,那就从澄清这个误解开始。

%title插图%num

后记

预测趋势要比预测时间点简单得多,一些分析判断:

  • 5G、物联网、边缘计算等技术革新,不是为了技术而技术,而是为了能将数字化、信息化、智能化,从消费互联网行业,延展到更为广阔的产业互联网领域。
  • 为什么产业互联网重要?因为第三次科技革命所能支撑起的消费互联网,已经接近尾声了,存量搏杀越来越激烈,政府、企业,都迫切需要新的增量来安抚“不安的灵魂”。
  • 那当下产业互联网为什么难做?除了技术原因之外,需要的主流创新模式不同。越上层的创新,复制起来也相对越快,这也客观造就了当下能直接复制解决的问题,大部分都已经解决了。这种情况下,需要ICT(Information and Communication Technology,信息和通信技术)领域与各个行业领域,能有更加广泛而深入的交流与融合,在原理层面相互理解贯通,才有可能孵化出更有意义的产品