智联边缘： CDN算网联动新范式
内容介绍：
一、淘宝HTTP3升级实践
二、阿里云CDN QUIC应用升级
三、鸟瞰CDN边缘流量计算应用生态矩阵
四、新一代Web架构-基于边缘应用开发者平台高效构建低延迟、免运维的前端边缘应用
一、淘宝HTTP3升级实践
本次分享的主题关于QUIC传输加速实践的分享。首先从应用厂商的角度，从2019年往前更早的时候，关注整个传输网络传输方面发展的最大的技术突破就是QUIC对于TCP新的传输协议栈的发展，在一九年发现就是当时行业的开源的解决方案都不能很好的解决问题，因为希望在APP端上有轻量级高性能的的传输协议栈，并且它能够实现跨平台和整个包大小的优化。
在一九年的时候就启动IETF QUIC阵眼，经过两年的闭关的研发，在二一年的时候开始在线上做规模化的验证，发现在线上的整个传输的优化效果还是带来巨大的突破，因此在2022年正式把这一套方案对外做开源，现在其实github上可以看到就是XQUIC的整个传输协议方面的源码，后续就是进一步会在多路径的传输，包括IETF最新的多路传输的标准方面进行持续发力，包括和合作伙伴进一步推动整个行业传输技术的演进。XQUIC的整个核心的优势首先继承所有IETF QUIC的传输所带来的加速的性能效果，包括它在建联方面的像0-RTT的优势，包括像ACK的设计性上的优化，在安全方面也是完全能够继承到TLS/1.3包括QUIC TLS核心的优势,带来传输方面的前向安全性的核心，在工程实践方面，针对就是拥塞控制算法，可以做到灵活的插拔，并且整个拥塞控制算法的模块化可以为下一步通过AI的整个方法驱动拥塞制算法的传输加速打下坚实的基础。
从二一年开始做整个线上的规模化，最早是从二零年开始线上做部分的试点，到现在为止已经把整个线上所有淘宝的核心场景都转变成基于XQUIC HTTP3做整个传输，可以看到在各个核心场景下面取得比较好的传输性能优化的效果，包括在整个RPC的调用下面，有近20%以上的传输耗时的优化，和CDN的合作伙伴做紧密的配合，在图片和视频方面，整个传输的速率上也是有重大的突破，视频下载速度是几乎提升一倍，在图片的长尾的传输的优化效果上面也是有将近15%以上的耗时的优化，在整个IETF QUIC的标准方面最新的技术就是多路径传输的技术。
它会在整个网络传输方面带来新的核心的优势，它能够支持双路的鲁棒性的传输。可以通过在终端上面和服务端配合把多条的物理链路的整个带宽，做充分的利用，实现双路的聚合加速的效果，实现带宽上线的突破，对于过去的单路是巨大的在带宽利用率上的提升，其次对于像终端上碰到的一些wifi的信号弱，包括就是单路的信号有波动的情况之下，可以通过像wifi和蜂窝的双路的鲁棒性的传输实现，就是整个传输层面的平滑，包括针对入网场景下的对抗。
其次在传输协议栈层面也做了非常灵活的设计，可以针对各个应用场景下定制多路的解决方案，从而使得针对各个应用场景下面能够达到最佳的实践效果，想要用好整套多路径的加速特性与优势，就需要在端和服务端之间呈现整套多路径的调度的算法。它的核心实施是需要在端和服务端之间基于多条路径的指量的情况，包括RDT丢包率以及一些延迟和带宽的标准信息进行多条路径上的数据包的调度，通过这套端和服务端联动的算法，可以实现整个端到端的整个加速特性的最大化，这套的加速特性在整个包括RDC和图片的场景下面验证，针对长尾是有10%以上的耗时的优化收益，可以看到针对最新的IETF QUIC的发展，除了最火热的HTTP/3标准的应用层的传输实现之外，针对Web方向也有Web Transport的整个协议栈的发展，针对其实最新的流媒体的传输方向，也会有Media over QUIC的整个生态的发展，可以看到整个QUIC传输声带是在持续的发展和繁荣。
针对这一套解决方案的开源是希望能和大家共同促进整个业界技术的发展。这套开源方案可以无缝衔接到云的CDN产品上，享受整个加速性能所带来的优势。
二、阿里云CDN QUIC应用升级
在刚才的分享过程中，大家对于淘宝XQUIC的规模化应用历程有非常充分的了解，以及QUIC在耗时优化和传输的安全稳定性上的效果有非常的显著，在了解淘宝的优秀实践之后，在阿里云的CDN场景上支持QUIC应用,接下来介绍阿里云CDN QUIC的产品在CDN场景下的特点，阿里云的QUIC的有四大特点，一个是比较易用可靠，另外是功能很丰富，一直在持续的进化。第一个部分是应用可靠，QUIC在阿里云CDN的控制台上是一键开启的，开启之后它其实就和TCB是无缝服务，不需要做其他的任何的切换或者设备。对于阿里云QUIC服务的客户端有来自像CHROME XQUIC NGTCP2,包括QUIC-GO是主流的客户端都有比较好的服务质量，如果从HTPS切换到QUIC没有任何成本。当前QUIC在CDN的部署情况是全网3200个节点已经全部覆盖。核心域名图片包括视频都是已经百分之百到QUIC。
在当前CDN的QUIC的量大概有10%左右，虽然QUIC功能在AliCDN是一键开启，但是为设备各种各样的场景和需求支持各种有特色的定制，比如针对连接设置不同的拥塞算法,控制不让浏览器进行流量访问，希望自己控制进行流量切入，避免干扰流量。在客户侧定制服务端的传输行为，比如可以设置初始化拥塞窗口，或者是使能Multipath和HTTP/3的优先级控制的行为。另外支持客户端主动进行自己的配置圈的选择。这种功能在做ab测试的时候就比较有作用，可以很方便的比较a选项和b选项性能的差异。也支持QUIC日志的输出，在QUIC是天生是与TLS1.3是嵌在一起的,TLS1.3安全性和速度方面，带来在安全情况下能保证效率的组件。
但是在不同场景下，比如图片或者视频的安全性不是那么重要，可以通过降低安全性的套件提升服务体验，可以支持自定义TLS1.3的加密套件。另外如果客户端在进行加解密操作的时候是比较浪费电，也支持对QUIC协议进行额外的拓展，支持明文进行传输，实测效果可以显著的降低视频的卡顿率。另外也支持国密的套件，在比较对安全要有很高的场合，不需要把私钥托管在CDN，由客户端自己安装服务，这个服务是安装在客户端自己的机器上的，基于这个服务可以实现完整的SSL服务，性能优化对于CDN和对客户都是一目了然的，这是服务端的监控，对像RTT测量 SSL故障 Stream ACK的指标 丢包检测都可以看到，当做一些策略调整的时候，这边指标就是对动作的评估，同时异常也能够及时发现，甚至可以做成告警。在实际服务客户过程中，不仅要跟踪到趋势，还有边缘的case需要排查分析，比如弱网情况下也支持全链路的日志提供，就是达到连基于连接级的，在日志里面可以输出RTD测量，可以输出拥塞算法的内部的状态。可以跟踪到每个具体的客户端的收包时间，这些都可以完整的进行提供，QUIC是一个非常庞大的生态，结合着各种不同的客户需求和不同的断边能力持续进化，通常情况会有一些客户说开启的规格之后，它质量好像不是很明显，这种情况下一般都会和客户进行调优合作。
首先双方沟通调优目标，对齐质量指标的情况，基于阿里CDN非常健壮的平台，可以快速的搭建实验平台，基于实验平台可以进行部分导流进行算法调优，算法调优就是基于趋势分析以及日志分析，看某些场景下传输行为是否符合预期，在适配场景之后，同时把经验及时的分享给其他的客户，比如下面这个短视频场景会用到算法，以及在图文场景会用到算法，对所有客户都是受益的。让多路径算法在CDN场景下落地服务更多的客户。因为CDN服务非常多的客户，是非常要求稳定性的系统，在这个体系下构建新的协议进行实验性的分析或者开发，得益于阿里云CDN的完整和健壮的系统，可以做到按需弹性部署，比如实验流量是在杭州，可以在杭州弹性出实验平台出来，同时对它进行资源隔离、故障与隔离，实验平台质量问题都不会影响稳定的线上环境，到目前为止典型的客户的收益，在短视频领域的下载速度能够提升30%，APF大文件下载耗时下降40%以上，图片场景有14%的下载耗时的降低，锁屏渲染线能有6%的降低。
三、鸟瞰CDN边缘流量计算应用生态矩阵
对CDN的QUIC的应用以及未来持续优化的方向有更全面的认识。接下来本场智联边缘主题分享聚焦于新一代边缘流量计算产品CR的能力与应用，主题分享是边缘流量计算应用的生态矩阵，继续探索基于流量的边缘计算场景的生态矩阵。
在位于边缘的IDC中，阿里云建立一朵完整的边缘云，用来处理各种流经边缘节点的流量，阿里云基于流量的计算产品叫做EdgeRoutine，它本质上是传统的CDN产品，这是一种纯面向流量分发的产品，传统的CDN在边缘计算时代的演进，EdgeRoutine在边缘节点上提供多种位置无感的serverless的计算形态，包括fast的函数计算形态，和直接上传镜像的容器计算的形态，是分别面向轻重不同的算力需求，同时针对计算场景的数据存储和数据缓存的需求，提供缓存和存储相关的组件。最后对于外部交互的情况，因为写程序总是要和各种外部的数据或者是外部的站点进行交互。例如要访问资源在国外或者弱网的环境，也提供相应的网络加速能力，针对动静态资源都可以进行访问加速。所以看到典型的EdgeRoutine应用是运行在边缘节点上的，它依靠CDN成熟可靠的边缘网关提供安全防护负载均衡的各项功能，同时复用CDN的高并发的超大容量的缓存能力，当客户端的流量流经边缘节点的时候，它就可以被客户自己编写的EdgeRoutine程序，接受请求进行各种处理或者是加工，在和外部交互的时候，ER程序利用CDN加速链路进行访问加速，现在进一步观察函数计算服务的能力。
函数计算服务本质是基于javascript V8引擎的isolate机制进行租户间隔离,isolate机制相对于传统的容器和虚机来说，它更轻亮和高效，导致冷启动时间延迟特别低。对于做位置无感的边缘计算场景是非常有意义的，基于V8整个自研的底层计算引擎，实现对deno node等js生态的兼容，再加上全球节点调度，节点内调度，进程类调度，做三级的资源调度体系，整体配合引擎实现低延迟地域无感以及部署方便的serverless的fast服务。针对Web应用场景特别适合，Web应用场景的典型特点就是计算量比较低，但是它是IO密集型，延迟和消耗比较低的引擎最适合于这种场景。而对于更重量级的计算场景，例如边缘的AI应用、推理、训练各种场景，以及大数据量的计算，比如日志汇聚的场景，在边缘开放容器计算的服务，容器计算具备地域无感的弹性伸缩能力，全球节点调度系统实现延迟低于一分钟的节点间的流量调度，同时在节点内部，容器的弹性能力也已经低到十秒钟左右，容器和轻量级的isolate机制不一样，所以延迟到达秒级。它仍然是业界领先的低延迟能力。这意味着针对突发流量，十秒内资源就可以开始进行弹性伸缩，突发流量实现削峰填谷的效果，计算离不开数据。
在边缘计算的应用场景中，除了客户端发过来的请求数据之外，很多时候需要与外部的站点进行交互，与中心IDC网络不同的是边缘节点分布比较广泛，它的网络条件是更加复杂的，利用网络访问加速的服务，可以通过全球的选入机制，复用CDN稳定可靠的网络链路，为动态或者静态的内容同时进行访问加速。同一时刻可以享受到CDN多年积累的网络协议栈的优化的效果。而对于计算结果的缓存或者是存储，在边缘也提供缓存和KV存储两种方案，缓存方案是直接复用的经典的CDN的缓存组件，通过HRoutine的编程，既可以实现传统CDN链路上缓存的自定义修改，也可以将边缘计算的应用计算的结果进行暂存，从而进一步降低计算的消耗量。而另一方面KV存储服务是通过自研的全球最终一致性的存储系统实现的，通过KV存储服务，可以实现在EdgeRoutine程序中间持久化的存储KV数据，所有在边缘和中心写入的数据都会通过gossip网络,在十秒钟之内同步至全球99.5%的节点。
KV存储解决EdgeRoutine程序的配置问题，传统上程序在运行的时候，它会需要配置文件提供各项程序的配置，而在这个函数计算的场景下面,不存在传统的配置文件，这个时候可以利用KV存储实现程序的配置功能，以上就是Edge Routine各个组件的详细介绍。再次回顾边缘流量计算的生态矩阵的全图。首先通过CDN经典可靠的边缘网关,向EdgeRoutine程序提供安全防护和流量接入的能力。有两种不同形态的计算服务，为多种计算负载提供不同的算力支持，包括fast的计算引擎和容器的计算服务。也有缓存和KV存储两种不同的存储方案，分别针对数据的暂存和数据的持久化存储提供服务。在与外部的数据交互的过程中间，通过加速服务，复用经典的CDN链路对访问过程进行加速。最后所有的生态组件都接入统一的监控服务和日志服务，供研发和运维人员监控程序状态，以及进行程序的调试和程序的运行过程的监督，这就是整个生态矩阵的全图。
四、新一代Web架构-基于边缘应用开发者平台高效构建低延迟、免运维的前端边缘应用
对ER的计算、缓存、存储的能力以及ER与CDN之间的全面的交互有初步的认识。在了解具体能力之后，下面分享新一代Web架构基于于边缘应用开发平台，高效构建低延迟年运维的前端边缘应用。通过边缘开发者平台帮助用户构建下一代Web应用。当前社会上绝大部分的商业行为都是通过网络连接用户，通过企业提供的网站点实现购买消费等行为，从而实现商业上的转换，网站的转换率和企业的收入是直接相关的，对于转换率最影响最大的因素是网站的性能，所以帮用户提升网站的性能。
首先看传统的Web架构，目前业内绝大部分公司采用的都是CSR的前端架构，Client Side Rendering就是相当于用户请求企业的站点，先向服务器发请求，首先拿到HTML的壳子，这个壳子里面其实是没有任何内容的，只有前端静态资源的链接，用户加载完HTML之后，它是白屏的状态。浏览器请求前端的javaScript CSS,图片加载好之后运行完，生成网站的内容，CSR瀑布流会造成页面白屏的时间比较长，让用户感觉到网站好慢，性能不好影响转换率，有部分企业开始采用SSR的架构，像淘宝 支付宝，现在有很多业务都是SSR架构，把页面渲染的流程放在服务端，在服务端提前渲染好所有的前端的页面，直接返回浏览器或者手机端，用户就能够更快速的看到网站的内容，性能会非常好，传统SSR虽然能提升网站的性能，但是会遇到挑战，首先是实验的挑战，渲染服务是中心化的部署，比如渲染服务部署在杭州，但是用户在东北或者在新疆，这种远距离的物理网络距离会带来时延。第二个就是SSR是一种比较消耗CPU的计算，如果流量突增，大量的用户突然对业务进行访问，会让渲染服务过载宕机。
最后需要花不少的精力和时间构建像异地容灾的高可用架构，这些都是传统SSR架构带来的成本和挑战，通过CDN的产品帮用户解决问题。引入ESR (Edge Side Rendering)概念，就是把原来用户在源站进行渲染的服务下沉到边缘，在CDN节点上进行渲染，这样就能解决上述的三个挑战，第一个就是超低延时，基于CDN全球的调度系统，能够在访问用户的就近节点进行边缘计算和边缘渲染，解决物理距离带来的时延。并且Edge Routine是一种高性能算子。它的冷启动时间只有十毫秒，这个是非常好的性能。其次天然支持高可用高并发，因为在全球有3200个节点，基于CDN的全球负载均衡能力，天然支持高并发的能力。最后能够让用户能够快速的将它的应用嵌入到边缘，EdgeRoutine的Runtime是兼容Node.js和Deno的生态，绝大部分前端的开发者不需要再学一套新的语言，或者不需要再学后端语言。只要写前端的javaScript，就可以写边缘应用。
同时还为边缘应用打造开发者喜欢用的CLI工具，接下来介绍阿里云控制台下沉到CDN，ESA产品的控制台本身就是用EdgeRoutine做边缘渲染加速。整个流程就是用户访问控制台的域名之后，首先打到ESA的节点，到节点之后，去源站请求HTML回来，开始做渲染的工作。在EdgeKV里面获取提前缓存的前端渲染代码，在ER上进行渲染，把渲染的结果做缓存，下次再请求的时候就不用再做渲染，实现超高性能的返回。与此同时可以利用流式返回提升整个HTML的首字节的响应时间。最后通过这一系列的手段大幅的提升站点的性能，这是性能的对比，左侧是用ESR架构访问的ESA控制台，右侧是用传统的CSR的架构，可以看到左侧是非常快速的出现整个页面的内容，要比传统的CSR要快很多，性能大概提升40%以上。
最后介绍高效的开发边缘应用，第一个就是为EdgeRoutine量身打造ESA-CLI，能够高效的开发的边缘应用。播放简单的demo，大概用两分钟的时间，就可以从零到一部署全球可以访问的边缘应用。首先初始化项目，取名字和选模板，并且gate工程初始化已完成，进入到项目里面，所有的模板代码都是生成的，可以开始进行开发和调试。启动本地调试的命令，可以在本地模拟边缘的Runtime执行边缘程序。按快捷键打开在本地能够访问的边缘程序，在18080本地端口可以看到效果，可以一边改代码，一边看效果，把代码向全球进行部署。
执行ESA commit的命令，把这个代码发布，登录也是采用阿里云的账号体系，使用的是xsk和xsSecret，把阿里云的账号的AKSK粘贴在这里就登录成功，登录完之后继续发布代码，给这次提交写描述，方便后续的维护。选一个函数的规格和版本，选发布的环境，可以支持在线上发布，灰度环境发布和测试环境发布，最后要提边缘程序添加全球可以访问的域名，这里添加自己使用的测试域名，添加完成之后，就能获得在全球可以访问的具有超低时延，支持高并发高可扩展性的边缘程序。最后在控制台上提供两个关键核心能力，第一个是边缘程序EdgeRountine的性能监控指标，它有丰富的性能数据，能够帮用户更好的提升边缘程序的性能。第二个提供实时的计时日志查看，能够实时的查看在线运行的边缘程序的访问日志，更好的在线上排查线上的问题。
