CDN网络（一）之典型的CND架构与HTTP协议的缓存控制

前言

本人以前在CDN厂商蓝汛就职过一年时间，利用脑子里还残留的一些CDN知识，结合现有的书籍材料，写点东西。

what's the CDN

CDN(content delivery Network) 是一个复杂的系统，我们进行简化抽象来看，就能用下面几步来简单概括：

我们模拟北京电信用户访问www.ljf.info为例

北京电信用户请求首选DNS服务器(北京电信DNS服务器)，要求解析www.ljf.info。
如果北京电信DNS服务器没有该域名的缓存，就从该域名的权威域名服务器。如果有这个域名解析记录的缓存，直接返回
ljf.info的权威域名服务器根据DNS视图技术，根据发起请求的源IP，把www.ljf.info解析到北京电信CDN节点上。
北京电信用户访问到北京电信CDN节点。
北京CDN节点如果有网民访问的内容，就直接返回，没有的话，回源站取，返回给网民并且自己本地保留一份。

通过上面五步，CDN系统的2个关键技术分别如下：

DNS调度技术

这个技术能够让来自不同区域、运营商的网民调度到距离网民最近的不同的CDN节点。
CDN节点缓存代理技术

所谓的缓存技术，就是该节点上如果有网民访问的未过期的网页资源，则它就直接返回给网民，减少网民访问的时间开销。
所谓的代理技术，如果该节点上没有对应的资源，或者资源过期，则他会请求源站内容后再返回给网民。

缓存和代理技术优化了已经缓存的传输效率，对于某些不能够缓存的资源，如动态的登陆请求，将其优化网民和源站的链路，减少延时和丢包率。

典型的架构

架构讲解

负载均衡组：

使用LVS的DR模式实现4层的网络负载均衡。使用DR模式的网络负载，主要优点在于实现高吞吐量以及屏蔽后端Nginx代理服务器中单台宕机对业务的影响。
Nginx/Haproxy代理服务器：

使用Nginx反向代理技术（upstream），配置url_hash的方式提高后端squid缓存服务器组的缓存命中率，同时也能够对squid做建康检测，剔除宕机的服务器。
squid缓存服务器：

根据HTTP协议中的有关缓存设置的规定，实现对页面和资源进行缓存的关键功能业务。通过改组服务器，可以实现缓存文件的快速响应和对源站的代理。

了解HTTP协议中的缓存控制指令和原理，是构建squid缓存的必要步骤。所以下面我们将下HTTP协议的缓存控制。

当然，有些CDN公司并不是这样的架构，而是这样的：

理解HTTP协议中的缓存控制

HTTP协议是采用客户端（request），服务器端响应(Response) 模型。在响应中，都能够通过相关控制指令对对端的缓存行为进行管理。首先要关心的是服务器端响应中的缓存控制头部，利用这些头部控制信息可以精细化地管理客户端缓存行为。

下面使用wget命令来看一个简单的列子。

[root@localhost ~]# wget -SO /dev/null "http://www.baidu.com"

--2016-11-06 21:03:44--  http://www.baidu.com/

Resolving www.baidu.com... 61.135.169.121, 61.135.169.125

Connecting to www.baidu.com|61.135.169.121|:80... connected.

HTTP request sent, awaiting response...

  HTTP/1.1 200 OK

  Server: bfe/1.0.8.18

  Date: Sun, 06 Nov 2016 13:03:44 GMT

  Content-Type: text/html

  Content-Length: 2381

  Last-Modified: Mon, 25 Jul 2016 11:11:20 GMT    ①

  Connection: Close

  ETag: "5795f3d8-94d"         ②

  Expires: Sat,09 Jan 2016 07:47:23 GMT   ③

  Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform     ④

  Pragma: no-cache

  Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/

  Accept-Ranges: bytes

Length: 2381 (2.3K) [text/html]

Saving to: “/dev/null”

100%[======================================================================================>] 2,381       --.-K/s   in 0.001s

2016-11-06 21:03:44 (4.40 MB/s) - “/dev/null” saved [2381/2381]

下面对①，②，③，④标注的内容进行详解：

Last-Modified: Mon, 25 Jul 2016 11:11:20 GMT

表示该文件的最后修改时间是Mon, 25 Jul 2016 11:11:20 GMT。客户端在后续需要请求该文件的时候，使用对应的请求头部If-Modified-Since：Mon, 25 Jul 2016 11:11:20 GMT 就可以验证服务器端的文件是否发生了变化，可以使用下面的命令去验证.

[root@localhost ~]# wget --header="If-Modified-Since: Mon, 25 Jul 2016 11:11:20 GMT"   -SO /dev/null "http://www.baidu.com/"

如果服务器端文件没有在此时间后没有发生变化，则服务器端不需要重新发送整个文件，而只需要发送"304 Not Modified" 通知客户端即可。节省传输文件的带宽和时间

ETag: "5795f3d8-94d"

相当于该静态资源的ID，在Web服务器器Nginx中，Etag值是基于文件的最后修改时间和文件大小（字节）计算出来的。浏览器在下一次请求该资源的过程中。使用If-None-Match：“5795f3d8-94d” 就可以确定这个资源是否发生了变化。服务器端再次验证，如果未变化，则直接返回给客户端 HTTP/1.1 304 Not Modified ，则不需要再次传输整个文件，祈祷缓存的作用。命令如下所示：

[root@localhost ~]# wget --header='If-None-Match: "5795f3df-94d"'   -SO /dev/null "http://www.baidu.com/"

--2016-11-06 21:25:00--  http://www.baidu.com/

Resolving www.baidu.com... 61.135.169.121, 61.135.169.125

Connecting to www.baidu.com|61.135.169.121|:80... connected.

HTTP request sent, awaiting response...

  HTTP/1.1 200 OK

  Server: bfe/1.0.8.18

  Date: Sun, 06 Nov 2016 13:25:00 GMT

  Content-Type: text/html

  Content-Length: 2381

  Last-Modified: Mon, 25 Jul 2016 11:11:30 GMT

  Connection: Close

  ETag: "5795f3e2-94d"

  Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform

  Pragma: no-cache

  Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/

  Accept-Ranges: bytes

Length: 2381 (2.3K) [text/html]

Saving to: “/dev/null”

100%[======================================================================================>] 2,381       --.-K/s   in 0.001s

2016-11-06 21:25:00 (3.34 MB/s) - “/dev/null” saved [2381/2381]

Expires: Sat,09 Jan 2016 07:47:23 GMT

服务器端告诉客户端，在Sat,09 Jan 2016 07:47:23 GMT之前需要获取该资源时，不必要在发起HTTP请求，直接使用这个缓存文件即可。
Cache-Control: private, no-cache, no-store, proxy-revalidate,

这样出现no-cache一般都是不缓存的，每次访问都需要从服务器上获取，还有一种是“Cache-Control: max-age=86400”，这个表示从收到这个网页资源的864000秒之内，都可以重复使用，不需要再访问网站。

如有问题请与本人联系，18500777133@sina.cn