这个问题的解答，需要分五步。
HTML的文件头（也有文件中，文件尾）那边常有其他文件引用，比如CSS以及JS的引用。
就以bootstrap常用的引用来举个栗子
也可以打开这个看看： http://static.zhihu.com/static
CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。
简单地说，
内容分发网络(CDN)是一个经策略性部署的整体系统，包括
分布式存储、
负载均衡、网络请求的重定向和内容管理4个要件，而内容管理和全局的网络流量管理(Traffic Management)是CDN的核心所在。通过用户就近性和
服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。
总的来说，内容服务基于
缓存服务器，也称作
代理缓存(Surrogate)，它位于网络的边缘，距用户仅有"一跳"(Single Hop)之遥。同时，
代理缓存是内容提供商源
服务器（通常位于CDN
服务提供商的数据中心）的一个透明
镜像。这样的架构使得CDN
服务提供商能够代表他们客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍
请求响应时间有任何延迟的。
HTML的文件头（也有文件中，文件尾）那边常有其他文件引用，比如CSS以及JS的引用。
就以bootstrap常用的引用来举个栗子
你常见的引用可能会是这样的：
<head>
<title>Mushroom</title>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,Chrome=1" />
<meta http-equiv="X-UA-Compatible" content="IE=9" />
<!-- 引入 Bootstrap -->
<link href="/css/bootstrap.min.css" rel="stylesheet">
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="/js/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="/js/bootstrap.min.js"></script>
</head>
这之中，<script src="/js/bootstrap.min.js"></script> 这段就是外部脚本文件的一个链接，当前的这种链接是相对URL，指向站点内的文件，即你本项目里对应路径下面放置的文件。可以在
HTML <script> 标签的 src 属性 查看这个标签的具体属性。
属性值
值 描述
URL 外部脚本的 URL。可能的值有：
•绝对 URL - 指向其他站点（比如 src="www.example.com/example.js"）
•相对 URL - 指向站点内的文件（比如 src="/scripts/example.js"）
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>
第二步，系统的资源引用
在一个网站项目中，页面里经常会有许多js以及css的引用，接触过开发项目的一般都会了解，大部分界面里的脚本引用并不是像第一步里的那么精简，如果是直接引用项目内文件的话，他们可能是这样的：
在一个网站项目中，页面里经常会有许多js以及css的引用，接触过开发项目的一般都会了解，大部分界面里的脚本引用并不是像第一步里的那么精简，如果是直接引用项目内文件的话，他们可能是这样的：
<SCRIPT src="/iforums/templates/default/js/common.js" type=text/javascript></SCRIPT>
<SCRIPT src="/iforums/templates/default/js/ajax.js" type=text/javascript></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/third-party/jquery-1.10.2.min.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.config.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.parse.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.all.js"></SCRIPT>
可能甚至引用的更多，这样将资源文件与业务代码一锅炖的方式适用于小型的，应用服务器压力并不是太大的系统（并发、带宽、存储空间、资源等等）。这种方式的优点是开发省力，发布省力，对服务器要求小，省钱，没有具体公网接入需求。许多小型，内部使用型的网站系统往往采取这种形式放置资源文件。
第三步，系统访问量变高了，速度变慢了怎么办
怎么办？优化系统部署呗。
怎么优化？优化方式有很多，读写分离，负载均衡，这方面的东西可以讲上三天三夜。具体到本问题的范畴内，那就是资源服务器与应用服务器的分离。粗暴的理解方式就是，就是应用安在应用服务器（一台或者是集群），资源部署在资源服务器（单台或者是集群），这时候，js以及css的引用就需要更改为绝对URL，指向对应的资源服务器。
比如知乎的引用：
怎么办？优化系统部署呗。
怎么优化？优化方式有很多，读写分离，负载均衡，这方面的东西可以讲上三天三夜。具体到本问题的范畴内，那就是资源服务器与应用服务器的分离。粗暴的理解方式就是，就是应用安在应用服务器（一台或者是集群），资源部署在资源服务器（单台或者是集群），这时候，js以及css的引用就需要更改为绝对URL，指向对应的资源服务器。
比如知乎的引用：
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(57px).png" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(72px).png" sizes="72x72" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(76px).png" sizes="76x76" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(114px).png" sizes="114x114" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(120px).png" sizes="120x120" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(152px).png" sizes="152x152" />
<script src="http://static.zhihu.com/static/revved/js/-/vendor.min.5a2082ff.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app_core.fb4023ac.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/sign.e0ca7b10.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app.9eaaec15.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/rich_text_editor.3a07c473.js"></script>也可以打开这个看看： http://static.zhihu.com/static
第四步，网络方面的优化
网站的访问速度，只基于一点，那就是页面包含的内容传输到用户电脑的速度，服务器搭的再好再完美，如果用户到服务器的链路之间有一段比较缓慢的话，整体速度也会被拉的十分差劲。
想象一下，你给公司做了个运行于公司内网的网站，一切运行良好，分布式部署也已搭建完毕，一切都很完美。
后来，你公司运营良好，开了一个十分遥远的分公司（不要问为什么遥远，再问自绝经脉），你们的内网也同时连了过去（对，就是那种很直接的搭了几条网线就把两个局域网连成一个局域网的黑科技）。但是因为太远了线节点太多了，分公司访问公司的系统十分缓慢，这时候你就愁啊，这可咋办？那不行就在分公司那边部署一套内容缓存好了，内容进行同步，这样至少分公司的网页访问速度能提升很多，你也可以立功升职加薪了。
紧接着，因为你的出色表现，你们公司扩展十分厉害，在全国各地都建立了分公司，你又开始愁了，这不能每个分公司都搭一套啊，累得慌啊。思来想去，那就华东一套华北一套华南一套东北一套这样分吧，然后搭一些分发服务器，接入访问地址，然后跳转到就近的内容缓存服务器进行内容读取，OK，又到了升职加薪的时刻了~
对，到这里，你已经完成了一套简易CDN的建设。
网站的访问速度，只基于一点，那就是页面包含的内容传输到用户电脑的速度，服务器搭的再好再完美，如果用户到服务器的链路之间有一段比较缓慢的话，整体速度也会被拉的十分差劲。
想象一下，你给公司做了个运行于公司内网的网站，一切运行良好，分布式部署也已搭建完毕，一切都很完美。
后来，你公司运营良好，开了一个十分遥远的分公司（不要问为什么遥远，再问自绝经脉），你们的内网也同时连了过去（对，就是那种很直接的搭了几条网线就把两个局域网连成一个局域网的黑科技）。但是因为太远了线节点太多了，分公司访问公司的系统十分缓慢，这时候你就愁啊，这可咋办？那不行就在分公司那边部署一套内容缓存好了，内容进行同步，这样至少分公司的网页访问速度能提升很多，你也可以立功升职加薪了。
紧接着，因为你的出色表现，你们公司扩展十分厉害，在全国各地都建立了分公司，你又开始愁了，这不能每个分公司都搭一套啊，累得慌啊。思来想去，那就华东一套华北一套华南一套东北一套这样分吧，然后搭一些分发服务器，接入访问地址，然后跳转到就近的内容缓存服务器进行内容读取，OK，又到了升职加薪的时刻了~
对，到这里，你已经完成了一套简易CDN的建设。
第五步，CDN是什么？
你的搭建只是基于你公司的大型局域网，而现行的流行CDN则是基于地球搭建的超大型局域网--因特网。它的好处是什么呢？
比如你这么写：
你的搭建只是基于你公司的大型局域网，而现行的流行CDN则是基于地球搭建的超大型局域网--因特网。它的好处是什么呢？
比如你这么写：
<!-- 引入 Bootstrap -->
<link href="http://apps.bdimg.com/libs/bootstrap/3.3.0/css/bootstrap.min.css" rel="stylesheet">
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="http://apps.bdimg.com/libs/html5shiv/3.7/html5shiv.min.js"></script>
<script src="http://apps.bdimg.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="http://apps.bdimg.com/libs/jquery/2.1.4/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>
上面的地址是百度CDN的链接地址。
那么用户在读取网页内容的时候，就会去百度的就近服务器上掏这些js和css，而不是在你的服务器里捞。
好处呢，第一，一般来说，访问速度有保障，稳定性也有保障；第二，你可以省下资源服务器的一部分资源负担，节省空间节省流量，艰苦创业，能省则省啊。
这时候你会问了，为什么只有js和css呢？其他的图片啊html内容啊不能放进CDN吗？
能啊为啥不能，CDN服务就靠这赚钱呢为啥不能，非广告非广告非广告，你看：
CDN-Content Delivery Network-百度开放云
同类产品还有阿里云等等等等。。
那么用户在读取网页内容的时候，就会去百度的就近服务器上掏这些js和css，而不是在你的服务器里捞。
好处呢，第一，一般来说，访问速度有保障，稳定性也有保障；第二，你可以省下资源服务器的一部分资源负担，节省空间节省流量，艰苦创业，能省则省啊。
这时候你会问了，为什么只有js和css呢？其他的图片啊html内容啊不能放进CDN吗？
能啊为啥不能，CDN服务就靠这赚钱呢为啥不能，非广告非广告非广告，你看：
CDN-Content Delivery Network-百度开放云
同类产品还有阿里云等等等等。。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
