CDN，前端必知必会

cdn全称Content Delivery Network（内容分发网络），是构建于现有互联网基础上的通过中心节点对****边缘节点（包括负载均衡设备、高速缓存服务器）进行负载均衡、内容分发以及调度的虚拟网络，由遍布在各个地区的服务器集群组成，有“网络加速器”之称。

其实现原理简单地说就是将源站的资源缓存到分布在全国各地的CDN节点，用户请求数据时，先访问距离用户最近的CDN节点上缓存的资源，没有取到缓存的时候才去访问源站。不必让所有用户请求都从源站获取，避免了高峰期网络拥塞、为源站分担了压力，也缩短了用户等待时长。这是一项用存储空间换取时间的技术。

很久以前，A国有一位长工叫溪森堡，他是一个吸猫狂魔。但是那时候A国本土并没有猫咪，所有的猫都需要从遥远的B王国重金引进，并且由于只有B国有猫，C,D,E等国也都纷纷派使者前往B国，D国与B过接壤倒是还好，A国使者不光需要长途跋涉，还需要穿过人山人海才能买到小猫再翻山越岭回到A国；能拥有一只小猫咪的都是达官贵人，而溪森堡也只能在远处偷偷看着主人与小猫咪嘻闹……

有一天，溪森堡发现自己突然变成了A国国王，这下可以肆无忌惮地吸猫了。但是，不管溪森堡现在是什么身份，猫咪要从B国引进依旧是一个难以改变的事实，并且舟车劳顿极易让小猫咪因水土不服应激、伤亡，皇宫内的寥寥几只小猫也不便在微服私访或南征北伐的时候带着。溪森堡为此终日夜不能寐食不下咽，天天都喊着“我要猫咪，我要很多很多的猫咪、无处不在的小猫咪！”。身边的谋士见状给溪森堡提议道：在国王常到的城市都建造猫咖，从B国一次性引进可爱的小猫细心喂养，等国王到对应的城市就随时可以去撸猫了。从此以后，溪森堡不管在哪个城市，身边都围绕着一大群小猫咪……

我们看看溪森堡实现吸猫自由的旅途中都遇到了哪些困难：

途中跨越多个地区(路由器)，使者往返B国时间长(Round-Trip-Time)，溪森堡（用户）等待时间长；
路途远，乘坐相同交通工具比距离近的国家使者需要更多的旅途经费(带宽资费多)
进出B国人山人海、水泄不通（主干网络压力大，网络拥塞，影响数据传输速度和稳定性以及网站的稳定性）；
A国使者与B国猫商语言不通(不同运营商互联瓶颈)
B国如果受到恶意攻击，所有猫咪荡然无存（源服务器受到恶意攻击，造成服务不可用，服务器随时有宕机危险）

访问未开启CDN的网站时，A国使者到B国买猫就像用户1访问某网站源服务器获取数据由于距离遥远需要经过多次路由转发，D国使者是用户2则只需要1次转发。相比之下对用户1来说网络时延大、等待时间长且带宽成本高。

当接入CDN后，当用户访问某个网站的时候，访问的是距离用户**最近的可处理该请求的节点。**将源服务器资源存储在各个离用户较近的CDN节点中，减少了请求/响应所需时间、节约带宽成本。

三个一公里：

第一公里：源站接入ISP的链路，这里的带宽决定了网站的负载能力（网站的接入带宽）
第二公里：源站ISP接入点到客户机器ISP接入点的链路。其中可能涉及多家运营商，存在运营商之间互联互通的数据交换问题（不同运营商之间进行数据交换需要在指定的交换中心进行，当两个运营商在同一个城市，但是交换中心在遥远的另一个城市的时候，流量中转要长途迂回，增加访问时延，跨网访问的用户体验差）。
第三公里：客户机器接入ISP的链路

CDN用来加速网络的第二公里

CDN和DNS调度

以www.xisenbao.com为例

A. 传统模式下用户终端访问网站的过程：

