最深的云网融合:多接入边缘计算(MEC)
作者:互联网
1.1 系列导读
本文是SD-WAN相关行业分析报告的完结篇。前两篇分别是:
第一篇:《SD-WAN行业理解:从广域网云化看SD-WAN》。提供了一个从“广域网云化”的视角去理解SD-WAN的思路:通过「行业背景」挖掘「行业本质」;通过「行业玩家」理清「行业生态」;通过「行业动态」推演「行业趋势」;通过「行业预测」预测「产品方向」。
第二篇:《从广域网云化推演SASE:面向物联网和边缘计算的SD-WAN演进》。承续前一篇的判断:“SD-WAN在单点技术上可能不是革命性的创新,但它改造的对象是广域网,后者已经是一项***到现代社会方方面面的基础设施,这种连接型创新会对整个行业造成非常深远的影响”。以“广域网云化和网络安全相结合”为例,推演当前最具前景的SASE:从「背景分析」挖掘「领域问题」;再从「领域问题」推演「产品分析」;再从「产品分析」梳理「行业玩家」;最后再回到「领域问题」,推演SASE的「未来展望」。
本篇填上两个旧坑和一个新坑:
为什么要关注“面向物联网和边缘计算的产品演进”?
为什么说“之前相对平行的行业(指传统行业和互联网行业)马上要见面了”?
为什么说MEC是最深的云网融合?
备注:所谓完结篇,是指之后不再特别提供SD-WAN视角的分析。也希望通过这三篇的分析报告,可以说明最初的看法:“SD-WAN不是一种技术,也不是一个产品,更像是一种生产方式的变迁”。SD-WAN的从业者,可以不必局限于SD-WAN;非SD-WAN的从业者,也可以了解一下SD-WAN。
1.2 本文导读
第二章,介绍基础概念,推演基本趋势,作为全文背景。
第三章,“最大的悲剧是战胜了所有对手,却输给了时代”。诺基亚之于苹果,余音缭绕;英特尔之于英伟达,历历在目。功能机的巅峰,输给了移动互联网时代;CPU的巅峰,输给了人工智能时代。做竞品分析时,最可怕的竞争对手,可能都没在视野范围内。本章从一则行业新闻开始,先从商业角度分析其相关性,再从技术角度分析其颠覆性。
第四章,从应用优化扩展到SD-WAN另一大广泛存在的产品形态:企业组网。本章将继续推演MEC在企业组网方面的新趋势,方便读者结合自己的业态分析竞合关系,规划产品演进。本章会从技术原理出发,重新回到MEC在商业落地上的独特优势。
第五章,为有兴趣进一步了解MEC的同学,提供一些说明。
备注:以上诺基亚指诺基亚手机;以下诺基亚指诺基亚网络。诺基亚有四大业务:手机,网络,软件和技术。
2 基础概念
2.1 什么是边缘计算
边缘计算是一种分布式计算范式 (distributed computing paradigm),它把计算和存储部署到更接近需要的位置(一般是更靠近应用的数据源或使用者),从而缩短响应时间并节省带宽。
Edge computing is a distributed computing paradigm that brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth. — Wikipedia
可以推出,CDN产品是边缘计算的一种早期形态;也可以理解,CDN厂商会是一类重要的行业玩家。
此外,既然是一种范式,边缘计算就会有非常多的落地形态,例如本文的主角,多接入边缘计算(Multi-access Edge Computing, MEC)。
2.2 为什么需要边缘计算
这个问题其实是与一系列问题高度关联的。推演这个问题的逻辑时,顺带也会推出“为什么需要物联网”、“为什么需要5G”、“为什么需要人工智能/机器学习”等一系列问题的答案。
以云计算为基础的算力爆发(算力) + 以消费互联网行业为代表的数据积累(算料) + 以深度学习为代表的人工智能算法突破(算法)= 令人兴奋的智能应用(智能);这个模式已经被实证了,并且三要素还在快速演进。
“Two things are infinite: the universe and human stupidity; and I’m not sure about the universe.” — Albert Einstein
人类的欲望是无止尽的。前三次工业革命解放了人类的双手,极大提升了人类的体力边界,第四次工业革命能否解放人类的大脑,提升人类的脑力边界?自然的第一步就是:能不能将已经实证的智能模式,扩展到其他领域?能。
智能的扩张需要数量更多的数据来喂养。物联网技术会将人、物、环境、过程等数字化,带来前所未有的数据广度和数据深度。这也会直接催化一个产业互联网的大势,比如行业估值惊人的工业物联网。
消费互联网过渡到产业互联网,会遭遇怎样的根本性矛盾?网络主体的变化必然会导致网络本质的变化:消费互联网的主要参与者是人,产业互联网的主要参与者是机器。人与机器有什么最大的不同?答案是人弱爆了:例如100ms的应用响应延迟,对人而言几乎无感,但对机器而言,可能已是“沧海桑田”了。
如何解决“快”的问题?一方面,就是以5G为代表的下一代通信技术。5G从设计之初,定位的通信主体就是物/机器,涵盖了对增强型移动宽带(enhanced Mobile Broad Band, eMBB)、大规模机器类型通信(massive Machine Type Communications,mMTC)、超可靠低延迟通信(ultra-Reliable and Low Latency Communications, uRLLC)三大场景的支持,为此重点投入到一系列关键技术:
切片(Slicing):三大应用场景属于“既要又要还要”的“无理要求”,太刺激太挑战了,需要通过切片技术让同一张物理网络具备变形金刚的能力,即将同一张物理网络按需动态切分成各个子网络。
控制与数据面分离(Control and User Plane Separation, CUPS):延续了4G的趋势,但是为了支持切片分离得更为彻底了,彻底到连网元的命名都功能化了。
基于服务的架构(Service-Based Architecture,SBA):核心网网元被彻底打散,各网元会按场景所需灵活部署到所需位置,架构上就借鉴了互联网行业松耦合的SBA架构。
用户数据面功能(User Plane Function, UPF):UPF是唯一的核心网数据面网元,也是MEC和5G网络的连接点,其灵活下沉的能力是5G实现三大场景的关键之一。
网络功能虚拟化(Network Function Virtualization, NFV):为了摆脱被硬件捆绑和被位置束缚,从核心网到接入网都被NFV搞得面目全非,各网元甚至都没了“正经名字”。
软件定义网络(Software-Defined Networking, Software-Defined WAN, SDN/SD-WAN):承载网应对三大场景挑战的大势所趋。
不过5G的网络再强,光速也会是一个无法突破的物理限制,那该怎么办呢?“山不过来,我就过去”,把计算和存储,部署到更靠近数据源或用户的位置。这不就回到了边缘计算的定义了么。
图2-1: 5G的三大应用场景;来源: https://www.etsi.org/technologies/5g
以上,边缘计算和5G、物联网、人工智能/机器学习等领域,都是产业互联网时代,或者说“泛智能时代”的必然趋势,只不过各有分工侧重而已。
小结一下,为什么需要边缘计算?突破以下限制:
物理限制:端到端的应用时延无法突破光速。
安全限制:特定行业要求数据不出园区。
经济限制:原始数据直接回传会产生大量的带宽费用和存储费用(一辆智能汽车一天产生的数据量约为4TB — Intel),在近数据源预处理后再协同,可以极大地降本增效。
网络限制:莫非定律,突破对可靠连接的依赖。
图2-2: Imperatives That Determine the Value of Edge Computing;来源: 2021 Strategic Roadmap for Edge Computing
2.3 什么是多接入边缘计算
理解了什么是边缘计算,那么什么又是多接入边缘计算呢?
多接入边缘计算(Multi-access Edge Computing, MEC)在网络边缘为应用程序开发者和内容提供商,提供了云计算能力和IT服务环境。这种环境的特点是超低时延和超高带宽,并且应用程序可以使用无线网络侧的实时信息。MEC提供了新的生态系统和价值链。运营商可以向授权的第三方开放其无线接入网的边缘,从而使他们能够灵活、快速地向移动网络用户、企业用户和细分垂直市场,部署创新的应用程序和服务。
Multi-access Edge Computing (MEC) offers application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network. This environment is characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that can be leveraged by applications. MEC provides a new ecosystem and value chain. Operators can open their Radio Access Network (RAN) edge to authorized third-parties, allowing them to flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments. — ETSI
值得一提的是,“超低时延和超高带宽”很直观很好理解,“可以使用无线网络侧的实时信息”又有什么特别之处吗?太重要了!应用程序具备了获取实时无线信道特性的可能性,当前没有比这更为彻底的云网融合的方式了。科班同学可以回忆一下数字通信原理,信道编码的目的就是基于不同的信道特性,设计出匹配信道特性的码元,从而提升整个系统的抗干扰能力,发挥最大的系统性能。不是相关专业的读者,有兴趣的话可以参考下图的来源链接;暂时不理解也无妨,后续会拆解多个相关用例,给出多个形象化的说明。
图2-3: 数字通信系统原理;来源: http://www.ecsponline.com/yz/B0DA2CFC0D1DC4C279849FF3A55BE9F1A000.pdf
备注:无线接入网(Radio Access Network, RAN)是移动通信系统(有时也被称为“蜂窝移动通信系统”)的重要组成部分,就是手机直接连接的这个网络;后续会结合上下文需要,逐步给出相关介绍。
2.4 为什么需要MEC
十亿级人口,千亿级设备的第一入口,并且可以支持广域网级别的移动性,这个理由足够了吗。
2.5 MEC的现状
多接入边缘计算,原名移动边缘计算(Mobile Edge Computing, MEC),这个概念最早出现于2013年。
2013年,IBM与诺基亚网络共同推出了全球第一款移动边缘计算平台,可在基站侧提供富媒体服务。
2014年,欧洲电信标准协会(European Telecommunications Standards Institute, ETSI)成立MEC规范工作组,正式宣布推动MEC的标准化。
2016年,ETSI把MEC的接入方式从蜂窝网络扩展到WLAN等其他接入方式,即把移动边缘计算的概念,扩展成为了多接入边缘计算。
此外,MEC还将作为5G的关键技术之一,用于支撑5G的低时延业务场景。2020年12年,ETSI发布了5G MEC集成报告,并宣布扩展规范工作组的对应职能。所以,可以认为当前MEC标准由ETSI和3GPP共同制定:ETSI负责定义整个MEC的框架和架构,包括应用部署环境,管理软件架构、应用场景和API接口等;3GPP负责定义5G网络对MEC的支撑和实现,以及如何提供服务质量保障。
3 MEC在应用优化领域的融合演进
3.1 从一则新闻说起
2020年04月29日,中国联通首张MEC规模商用网络正式发布。其中披露:2019年,中国联通联合腾讯、中兴在深圳进行了基于MEC的vCDN边缘加速和TCPO的规模化商用试点验证。一方面,通过MEC边缘云与部署在云端的DNS、CDN及移动客户端联动,利用MEC实现vCDN下沉和本地流量卸载,减小时延提升用户感知;另一方面,在MEC部署TCP优化能力,解决无线丢包导致的服务器降速问题。本次商业试点涉及近百个现网基站,日用户连接建立数最大近3万,忙时小时粒度流量达到2.5T。测试结果表明,通过部署边缘vCDN,平均降低40%接入时延,并减少30%卡顿;通过部署TCPO功能,上传平均速率增益15%,下载平均速率增益56%,可极大提升用户体验。— 声明:利益不相关
这则新闻包含了两个关键特性:
通过部署边缘vCDN,平均降低40%接入时延,并减少30%卡顿
通过部署TCPO特性,上传平均速率增益15%,下载平均速率增益56%,可极大提升用户体验
为了简化分析但不失逻辑,这里把vCDN特性,简化为静态内容加速方案;把TCPO特性,简化为动态内容加速方案。
鉴于当前的SD-WAN类型产品,一大卖点就是“提升应用体验”,所以先从商业竞争角度分析一下关联性:
这则新闻说明了什么?诞生了一种新产品,可以大幅提升最终用户的应用体验,包括静态内容和动态内容。
新产品的产品形态?不需要额外的硬件和软件,后台可以即时开通,即可以做到最终用户无感开通。
新对手是谁?好家伙,巨无霸,进来一个基础运营商。
新产品的供应范围?理论上只要是基站信号可以覆盖的区域,都可以提供。顺便插播两则“坏消息”:
作为基建狂魔,中国是全球基站信号覆盖最好的国家之一。
中国的智能手机普及率为69%。上限在哪呢?可以参考一下其他国家:美国为77%;同属东亚文化体系的韩国为94%,即东亚人相对更加腼腆,更偏好智能终端。
新对手的客户资源?理论上拥有包括消费用户和企业用户在内的所有用户。开发存量客户和开发新客户之间的难度差别,不可同日而语。对手一次原型测试,就可以做到“日用户连接建立数最大近3万”。
小结一下对比参考:
客户资源:对手在接入侧掌握着全部用户,即上述的“十亿级人口和千亿级设备的第一入口”。
开通速度:对手可以零等待,无感开通。
边际交付成本:对手几乎零成本。
产品价值 = (新体验 - 旧体验 - 迁移成本) x 用户规模
在“迁移成本”和“用户规模”方面,对方完胜;在2B市场的品牌形象方面,对手也具有压倒性的优势。剩下能比拼的就是在特定的细分场景下,“新体验”和“旧体验”之间,到底有多少差异了;当然还有就是时间问题,时间会影响稳定性和价格等。不过,因为对手掌握着全部客户,并且可以做到无感交付,这意味着一个什么样的战略态势?“先为不可胜,以待敌之可胜”,所以,时间站在了运营商那一边。
以上是外部视角分析,新产品落地时需要考虑的问题很多,远非外部视角分析那么简单。本文的目的也不是为了制造焦虑,而是为了提供新维度,便于读者结合各自的内部视角进一步分析。
备注:vCDN边缘加速,前期大概率不是为了和当前的CDN产品去做商业竞争,而是为了解决运营商自己的回传压力,也就是说,初衷可能是为了与同等规模的运营商去竞争网络体验。但在另一个维度上,它同时也是坏消息,“神仙打架,凡人遭殃”,即使不直接参与商业竞争,也是会和CDN厂家合作演化,在源头直接消灭一批客户需求。
3.2 vCDN边缘加速
以下从技术角度,继续挖掘这则新闻。vCDN边缘加速,更为正式的名称可能是:移动边缘缓存本地内容 (Local content caching at the mobile edge)。该用例是MEC众多用例中,技术难度相对较低,容易早期实现的,其本质是“将CDN功能下沉到基站”。
第一个问题:我们不是已经有了CDN吗,为什么要在移动边缘缓存本地内容?
在回答这个问题之前,以及为了便于真正理解MEC,需要先做一段预备科普。
互联网行业人员,习惯把运营商网络叫做“管”,习惯了之后就容易被迷惑了。这个所谓的“管”,其实是一个庞大而复杂的系统,可能是世界上最为复杂的民用系统之一。以移动通信网为例,在最宏观层面进行拆解,可以分为无线接入网(Radio Access Network, RAN)、核心网(Core Network, CN)和承载网三部分。我们的手机通过各种制式的无线接入技术(Radio Access Technology, RAT)连接到无线接入网;无线接入网再通过各种回传(Backhaul)技术连接到核心网;经过核心网之后,才会进入互联网。大家所熟悉的CDN系统,大多就部署在核心网之后,其实离最终用户很远,可以参考下图。
图3-1: Mobile Network Problems Before MEC;来源: https://qwilt.com/5g-mec/qwilts-5g-mec-solution/
有了对移动通信网络的预备科普之后,为了能理解问题的本质,还缺了对其承载的主要业态的推演。
现阶段的互联网有个别称,叫“移动互联网时代”,它的几个特点:1、人是网络主体;2、智能终端已普及;3、高速网络已建立。有一个行业的充分条件已经具备,只缺在源头推它一把,这个源头就是:人类是一个特别有八卦精神的种族。在移动互联网时代,每个人都有一个可以随时随地随意匿名生产/消费八卦的终端,任何一个火星,都有可能激活一个链式反应,被网络急剧放大,造就了一大批新型社交媒体类型的巨头:Facebook、Twitter、YouTube、Instagram,微博等。热点会以病毒式传播,多媒体内容会在同一地区,几乎同时被消耗很多倍,而被寄予厚望的CDN系统,对此却无能为力。
综上,移动互联网在逻辑结构上适合社交媒体业务的发展,但在物理结构上又难以适应它的爆发,结果就是:普罗大众盼着第一时间吃瓜的体验不爽;运营商在管道层面承受着巨大的压力;需求被层层上捅之后,就容易导致丁振凯,史上最惨新浪程序员。呜呼哀哉,我等无辜码农是相对最不八卦的群体了,最终却被八卦伤得最深。
究其原因,根源就在于当前的内容分发系统(比如CDN),与移动通信系统,是两套相对独立的系统。移动通信系统,就负责通信,真的在认认真真做管道,属于运营商的强管控范围;内容分发系统,是一套互联网应用系统,属于互联网公司的强管控范围,两者是脱离的。
如此,通过MEC部署vCDN的价值及意义,相对就更加明确了。MEC可以在最接近用户的地理边缘,缓存本地热点内容。最终用户可以大幅提升用户体验,运营商可以节省回传费用,内容提供商也可以躺着增收。
图3-2: MEC - Outcomes for Mobile Service Providers;来源: https://qwilt.com/5g-mec/qwilts-5g-mec-solution/
备注:
以上“八卦”是个中性词,包含着“看看别人在干些什么,然后发表评价/发挥想象/结成群体”等广义含义,没有贬义成分。八卦其实是个严肃的话题,它是人类社会的根基,是人类得以在万千物种中胜出的根本。有兴趣可以参考一下《人类简史》。
为了避免画图找了两张示意图。图片来自国外公司,所以出现了“Mobile Backhaul”的无线回传方式。国外普遍挖沟不便,采用无线方式回传相对较多,我国国情不同,多采用有线回传方式,特此说明。
应用系统和移动通信系统两者的脱离,有移动通信系统技术演进方面的历史原因。移动通信设备,长期是一个“系统复杂,硬件专用,软件定制”的相对封闭的行业,但也是一直在努力往“通用化-池化-云化”方向努力,部分读者可能听说的C-RAN(C一般是指Centralized,在不同的上下文中,也可能指Clean, Collaborative或Cloud)就是一个最好的例子。O-RAN就又是在这方面一个喧闹的方向,喧闹到已经可以看到国家层面的博弈了。不过在技术上,在争论的可能更多是一个“迈多大的步子可以不扯到蛋”的问题,很欢乐很有意思,而且MEC会与O-RAN之间存在较强关联,有兴趣可进一步参考相关文档。本文已很长,不再展开。
3.3 TCPO特性
中国联通在白皮书中也给出了“基于MEC的CDN边缘加速方案图”,包含了vCDN特性和TCPO特性。
图3-3: 基于MEC的CDN边缘加速方案图;来源: 《中国联通5G MEC边缘云平台架构及商用实践白皮书》
这类PR的方案图一般经过处理,只会让你看到“牛逼”不会让你看到原理,以下就从外部视角来做一下相关的技术拆解。
TCPO特性,更为正式的名称可能是:基于TCP吞吐指引的移动视频分发优化(Mobile video delivery optimization using throughput guidance for TCP)。名字中带着“移动视频分发”是因为视频是移动网络上最受欢迎的内容(占总流量的55+%),但是这类TCP优化特性,并不局限于视频应用,可以适用于所有基于TCP的服务和应用,包括Web业务和文件下载。
TCP吞吐指引特性,应该会是直播、在线教育等实时音视频领域玩家感兴趣的,因为一些常用的流媒体协议,要么直接将TCP做为传输协议,例如Adobe的RTMP(Real Time Messaging Protocol),要么会基于HTTP流来完成,而HTTP流又通常基于TCP协议,比如Adobe的HTTP-FLV,以及Apple的HLS(HTTP Live Streaming)。
一个类似的问题?不是已经有了很多实时音视频优化类产品了,为什么还要MEC的TCP吞吐指引特性来优化?
也是一样,在回答这个问题之前,以及便于深入理解MEC,还需要再做一段预备科普。
在移动通信系统中,无线接入网的信道条件,其复杂性要远远超过固定网络:天气、地形、建筑、从步行速率到高铁速率的各种移动性,从普通电话到高清视频的各种多样性,导致了“只有想不到,没有不可能”的信道复杂性。一个最平凡的例子,你身边的任何人,都可能会随时进入网络并随时离开,这些都会造成系统负载和信道条件,在几秒之内就发生一个数量级的剧变。而在另一方面,TCP太古老了,在发明TCP时,压根就没考虑过无线信道这回事。到了移动互联网时代了,大量的应用被搬到移动环境了,TCP也就只能硬着头皮上了。这好比:你明明学的是计算机,但过年回家总会有亲友让你帮忙修一下电脑——你心里明明知道这可不是一回事,但也只能硬着头皮上,毕竟舍你其谁,你说是吧。
综上,传统的TCP难以适应快速变化的网络条件,会导致无线网络资源的低效使用,最终降低移动应用的性能和最终用户的体验。
在进一步介绍TCP吞吐指引特性之前,可能还得再来为细心的读者解答两个可能的疑问:
既然TCP那么不适应无线环境,那为什么不干脆在开启移动互联网时代时另起炉灶?这是因为基础设施行业具有很强的传承性,有时候比拼的不是技术的先进性,而是方案的传承性:你可以在旧方案上修补,但是不能完全抛弃。比如,即使都已经进入高铁时代了,车厢的宽度最终还是要取决于两匹马的马屁宽度,你到哪里说理去?有什么技术先进性可言吗?
好吧,听上去这是一个普遍的问题,那为什么不在运营商这一端做代理?本质上还是一样的原因,这会突破“通信系统”和“应用系统”之间的边界,之前缺少一个类似MEC这样的落位。这不仅仅是地理上的落位,也包括逻辑上的落位。而且,事实上MEC和TCP吞吐指引在4G时代就已被提出,但是并不普及,只不过在5G时代,MEC不再是一个锦上添花的分支,而是变成了一个系统必需。
终于可以来介绍一下TCP吞吐指引特性了。TCP吞吐指引是一个基于MEC服务构建的带无线分析(radio analytics)功能的MEC应用程序,它可以为后端的应用服务器提供接近实时的无线信道质量指示,这个指示叫做吞吐指引(Throughput Guidance, TG)。吞吐指引是一个特定于应用程序的数字,它为应用服务器提供了一个在即将到来的时间周期内,无线信道可以预期承载的比特率的提示,应用服务器可以据此信息来辅助TCP拥塞控制。有了吞吐指引,TCP就可以不必为探测可用资源而导致网络过载,也不必在拥塞发生后像传统算法那样过于保守。
互联网工程任务组(Internet Engineering Task Force, IETF)已经给出了吞吐指引的原理、方案及效果。ETSI也给出了在MEC运行TCP吞吐指引的参考模型:
启用带有吞吐指引功能的应用程序后,将使用MEC平台的服务注册表(service registry)来查找可以提供无线网络信息的服务程序(service)。
通过MEC平台,应用程序在连接匹配的服务程序后,可以获得所需的无线网络信息,然后计算出特定于应用的吞吐指引,然后通过MEC平台将吞吐指引带内传送给应用服务器。
终端用户设备上的客户端,可以不做任何修改。
图3-4: Throughput Guidance Mechanism;来源: IETF:https://www.ietf.org/proceedings/93/slides/slides-93-iccrg-3.pdf
值得说明的是,第一句其实是重要的,暗含了MEC里的生态关系。运营商是没有能力解决万千应用问题的,他们有很大的战略优势,但也需要整个生态的配合。MEC的魅力之一,也在于它第一次提供了一个极好的云网融合的协作平台,在这个生态里,目前可以预测的有:
网络运营商(Network Service Provider):不同运营商有不同的覆盖范围。
房地产商(Real estate owner):比如中国铁塔、各类园区和综合体等。
云厂商(Cloud capability provider):这是一个大类,可以进一步细分,比如提供计算能力的,提供存储能力的,另外一个细分维度是提供资的和提供服务的,等等。
应用服务提供方(Application/service provider):一方面跟当前应用市场类似,可能会有个人开发者和公司等多种形态;另一方面也会具有云市场的一些特点,即有些供应商它不直接生产软件,但会基于第三方软件提供服务。
有能力的玩家,可以身兼多职;而且觉得ETSI有点回避了平台方这个角色,可能会是个“既心知肚明又暗中较劲”的领域吧。
There is more than one stakeholder in this ecosystem, e.g. Network Service Provider, Real estate owner, Cloud capability (compute and storage resource) provider, Application/service provider. An entity can assume more than one role. From network operators point of view there may be “Cloud provider” or “Cloud service provider” depending on the roles assumed by external entity.
以上,可以看出TCP吞吐指引特性在技术上并不复杂,逻辑抽象之后就更为简单:特定于应用的吞吐指引生成器,可以看作是应用服务器部署在无线接入网侧的一个分布式组件,如下图。
图3-5: Throughput Guidance Solution Architecture;来源: IETF:https://www.ietf.org/proceedings/92/slides/slides-92-tsvwg-12.pdf
TCPO的实际效果,联通已经在生产环境中给出,此外,IETF也给出了吞吐指引在改善传统TCP慢启动方面的实测图,对比感更强。
标签:云网,WAN,MEC,接入,网络,TCP,边缘,移动 来源: https://blog.51cto.com/u_15127593/2737334