前言
本人以前在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