CDN除了加速外，不断被赋予更多价值。在阿里云CDN推出的《极速奔跑吧 2021》首场直播中，阿里云架构师和产品经理不仅对近期阿里云发布的CDN产品最佳实践图进行了详细解读，还对CDN产品和客户的场景如何更高效地匹配、形成最优方案进行了分享，希望基于阿里巴巴及成功客户经验的分享，为客户2021年的企业数字化升级之路加码提速。
本文整理自《边缘创新技术和落地实践》议题，介绍了边缘程序ER、QUIC这2个创新技术在前端渲染、小程序、短视频以及动态加速场景中的应用落地实践。
分享嘉宾：阿里云产品经理陈章炜，负责阿里云CDN边缘Serverless轻量计算产品、QUIC协议、CDN配置可编程等创新产品的孵化。
一、技术背景
1、边缘程序ER
边缘程序ER是在1月6日的阿里云CDN年度产品升级发布会中着重推出和介绍的创新产品，它的原理是在CDN边缘节点上运行计算服务，用户将javascript代码上传、部署至ER，即可在全球的CDN边缘节点上运行，相当于用户在全球拥有了大量微型服务器可以就近地处理客户端的计算请求。
过去传统CDN的缓存分发能力，是将静态文件就近发送给客户端，而现在阿里云CDN正在尝试让用户的后端计算服务下沉到CDN边缘节点，让计算能更靠近客户端，拿到更低延迟。同时由于CDN本身是一个巨大的弹性网络，用户不用像购买服务器一样去关心算力资源和扩缩容，CDN边缘节点网络可以很从容地弹性伸缩帮助用户应对每一次突发的业务。
2、QUIC协议 / HTTP3.0
阿里云CDN接入层支持3~7层、标准、私有等多种协议的接入，可以满足大部分场景的加速，QUIC就是其中一个协议。
QUIC是2013年由Google 发起的，虽然已经发起很多年了，但是真正的大规模商用，阿里云CDN是走得比较靠前的。QUIC基于UDP协议，在UDP的基础上实现了一套TCP+TLS+HTTP/2，所有用TCP能传输的数据都可以用QUIC传输，并且QUIC如他的名字一样，传输速度更快，仅仅只是替换客户端请求的协议，就能够提升大约10%的访问速度，在弱网环境下甚至能够提升20%，这种改造带来的收益是非常可观的，所以现在很多客户已经在使用阿里云CDN的QUIC协议进行加速了。
二、应用场景
1、边缘程序ER在电商前端渲染场景下的实践
电商前端渲染这个场景有什么特点？
第一个特点是电商的页面数以亿计，而且请求的量级非常地大。这些页面的内容大部分都是静态的，不会频繁变化的。因此电商页面是天然必须运行在CDN上的，依托CDN缓存分发的能力来降低源站服务器的压力。
第二个特点是页面元素非常多，包括大量的图片文字元素，将这些元素渲染成最终在手机上显示的页面。
常规情况下，有2种渲染技术，如上图右侧中所示，一种是csr客户端渲染，由客户端去发起，把整个异步的请求去拿到动静态的数据，最后回到客户端生成动静态数据，然后把这些动静态的数据渲染成最终的1个HTML的结果，这种渲染技术的缺点是客户端压力大、请求多延迟不可控。另一种是ssr服务端渲染，当客户端发起一次请求，由服务器端去做这些动静态资源的拉取和渲染，最终给客户端返回1个HTML的文件，由客户端去做加载。这种渲染技术下，首先客户需要有专门服务器集群去做SSR，成本比较高，另外服务器需要接受来自客户端的渲染请求，压力也比较大，而且客户端发起请求之后需要等待时间，也就是白屏时间，将会影响客户端的用户体验。而电商恰恰对页面加载的延迟是很敏感的，用户同样停留的时间，加载速度快意味着用户能看到更多的商品，更有可能成单，相反如果加载很慢，还可能造成买家用户的流失。
当阿里云CDN支持在边缘节点运行计算服务后，就出现了新的渲染架构ESR ，在边缘节点做前端页面渲染。这样既不用吃客户端性能，也不用到很远的中心服务器去做集中的渲染，看下图示意图：
页面渲染的代码部署到ER，客户端请求到达ER后，ER会生成DOM结构并开始拉取源数据进行渲染，而其中大部分的源数据都是静态文件，例如图片文件，这些静态文件就缓存在CDN上，可以直接从CDN缓存读取，不用发起网络请求。只有少部分例如页面上的粉丝数量、商品价格等少量数据需要实时的发起请求回源获取。边缘渲染完成后直接给客户端返回一个最终的HTML文件，客户端只要做加载即可。另外，边缘完成渲染后的HTML文件也可以直接缓存到CDN上，让一段时间内的请求可以准时地复用这个页面结果，减少不必要的重复渲染，进一步降低客户端的白屏时间。
2020年双十一，手机淘宝首次在阿里云CDN的边缘程序（ER）中进行主播详情页面的渲染计算，客户端的图文页面请求直接在边缘节点完成渲染，无需回源，页面整体加载时间降低60%。同时ER引擎渲染后的页面结果可以直接缓存在CDN中， 减少了每次回源的重复计算， 整体复用率达到40%~60%。在降低客户端延迟，为用户带去更顺畅的购物体验的同时，在边缘直接完成渲染计算还节约了中心源站的算力。
2、边缘程序ER在小程序场景下的实践
小程序是近年很热门的一种轻应用形态，相比原生开发的方式，小程序有很多优点，比如跨平台、免下载、随开随用、体积小等特点，对于一般的小型服务完全够用了。目前在淘宝店铺、支付宝应用里都可以看到小程序的身影。
小程序是高度模块化/插件化，1个小程序由多个json文件模块组成（模板信息、版本信息、灰度配置信息、客户端信息、验签信息、安全策略等），大部分的模块更新频率低，呈静态化的特点，少部分模块或个性化插件的实时性高需要动态回源获取。
基于小程序的这些特点，边缘程序ER能帮助他做哪些优化？
如上图所示，以店铺小程序为例，左侧是常规的小程序服务架构， 客户端请求由中心服务器做小程序组装，将各个模块组装成1个店铺框架后返回给客户端。
但是如刚才提到的，这些模块其实也能细分成静态化的更新频率低的通用模板，以及实时性高的个性化模块等。如果能在边缘根据客户端请求携带的用户信息做模块的精准区分，静态化的文件直接从CDN缓存读取，少部分的个性化模块、安全策略等高实时性模块等再异步回源拉取，可以减少大量网络请求。CDN缓存加上少量网络请求后组装成店铺模板返回给客户端，同时对组装完成的店铺模板文件也可以缓存在CDN缓存节点，供一段时间内的同类请求复用，减少重复的组装，提高客户端加载小程序的加载速度。
小结一下：直接在CDN边缘节点做计算的优势有很多。比如电商页面、小程序这种，访问量非常大，所以业务本身其实就会用CDN。而在经过CDN的时候增加一些判断的逻辑和内容，生成的逻辑其实对原本的业务的侵入性是很小的，业务改造成本也很小。同时，还能够有效的去减少回源的数据请求，避免网络请求可能带来的网延迟的风险。
同时，由于边缘程序ER是直接跑在CDN边缘节点上的，所以他就天然的具备所有CDN的优点。比如就近调度，客户端的请求会就近的调度到离它最近、最优的节点进行计算处理。而且当一个区域的请求有突发时，这些请求还会被自动调度到相对比较远，但是有计算资源的节点进行处理。这种自动弹性调度的机制，可以让客户无需担心业务的突发，也不用冗余储备资源来应对，整个资源的分配和扩容都由智能的CDN调度系统完成。
3、QUIC在短视频场景的应用
短视频这几年发展非常迅速，已经基本成为了互联网流量增长的主要增长点。它具有两个特点，第一短视频是纯静态的文件，文件大、流量大，所以，短视频业务也是天然适合用CDN做分发。第二个特点是短视频大多是移动端的客户端、各类App应用，移动端的网络环境更加复杂，弱网环境很多，这些场景下的卡顿率、失败率、首屏时间都会突增，而短视频应用的用户体验是非常重要的，卡顿和长时间的等待加载会打断用户的沉浸体验，所以短视频应用追求的视频播放性能指标比一般的加速业务要更多更细化。
在这种追求极致的场景下，如果换一个协议就能使传输速度有百分十几二十的提升，短视频类客户是非常愿意尝试的。目前阿里云CDN支持在客户端到L1的这段链路中开启QUIC协议传输，QUIC带来了非常多的新特性，例如0-RTT的建连，直接节省了TCP的3次握手和TLS握手这几个来回的RTT，视频首屏可以秒开。第二，QUIC支持连接迁移，手机在切换请求不会断连，视频的加载和播放不会被打断，让用户的观看不会被打断。第三，QUIC把拥塞算法从内核移到了应用层，这使得阿里云CDN可以按月甚至按周根据客户的业务特点去升级拥塞算法，帮助客户拿到更好的收益。第四，TCP有队头阻塞的问题，1个连接里的多个stream里只要有1个stream丢包，就必须等待这个stream包重传，后续的包即使已经被接收端接收了也无法被读取，而QUIC没有这个问题，在弱网环境可以减少了大量的重传，减少卡顿和失败。
从阿里云CDN服务短视频场景的实践数据来看，接入QUIC后，卡顿、首屏、下载速度都有明显提升。
4、QUIC在动态加速场景的应用
动态加速大家应该比较熟悉了，比如短视频是纯静态文件，可以直接缓存到CDN节点上，而应用里很多数据都是实时获取的，例如账号密码、版本更新、数据库中的读写操作的API访问等，这些数据都是实时变化的动态请求，无法缓存在CDN上，这时就需要请求源站获取。
在访问源站的网络链路里，动态加速就是做智能选路，它会实时探测网络的质量，并最终规划出最优、延迟最低的回源路线。
一般使用动态加速的业务都是对延迟敏感度极高，追求高性能。在回源这段链路里有智能选路了，那接入层到客户端这段链路能否再优化呢？
答案是可以。平台可以使用一些私有协议进一步提高传输效率，而QUIC是一个标准化的协议，可以让很多研发能力不是很强的平台也能够借助很多标准和开源的方案接入，让客户端到边缘节点这段链路用QUIC高速传输。另外一般会建议客户在端上做TCP和UDP的竞速逻辑，端上探测2种协议的传输速度，在弱网的时候用QUIC协议保证高可用性，网络好的时候用TCP，最终拿到一个平衡的最低延迟的收益。
从阿里云CDN动态加速场景的实践数据看，动态加速再接入QUIC后，动态请求总耗时降低29%，静态请求总耗时降低34%。
三、未来展望
阿里云CDN边缘程序ER目前支持代码包2MB以下的JavaScript代码部署，正在努力支持更多的语言和环境，例如使用Wasm技术让C、 C++、 Rust、Go的程序也能够部署到ER上，降低后端各种语言下沉到边缘的难度。在应用场景上，边缘程序ER目前在前端场景得到了较好的落地和实践，但我们认为边缘轻量计算平台的用武之地还有很多，例如站点托管、API网关、IoT数据清洗聚合、Abtest等，这块也是期待更多的客户接入后和我们一起探索。
关于QUIC协议，目前阿里云CDN线上的QUIC已经有了Tbps级别的大流量验证，并且为客户带来了明显的延迟收益。另外，阿里云CDN也在关注兼容IETF标准的QUIC，IETF目前已经是第34个草案了，预计将在未来的几个月内定稿。此外，像多路径QUIC也是重点研究方向，实际应用的场景例如移动端App，手机App有wifi、移动网络双通道，有了多路径QUIC后，当单边信号强度很弱时，就可以通过另一边通道进行补偿，最终实现平衡稳定的网络传输。在应用场景上，阿里云CDN的QUIC正在逐步扩展到直播，直播对卡顿、弱网可用性的要求甚至比短视频更高，对直播推流拉流的QUIC协议支持和调优也是未来一段时间内的投入方向。
后续阿里云CDN会在“阿里云Edge Plus”公众号里分享更多最新的产品能力、解决方案和技术实践，欢迎大家一起探讨。
阿里云CDN产品最佳实践图
