1.CDN基本原理
CDN 的基本原理是依靠放置在各地的缓存服务器，通过全局调度以及内容分发等功能模块，将用户需要的那部分内容部署到最贴近用户的地方，将原本低效、不可靠的网络转变成高效、可靠的智能网络，满足用户对内容访问质量的更高要求， 改善互联网网络拥塞问题，提高用户访问 网站的响应速度。
(1)内容CDN的内容通常是以下两种: 静态内容以及动态内容。
静态内容:内容不经常更改，并且一旦它在 CDN 缓存中，可以由许多用户进行访问，缓存性强。
静态内容服务又可分为 缓存类服务及流媒体类服务。
缓存类服务，即用户以最大的速度向服务器下拉内容，如基于HTTP的文件下载， CDN能够保证下载业务中终端用户的下载速度 。
流媒体类服务，主要是视频业务，分为点播与 直播两种 。 与静态内容不同，流式传输方式是流媒体与静态内容最大的 差异。流媒体服务将每一帧数据打上时序标签后进行流式传输，是一种按视频的码流需求向用户提供实时流的分发方式。发送端采集音视频数据，经过编码、格式封装、推流等过程处理，然后进行传输，客户端再下载数据并按时序进行解码播放，实现这些离不开 CDN对流媒体协议的支持。
动态内容:内容用于特定的用户或组，并且更新频率较高，通常来自源服务器并实时发送到 CDN 中，缓存性较弱。对于用户的每 一 次请求， CDN 都必须从源站服务器拉取动态内容 ，所以 动态内容加速的常用方法就是降低源站服务器和用户终端之间的传输时延。
2.CDN 的基本工作过程
CDN客户使用CDN的方法：
对于CDN客户来说，不需要改动网站架构，只需要修改自己的DNS解析，设置一个CNAME指向CDN服务商即可。原理在下面会解释
通过上图，我们可以了解到，使用了CDN缓存后的网站的访问过程变为：
用户向浏览器提供要访问的域名；
浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库得到的是该域名对应的CNAME记录（由于现在已经是使用了CDN服务，CNAME为CDN服务商域名），为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对应的IP地址，使得用户能就近访问。（CDN服务来提供最近的机器）
此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求；
缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程；
客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。
CDN工作原理
①当用户点击网站页面上的内容URL，经过本地DNS系统解析，DNS系统会最终将域名的解析权交给CNAME指向的CDN专用DNS服务器。
②CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回用户。
③用户向CDN的全局负载均衡设备发起内容URL访问请求。
④CDN全局负载均衡设备根据用户IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。
⑤区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务，选择的依据包括：根据用户IP地址，判断哪一台服务器距用户最近；根据用户所请求的URL中携带的内容名称，判断哪一台服务器上有用户所需内容；查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址。
⑥全局负载均衡设备把服务器的IP地址返回给用户。
⑦用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器将内容拉到本地。
DNS服务器根据用户IP地址，将域名解析成相应节点的缓存服务器IP地址，实现用户就近访问。使用CDN服务的网站，只需将其域名解析权交给CDN的GSLB设备，将需要分发的内容注入CDN，就可以实现网站内容加速。
阿里云解释
通过以下案例，您可以了解CDN的工作原理。
假设您的加速域名为www.a.com，接入CDN网络，开始使用加速服务后，当终端用户（北京）发起HTTP请求时，处理流程如下图所示。
当终端用户（北京）向www.a.com下的指定资源发起请求时，首先向LDNS（本地DNS）发起域名解析请求。
LDNS检查缓存中是否有www.a.com的IP地址记录。如果有，则直接返回给终端用户；如果没有，则向授权DNS查询。
当授权DNS解析www.a.com时，返回域名CNAME www.a.tbcdn.com对应IP地址。
域名解析请求发送至阿里云DNS调度系统，并为请求分配最佳节点IP地址。
LDNS获取DNS返回的解析IP地址。
用户获取解析IP地址。
用户向获取的IP地址发起对该资源的访问请求。
如果该IP地址对应的节点已缓存该资源，则会将数据直接返回给用户，例如，图中步骤7和8，请求结束。
如果该IP地址对应的节点未缓存该资源，则节点向源站发起对该资源的请求。获取资源后，结合用户自定义配置的缓存策略，将资源缓存至节点，例如，图中的北京节点，并返回给用户，请求结束。配置缓存策略的操作方法，请参见缓存配置。
详细解释
CDN 的基本工作过程，包括内容注入、用户请求调度、内容分发以及内容服务这 4个步骤。
(1 )内容注入
内容注入是 CDN 能为用户提供服务，是内容从源站注入 CDN 的过程，使得用户能从 CDN系统中获取源站的内容。
(2)用户请求调度
用户请求调度是用户向网站发起访问请求，最终用 户被引导到最佳的有内容的 CDN 节点的过程，具体如下 :
(a)当用户向网站发起访问请求时，经由本地 DNS 系统解析，本地 DNS 会通过递归方式将域名的解析权最终交给 CDN 授权 DNS 服务器 (GSLB);
(b) CDN GSLB 可将 CDN节点设备的回地址返回用户，也可以将另一个负责解析用户终端 IP 地址的 GSLB 设备的 IP 地址返回用户。
(c)用户向 CDN的GSLB设备发起内容访问请求(IP调度方式):
(d) CDN 的 GSLB 设备根据用户地址以及用户请求的内容 URL，选择一台用户所属地区的本地负载均衡 CSLB)设备，并让用户向该 SLB 发起访问请求;
(e)该 SLB 设备通过决策选择一 台最佳的服务器为用户提供服务，用户向该服务器发起访问请求;
(f) 若该服务器内容未命中，而 SLB 仍将该服务器分配给用户，则该服务器需要向上级节点请求内容，然后，由该服务器向用户提供“边拉边放”的服务或者由上级节点直接为用户提供服务。
3.CDN 内容接入
1.内容存储接入
内容存储接入指源站(互联网应用的内容源)在发布内容前，提前把内容注入 CDN。内容存储接入方式下，业务系统需主动向 CDN 内容库发送操作指令， CDN 根据指令获得内容并存储在 CDN 内容库中，从而在终端访问 CDN 时直接由 CDN 向终端提供内容，无需再从源站获取，提升了终端用户体验。
(2)内容预注入
内容预注入是指源站在内容发布之前将内容注入 CDN 中 。 内容预注入与内容存储接入方式类似，都是由业务系统主动向 CDN 发送操作指令 ， CDN 根据指令预先从 内容源回源获取内容，是就近提供服务的接入方式。
(3)实时回源
实时回源 (未注入〉是指源站在 内 容发布之前不向 CDN 注入内容，但当用户 内容访问请求时 ， CDN 实时地从源站 拉取内容。
静态内容服务是指 CDN 承载的内容主要是 HTML 文件、文本、 Flash动画、图片、视频、应用软件等。一般来说，这些文件相对更新频率较低，而且热点内容集中，通过缓存技术可将热点内容分发存储在 CDN 的节点上，以满足终端用户就近访问的需求 。
4.CDN调度系统是什么
调度系统是指CDN厂家有能力通过各种机制将客户域名的所有现网请求引导到合适的目标机房，从而实现流量控制、质量控制、成本控制以及故障处理。
一般有哪些调度形式？
1)DNS调度基于请求端local dns的出口IP归属地及运营商属性的DNS调度；
2)302调度再是基于客户端IP归属地及运营商属性的302跳转调度；
3)路由调度最后是基于Anycast技术（BGP路由）的机房流量调度；
1) CNAME方式
这是最常见的方式，即CDN厂家向客户提供一个调度域名，客户将自己业务域名的CNAME指向这个调度域名，从而实现将请求引导到CDN上来。比如腾讯云向客户提供的CDN是 $domain.cdn.dnsv1com ，所以客户的域名 www.test.com 如果需要将请求切到腾讯云CDN上，只需要将 www.test.com 的CNAME 设置为 www.test.com.cdn.dnsv1.com 即可。
CNAME方式的背后，又分几种：
a) 一种是CDN厂家提供基于DNS的调度，就最终客户的域名经CDN的调度域名解析出CDN节点的IP。腾讯云CDN就是这种玩法，大家可以dig p200107.ping.dnsv1.com看下效果。 对应前面的调度方式1。
b) 一种是CDN厂家给的CNAME实际不是真正CDN节点，而是一个调度集群，真正的CDN IP地址是通过在调度集群上向请求响应302跳转实现的。 对应前面的调度方式2。
c) 再有一种，是Anycast CDN。从DNS层面上看，CDN厂家提供给你的CNAME的解析结果只有全球固定的一两个IP地址，不像方式1中不同地区的解析结果IP不同。这种场景下的流量调度， 不是靠DNS解析，而是Anycast BGP路由的调整，通过调整Anycast的路由来调度各地区的流量到哪个机房。对应前面的调度方式3。
第一种基于local DNS的调度是怎么实现的？
CDN的调度服务器本身就是调度域名的NS权威服务器，调度域名的TTL被故意设置成很短（比如3分钟），这样所有请求都会较频繁地触发客户端的local DNS重新到CDN调度服务器解析新的IP地址。此时CDN的调度服务器依据是local DNS的出口地址。
调度流程如下：
A. 客户端DNS TTL过期无首次访问，向local DNS发起DNS查询
B. local DNS在递归解析过程中，向CDN的调度服务器发起解析请求；
C. CDN调度服务器可以看到local DNS的出口ip（有时还有基于EDNS的客户端ip）；
D. 通过IP库获取上一步IP的地理及运营商属性，从当前调度域名的策略规则中去匹配，同时结合其它的因素（比如质量监控、机房成本因素等）得到最佳的一组IP；
第二种 浏览器向第一次拿到的IP发起http请求；
如果这个IP实际上是CDN的边缘节点，它会从本机的配置文件中读取信息 p73.ping.dnsv1.com这个域名的请求Host如果不是IP，URL形式为：http://p73.ping.dnsv1.com/a.php 则将请求转发到后端调度集群；
若请求Host为IP，对应的URL形式为： http://61.142.166.245/p73.ping.dnsv1.com/a.php 则读取缓存提供文件服务。
此时请求到了调度群集上，我们能拿到的客户端信息有 客户端的出口IP（绝大多情况下是相同的），接下来算法和基于DNS的调度可以是一样的，只是判断依据由local DNS出口ip变成了客户端的出口IP；
调度集群毕竟不是CDN节点，无法向客户端提供实际的文件内容，此时它只能通过302报文告知客户端，你可以去上一步骤计算的IP请求文件；
浏览器收到302回应，跟随Location中的URL，继续发起http请求，这次请求的目标IP是CDN边缘节点，且Host是IP，CDN节点会响应实际的文件内容；
第三类基于Anycast BGP路由的调度如何实现
Anycast路由技术使得物理分布在全球/全球不同区域的不同服务器具有相同的IP地址，客户端对这个IP的请求会在路由层面引导到最近的物理服务器上。Anycast CDN我们后续单独用一篇文章讲解，这里先略过实现细节。
Anycast CDN的优点:
由于IP少且固定，TTL长，对CDN权威服务器的DNS解析性能要求不高；
在路由层面完成了就近接入CDN，比DNS抗干扰，比302兼容性好；
路由策略变动生效时间快，优于DNS调度；
受DDOS攻击时，只需调整路由，将攻击流量引导到高带宽清洗机房，无需从现网剔除IP；
基于DNS的调度有哪些缺点？
调度策略非实时生效
DNS是树型分布式系统，所有节点上都会按域名的TTL来做缓存，这就导致CDN的调度策略其实并不是实时生效的，比如有个IP（或VIP）故障，将它从现网完全隔离需要一定的时间，比如5~10分钟。
这个问题可通过将CDN调度域名的DNS TTL调小，比如由1~3分钟调到秒级，但又会遇到新的问题：
》一般运营商的DNS服务器出于安全考虑，会忽略太小的TTL值强制改为固定值；
》假设运营商老老实实按你的极短的秒级TTL来，也会导致较频繁触发DNS解析；
DNS解析是有成本的，当客户端自身网络或CDN的DNS权威网络或服务性能太差时，将非常明显地增加业务的请求延迟，这对冷域名请求量较小的业务又是响应时间敏感型业务影响非常大。
如果TTL太长呢，导致CDN的调度策略变化后全网生效时间过长，如果CDN某个机房故障需要从现网调度剔除，DNS全球生效如果要花上30分钟，那这30分钟内访问到原故障IP的请求就都仍旧是失败的。
调度不够精确
大量的local DNS不支持edns协议，拿不到客户的真实IP，CDN绝大多数时候只能通过local DNS ip来做决策，而local DNS ip有时候不太靠谱。常常遇到的问题有：
》客户配置了非本地区的DNS服务器，比如深圳电信用户配置了北京电信的DNS服务器，结果CDN给你分配了北方的CDN节点IP；
》DNS服务器的出口IP与入口IP差距大，比如某些小运营商的DNS服务器IP看起来是本地的，但实际DNS流量绕大半个中国从另外的区域出去，所以也会导致CDN给出完全不对的节点IP；
》上一种类型，还有一种情况，像8.8.8.8这种Public DNS，接入IP是Anycast IP没有归属地一说，出口IP经常变动，比如中国大陆使用时，出口IP经常是中国台湾的google 机房。DNSPOD所说有针对这种情况做特殊处理，凡是google中国台湾来的请求强制判断为中国大陆。
基于302跳转的调度有何优点：
实时调度
由于每次拿到的最终IP都是实时计算的结果，所以调度策略是实时生效的，不像基于DNS的调度会受到DNS TTL缓存的影响而有延迟。
实时调度有什么好处？
》可以快速隔离故障设备；
》可以精确控制节点与机房的带宽和资源负载；
》可以快速对应业务的突发，特殊适合大文件下载类突发场景，比如手机固件、游戏安装包、大体积资源的分发；
准确性高
由于可以拿到请求的出口IP，在不考虑NAT或小运营商出口飘移这种奇葩场景时，客户端归属地更贴近真实情况，不受用户的DNS配置影响，配错了也没关系；
但是也有限制:
业务兼容性
要求客户业务的客户端必须支持302跟随，比如手机固定或应用下载，如果下载客户端不识别http 302响应码，那下载就会失败。
对延时敏感业务不适用
这种模式的调度，每个请求都会多出一次http交互。比如web静态小资源就不太合适，一个网站加载几十个js/css文件，每个文件都302跳转一次？那加载时间会成倍增加。
所以302只适用于客户端兼容性好的大文件下载业务。
TCP优化
TCP 优化在传统的性能优化领域中很容易在应用层面被忽略，通常在 CDN 加速服务中会
考虑这个优化。大型网站不仅有图片还有动态请求， 经过 TCP层面优化，可以让网络耗时变短。而在 CDN层面，由于大型网站还有大量的图片和 JS等资源，这些静态资源占整个页面请求的 90%
以上，所以只要性能提升 10%，整体的性能体验改观就相当明显。特别是提供全球化服务的大型网站，近几年发展非常迅速，买家分布越来越广泛。跨境最大的挑战是地理距离长 ， 网络延迟天然巨大，例如北美洲到欧洲的网络距离 RTT 在 250ms 以上。亚洲到北美洲的网络距离 RTT 在 200ms 以上。根据数据初步估计，南美洲的某个国家到达北美洲的美国的请求去包率高达 6%~l0%。一旦丢包，大部分都会发生超时重传，基于 3 次重复ACK 的快速丢包发现算法，在很多情况下没有起到作用。减少丢包时的网络延迟，对跨境业务来说， 比淘宝在国内得到的效益将 更加可观 。 TCP 协议枝优化涉及 的地方非常多，从增大初始拥塞窗 口到减少默认的 RTO、 PRR、 Early Transmit。
TCP边过 “发送一应答(ACK确认〕一重传机制”来确保传输的可靠性， 它是端到端进行传输的。对于大型网站 ， I向应报文从服务器端给客户端浏览器进行报文 的传输， 所以在服务器端， 可以迦过优化来降低客户端网络耗时。传统的 TCP底层实现， 在很多时候会导致 TCP传输放率变低， 特别是网络刊’宽的扩充和整体网绵硬件技术的提升， 使得网络传输速度有很大的变化。
TCP传输是分段的，一个 HTTP响应拙文会被操作系统切成多个 MSS大小(一般为 1460B)的段，发送端每次只会发送若干段。 能够发送多少个数据包，由拥塞窗口和|接收端窗 口共同决定， 直到接收端接收到完整的报文为止。在此过程中，报文分段按照顺序进行发送， 所以当 HTTP 的请求响应模型将请求发送给服务器时，服务器响应都需要多个 RTT 的传输 ， 物理距离越远 ， 总体网络耗时越长。
滑动窗口本质上是描述接收方的 TCP数据报缓冲区大小的数据的， 发送方根据这个数据来计算自 己最多能发送多长的数据。如果发送方收到接收方的窗口大小为 0 的 TCP数据报，那么发送方将停止发送数据， 等到接收方发送窗口大小不为 0的数据报的到来。
1.窗口合拢: 当窗口 的左边缘向右边缘靠近的时候， 这种现象发生在数据被发送和确认的时候.
2.窗口张开：当窗口向右边缘移动时
3.窗口收缩：当窗口右边缘向左移动时
TCP 就是用这个窗口，慢慢地从数据的左边缘移动到右边缘，把处于窗口范围内的数据发送出去，只是窗口内的数据，这就是窗口的意义。
拥塞窗口一一发送端流量控制
Linux 内核升级中的 TCP 优化技术
1.初始拥塞窗口调整
Early Retransmit (Linux 3.5 开始支持 )
前端优化技术
(1) 合并HTTP请求
HTTP 作为无状态的应用层协议，对于每 一 次 HTTP 请求，通信链路建立以及数据传输都是必不可少的，并且需要在服务器端单独启动线程去处理每个 HTTP 请求。这就代表着DNS查询、 应用层重定向以及404等很可能会在每一次HTTP请求时发生，因此，可以通过合并 HTTP 请求的数目来有效提升访问性能，避免这些昂贵的通信服务和开销。将css、 JavaScript和图片合并成一个文件是减少HTTP请求的主要方法，这样只需要一次请求 即可 。
(2) 使用浏览器缓存
静态内容在网站’中通常更新频率较低 ，如 css、 JavaScript 以及图片等。上文说过，访问这些文件每次需要进行 HTTP 请求，那么，将这些缓存在浏览器中，则可以减少 HTTP 请求的次数，从而提升网站访问性能 。 浏览器缓存的设定是通过设置 HTTP 头中的 cache-control与 expires 的属性来实现的，设定的缓存保留时间可以短到数天，长到数月 。
值得注意的是，网站在利用浏览器缓存策略更新静态内容时， 最好能够一个个文件逐一进行更新，例如需要更新 20个图片时，不应该将 20个图片一次全部集中更新，而是需要相隔一定时间间隔逐一更新。 否则，用户浏览器会发生大量缓存突然失效，并且会造成服务器负载突发性加重以及网络堵塞的情况。
(3)压缩组件减少通信传输
在通信传输过程中，减少通信传输的数据量能起到减少传输负载大小的作用。 通常，在服务器端对需要传输的文件进行压缩，而在用户浏览器端再对文件进行解压缩，达到压缩组件减少通信传输的目的 。 对于提高压缩率，可以通过将外部的脚本和样式合并为 一个实现 。 HTML、css 和 JavaScript 文件利用 GZip 压缩方式使得压缩率超过 80%。然而，文件压缩对服务器和浏览器都会产生一定 的压力 ， 在通信带宽良好，但服务器资源不足 的状况下需要权衡考虑。
(4)使用外部 JavaScript和 css
由于JavaScript和css能够被浏览器缓存，因此， 使用外部文件通常会较快地打开页面。 而在内联的情况下， 由于 HT!\在L文档通常不会被配置为允许缓存的文件，所以用户下一次请求内联 HTML 文档时 ， JavaScript和 css 需要再次下载。由此得出，在外部文件中 ， 可以通过浏览器缓存 JavaScript ， 并减少 HTML 文档，达到避免增加 HTTP 请求数量的效果 。 可以说当 HTML 文档数占的比重过大时，使用外部文件是一个有效提升页面访问性能的手段 。
(5)减少 cookie 传输
对于每一次请求和响应 cookie 过大会对数据传输造成极大影响，所 以需要谨慎考虑并决定把哪些数据写入 cookie，以达到减少 cookie 中传输数据量的目的。对于访问一些静态内容， 例如， 对于 css和 JavaScript等发送 cookie是没有意义的。在这种情况下，通过使用独立域名访问静态内容的方式， 避免请求静态内容时发送 cookie， 并减少 cookie的传输次数。
(6)避免 css 表达式
css 表达式是一种动态设置 css 属性的强大且危险 的方式。在人们期望中表达式不只在页面呈现和值大小改变时需要利用表达式求值，甚至当页面上下滚动，包括鼠标在页面上移过时，表达式都要进行求值操作。使用 一 次性表达式能够减少 css 表达式求值次数。如果 css 表达式必须被求值一次， 可 以在这次中对它本身进行重写。