一.名词定义
回源
  在回源模式下，CDN的OC节点实质上是一个缓存服务器。在用户请求某个文件时，OC节点首先检查自己有无此文件的缓存，若有并且缓存没有过期，则直接返回给用户；若无此缓存或者缓存已经过期，则先到源服务器请求到最新的文件，再返回给用户。
业务源服务器
  业务侧同事维护的web服务器，apache、nginx或其他web服务器均可。业务侧运维同事对文件的新增、更新、删除操作也在这个机器上进行。为容灾考虑，可以同时部署多台业务源服务器，不过要维护好各源之间的文件和配置一致（尤其要注意存在多线路解析以及多地idc机房做集群不同步的场景存在）。
中间源服务器
  位于业务源和OC节点的一批中间层的回源服务器（其运行的软件及回源机制和OC节点并无不同）。目的是为了实现多运营商的接入，并且缓存OC节点的回源访问，降低业务源服务器的访问压力。 
OC节点
  我们将自建CDN在各地机房称为OC机房，相应的其服务器节点便称为OC节点，OC节点是用户可以直接访问到的服务器节点。
 
二.回源的文件更新机制
1.只有回源才会导致触发文件更新；
2.只有OC节点收到用户请求（对于中间源，是收到OC节点的请求时）时才会触发回源请求。
 
三.文件更新规则
文件更新的动作是根据源服务器返回的HTTP码来预期的。
200：缓存这个文件（节点现在无缓存）或更新这个文件（节点现在有缓存）。
304：保留现有的文件缓存。
404：删除现有的缓存。（为缓解404带来的回源请求压力，OC节点会缓存404状态10秒钟，中间源不会）
其他3XX或4XX：透传，不缓存。
5XX：源服务器异常，下面有详细解释。
关联文档 《cdn中对301/302/404的缓存问题》
四.回源触发规则
  如开头所说，在用户请求某个文件时，OC节点若无此缓存或者缓存已经过期，则就会触发回源。在OC节点缓存时间过期的情况下，回源的HTTP请求头会带上If-Modified-Since: ${文件的mtime} 这个项，这样若是文件没有修改的话，源服务器便会返回304。
 
五.缓存过期规则
  总体来说，一个文件的缓存时间，是由服务器返回的Cache-Control: max-age=${time} 项决定的。当节点缓存或者更新了一个文件，则有一个计时器开始倒计，当计时器倒计到0时，则标记此缓存为过期。服务器不返回Cache-Control项或者返回Cache-Control: no-cache，则文件不会被缓存。不过这里有两个例外：
5.1 为了容错起见，节点的缓存时间最长为24小时
  即对于服务器返回的缓存时间超过24小时的文件，节点的缓存时间只会为24小时，这样可以保证所有的文件在24小时内肯定会回源一次；
5.2 带有随机参数的请求节点最长缓存时间为1个小时
类似http://a.qq.com/bz.gif?qaz 这样url中带有?参数的请求，节点的缓存时间最长为3600S，这也是基于容错的考虑。
这里的例外只是针对于OC节点，用户请求时收到的缓存时间还是和业务源服务器配置是一致的。
六.回源失败的处理
  由于网络波动或者其他各种奇奇怪怪的缘由，回源的请求有时会失败。回源失败可以分为两种情况：源服务器返回码为5XX或回源请求连接超时（失败）。
场景1 源服务器返回为5XX
  此时OC节点会将此源服务器屏蔽45S（即45S内不会再向此服务器发起回源请求）；并将服务器的返回透传给用户。
场景2 回源请求连接超时（失败）
  此时OC节点同样会将源服务器屏蔽45S。若OC节点是有缓存（虽然已经标记为过期），则将现有的缓存返回给用户，同时会设置响应的Cache-Control: max-age=0，以防止用户缓存这个文件；若没有缓存，则给用户返回404。
若是在最差的情况下，所有的源服务器都被屏蔽了，则节点回源时会随机选择一个源服务器（就和所有的服务器都没有被屏蔽一样）。总之，尽最大努力提供服务。
  
