“所谓的抄近道，走的人多了，也就堵了。网络高速路亦是如此。”
慢，大抵是互联网时代的原罪。
因为“慢”的代价很大。
视频加载超过7s, 87%的用户放弃观看；
网站打开时间超过3s，57%的用户放弃访问；
研究表明，每0.1秒的网站延迟，用户转瞬流失，会损失1%的收入。
当用户在不断追求更快、更好的打开方式和体验之时，很难再接受慢下来的网络世界，那些充满拥塞、加载缓慢、卡顿、延时、掉帧……
如今，互联网用户无论是浏览网页、观看视频，还是网购、在线学习，背后都有CDN（内容分发网络）在后台“加速”的身影，在支撑各类互联网业务高速发展的同时，“加速”技术也随之不断发展。
一部“加速”技术的演进史，也正是一部互联网业务的发展史。
一切唯快不破，看看“网络高速公路”如何演进至今。
CDN 并不是互联网诞生之初就存在的。
当没有 CDN 加速时，大量的用户请求需要穿越互联网骨干网才能获得源站的内容。
上世纪80年代，互联网技术开始民用，人们主要通过拨号来访问网络，由于用户少、带宽小，并没有对骨干网和服务器带来压力。
随着互联网高速发展，使用互联网的用户数量出现井喷式增长，加之宽带接入网的出现，内容源服务器和骨干网络的压力越来越大。
由于网络距离远以及骨干网的网络拥塞问题，端到端的请求时延会非常长，无法及时响应用户的访问需求，这会严重影响用户体验。
在早期CDN架构设计中，核心的目标，是通过内容的分发来实现"加速"，本质逻辑就是将文件从源站“搬”到离用户近的地方，缩短内容传输的物理距离来实现所谓的"加速"效果。
那么基于这个前提和背景，技术上的重点，就是怎样让尽可能少的流量穿过边缘集群回到源站，即尽可能的提高内容的命中率。
事实上，业界的厂商基本也都是在这个方面注入了最多的技术投入，尽量将访问终结在边缘，其次在上游增加缓存层(很多厂商叫做中间源)，来"拦截"回源流量。
所以，经典的CDN静态加速，节点架构按照分层的设计就顺理成章了，即从边缘->一级父层->...->N级父->源站。
使用 CDN 之后，由于大量请求在边缘就可以找到其所需的内容，因此穿越互联网骨干网的流量大幅减少。
这样，既有效减轻了骨干网的流量压力，也节省了SP(Service Provider，服务提供商)的带宽成本，促进了互联网业务的快速发展。
然而，在部分场景下，CDN经典技术架构并不是万能的。
以电商、社交互动媒体、博客为代表的互联网业务，存在大量不能缓存、需要实时回源的动态内容加速场景。
比如：电商平台涉及了用户注册、登录、在线支付、秒杀等需要动态加速的场景。
从流量上来说，一个域名全网的流量，随着层级的深入，流量逐级减少，最终从几个节点回到源站，面对一些内容热度比较高的情况，回源量会更少。
从微观来讲，一般的逻辑是把内容送到离客户最近的边缘节点。那么，对于后续的父层节点来说(Parent Node)，依然遵循同样的逻辑，即：一级父离edge尽量近，二级父离一级父尽量近。
最终呈现的状态就是CDN的节点集中在离客户端比较近的地方。
基于此，会出现一种不可避免的情况，文件没有在CDN的网内节点命中，必须要回源，这就会经历一个比较长的非CDN可控的公网链路回源。
从质量的角度来看，回源引起的质量劣化对整体域名质量的影响权重不一定很高。
举个直观的例子，如果客户域名的CDN命中率是95%，即回源流量占比仅为5%，那么即使这部分流量出现响应时间异常，那么整体也只影响5%左右流量。
基于上面的论证，如果是一个需要100%回源的流量，比如登录，提交表单，推荐列表，支付等场景下的流量。当把流量切到CDN静态加速平台，那么面对节点高度集中在边缘，经过一个长距离不可控的公网链路回源，整体的质量将很容易失控。
对于纯动态的流量，核心的问题比较明确：
当客户流量接入到CDN边缘节点之后，需要跨越一个很长的物理距离将请求送到客户源站，CDN怎么承诺提供一个低延迟，高稳定的服务质量，就是一个核心的课题。
从边缘的接入角度来看，用户的动态流量基本都是https接入，那么基于CDN广泛分布的边缘节点来说，可以将客户端访问的TCP握手和SSL握手，卸载到CDN边缘节点，从而让本来需要长距离跟源站进行多次握手交互的操作，得到了极大的性能改善。
从节点内的传输的角度来看，要想做到最优的延迟，就需要利用最短最优的链路，同时在这个链路上配合最高效的传输。
“ 所谓“修好路，跑好车”，这两项能力必须同时满足，才能发挥最优的加速效果。”
再好的链路，如果中间传输伴随额外的交互开销，例如过多的tcp握手，ssl握手等，也很难承受住负向影响。
我们把这两项能力称为“选路能力”和“传输能力”，核心技术点就是：传输优化与动态选路。
对于低延迟来说，动态流量往往都是小文件内容为主，即一次网络交互就完成，所以传统的CDN基于大文件下载的TCP优化，难以发挥很大的作用。
其根本原因在于：
目前TCP优化多数都是基于多包的统计和测量等方式，来探测网络的最小延迟和最大窗口等维度的数据，来调整收发包数量和频率。那么一次网络交互的场景(典型的动态业务场景，例如弹幕、交易支付、登录等)，就明显不适用。
所以对于动态流量的加速，首包(基本就等于响应时间)就是一个核心指标。不像大文件场景，由于下载时长可能很多都是秒级以上，首包的多少，占比总的完成时间比例不是很高。
对于动态流量，首包基本就是全部。它的时间量级几乎等于一次tcp握手的时间，那么在传输过程中有额外的长链路握手开销，由此带来的影响是巨大的。
对于动态流量两项核心能力中的“传输能力”，核心其实是0rtt能力，所谓的0rtt指的是，CDN节点内除了必须产生的一次传输有效载荷行为外，不会出现网络上的额外往返(即所谓“0”)。
在这项能力方面，阿里云的全站加速，经过多年的打磨，构建了一个用户态的应用网络，让CDN边缘和源站之间得以实现运行时零握手开销的传输管道。
关于选路系统，基于阿里云全站加速DCDN多年的业务经验和演进，在此文主要抛出一些观点，来供读者进一步的思考。
前面谈到，在CDN的默认架构下，回源涉及很长的公网链路，这段链路可能要跨越不通的省份，国家，甚至大洲，又或者是需要穿过不同种类的运营商网络。
而在广域网的路由中，有很多复杂的地域和商业上面的定制策略，绕路之类的情况是经常出现的。
一种行之有效的方案就是基于CDN广泛分布的节点，通过节点间的探测，配合CDN节点与各运营商的广泛连通性，构造“路径切割”来尽量规避穿越长链路可能存在的问题。
所谓的“路径切割”就是构建多段TCP来引导数据，在路由层面尽量按照预期的链路来走。
对于选路来说，区别于通用的三层路由选路。
因为动态业务流量是一种具体的场景，在选路时会额外的关注节点间。节点到用户源站层面上，业务特征、HTTP和HTTPS流量特征、TCP和UDP差异、长连接和短连接等方面，对于业务流量会有一些微妙的影响。
所以，对于网络(如下图)的最优路径计算，相关的算法可以参考的较多。
“ 最优路经计算，其核心的问题，在于如何构图，即图的边到底，通过哪些维度来度量与归一化，是非常重要的课题。”
除了构图中关于“边”的度量和定义，还要关注“节点”的维度。学术界的经典最优选路的算法，并不考虑链路或者节点容量的问题。
那么，如果按照最优路径相关算法的运行结果，会导致流量汇聚到某条链路或者节点，产生反向作用，导致链路质量上的劣化。
一个形象的比喻就是：所谓的抄近道，走的人多了，也就堵了。
传统的经典算法，一旦涉及到链路容量限制，就不能正常运行，需要有新的模型来处理这类问题。
另外一个选路层面需要考虑的问题，就是：经典的路径算法是无状态的。
意思是说，每两次选路的过程之间是没有关联的，这就会导致每次选路的结果可能差异很大，流量在网络内疯狂震荡，对于系统的稳定性和处理能力有很大挑战和风险。
最后一个在“选路”层面重点考虑的问题就是，分清楚哪些是节点层面应该做好的，哪些应该选路层面去做好的。
在SDN的领域中，节点层面被定义为数据面，选路层面定义为控制面。换句话说，所谓的控制面要控制哪些，能控制哪些？
对于业界常见的方案来说，选路基本都是中心化的，那么天然来说，节点到中心的交互就不能太频繁。
选路层面都需要经过收集和汇聚数据的过程，决策和策略必然产生延迟。
比如10分钟完成一个周期的任务处理和下发，那么系统一定是留有足够的buffer的。这个buffer核心一般体现两点，一是留有一定的余量，二是带有一定的预测。
用一句话来讲，选路系统每次计算结果，其实对节点数据面来说，有一个隐含SLA（服务水平协议）的。
比如在某个选路系统中，当前给的结果是保证的未来10分钟内，在流量不超过xx的阈值下，延迟可以控制xx毫秒的概率是99.9%，那么对于一些秒级的链路闪断或者质量恶化，就需要节点数据面有自己的容灾和兜底策略，这部分是中心式选路系统的交互时间尺度内，难以提供有效支持的。
单独站在选路的视角来看未来的演进，传统的基于分场景，人为指定策略的探测模式(探测本质是一种旁路采样，从统计学上来讲就是希望构造一种抽样来最大化的反映整体或者实际业务流)，然后基于此进行构图和算路的架构，在系统优化和迭代方面，针对业务的贴合度，或多或少存在一定的GAP。
然而，在实际业务发展过程中，面对同时混合了动、静态两种流量场景的全站业务，相应的技术架构就需要有更多的兼顾和综合视角的考虑，无论是“传输”还是“选路”。
动态加速业务的技术演进，从历史的角度看，基本都是立足于静态CDN架构在特定场景下的问题，不断迭代和演进，走出了一套有差异化的架构和技术栈。
京公网安备 11010802035086号