为什么要用CDN ？CDN是怎么工作的？

CDN 全称 Content Delivery Network，即内容分发网络，它是构建在现有网络基础上的虚拟智能网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、调度及内容分发等功能模块，使用户在请求所需访问的内容时能够就近获取，以此来降低网络拥塞，提高资源对用户的响应速度。

为什么要用CDN

我们所熟知的浏览器缓存方案，它们带来的性能提升主要针对的是浏览器端已经缓存了所需的资源，当发生二次请求相同资源时便能够进行快速响应，避免重新发起请求或重新下载全部响应资源。

这些方法对于首次资源请求的性能提升是无能为力的，因此我们需要使用CDN技术。

CDN如何工作

借中国地图一角来给大家举一个简单的例子：

假设我的根服务器在杭州，同时在图示的五个城市里都有自己可用的机房。

核心功能

CDN 的核心点有两个，一个是缓存，一个是回源。

这两个概念都非常好理解。对标到上面描述的过程，“缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程，“回源”就是说 CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。

虽然这个过程看起来稍微复杂了一些，但对用户体验来说是无感知的，并且能带来比较明显的资源加载速度的提升，因此对目前所有一线互联网产品来说，使用 CDN 已经不是一条建议，而是一个规定。

针对静态资源

CDN 网络能够缓存网站资源来提升首次请求的响应速度，但并非能适用于网站所有资源类型，它往往仅被用来存放网站的静态资源文件。所谓静态资源，就是指不需要网站业务服务器参与计算即可得到的资源，包括第三方库的 JavaScript 脚本文件、样式表文件及图片等，这些文件的特点是访问频率高、承载流量大，但更新修改频次低，且不与业务有太多耦合。

如果是动态资源文件，比如依赖服务器端渲染得到的 HTML 页面，它需要借助服务器端的数据进行计算才能得到，所以它就不适合放在 CDN 缓存服务器上。

CDN预热

CDN预热是指将源站的内容提前缓存到 CDN 节点上，避免在用户首次访问时因为缓存未命中而回源，从而提升用户体验。

预热场景

新内容发布：在新内容上线时，提前将内容推送到 CDN 节点。
热门内容：预测某些内容将成为热门，提前预热到 CDN 节点。
大文件分发：对于大文件（如视频、安装包），提前预热可以避免用户下载时回源，减轻源站压力。

预热方式

主动推送：通过 CDN 服务商提供的 API 或控制台，主动将指定 URL 预热到 CDN 节点。
模拟访问：通过工具模拟用户访问，触发 CDN 节点回源缓存。

应用场景

静态资源本身具有访问频率高、承接流量大的特点，因此静态资源加载速度始终是前端性能的一个非常关键的指标。CDN 是静态资源提速的重要手段，在许多一线的互联网公司，“静态资源走 CDN”并不是一个建议，而是一个规定。

比如以淘宝为代表的阿里系产品，就遵循着这个“规定”。
打开淘宝首页，我们可以在 Network 面板中看到，“非纯静态”的 HTML 页面，是向业务服务器请求来的：

接着我们进一步去查看静态资源所请求的URL，并列举几种不同类型的资源文件如下：

// JavaScript 资源

https://g.alicdn.com/alilog/mlog/aplus_v2.js

// CSS 资源

https://g.alicdn.com/tb-mod/tbh-conve-common/0.0.1/index-min.css

// 图片资源

https://img.alicdn.com/tfs/TB1eiXTXlTH8KJjy0FiXXcRsXXa-24-595.png

从上述资源文件的请求域名中我们可以发现，这些文件都是从 CDN 网络上获取的，JavaScript 和样式表这样的文本文件与图片文件使用的是不同的 CDN 域名，而且 CDN 域名与主站域名也完全不同，这样的设计也是出于对性能的考虑，下面来分析具体的优化原理。

优化实践

我们以上节的示例来进行说明，主站请求的域名为 www.taobao.com，而静态资源请求 CDN 服务器的域名有 g.alicdn.com 和 img.alicdn.com 两种，它们是有意设计成与主站域名不同的，这样做的原因主要有两点：第一点是避免对静态资源的请求携带不必要的 Cookie 信息，第二点是考虑浏览器对同一域名下并发请求的限制。

1. 首先对第一点来说，Cookie 的访问遵循同源策略，并且同一域名下的所有请求都会携带全部 Cookie 信息。

虽然 Cookie 的存储空间就算存满也并不是很大，但如果将所有资源请求都放在主站域名下，那么所产生的效果对于任何一个图片、JavaScript 脚本及样式表等静态资源文件的请求，都会携带完整的 Cookie 信息，若这些完全没有必要的开销积少成多，那么它们所产生的流量浪费就会很大，所以将 CDN 服务器的域名和主站域名进行区分是非常有价值的实践。

2. 其次是第二点，因为浏览器对于同域名下的并发请求存在限制，通常 Chrome 的并发限制数是 6，其他浏览器可能多少会有所差异。这种限制也同时为我们提供了一种解决方案：通过增加类似域名的方式来提高并发请求数，比如对多个图片文件进行并发请求的场景，可以通过扩展如下类似域名的方式来规避限制：

https://img1.alicdn.com/examp1.jpg https://img2.alicdn.com/examp1.jpg

虽然这种方式对于多并发限制是有效的，但是缓存命中是要根据整个 URL 进行匹配的，如果并发请求了相同的资源却又使用了不同的域名，那么图片之前的缓存就无法重用，也降低了缓存的命中，对于这种情况我们应该考虑进行恰当的域名合并优化。