前言
大家好，我是所长大白(●—●)。
今天和大家聊聊内容分发网络的那些事儿，希望大家有所收获。
废话不说，各位坐好发车啦！
为什么需要CDN
今天的主角是CDN，我们先看下百度百科对CDN的定义：
CDN的全称是Content Delivery Network，即内容分发网络。
CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
原来CDN并非网络基础设施，而是构建在实体网络基础设施的一个"应用层"，来看看为什么需要它。
2.1 互联网中的三个一公里
这幅图展示了互联网通信领域中常说的"三公里"：
-
第一公里
网站服务器接入互联网公网的链路，这里的带宽也决定了网站的负载能力，也称为网站的接入带宽。 -
中间一公里
中间一公里主要是接入网、城域网、骨干网组成的链路实体，其中会涉及多家运营商，也就出现了运营商之间互联互通的数据交换问题。 -
最后一公里
这是用户接入互联网获取信息的最后环节，换句话说就是你们小区的网络、你们家楼的网，往往这部分的带宽不高，影响也比较明显。
2.2 运营商的互联互通问题
运营商之间数据的互联互通问题，比如A市联通要访问A市电信的数据资源，按照互联互通的规则限制，不同运营商的数据要在指定的交换中心进行数据交换，假如交换中心位于较远的B市，那么就存在如下图的关系：
换句话说，本来两个运营商是同一个城市的，但由于运营商的网络差异需要到几百公里之外的交换中心所在的城市进行数据交换，实现资源的访问。
对于不同运营商间的互联互通，一般是采用BGP peering（对等）的方式进行。两家运营商相互协商，在特定地点建立连接，通过一系列的配置，运营商A的用户就能访问运营商B的资源了。
在中国，运营商之间通过“国家级互联网骨干直联点”进行连接，2001到2014年，国内只有北上广三个直联点，导致跨网访问体验极差，流量无法本地中转需要长途迂回，大大增加了延迟。
三批国家级互联网骨干直联点：
第一批2001年投入使用：北京、上海、广州
第二批2014年投入使用：成都、郑州、武汉、西安、沈阳、南京、重庆
第三批2017年投入使用：杭州、贵阳、福州
2.3 难兄难弟
试想北美的海外用户要访问在服务器在深圳的资源，物理距离就有几万公里，算上三个一公里的消耗，恐怕用户的体验会非常糟糕。
同样的，网站服务器的接入带宽是有限的，对于海量用户的接入访问非常容易出现拥塞，这样很容易把网站服务器压垮。
同时，对于运营商来说也很糟糕，骨干网充斥着大量相同的请求，网络基建压力很大，如果把这些请求在本地处理掉该多好！
可见，如果没有CDN这一层Cache应用，网站、用户、运营商都会很崩溃。
CDN的思想和某东物流建立的区域仓库、前置仓库很像，用户下单后优先在最近的仓库配货，极限情况下几小时就可以送到用户手里，用户体验好、物流压力小。
CDN的基本原理
CDN是个非常复杂的大系统，作为普通的开发人员，我们抓住重点理解精髓就好。
3.1 CDN和DNS的调度
假如没有CDN，我们访问资源时会使用DNS进行解析获取资源服务器的IP地址进行数据交互。
-
传统模式下DNS的调度过程
图中我们看到用户从LocalDNS开始查询，如果找不到就到根权威DNS服务器，再向顶级权威DNS服务器访问，依次迭代最终获取待访问域名的IP地址。
- 有CDN参与的DNS调度过程
前面我们曾经提到CDN是构建在承载网上的一个Cache应用层，也就是CDN作为用户和网站服务器之间的Cache来参与整个过程。
这样就出现一个问题：用户如何获取CDN资源节点的IP地址呢？
没错，其中一种常见的调度方案就是DNS调度，如图所示：
前半部分和传统模式类似，重要的区别在于专用DNS调度服务器的出现，图中为TenCent DNS Server，这台CDN服务商提供的专用DNS调度服务器根据CDN系统内部节点的位置、负载情况、资源分配等因素选出最优的CDN资源节点IP地址返回给用户。
我们展开聊一下。
3.2 专用CDN调度过程
要实现CDN资源节点的调度，需要网站做一些准备工作：
- 网站去CDN服务商进行域名加速
比如为源站abc.com到阿里云进行域名加速，配置完成后阿里云会自动关联生成加速域名的别名如abc.com.aliyuncdn.net，这个别名也称为CNAME。
这里我们提两个重要的概念:CNAME和A记录，它们是理解CDN的基础概念。
CNAME记录，也叫别名记录，比如www.xx.com的别名是www.yy.com，CNAME记录是一种指向关系，把www.yy.com指向了www.xx.com，一个域名可以有多个别名，存在多对一的关系。
A记录，即Address记录，我们可以把它理解为一种域名和IP地址的映射关系。
由于加速域名已经进行了CDN的CNAME配置，在权威DNS服务器的解析下得到的并不是IP地址，而是CNAME。
- 权威DNS服务器的请求转发
当用户访问abc.com时，传统的权威DNS服务器对abc.com进行解析时得到的是abc.com.aliyuncdn.net这个配置的CNAME，从而通过CNAME顺利将请求转到CDN服务商专用的DNS服务器，由该服务器返回CDN的资源节点。
3.3 其他调度模式
除了DNS调度，还有httpDNS调度、302调度等场景，来简单看一下。
- httpDNS调度
HTTPDNS技术是一种针对DNS防劫持的有效手段，以HTTP的方式代替传统DNS协议传递解析结果，能够有效避开DNS层面的拦截和故障。该方案可以根据客户端的来访IP，直接通过Httpdns服务器获取最精准的解析结果，避免因为DNS多出口，DNS攻击导致的DNS解析失败的问题。
客户端直接调用HttpDNS接口获取缓存服务器IP组，再择优向IP组中的缓存服务器发送请求，替代常规DNS调度策略，适用于客户端，且客户端需稍作修改进行HttpDNS接口调用。
- 302调度
基于终端用户的IP，做HTTP的精确重定向，需要协议支持、具有相当的时延，一般用于流媒体类加速场景。
该调度方式是通过DNS解析获得CDN的GLSB集群的IP地址，用户发送HTTP请求，GLSB服务器返回302 Found，将访问重定向到合适的服务节点。
该方式也存在着一些不足：
1、仅限HTTP的应用，可拓展性不足 2、调度过程多了302跳转的重定向过程，相对DNS调度时延较长
httpsDNS和302调度都有自己的优势和使用场景，不同的网站可以采用一种或者多种调度方案来综合实施加速，三种方案并不对立，而是相互补充。
3.4 CDN内部架构简介
有了CDN的加速，用户就可以访问近距离的服务器节点，大大提升了用户体验，同时源站的带宽压力也得到了分流，运营商骨干网压力也随之降低，看起来确实是个win-win-win的方案呀。
我们以阿里云官方文档为蓝本进行展开：
- 调度系统
支持DNS、HTTPDNS和302调度模式，当终端用户发起访问请求时，用户的访问请求会先进行域名DNS解析，然后通过CDN的调度系统处理用户的解析请求，就是我们前面介绍的CDN参与下的DNS调度过程。
- 质量系统
实时监测缓存系统中的所有节点和链路的实时负载以及健康状况，根据用户请求中携带的IP地址解析用户的运营商和区域归属，综合链路质量信息为用户分配一个最佳接入节点。
这里算是进行CDN节点选择的一个策略和质量监控的闭环系统。
- 缓存系统
用户在最佳接入节点访问数据，如果节点已经缓存了资源，会直接将资源返回给用户，如果L1和L2节点都没有缓存户请求的资源，此时回源站去获取资源并存储到缓存系统。
- 支撑系统
支撑服务系统包括数据智能和配置管理系统，实现资源监测和数据分析，例如对CDN加速域名的QPS、带宽、HTTP状态码等常见指标的监控，用户可以分析CDN加速域名的PV、UV等数据。
3.5 静态资源和动态资源的加速
CDN本质上就是一层Cache，有缓存就一定会有数据不一致问题，以及哪些资源适合做缓存，哪些不适合的问题。
- 静态资源
如果每个用户访问得到的资源一样，就像电视台播放节目，大家看到的都一样，并非个性化的结果，这类资源就可以称为静态资源。 比如网站的图片、视频、软件安装包、各类下载资源文件等。
这些资源变化很小，因此非常使用CDN加速，对改善网站性能效果明显。
- 动态资源
区别于静态资源，动态资源则更倾向于接口、个性化内容，用户每次请求得到的结果可能不同，这些资源并不适合CDN场景，如果强行使用会带来数据更新缓慢和不一致问题，但是动态资源有其特有的加速方法。
动态资源就意味着回源站进行数据请求，这其中就涉及到最优回源路径的选择，让路更好走，数据获取更快捷，实现动态资源的加速。
所以CDN也并非万金油，我们要合理使用。
4. CDN的商业简史
镜头拉回到20世纪90年代，当时全球范围内网络基础设施还很薄弱，尤其在骨干网接入用户越来越多，数据的长距离传输效果很差，已经阻碍了新兴网络科学的发展。
4.1 Akamai的诞生
这个现象很快被万维网的发明人Tim Berners Lee注意并提出来，随后他和一位数学教授讨论该问题，他就是麻省理工学院应用数学教授 Tom Leighton，如图为Tim Berners Lee(蒂姆·伯纳斯·李)。
Tim Berners Lee教授
在意识到这问题的重大意义后，Tom Leighton教授带领着研究生 Danny Lewin 和其他几位顶级研究人员一起尝试用数学问题解决网络拥堵问题。
Tom Leighton教授
最终他们使用数学算法，处理内容的动态路由安排，解决了这个难题。
故事还没有完，史隆管理学院的 MBA 学生 Jonathan Seelig 加入了 Leighton 的队伍中，为这支技术队伍插上了商业的翅膀，最终于 1998 年 8 月 20 日正式成立公司，命名为 Akamai。
时至今日，Akamai仍然是一家承载全球15%-30%网络流量，客户涉及谷歌、脸书、微软等知名互联网公司。
Akamai在全球部署150000多台服务器，这些服务器部署在全球90多个国家，800多个城市，1000多个运营商的2500多个节点上。
4.2 CDN在中国的发展
和Akamai同一年诞生的还有中国第一家CDN公司蓝汛ChinaCache。
随着互联网的发展，后续又出现了网宿科技、帝联、快网等公司，在2014年之后各大互联网公司纷纷推出了自己的云服务，其中佼佼者便是阿里云、腾讯云、金山云、七牛云等云服务商CDN公司。
其中阿里云目前在国内市场份额第一，大约覆盖了1/3的市场需求。
阿里云在全球拥有2800+节点。中国内地拥有2300+节点，覆盖31个省级区域；海外、中国香港、中国澳门和中国台湾拥有500+节点，覆盖70多个国家和地区。全网带宽输出能力达150 Tbps。
目前在用户需求、技术革新、市场竞争等多因素影响下，各大CDN服务商都开始进行转型和技术优化，给用户更好的体验、更安全、更灵活的大方向已经取代了单纯拼价格的路子。
5.总结
本文通过介绍CDN的定义、基本功能、互联网三个一公里带来的数据流动等问题，让我们对CDN要解决什么问题及其重要意义有了初步认识。
进一步，通过传统DNS调度和使用CDN加速后的调度过程，阐述了CDN资源节点是如何被用户端感知的。
同时以阿里云为蓝本介绍了CDN网络架构的基本组成部分，以及静态资源和动态资源不同的加速方式。
最后从商业的角度介绍了互联网之父提出的长距离传输问题、麻省理工教授创办第一家CDN公司、再到中国CDN的发展情况。
CDN是个复杂的工程，篇幅和能力所限，只能和大家分享这么多了，希望对朋友们有所帮助，我们下期再见！
