CDN（Content Delivery network，內容分發網絡），通過GSLB技術使得用戶能訪問到最近物理機房的文件，以節省網絡時間，也就是說一份文件可能會在全國乃至全球的多個服務器存在，這就涉及到一個文件分發的問題，目前通常的CDN都是采取回源策略來同步文件，即每個cdn域名關聯了一些源服務器，發布文件只要發布到源服務器即可，cdn會根據策略從源服務器拉取文件，以保證用戶能盡早訪問到最新的文件內容。
那么cdn何時會去源服務器取內容呢？事實上，這個策略和瀏覽器緩存非常類似，我們知道，http 1.1通過cache-control的max-age頭可以告知文件在瀏覽器的緩存時間，在max-age指定的時間內，瀏覽器會直接使用本地緩存，而不會請求服務器，cdn采取了類似的機制，你只要把cdn節點看成瀏覽器，源服務器看成瀏覽器需要請求的服務器即可，此時，源服務器的max-age頭決定了資源在cdn節點本地緩存的時間，有一點差別的是，cdn規定了一個自定義協議，s-maxage，若源站該header存在，會優先使用該header作為緩存時間：
Cache-Control:max-age=0, s-maxage=86400
舉個栗子解釋下cdn緩存策略：
為了避免干擾，我們假設例子中說的cdn只有你一個人在訪問。
源站的max-age設定了緩存時間為3600秒，即一小時，cdn的max-age設定了緩存時間為315360000秒，即10年，那么用戶首次訪問該cdn的文件a.js?v=1時，cdn節點發現本機沒有該文件的緩存，會去源服務器取，接下來該文件會在cdn節點緩存3600秒，cdn節點帶上自己的max-age頭（315360000）返回到瀏覽器，接下來用戶之后10年內訪問同一個a.js?v=1不會再發請求（非刷新情況下，且用戶側緩存假設不清除）。
若用戶在一小時之內刷新a.js?v=1，意味着該請求會進到cdn服務器，此時服務器發現該url的緩存還沒過期（在3600秒內），不會去源站請求，直接返回服務器內容，根據請求header的last-modified（ctrl+f5不帶，f5和回車帶）決定是吐出304還是200。
若用戶在一小時之后刷新a.js?v=1，意味着該請求會進到cdn服務器，此時服務器發現該url的緩存已經超過了3600秒，於是會去源站請求一次，源站會根據請求header的last-modified（ctrl+f5不帶，f5和回車帶）決定是否吐出304還是200，並把源站的響應直接吐出到瀏覽器。
對於這個例子，用戶側最壞的情況是10年不請求新版的js，那么怎么解決這個問題，想必大家也知道了，就是加版本號（比如時間戳，可參考此文），因為無論是瀏覽器緩存還是cdn的緩存，其緩存的key都是get請求，而不只是文件名，因此若a.js變成a.js?v=2，無論是瀏覽器還是cdn，都會去上一級網絡拿取更新的資源。
對於不適合加版本號的頁面，比如html文檔，此時源站的max-age就要設短一點了，比如設置成1小時，那么再壞的情況下，cdn也會在1小時候回源拿取新的內容，如果想快點生效，需要使用cdn的緩存清理API或工具。
另外可以通過age頭查看該資源在當前cdn節點已緩存了多久：
Age: 1921
X-Cache: HIT TCP_MEM_HIT dirn:5:277366080
比如這個例子說明已緩存1921秒。
參考資料：http://baike.corp.taobao.com/index.php/CDN-Usermanul?spm=0.0.0.0.wxN22z