易栈网-膘叔

 本来觉得orca.io这个免费的cdn还是不错的，用了一个月也确实觉得还行。结果。。。怎么这么快就被墙了呢？我晕啊。。

CDN这个东西，当然是个好东西。。。所以看到有FAQ就理所当然的复制下来，其实，最近我突然想到一件事情，中国的地区域名还有一个很有意思的地域域名，那就是js.cn，所以，我悄悄的申请了两个域名，cache.js.cn和cdn.js.cn，就是想用来做这种CDN转发，当然，只是简单的。。。

我最初的想法是（有一小部分），如果我的服务器里有N多人装了DZ论坛，那么这些JS和CSS其实都是共用的。如果我都用同样的域名进行转发，那，其实节约了很多空间，也节约了带宽。因为同一个域名出来的JS和CSS文件，理论上是应该被缓存的哦。。

以下内容就是FAQ，自己也学习一下。。。

1.CDN加速原理
通过动态域名解析，网友的请求被分配到离自己最快的服务器。CDN服务器直接返回缓存文件或通过专线代理原站的内容。
网络加速+内容缓存，有效提供访问速度

2.CDN节点数量
全国多个机房，每个机房多台服务器，CDN节点一般上百台

3.CDN缓存什么内容
缓存html、图片、css、xml等静态资源，不缓存含有？的动态地址、jsp、php，js文件也不缓存【除非特殊设置】
缓存原站返回HTTP状态为20*或304，不缓存其他状态(例如404，500，503)

4.CDN缓存内容的更新
a）用户首次请求，CDN从原站抓取后缓存，直到文件过期后有用户请求再次更新
b）程序主动通知CDN抓取

5.CDN缓存内容的有效期
a）原站apache吐出的静态文件：由apache的expire和header模块控制
主要两项：last-modified，cache-control：max-age
apache缺省配置，所有静态文件在cdn只缓存3600s【需要我们按需求调整被加速服务器的apache设置】
3600s后cdn失效，用户访问时会重新请求原站，如果没有变化，缓存失效周期自动延长10%。
b）原站jsp或php吐出的动态内容（url形式必须是静态的）
由程序控制last-modified，cache-control：max-age public ，apache的设置将不起作用
cdn根据这两项判断是否需要到原站更新内容

6.CDN和应用的结合策略
a）变化不频繁的页面：例如图吧的图片显示页、车型页、已结束的比赛对阵页
在原站生成静态页面，原站apache上定义过期时间，例如1天。
原站上静态文件更新后，可以等待cdn过期。或者主动通知cdn更新（随着cdn节点越来越多，代价会非常高）
b）变化频繁的页面：例如足球库中的及时亚盘、及时欧赔、正在进行的比赛对阵页
不生成静态页面，由jsp或php定义过期时间，例如5s或60s。cdn过期后，如果有用户访问就从原站上抓取。
优点：相关页面内容更新后，不需要主动通知100个原站都来抓取，有效降低原站的压力。
如果页面内容没有变化，返回lastmodified不变，这样原站会直接返回304给cdn，cdn也会返回304给用户。减少网络传输和速度
比赛结束后，“正在进行的比赛对阵页”转换为第一类情况，再生成静态文件
c）特殊静态资源：例如图片库和某些大型产品库中的评论js
或者频繁访问、频繁更新的页面：例如足球赛事库的及时比分文件
通过apache nocache告诉IE不缓存，html中就不需要使用pinglun.js?123456这样的代码形式
然后用max-age告诉cdn缓存1s，这样避免每次用户请求都转到原站

本文来源：http://71j.cn/archives/10

看到这篇文章，就随手转贴了一下，因为我自己也在使用这样的功能，而且，现在的网站几乎都有google的广告。所以从yahoo的14条军规来说，这并不违反这个规则：使用CDN，尽量不要有超过4个域名的链接。所以你想呀，有一些google广告和yahoo的统计再加上1至2个其他的链接，肯定是没有超过4个域名了。CDN，有现成的，使用了，也算是完成了14条军规中的一些了。不是吗？所以。。。。。。

原文：http://shawphy.com/2009/01/why-google-cdn.html

自从之前jQuery 1.3版起，就已经没有提供pack版了，而我也十分赞成使用Google CDN进行代码托管。

这样做有以下几个好处：
1，更小下载量。
都知道jQuery 1.3 pack后有38k之多，如果当然可以删除版权注释以获得更小的代码，遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版，只有18k，对用户来说下载量更小。

2，减轻服务器压力。
虽然现代浏览器都有了缓存，但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的（哪位同学能帮忙找到资料请下面留言，不胜感激~）。所以，让Google为我们提供服务，而不用自己操心自己的流量~少个库可以少个连接数，何乐而不为。

3，多个网站共享缓存。
如果用户访问的多家网站都使用Google提供的jQuery，那么对于用户来说，只需要缓存一次后即可只读取缓存中的数据！而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。

4，更快执行速度。
jQuery 1.3.1发布的发布信息中， 为jQuery不提供pack版给出了官方的解释。除了不易debug，在Adobe AIR和Caja-capable等环境下无法使用之外，更重要的是因为执行速度问题。随着jQuery逐渐变“胖”，用pack压缩后在浏览器端“解压 缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给 出了一些数据，有兴趣的同学可以看看。

反对的声音：
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢？”、“以前刚开始的时候就down过”

我认为（晕……怎么我觉得我在写四六级作文……）Google服务器down的几率与我们自己服务器down的几率不会有显著性差异（抱歉，我又空 口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设，认可备选假设的，欢迎提供，再次不胜感激~）。所以就放他们那边吧，挺安全的。

另外我还听到关于不能让整个世界为着Google转，Google阴谋论，Google威胁论的声音。实际上Google确实正朝这个方向发展，让 整个互联网围着他转。可以看他提供的一些服务，什么云计算，什么App Engine之类的，都企图让人们的应用都建立在Google至上，当Google成为了空气的时候，他已经无处不在了。这点来说，值得担忧。