七.强制刷新缓存指令
  由于业务发布或者其他各种理由 用户可能希望文件可以尽快的更新（即尽快的让OC节点的现有缓存失效），cdn提供了一个接口，用户可以在控制台上手动地将需要即时更新的文件的url（或url列表）提交到这个接口，CDN侧将会在5分钟内（实际时间可能更短）将全网的OC节点的缓存失效掉。多说一句，在刷新之前，为确保刷新成功，建议用户在源站上先将需刷新的文件touch一下，以保证其mtime比现有文件的mtime更新。
 
八.CDN常见优化配置建议
8.1 对源服务器配置建议


  回源模式下，若用户访问触发了回源，则此次的访问耗时为用户访问时间+回源时间。一般来说回源时间在几ms到几百ms之间（极端情况可能会更长）。因此，若要减少回源对用户的影响，则要尽可能减少回源请求的数量，并尽量降低单个回源的耗时。这个就是总体的指导原则。
8.2 web服务器配置建议


  对于业务源，请确保web服务器返回的HTTP头包含Cache-Control和Last-Modified两项并避免使用Transfer-Encoding: chunked，没有Cache-Control项则文件不会被缓存，没有Last-Modified则源服务器在回源请求带有If-Modified-Since头时也不会返回304（相同情况下304比200响应更短更快），有Transfer-Encoding: chunked的响应是没有Last-Modified项的（常见的header头部含义见文档 《HTTP KeepAlive详解及头部字段含义释义》）。


8.3 控制台缓存时间配置建议
  总体来说缓存时间越长越好，一个非严格的建议值为7200S或更长。具体操作时，需根据不同文件的更新频次来配置不同的缓存时间，即更新越不频繁的文件，缓存时间可以设置的越长。一般可以针对不同类型的文件或者不同目录的文件来配置不同的缓存时间，举例说明，一般图片和flash文件更新是不太频繁的，则可是设置最长的缓存时间，JS和CSS文件次之，html文件等用户可以直接访问的入口文件应设置较短的缓存时间。对于短缓存时间的文件，应严格控制其数量，并且避免针对所有的文件使用相同的缓存配置。
8.4 文件更新建议


  总体的原则就是避免同名更新及带?参数的url（基本上?参数就是为了规避同名更新的风险而使用的）。通过将版本号嵌入到文件名（或目录名）中是一个不错的办法，基本就可以避免同名更新了，这样的话，就可以给资源设置一个极长的缓存时间。 


8.5 预拉取策略


  对于大型活动开始之前，或者新上线业务发布之前，建议对业务url做预热（预拉取）操作。当业务有发布时，强刷指令只是让OC节点的缓存标记为失效，实际的文件更新动作还要在用户访问的时候去完成。针对这个情况，我们后期会在强刷后，由专门的预拉取系统来触发相应的回源请求，避免由用户触发，从而提高用户的体验。
目前已经有api和控制台提供预拉取策略：
API操作 
控制台预热
8.6 异步回源策略


针对回源的统计数据表明，绝大部分的回源请求服务器返回的都是304（即文件内容没有变化），所以可以将OC节点的回源步骤改为先吐给用户现有的文件再发起回源请求（即将现有的步骤反过来），以避免回源时造成的用户访问等待。为了规避文件真的更新这种情况，异步回源时给用户返回会设置Cache-Control: max-age=0，以避免用户缓存此次响应。异步回源策略搭配预拉取策略将会起到最好的效果。


8.7 302跳转策略


  这个是异步回源策略的进一步加强，主要是针对的文件尺寸偏大的业务。当OC节点存在缓存时，其工作模式和异步回源一致；若OC节点不存在缓存，则向用户返回一个指向到源服务器的302跳转响应，让用户直接去访问源服务器，然后OC节点再发起回源请求。这个策略现在仅在3G下载业务上启用，正常的静态资源类业务应该不会用到这个策略。


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
注：
“The fear of the Lord is the beginning of wisdom, and the knowledge of the Holy One is wisdom.”
原文由博主方胜山编辑撰写，版权归博主所有。更多相关资讯请关注微信“ebookyx”原文地址 http://www.itts-union.com/3064.html 转载请注明出处！