前言
CDN （Content Delivery Network，即内容分发网络）指的是一组分布在各个地区的服务器。这些服务器存储着数据的副本，因此服务器可以根据哪些服务器与用户距离最近，来满足数据的请求。 CDN 提供快速服务，较少受高流量影响。
为什么要用 CDN？
- 提升用户访问体验。CDN 可以将网站部署到全国的各个节点上，可以实现用户就近访问，降低网络延迟，提升用户的访问体验。
- 任意网络资源访问。CDN 可以有效避免各个运营商之间互联问题，可以实现不论用户使用哪家运营商的网络都可以快速访问。
- 提升安全性、可靠性。CDN 可以实现各个节点冗余机制，不会因某一节点出现问题而造成该网站无法访问的现象，在一定程度上可以降低 DDOS 攻击。
CDN 如何工作？
下面我们通过一个例子，来了解 CDN 是如何工作的：
假设我的根服务器在杭州，有一位北京的用户向我请求资源。在网络带宽小、用户访问量大的情况下，杭州的这一台服务器或许不那么给力，不能给用户非常快的响应速度。于是我灵机一动，把这批资源 copy 了一批放在北京的机房里。当用户请求资源时，就近请求北京的服务器，北京这台服务器低头一看，这个资源我存了，离得这么近，响应速度肯定快啊！那如果北京这台服务器没有 copy 这批资源呢？它会再向杭州的根服务器去要这个资源。在这个过程中，北京这台服务器就扮演着 CDN 的角色。
CDN 的核心点有两个，一个是 缓存，一个是 回源。
这两个概念都很好理解。对标到上面描述的过程，“缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程，“回源”就是说 CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。
CDN 与前端性能优化
CDN 往往被用来存放静态资源。上面我们举例所提到的“根服务器”本质上是业务服务器，它的核心任务在于 生成动态页面或返回非纯静态页面，这两种过程都是需要计算的。业务服务器仿佛一个车间，车间为我们产出所需的资源。相比之下，CDN 服务器则像一个仓库，它只充当资源的“栖息地”和“搬运工”。
所谓“静态资源”，就是像 JS、CSS、图片等 不需要业务服务器进行计算即得的资源。而“动态资源”，顾名思义是需要 后端实时动态生成的资源，较为常见的就是 JSP、ASP 或者依赖服务端渲染得到的 HTML 页面。
什么是“非纯静态资源”呢？它是指 需要服务器在页面之外作额外计算的 HTML 页面。具体来说，当我打开某一网站之前，该网站需要通过权限认证等一系列手段确认我的身份、进而决定是否要把 HTML 页面呈现给我。这种情况下 HTML 确实是静态的，但它 和业务服务器的操作耦合，我们把它丢到CDN 上显然是不合适的。
CDN 的实际应用
静态资源本身具有访问频率高、承接流量大的特点，因此静态资源加载速度始终是前端性能的一个非常关键的指标。CDN 是静态资源提速的重要手段，在许多一线的互联网公司，“静态资源走 CDN”并不是一个建议，而是一个规定。
以淘宝官网为例，我们注意到业务服务器的域名是这个：
www.taobao.com
在 Network 面板中可以看到 CDN 服务器的域名是这个：
g.alicdn.com
之所以设置不同域名，跟 Cookie 有很大关系。Cookie 是紧跟域名的，同一个域名下的所有请求，都会携带 Cookie。如果我们仅仅是请求一张图片或者一个 CSS 文件，我们也要携带一个 Cookie 跑来跑去（关键是 Cookie 里存储的信息我现在并不需要），这是一件多么劳民伤财的事情。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的……
同一个域名下的请求会不分青红皂白地携带 Cookie，而静态资源往往并不需要 Cookie 携带什么认证信息。把静态资源和主页面置于不同的域名下，完美地避免了不必要的 Cookie 的出现！
看起来是一个不起眼的小细节，但带来的效用却是惊人的。如果网站静态资源的流量庞大，没把这个多余的 Cookie 拿下来，不仅用户体验会大打折扣，每年因性能浪费带来的经济开销也将是一个非常恐怖的数字。
如此看来，性能优化还真是要步步为营！