用户在浏览器地址栏键入网站域名
浏览器查DNS缓存看能否获取目标网站对应的IP地址
如果键入的是域名，浏览器先查询浏览器本地DNS缓存获取目标网站对应的IP地址（chrome可访问chrome://net-internals/#dns查看），没有对该域名缓存，则进行下一步
查询本地操作系统的DNS缓存（host文件），没有对该域名缓存，则进行下一步
查询与本地直接相连的路由器中是否有对应的DNS缓存
当没能从DNS缓存中获取到目录网站IP，浏览器调用域名解析程序以递归查询的方式，向本地DNS服务器查询。本地DNS服务器查询该域名是否包含在本地配置区域资源中，有则返回对应IP，无则进行下一步
本地DNS服务器如果有设置转发器，则向上一级发起查询，直到查询到目标网站IP或返回查询失败结果
本地DNS服务器如果没有设置转发器，本地DNS服务器以迭代查询的方式依次向根域名服务器、顶级域名服务器、权威DNS服务器发起查询请求：
根域名服务器(.)返回一条NS记录，让本地DNS服务器转到对应的顶级域名(.com)服务器查询
顶级域名服务器接收到本地DNS服务器请求，返回一条NS记录，让本地DNS服务器转到xisenbao.com对应的权威域名服务器进行查询
权威域名服务器查询到www.xisenbao.com对应的IP并返回给本地域名服务器，本地域名服务器将查询结果返回给浏览器（这里忽略没有找到IP的情况）
浏览器根据步骤4中拿到的IP地址和ARP协议(地址解析协议，根据IP得到服务器mac地址)访问对应的服务器
三次握手建立TCP连接
浏览器发送HTTP请求，等待服务器应答
服务器响应请求返回数据
浏览器得到数据开始进行页面渲染
四次挥手断开TCP连接等

步骤1-4是传统模式下DNS调度过程

在开头故事中，全国各地的猫咖扮演着CDN的角色。把用户访问网站整个过程看作A国使者在国内还没有修建猫咖的时候到B国买猫的过程，其弊端也已在上文指出。

B. 在接入CDN缓存后，用户访问网站的过程变成：

用户在浏览器地址栏键入网站IP/域名
浏览器查DNS缓存看能否获取目标网站对应的IP地址
如果键入的是域名，浏览器先查询浏览器本地DNS缓存获取目标网站对应的IP地址（chrome可访问chrome://net-internals/#dns查看），没有对该域名缓存，则进行下一步
查询本地操作系统的DNS缓存（host文件），没有对该域名缓存，则进行下一步
查询与本地直接相连的路由器中是否有对应的DNS缓存
当没能从DNS缓存中获取到目录网站IP，浏览器调用域名解析程序以递归查询的方式，向本地DNS服务器查询。本地DNS服务器查询该域名是否包含在本地配置区域资源中，有则返回对应IP，无则进行下一步
本地DNS服务器如果有设置转发器，则向上一级发起查询，直到查询到目标网站IP或返回查询失败结果
本地DNS服务器如果没有设置转发器，本地DNS服务器以迭代查询的方式依次向根域名服务器、顶级域名服务器、权威DNS服务器发起查询请求：
根域名服务器(.)返回一条NS记录，让本地DNS服务器转到对应的顶级域名(.com)服务器查询
顶级域名服务器接收到本地DNS服务器请求，返回一条NS记录，让本地DNS服务器转到xisenbao.com对应的权威域名服务器进行查询
权威域名服务器查询到www.xisenbao.com对应的CNAME并返回给本地域名服务器（注意如果链路较长的时候这一步可能重复多次，依次查询到多个CNAME）
本地域名服务器向CDN专用的域名解析服务器发起域名解析，CDN专用的域名解析服务器返回CDN全局负载均衡系统的IP地址给本地域名服务器
本地域名服务器将全局负载均衡系统的IP地址返回给浏览器
浏览器访问全局负载均衡系统的IP地址
全局负载均衡系统的IP地址根据浏览器所在机器的IP地址判断请求来源于哪个区域，返回对应区域的本地负载均衡服务器的IP地址给浏览器
本地负载均衡服务器根据

a. 用户IP地址，判断哪一台服务器距用户最近； b. 用户所请求的URL中携带的内容，判断哪一台CDN节点上有用户所需内容； c. 查询各个节点当前的负载情况，判断哪一台服务器尚有服务能力 来选择最合适的CDN 服务器返回对应的IP地址给浏览器

浏览器拿到IP地址向CDN节点获取数据(如果CDN节点有命中缓存直接返回用户所需数据，如果对应节点中没有缓存用户所需要数据，该CDN节点则需要去找到源站获取数据并缓存下来，下一次有用户访问同样的数据直接返回)。
三次握手建立TCP连接
浏览器发送HTTP请求，等待服务器应答
服务器响应请求返回数据
浏览器得到数据开始进行页面渲染
四次挥手断开TCP连接等

注意，步骤14-17的具体实现方式不是唯一的，可能是图中的Http重定向并访问下一节点IP给客户端的方式，也可能是对外暴露同一个IP，由GSLB直接转发客户端请求给下一站节点的方式，具体可以参考下CSDN的这边文章《全局负载均衡与CDN网络简介》

