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
