浅谈CDN

转自知乎：https://www.zhihu.com/question/36514327/answer/68143522

第一步，HTML的文件引用

HTML的文件头（也有文件中，文件尾）那边常有其他文件引用，比如CSS以及JS的引用。

就以bootstrap常用的引用来举个栗子

这段就是外部脚本文件的一个链接，当前的这种链接是相对URL，指向站点内的文件，即你本项目里对应路径下面放置的文件

• 绝对 URL - 指向其他站点（比如 src=“www.example.com/example.js”）
• 相对 URL - 指向站点内的文件（比如 src="/scripts/example.js"）

，URL的引用有两种方式，绝对和相对，绝对的方式就是直接引用其他站点的js地址，比如把上方的引用改为

这样即是引用其他站点的js。
CSS文件的引用、图片以及其他文件的引用也类似。

第二步，系统的资源引用

在一个网站项目中，页面里经常会有许多js以及css的引用，接触过开发项目的一般都会了解，大部分界面里的脚本引用并不是像第一步里的那么精简，如果是直接引用项目内文件的话，他们可能是这样的：

可能甚至引用的更多，这样将资源文件与业务代码一锅炖的方式适用于小型的，应用服务器压力并不是太大的系统（并发、带宽、存储空间、资源等等）。这种方式的优点是开发省力，发布省力，对服务器要求小，省钱，没有具体公网接入需求。许多小型，内部使用型的网站系统往往采取这种形式放置资源文件。

第三步，系统访问量变高了，速度变慢了怎么办

怎么办？优化系统部署，优化方式有很多，读写分离，负载均衡，这方面的东西可以讲上三天三夜。具体到本问题的范畴内，那就是资源服务器与应用服务器的分离。粗暴的理解方式就是，就是应用安在应用服务器（一台或者是集群），资源部署在资源服务器（单台或者是集群），这时候，js以及css的引用就需要更改为绝对URL，指向对应的资源服务器。

比如知乎的引用：

第四步，网络方面的优化网站的访问速度

只基于一点，那就是页面包含的内容传输到用户电脑的速度，服务器搭的再好再完美，如果用户到服务器的链路之间有一段比较缓慢的话，整体速度也会被拉的十分差劲。想象一下，你给公司做了个运行于公司内网的网站，一切运行良好，分布式部署也已搭建完毕，一切都很完美。

后来，你公司运营良好，开了一个十分遥远的分公司（不要问为什么遥远，再问自绝经脉），你们的内网也同时连了过去（对，就是那种很直接的搭了几条网线就把两个局域网连成一个局域网的黑科技）。但是因为太远了线节点太多了，分公司访问公司的系统十分缓慢，这时候你就愁啊，这可咋办？那不行就在分公司那边部署一套内容缓存好了，内容进行同步，这样至少分公司的网页访问速度能提升很多，你也可以立功升职加薪了。紧接着，因为你的出色表现，你们公司扩展十分厉害，在全国各地都建立了分公司，你又开始愁了，这不能每个分公司都搭一套啊，累得慌啊。思来想去，那就华东一套华北一套华南一套东北一套这样分吧，然后搭一些分发服务器，接入访问地址，然后跳转到就近的内容缓存服务器进行内容读取，OK，又到了升职加薪的时刻了~
对，到这里，你已经完成了一套简易CDN的建设。

第五步，CDN是什么？

你的搭建只是基于你公司的大型局域网，而现行的流行CDN则是基于地球搭建的超大型局域网–因特网。它的好处是什么呢？比如你这么写：

上面的地址是百度CDN的链接地址。那么用户在读取网页内容的时候，就会去百度的就近服务器上掏这些js和css，而不是在你的服务器里捞。
好处呢，第一，一般来说，访问速度有保障，稳定性也有保障；
第二，你可以省下资源服务器的一部分资源负担，节省空间节省流量，艰苦创业，能省则省啊。

最后

除了js和css呢、其他的图片啊html内容啊都可以放进CDN。