用CDN解决了什么问题：

减少用户访问网站的时延

将源站内容缓存到世界/全国各地的离用户最近的CDN节点，减少用户访问网站时的等待时间，提升用户体验。
跨运营商数据互通带来的时延问题

常见的解决方案为：使用多线机房，可以看成是出口线路同时接入多家运营商，这些运营商都可以访问同一个机房中缓存的数据。
减轻源站负载压力

CDN节点之间的智能冗余机制，可以有效降低黑客入侵、讲个ddos攻击对网站的影响，提升服务的稳定性。
节约成本

可以在全国各地设置CDN节点，不用考虑购买服务器与后续的托管运维，服务器之间镜像同步，也不用为了管理维护技术人员而烦恼，还节省了带宽资源、人力、精力和财力。

使用CDN的缺点：

网站内容更新时，CDN节点缓存还没失效，即使用户强制刷新网页让浏览器缓存失效，拿到的数据也不是新的。

CDN缓存

可在CDN服务提供商提供的管理后台配置

腾讯云为例，未配置任何规则或请求未命中配置的规则时，默认遵循以下平台策略：

当用户请求您某一业务资源时，若源站对应的 HTTP Response Header 中存在 Cache-Control 字段，则遵循该 Cache-Control 。

若源站对应的 HTTP Response Header 中无 Cache-Control 字段，则：CDN 节点默认对该资源缓存600s。

https://intl.cloud.tencent.com/zh/search/?wd=%E7%BC%93%E5%AD%98&type=document&productId=228

‍

如何更新CDN缓存

请求的url中拼接timestamp，随着时间的更新，不命中缓存，cdn节点会重新同步服务器最新的数据

http://www.xisenbao.com/a.txt

http://www.xisenbao.com/a.txt?timestamp=202206202253
调用cdn服务提供商的接口刷新缓存

下载CDN资源

直接下载cdn资源，使用a标签的download属性，点击超链接时会被浏览器解析成下载行为而不是打开超链接,注意download属性只能用于同源的url。我们都知道浏览器跨域行为是ban掉了返回的结果，如果引用不同源的资源，可以将返回内容转换成浏览器不能直接打开的二进制流文件。具体请参考文章《前端从web服务器或者CDN下载资源》

<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title></title> <script src="https://cdn.bootcdn.net/ajax/libs/axios/0.27.2/axios.js"></script> </head> <body> <!--去淘宝透了一张cdn资源--> <img src = "https://img.alicdn.com/imgextra/i2/6000000005627/O1CN01HY1GRG1rRDQMeexpd_!!6000000005627-0-octopus.jpg" alt="溪森堡的猫" /> <a href ="##" onclick="getBlob('https://img.alicdn.com/imgextra/i2/6000000005627/O1CN01HY1GRG1rRDQMeexpd_!!6000000005627-0-octopus.jpg','溪森堡的猫.jpg')">点击下载图片</a> </body> <script> function getBlob(url,fileName) { console.log(url); console.log(fileName); axios .get(url, { responseType: 'blob' }) .then(res => { data = res.data; if (!data) return; const blob = new Blob([data], {type: "image/png"}); const link = document.createElement("a"); link.style.display = "none" ; link.href = URL.createObjectURL(blob); // 根据二进制流对象生成一个url，是一个UTF-16 字符串，这个url没有禁止跨域的限制 link.download = fileName ;//下载之后保存的文件名 link.click(); //激活a标签 URL.revokeObjectURL(link.href); //createObjectURL每次调用都创建一个domstring，容易造成内存泄露，不需要的时候要用revokeObjectURL释放掉 link.remove(); }); } </script> </html>

获取cdn连接对应的内容，发送一个get请求

const url = 'cdn资源连接' const xhr = new XMLHttpRequest(); xhr.open('GET',url,false); xhr.send(null); if(xhr.status === 200){ //..... }

webpack配置CDN资源

其实就是在webpack启动和打包项目的时候动态插入script和style链接，后面专门写一篇文章介绍配置过程吧，溜了溜了。

突然，冷、彻骨的冷……一盆水霹头盖脸往溪森堡脸上泼去，耳边传来一句：“溪森堡，你居然在这睡懒觉，看我不打断你狗腿！”。努力撑开眼皮，看到一个身长五尺、肥头大耳的男人正骂骂咧咧，目之所及，都是湿漉漉的草杆，没有小猫……“是管家，害，梦醒了，要起来搬砖了。”

CDN，前端必知必会

相关推荐

发表回复