1.HTTP緩存機(jī)制及原理

已存在緩存數(shù)據(jù)時(shí)，僅基于強(qiáng)制緩存璃谨，請(qǐng)求數(shù)據(jù)的流程如下

已存在緩存數(shù)據(jù)時(shí)系谐，僅基于對(duì)比緩存矮锈，請(qǐng)求數(shù)據(jù)的流程如下

對(duì)緩存機(jī)制不太了解的同學(xué)可能會(huì)問，基于對(duì)比緩存的流程下樟蠕，不管是否使用緩存貌亭，都需要向服務(wù)器發(fā)送請(qǐng)求柬唯，那么還用緩存干什么？

我們可以看到兩類緩存規(guī)則的不同圃庭，強(qiáng)制緩存如果生效锄奢，不需要再和服務(wù)器發(fā)生交互，而對(duì)比緩存不管是否生效剧腻，都需要與服務(wù)端發(fā)生交互拘央。

兩類緩存規(guī)則可以同時(shí)存在，強(qiáng)制緩存優(yōu)先級(jí)高于對(duì)比緩存书在，也就是說灰伟，當(dāng)執(zhí)行強(qiáng)制緩存的規(guī)則時(shí)，如果緩存生效儒旬，直接使用緩存栏账，不再執(zhí)行對(duì)比緩存規(guī)則。

強(qiáng)制緩存

從上文我們得知栈源，強(qiáng)制緩存挡爵，在緩存數(shù)據(jù)未失效的情況下，可以直接使用緩存數(shù)據(jù)甚垦，那么瀏覽器是如何判斷緩存數(shù)據(jù)是否失效呢茶鹃？

我們知道，在沒有緩存數(shù)據(jù)的時(shí)候艰亮，瀏覽器向服務(wù)器請(qǐng)求數(shù)據(jù)時(shí)闭翩，服務(wù)器會(huì)將數(shù)據(jù)和緩存規(guī)則一并返回，緩存規(guī)則信息包含在響應(yīng)header中垃杖。

對(duì)于強(qiáng)制緩存來說男杈，響應(yīng)header中會(huì)有兩個(gè)字段來標(biāo)明失效規(guī)則（Expires/Cache-Control）

使用chrome的開發(fā)者工具丈屹，可以很明顯的看到對(duì)于強(qiáng)制緩存生效時(shí)调俘，網(wǎng)絡(luò)請(qǐng)求的情況

Expires

Expires的值為服務(wù)端返回的到期時(shí)間，即下一次請(qǐng)求時(shí)旺垒，請(qǐng)求時(shí)間小于服務(wù)端返回的到期時(shí)間彩库，直接使用緩存數(shù)據(jù)。不過Expires 是HTTP 1.0的東西先蒋，現(xiàn)在默認(rèn)瀏覽器均默認(rèn)使用HTTP 1.1骇钦，所以它的作用基本忽略。另一個(gè)問題是竞漾，到期時(shí)間是由服務(wù)端生成的眯搭，但是客戶端時(shí)間可能跟服務(wù)端時(shí)間有誤差窥翩，這就會(huì)導(dǎo)致緩存命中的誤差。所以HTTP 1.1 的版本鳞仙，使用Cache-Control替代寇蚊。

Cache-Control

Cache-Control 是最重要的規(guī)則。常見的取值有private棍好、public仗岸、no-cache、max-age借笙，no-store扒怖，默認(rèn)為private。

private:?客戶端可以緩存,public:?客戶端和代理服務(wù)器都可緩存（前端的同學(xué)业稼，可以認(rèn)為public和private是一樣的）

max-age=xxx:?緩存的內(nèi)容將在 xxx 秒后失效

no-cache:?需要使用對(duì)比緩存來驗(yàn)證緩存數(shù)據(jù)（后面介紹）

no-store:?所有內(nèi)容都不會(huì)緩存盗痒，強(qiáng)制緩存，對(duì)比緩存都不會(huì)觸發(fā).

Last-Modified??/??If-Modified-Since

Last-Modified：

服務(wù)器在響應(yīng)請(qǐng)求時(shí)低散，告訴瀏覽器資源的最后修改時(shí)間积糯。

If-Modified-Since：

再次請(qǐng)求服務(wù)器時(shí)，通過此字段通知服務(wù)器上次請(qǐng)求時(shí)谦纱，服務(wù)器返回的資源最后修改時(shí)間看成。

服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-Modified-Since 則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行比對(duì)。

若資源的最后修改時(shí)間大于If-Modified-Since跨嘉，說明資源又被改動(dòng)過川慌，則響應(yīng)整片資源內(nèi)容，返回狀態(tài)碼200祠乃；

若資源的最后修改時(shí)間小于或等于If-Modified-Since梦重，說明資源無新修改，則響應(yīng)HTTP 304亮瓷，告知瀏覽器繼續(xù)使用所保存的cache琴拧。

Etag??/??If-None-Match（優(yōu)先級(jí)高于Last-Modified??/??If-Modified-Since）

Etag：

服務(wù)器響應(yīng)請(qǐng)求時(shí)，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定）嘱支。

If-None-Match：

再次請(qǐng)求服務(wù)器時(shí)蚓胸，通過此字段通知服務(wù)器客戶段緩存數(shù)據(jù)的唯一標(biāo)識(shí)。

服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-None-Match 則與被請(qǐng)求資源的唯一標(biāo)識(shí)進(jìn)行比對(duì)除师，

不同沛膳，說明資源又被改動(dòng)過，則響應(yīng)整片資源內(nèi)容汛聚，返回狀態(tài)碼200锹安；

相同，說明資源無新修改，則響應(yīng)HTTP 304叹哭，告知瀏覽器繼續(xù)使用所保存的cache忍宋。

總結(jié)

對(duì)于強(qiáng)制緩存，服務(wù)器通知瀏覽器一個(gè)緩存時(shí)間风罩，在緩存時(shí)間內(nèi)讶踪，下次請(qǐng)求，直接用緩存泊交，不在時(shí)間內(nèi)乳讥，執(zhí)行比較緩存策略。

對(duì)于比較緩存廓俭，將緩存信息中的Etag和Last-Modified通過請(qǐng)求發(fā)送給服務(wù)器云石，由服務(wù)器校驗(yàn)，返回304狀態(tài)碼時(shí)研乒，瀏覽器直接使用緩存汹忠。

瀏覽器第一次請(qǐng)求：

瀏覽器再次請(qǐng)求時(shí)：

1.瀏覽器在請(qǐng)求某一資源時(shí)，會(huì)先獲取該資源緩存的header信息雹熬，判斷是否命中強(qiáng)緩存（cache-control和expires信息）宽菜，若命中直接從緩存中獲取資源信息，包括緩存header信息竿报；本次請(qǐng)求根本就不會(huì)與服務(wù)器進(jìn)行通信铅乡；在firebug下可以查看某個(gè)具有強(qiáng)緩存資源返回的信息，例如本地firebug查看的一個(gè)強(qiáng)緩存js文件

2.如果沒有命中強(qiáng)緩存烈菌，瀏覽器會(huì)發(fā)送請(qǐng)求到服務(wù)器阵幸，請(qǐng)求會(huì)攜帶第一次請(qǐng)求返回的有關(guān)緩存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服務(wù)器根據(jù)請(qǐng)求中的相關(guān)header信息來比對(duì)結(jié)果是否協(xié)商緩存命中芽世；若命中挚赊，則服務(wù)器返回新的響應(yīng)header信息更新緩存中的對(duì)應(yīng)header信息，但是并不返回資源內(nèi)容济瓢，它會(huì)告知瀏覽器可以直接從緩存獲溶睢；否則返回最新的資源內(nèi)容

強(qiáng)緩存與協(xié)商緩存的區(qū)別旺矾，可以用下表來進(jìn)行描述：

獲取資源形式狀態(tài)碼發(fā)送請(qǐng)求到服務(wù)器

強(qiáng)緩存?從緩存取?200（from cache）否蔑鹦，直接從緩存取

協(xié)商緩存?從緩存取?304（not modified）是，正如其名宠漩，通過服務(wù)器來告知緩存是否可用

強(qiáng)緩存相關(guān)的header字段

強(qiáng)緩存上面已經(jīng)介紹了举反，直接從緩存中獲取資源而不經(jīng)過服務(wù)器；與強(qiáng)緩存相關(guān)的header字段有兩個(gè)：

expires扒吁，這是http1.0時(shí)的規(guī)范；它的值為一個(gè)絕對(duì)時(shí)間的GMT格式的時(shí)間字符串，如Mon, 10 Jun 2015 21:31:12 GMT雕崩，如果發(fā)送請(qǐng)求的時(shí)間在expires之前魁索，那么本地緩存始終有效，否則就會(huì)發(fā)送請(qǐng)求到服務(wù)器來獲取資源

cache-control：max-age=number盼铁，這是http1.1時(shí)出現(xiàn)的header信息粗蔚，主要是利用該字段的max-age值來進(jìn)行判斷，它是一個(gè)相對(duì)值饶火；資源第一次的請(qǐng)求時(shí)間和Cache-Control設(shè)定的有效期鹏控，計(jì)算出一個(gè)資源過期時(shí)間，再拿這個(gè)過期時(shí)間跟當(dāng)前的請(qǐng)求時(shí)間比較肤寝，如果請(qǐng)求時(shí)間在過期時(shí)間之前当辐，就能命中緩存，否則就不行鲤看；cache-control除了該字段外缘揪，還有下面幾個(gè)比較常用的設(shè)置值：

no-cache：不使用本地緩存。需要使用緩存協(xié)商义桂，先與服務(wù)器確認(rèn)返回的響應(yīng)是否被更改找筝，如果之前的響應(yīng)中存在ETag，那么請(qǐng)求的時(shí)候會(huì)與服務(wù)端驗(yàn)證慷吊，如果資源未被更改袖裕，則可以避免重新下載。

no-store：直接禁止游覽器緩存數(shù)據(jù)溉瓶，每次用戶請(qǐng)求該資源陆赋，都會(huì)向服務(wù)器發(fā)送一個(gè)請(qǐng)求，每次都會(huì)下載完整的資源嚷闭。

public：可以被所有的用戶緩存攒岛，包括終端用戶和CDN等中間代理服務(wù)器。

private：只能被終端用戶的瀏覽器緩存胞锰，不允許CDN等中繼緩存服務(wù)器對(duì)其緩存灾锯。

注意：如果cache-control與expires同時(shí)存在的話，cache-control的優(yōu)先級(jí)高于expires

3嗅榕、協(xié)商緩存相關(guān)的header字段

協(xié)商緩存都是由服務(wù)器來確定緩存資源是否可用的顺饮，所以客戶端與服務(wù)器端要通過某種標(biāo)識(shí)來進(jìn)行通信，從而讓服務(wù)器判斷請(qǐng)求資源是否可以緩存訪問凌那，這主要涉及到下面兩組header字段兼雄，這兩組搭檔都是成對(duì)出現(xiàn)的，即第一次請(qǐng)求的響應(yīng)頭帶上某個(gè)字段（Last-Modified或者Etag）帽蝶，則后續(xù)請(qǐng)求則會(huì)帶上對(duì)應(yīng)的請(qǐng)求字段（If-Modified-Since或者If-None-Match）赦肋，若響應(yīng)頭沒有Last-Modified或者Etag字段，則請(qǐng)求頭也不會(huì)有對(duì)應(yīng)的字段。

Last-Modified/If-Modified-Since

二者的值都是GMT格式的時(shí)間字符串佃乘，具體過程：

瀏覽器第一次跟服務(wù)器請(qǐng)求一個(gè)資源囱井，服務(wù)器在返回這個(gè)資源的同時(shí)，在respone的header加上Last-Modified的header趣避，這個(gè)header表示這個(gè)資源在服務(wù)器上的最后修改時(shí)間

瀏覽器再次跟服務(wù)器請(qǐng)求這個(gè)資源時(shí)庞呕，在request的header上加上If-Modified-Since的header，這個(gè)header的值就是上一次請(qǐng)求時(shí)返回的Last-Modified的值

服務(wù)器再次收到資源請(qǐng)求時(shí)程帕，根據(jù)瀏覽器傳過來If-Modified-Since和資源在服務(wù)器上的最后修改時(shí)間判斷資源是否有變化住练，如果沒有變化則返回304 Not Modified，但是不會(huì)返回資源內(nèi)容愁拭；如果有變化讲逛，就正常返回資源內(nèi)容。當(dāng)服務(wù)器返回304 Not Modified的響應(yīng)時(shí)敛苇，response header中不會(huì)再添加Last-Modified的header妆绞，因?yàn)榧热毁Y源沒有變化，那么Last-Modified也就不會(huì)改變枫攀，這是服務(wù)器返回304時(shí)的response header

瀏覽器收到304的響應(yīng)后括饶，就會(huì)從緩存中加載資源

如果協(xié)商緩存沒有命中，瀏覽器直接從服務(wù)器加載資源時(shí)来涨，Last-Modified的Header在重新加載的時(shí)候會(huì)被更新图焰，下次請(qǐng)求時(shí)，If-Modified-Since會(huì)啟用上次返回的Last-Modified值

Etag/If-None-Match

這兩個(gè)值是由服務(wù)器生成的每個(gè)資源的唯一標(biāo)識(shí)字符串蹦掐，只要資源有變化就這個(gè)值就會(huì)改變技羔；其判斷過程與Last-Modified/If-Modified-Since類似，與Last-Modified不一樣的是卧抗，當(dāng)服務(wù)器返回304 Not Modified的響應(yīng)時(shí)藤滥，由于ETag重新生成過，response header中還會(huì)把這個(gè)ETag返回社裆，即使這個(gè)ETag跟之前的沒有變化拙绊。

配置回源SNI

如果您的源站IP綁定了多個(gè)域名，當(dāng)全站加速節(jié)點(diǎn)以HT T PS協(xié)議訪問您的源站時(shí)泳秀，您可以設(shè)置回源SNI标沪，指

明具體訪問的域名。

背景信息

服務(wù)器名稱指示SNI(Server Name Indication)是一個(gè)擴(kuò)展的傳輸層安全性協(xié)議TLS(Transport Layer

Security)嗜傅。在該協(xié)議下金句，握手過程開始時(shí)，客戶端會(huì)返回正在連接的那臺(tái)服務(wù)器即將要連接的主機(jī)名稱吕嘀，

以允許該服務(wù)器在相同的IP地址和TCP端口號(hào)上呈現(xiàn)多個(gè)證書违寞，即一臺(tái)服務(wù)器可以為多個(gè)域名提供服務(wù)贞瞒。因

此，同一個(gè)IP地址上提供的多個(gè)安全的HT T PS網(wǎng)站(或其他任何基于T LS的服務(wù))坞靶，不需要使用相同的證

書憔狞。如果您的源站服務(wù)器使用單個(gè)IP提供多個(gè)域名的HT T PS服務(wù)蝴悉，且您已經(jīng)為您的全站加速設(shè)置了443端口回源

(CDN節(jié)點(diǎn)以HT T PS協(xié)議訪問您的服務(wù)器)彰阴，您就需要設(shè)置回源SNI，指明所請(qǐng)求的具體域名拍冠。這樣全站加

速節(jié)點(diǎn)以HT T PS協(xié)議回源訪問您的服務(wù)器時(shí)尿这，服務(wù)器才會(huì)正確地返回對(duì)應(yīng)的證書。

回源SNI的工作原理如下圖所示庆杜。

1. 全站加速節(jié)點(diǎn)以HTTPS協(xié)議訪問源站時(shí)射众，在SNI中指定訪問的域名。

2. 源站接收到請(qǐng)求后晃财，根據(jù)SNI中記錄的域名叨橱，返回對(duì)應(yīng)域名的證書。

3. 全站加速節(jié)點(diǎn)收到證書断盛，與服務(wù)器端建立安全連接罗洗。

配置Range回源

Range回源是指客戶端通知源站服務(wù)器只返回指定范圍內(nèi)的部分內(nèi)容，有利于較大文件的分發(fā)加速钢猛。開啟

Range回源功能伙菜，可以減少回源流量消耗，并且提升資源響應(yīng)時(shí)間命迈。通過本文您可以了解開啟Range回源的

背景信息：配置Range回源時(shí)贩绕，需要源站支持Range請(qǐng)求，即HTTP請(qǐng)求頭中包含Range字段壶愤，源站能夠響應(yīng)正確的

206文件分片淑倾。

HTTP/2也被稱為HTTP 2.0，相對(duì)于HTTP 1.1的新增多路復(fù)用征椒、壓縮HTTP頭娇哆、劃分請(qǐng)求優(yōu)先級(jí)、服務(wù)端推

送等特性陕靠，解決了在HTTP 1.1中一直存在的問題迂尝，優(yōu)化了請(qǐng)求性能，同時(shí)兼容了HTTP 1.1的語(yǔ)義剪芥。目

前垄开，Chrome、 IE11税肪、Safari和Firefox等瀏覽器已經(jīng)支持HTTP/2協(xié)議溉躲。

HTTP/2的優(yōu)勢(shì):

二進(jìn)制協(xié)議:相比于HTTP 1.x基于文本的解析榜田，HTTP/2將所有的傳輸信息分割為更小的消息和幀，并對(duì)

它們采用二進(jìn)制格式編碼锻梳〖基于二進(jìn)制可以使協(xié)議有更多的擴(kuò)展性，例如疑枯，引入幀來傳輸數(shù)據(jù)和指令辩块。

內(nèi)容安全:HT T P/2基于HT T PS，具有安全特性荆永。使用HT T P/2特性可以避免單純使用HT T PS引起的性能

下降問題废亭。

多路復(fù)用(MultiPlexing):通過該功能，在一條連接上具钥，您的瀏覽器可以同時(shí)發(fā)起無數(shù)個(gè)請(qǐng)求豆村，并且響

應(yīng)可以同時(shí)返回。另外骂删，多路復(fù)用中支持了流的優(yōu)先級(jí)(Stream dependencies)設(shè)置掌动，允許客戶端告

知服務(wù)器最優(yōu)資源，可以優(yōu)先傳輸宁玫。

Header壓縮(Header compression):HTTP請(qǐng)求頭帶有大量信息粗恢，而且每次都要重復(fù)發(fā)送。HTTP/2

采用HPACK格式進(jìn)行壓縮傳輸撬统，通訊雙方各自緩存一份頭域索引表适滓，相同的消息頭只發(fā)送索引號(hào)，從而提

高效率和速度恋追。

HSTS

通過開啟HSTS(HTTP Strict Transport Security)功能凭迹，您可以強(qiáng)制客戶端(如瀏覽器)使用HTTPS與服

務(wù)器創(chuàng)建連接，降低第一次訪問被劫持的風(fēng)險(xiǎn)苦囱。

前提條件

執(zhí)行該操作前嗅绸，請(qǐng)您確保已成功配置HT T PS證書，操作方法請(qǐng)參見配置HT T PS證書撕彤。背景信息

當(dāng)您的網(wǎng)站全站使用HT T PS后鱼鸠，需要將所有HT T P請(qǐng)求的301和302重定向到HT T PS。如果您在瀏覽器輸入或

直接單擊HT T P鏈接羹铅，則服務(wù)器會(huì)將該HT T P請(qǐng)求的301和302重定向到HT T PS蚀狰。該操作過程可能被劫持，導(dǎo)

致重定向后的請(qǐng)求未發(fā)送到服務(wù)器职员，該問題可以通過HST S來解決麻蹋。

配置Referer防盜鏈

您可以通過配置訪問的Referer黑名單和白名單來實(shí)現(xiàn)對(duì)訪客身份的識(shí)別和過濾，從而限制訪問全站加速資

源的用戶焊切，提升全站加速的安全性扮授。通過本文您可以了解Referer防盜鏈的配置方法芳室。

背景信息

防盜鏈功能基于HTTP協(xié)議支持的Referer機(jī)制，通過Referer跟蹤來源刹勃，對(duì)來源進(jìn)行識(shí)別和判斷堪侯。

目前防盜鏈功能支持黑名單或白名單機(jī)制，您對(duì)資源發(fā)起請(qǐng)求后荔仁，請(qǐng)求到達(dá)全站加速節(jié)點(diǎn)伍宦，全站加速節(jié)點(diǎn)

會(huì)根據(jù)您預(yù)設(shè)的防盜鏈黑名單或白名單，對(duì)訪客的身份進(jìn)行過濾咕晋。符合規(guī)則的用戶可以順利請(qǐng)求到資源雹拄，

不符合規(guī)則的用戶收奔，請(qǐng)求會(huì)返回403響應(yīng)碼掌呜。

什么是盜鏈

客戶端向服務(wù)器請(qǐng)求資源時(shí)，為了減少網(wǎng)絡(luò)帶寬坪哄，提升響應(yīng)時(shí)間质蕉，服務(wù)器一般不會(huì)一次將所有? 資源完整地傳回給客戶端。比如在請(qǐng)求一個(gè)網(wǎng)頁(yè)時(shí)翩肌，首先會(huì)傳回該網(wǎng)頁(yè)的文本內(nèi)容模暗，當(dāng)客戶端? 瀏覽器在解析文本的過程中發(fā)現(xiàn)有圖片存在時(shí)，會(huì)再次向服務(wù)器發(fā)起對(duì)該圖片資源的請(qǐng)求念祭，服務(wù)器將存儲(chǔ)的圖片資源再發(fā)送給客戶端兑宇。在這個(gè)過程中，如果該服務(wù)器上只包含了網(wǎng)頁(yè)的文本 內(nèi)容粱坤，并沒有存儲(chǔ)相關(guān)的圖片資源隶糕，而是將圖片資源鏈接到其他站點(diǎn)的服務(wù)器上，就形成了盜? 鏈行為

referer

HTTP Referer是header的一部分站玄，當(dāng)瀏覽器向web服務(wù)器發(fā)送請(qǐng)求的時(shí)候枚驻，一般會(huì)帶上Referer，告訴服務(wù)器我是從哪個(gè)頁(yè)面鏈接過來的株旷，服務(wù)器藉此可以獲得一些信息用于處理再登。通過該頭域的值，我們可以檢測(cè)到訪問目標(biāo)資源的源地址

對(duì)象存儲(chǔ)中防盜鏈

對(duì)于私有的bucket晾剖，因?yàn)樵L問控制的原因锉矢，基本不存在大規(guī)模盜鏈的可能性，對(duì)于公開空間齿尽，因?yàn)闆]有訪問權(quán)限控制沽损，需要進(jìn)行防盜鏈設(shè)置

友商防盜鏈做法

七牛

七牛對(duì)于公開空間的防盜鏈做法主要是通過設(shè)置白名單、黑名單和空referer是否可以訪問來實(shí)現(xiàn)的

設(shè)置選項(xiàng)(白名單和黑名單不會(huì)同時(shí)生效)有：白名單雕什、黑名單缠俺、關(guān)閉三個(gè)選項(xiàng)

七牛防盜鏈.png

七牛采用三個(gè)參數(shù)來實(shí)現(xiàn)防盜鏈：

<RefererType>: 防盜鏈類型：黑名單(black)|白名單(white)

<RefererValue>: 防盜鏈黑白名單列表：以逗號(hào)(,)分割

<NullReferer>:是否允許空referer

AWS

AWS也是通過bucket的訪問控制來實(shí)現(xiàn)防盜鏈的

AWS通過bucket Policy中的condition來先設(shè)置不同請(qǐng)求的權(quán)限

上面的例子就是說显晶，允許匹配的域名和ip擁有bucket：mybucket? GetObject的權(quán)限

作者：zhllsr

鏈接：http://www.reibang.com/p/c02064db8b5b

來源：簡(jiǎn)書

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)壹士，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處磷雇。

配置URL鑒權(quán)

URL鑒權(quán)功能主要用于保護(hù)用戶站點(diǎn)的內(nèi)容資源不被非法站點(diǎn)下載盜用。通過防盜鏈方法添加Referer黑名

單和白名單的方式可以解決一部分盜鏈問題躏救，由于Referer內(nèi)容可以偽造唯笙，所以Referer防盜鏈方式無法徹底

保護(hù)站點(diǎn)資源。因此盒使，您可以采用URL鑒權(quán)方式保護(hù)源站資源更為安全有效崩掘。

背景信息

URL鑒權(quán)功能通過阿里云全站加速節(jié)點(diǎn)與客戶資源站點(diǎn)配合，形成了更為安全可靠的源站資源防盜方法少办。

全站加速客戶站點(diǎn)提供加密URL苞慢，URL中包含權(quán)限驗(yàn)證信息。

用戶使用加密后的URL向加速節(jié)點(diǎn)發(fā)起請(qǐng)求英妓。

加速節(jié)點(diǎn)對(duì)加密URL中的權(quán)限信息進(jìn)行驗(yàn)證挽放，判斷請(qǐng)求的合法性。正常響應(yīng)合法請(qǐng)求蔓纠，拒絕非法請(qǐng)求辑畦。

配置IP黑白名單

您可以通過配置IP黑名單和白名單來實(shí)現(xiàn)對(duì)訪客身份的識(shí)別和過濾，從而限制訪問全站加速資源的用戶腿倚，提

升全站加速的安全性纯出。通過本文您可以了解IP黑名單和白名單的配置方法。

背景信息

配置IP黑名單和白名單功能說明如下:

IP黑名單:黑名單內(nèi)的IP均無法訪問當(dāng)前資源敷燎。

如果您的IP被加入黑名單暂筝，該IP的請(qǐng)求仍可訪問到全站加速節(jié)點(diǎn)，但是會(huì)被全站加速節(jié)點(diǎn)拒絕并返回

403懈叹，全站加速日志中仍會(huì)記錄這些黑名單中的IP請(qǐng)求記錄乖杠。

IP白名單:只有白名單內(nèi)的IP能訪問當(dāng)前資源，白名單以外的IP均無法訪問當(dāng)前資源澄成。

配置User-Agent黑白名單

您可以通過配置User-Agent黑名單和白名單來實(shí)現(xiàn)對(duì)訪客身份的識(shí)別和過濾胧洒，從而限制訪問全站加速資源

的用戶，提升全站加速的安全性墨状。通過本文您可以了解User-Agent黑/白名單的配置方法卫漫。

當(dāng)您需要根據(jù)請(qǐng)求的User-Agent字段進(jìn)行訪問控制時(shí)，請(qǐng)配置User-Agent黑/白名單功能

User-Agent黑名單:黑名單內(nèi)的User-Agent字段均無法訪問當(dāng)前資源肾砂。

如果您的User-Agent字段被加入黑名單列赎，該帶有User-Agent字段的請(qǐng)求仍可訪問到全站加速節(jié)點(diǎn)，但是

會(huì)被全站加速節(jié)點(diǎn)拒絕并返回403镐确，全站加速日志中仍會(huì)記錄這些黑名單中的User-Agent字段記錄包吝。

User-Agent白名單:只有白名單內(nèi)的User-Agent字段才能訪問當(dāng)前資源饼煞，白名單以外的User-Agent字

段均無法訪問當(dāng)前資源。

性能優(yōu)化

1.頁(yè)面優(yōu)化

當(dāng)您開啟頁(yè)面優(yōu)化功能時(shí)诗越，全站加速自動(dòng)清除HT ML頁(yè)面冗余的注釋和重復(fù)的空白符砖瞧，縮小文件體積，提升

頁(yè)面可閱讀性嚷狞。本文為您詳細(xì)介紹開啟頁(yè)面優(yōu)化功能的方法块促。

開啟頁(yè)面優(yōu)化功能后，全站加速自動(dòng)刪除當(dāng)前域名下所有HT ML頁(yè)面中冗余的注釋和重復(fù)的空白符床未，這樣可

以有效地去除頁(yè)面的冗余信息竭翠，減小文件體積，提高加速分發(fā)效率薇搁。

如果源站文件配置了MD5校驗(yàn)機(jī)制斋扰，則請(qǐng)勿開啟該功能。當(dāng)全站加速進(jìn)行頁(yè)面優(yōu)化時(shí)只酥，該文件的MD5值會(huì)被

更改褥实，導(dǎo)致優(yōu)化后文件的MD5值和源站文件的MD5值不一致。

2.智能優(yōu)化

當(dāng)您開啟智能壓縮功能時(shí)裂允，全站加速自動(dòng)對(duì)靜態(tài)文件進(jìn)行Gzip壓縮。通過智能Gzip壓縮方式哥艇，可以有效減小傳輸文件大小绝编，提升加速效率。本文為您詳細(xì)介紹開啟智能壓縮功能的方法貌踏。

目前智能壓縮支持的內(nèi)容格式: text/html 十饥、 text/xml 、 text/plain 祖乳、 text/css 逗堵、 application/jav

ascript 、 application/x-javascript 眷昆、 application/rss+xml 蜒秤、 text/javascript 、 image/tiff 亚斋、 ima

ge/svg+xml 作媚、 application/json 、 application/xmltext 帅刊。

客戶端請(qǐng)求攜帶請(qǐng)求頭 Accept-Encoding: gzip :客戶端希望獲取對(duì)應(yīng)資源的gzip壓縮響應(yīng)纸泡。

服務(wù)端響應(yīng)攜帶響應(yīng)頭 Content-Encoding: gzip :服務(wù)端響應(yīng)的內(nèi)容為gzip壓縮的資源 。

3.過濾參數(shù)

如果您的URL請(qǐng)求中攜帶大量參數(shù)赖瞒，需要忽略參數(shù)瀏覽文件時(shí)女揭，則可以開啟過濾參數(shù)蚤假，過濾攜帶參數(shù)的URL

返回源站，提高緩存命中率吧兔。本文為您詳細(xì)介紹配置過濾參數(shù)的方法勤哗。

背景信息

開啟過濾參數(shù)。

開啟過濾參數(shù)后掩驱，請(qǐng)求URL到全站加速節(jié)點(diǎn)后芒划，會(huì)截取到?jīng)]有該參數(shù)請(qǐng)求的URL，且全站加速節(jié)點(diǎn)僅保留

一份副本欧穴。如果您的URL請(qǐng)求中攜帶大量問號(hào)( ? )參數(shù)民逼，例如: http://alibaba.com/content?a ，但是這些參

數(shù)內(nèi)容優(yōu)先級(jí)不高涮帘，可以忽略參數(shù)瀏覽文件時(shí)拼苍，建議您開啟過濾參數(shù)。開啟過濾參數(shù)的作用是忽略URL

請(qǐng)求中 ? 之后的參數(shù)调缨，提高全站加速緩存的命中率疮鲫。

例如:第一次訪問 http://www.****.com/1.jpg ，全站加速?zèng)]有緩存弦叶，直接回源訪問數(shù)據(jù);第二次訪問http://www.****.com/1.jpg?test1 俊犯，由于開啟了過濾參數(shù)，所以 ? 后的參數(shù)無需匹配伤哺，即可命中CDN

緩存 http://www.****.com/1.jpg 燕侠。

4.拖拽播放

當(dāng)您播放視音頻時(shí)，需要隨意拖拽播放進(jìn)度立莉，而不影響視音頻的播放效果绢彤，可以開啟拖拽播放。通過本文您

可以了解配置拖拽播放功能的操作方法蜓耻。

背景信息

拖拽播放功能是指在視音頻點(diǎn)播場(chǎng)景中茫舶，如果您拖拽播放進(jìn)度，則客戶端會(huì)向服務(wù)器端發(fā)送URL請(qǐng)求刹淌，例

如: http://www.aliyun.com/test.flv?start=10 饶氏，服務(wù)端會(huì)向客戶端響應(yīng)從第10字節(jié)的前一個(gè)關(guān)鍵幀(如

果start=10不是關(guān)鍵幀所在位置)的數(shù)據(jù)內(nèi)容。

配置拖拽播放功能之前芦鳍，需要確認(rèn)源站支持Range請(qǐng)求嚷往。如果HTTP請(qǐng)求頭中包含Range字段，則源站需

要響應(yīng)正確的206文件分片柠衅。

拖拽播放功能支持的文件和URL格式如下表所示皮仁。

4.?Websocket

通過本文您可以了解Websocket的概念、優(yōu)勢(shì)和使用場(chǎng)景。

什么是Websocket

Websocket協(xié)議是基于TCP的一種新的網(wǎng)絡(luò)協(xié)議贷祈。它實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工(full-duplex)通信趋急，

即允許服務(wù)器主動(dòng)發(fā)送信息給客戶端。因此势誊，在Websocket中呜达，瀏覽器和服務(wù)器只需要完成一次握手，兩

者之間就直接可以創(chuàng)建持久性的連接粟耻，并進(jìn)行雙向數(shù)據(jù)傳輸查近，客戶端和服務(wù)器之間的數(shù)據(jù)交換。

Websocket的優(yōu)勢(shì)

現(xiàn)在挤忙，很多網(wǎng)站為了實(shí)現(xiàn)推送技術(shù)霜威，所用的技術(shù)都是Ajax輪詢。輪詢是在特定的時(shí)間間隔(如每1秒)册烈，由

瀏覽器對(duì)服務(wù)器發(fā)出HT T P請(qǐng)求戈泼，然后由服務(wù)器返回最新的數(shù)據(jù)給客戶端的瀏覽器。

這種傳統(tǒng)的模式帶來很明顯的缺點(diǎn)赏僧，即瀏覽器需要不斷的向服務(wù)器發(fā)出請(qǐng)求大猛。然而HT T P請(qǐng)求可能包含較長(zhǎng)

的頭部，其中真正有效的數(shù)據(jù)可能只是很小的一部分淀零，顯然這樣會(huì)浪費(fèi)很多的帶寬等資源挽绩。HT ML5定義的

Websocket協(xié)議優(yōu)勢(shì)如下:

小Header:互相溝通的Header非常小，只有2Bytes左右窑滞。

服務(wù)器不再被動(dòng)接收到瀏覽器的請(qǐng)求之后才返回?cái)?shù)據(jù)拍屑，而是在有新數(shù)據(jù)時(shí)就主動(dòng)推送給瀏覽器局义。

Websocket協(xié)議能更好的節(jié)省服務(wù)器資源和帶寬，并且能夠更實(shí)時(shí)地進(jìn)行通訊丐箩。

常見服務(wù)器鑒權(quán)技術(shù)

1）判斷引用地址撬槽，通過HTTP頭的Referer字段來獲取瀏覽器的頁(yè)面地址此改，方法通常用于防止圖片，MP3侄柔，嵌入其它網(wǎng)站共啃。

2）使用合法性驗(yàn)證信息，存儲(chǔ)在HTTP請(qǐng)求的cookie字段暂题，用于進(jìn)行快速查詢移剪。

3）使用cookie攜帶動(dòng)態(tài)驗(yàn)證信息，對(duì)使用cookie是否有正確的值進(jìn)行判斷薪者。

4）使用POST下載纵苛，若是POST請(qǐng)求，則讀取目標(biāo)資源并寫入響應(yīng)對(duì)象

5）使用圖像驗(yàn)證碼

6）使用動(dòng)態(tài)密鑰，一定時(shí)間內(nèi)有效的密鑰值

7）在內(nèi)容中插入隨機(jī)數(shù)據(jù)攻人，整個(gè)文件的散列值會(huì)發(fā)生變化取试。

8）打包下載

CDN訪問異常篇之502/503/504錯(cuò)誤

一. 源站不通或源站域名無法解析

CDN 都是公網(wǎng)上的節(jié)點(diǎn)，CDN配置的源站必須要公網(wǎng)可達(dá)怀吻。如果配置的源站IP公網(wǎng)不可達(dá)瞬浓、端口不通或者源站域名沒有解析，則會(huì)導(dǎo)致CDN回源請(qǐng)求源站失敗蓬坡，報(bào)錯(cuò)5xx猿棉。

常見的幾種異常情況如下：

(1)源站網(wǎng)絡(luò)不通，測(cè)試無法ping通源站IP屑咳。ping測(cè)試命令：ping 源站IP

(2)源站端口不通或源站直接響應(yīng)5xx錯(cuò)誤萨赁。例如以下案例，telnet端口報(bào)錯(cuò)Connection timed out

i)如果源站端口配置的是80乔宿，則測(cè)試80端口是否通：telnet 源站IP 80

ii)如果源站端口配置的是443位迂，則測(cè)試443端口是否通。如果源站端口配置的是自定義端口详瑞，則測(cè)試自定義端口是否通掂林。

iii)可以在CDN控制臺(tái)獲取配置的源站地址和端口，然后本地host綁定到源站坝橡，固定源站做七層測(cè)試泻帮，查看是否是源站直接無響應(yīng)或源站直接響應(yīng)5xx，具體可以參考

二.CDN配置了HTTPS回源计寇，但源站不支持HTTPS

（1）源站端口配置成443锣杂，但源站不支持HTTPS

在CDN控制臺(tái)的源站配置界面，如果源站端口配置成443番宁，則CDN回源的時(shí)候是HTTPS回源到源站的443端口元莫。源站需要開放443端口，且配置HTTPS證書蝶押。如果源站不支持HTTPS訪問踱蠢，則CDN回源失敗，報(bào)錯(cuò)5xx棋电。對(duì)于這種情況茎截，可以把回源端口改成80；如果業(yè)務(wù)需要443回源的話赶盔，那么需要在源站配置HTTPS證書企锌。

（2）CDN配置了協(xié)議跟隨回源，但是源站不支持HTTPS訪問于未。

協(xié)議跟隨回源如果設(shè)置成“HTTPS”撕攒，則CDN是以HTTPS回源陡鹃；協(xié)議跟隨回源如果設(shè)置成“跟隨”，則當(dāng)客戶端是HTTPS訪問的時(shí)候打却，CDN是HTTPS回源杉适。源站不支持HTTPS的情況下，會(huì)出現(xiàn)訪問失敗柳击。對(duì)于這種情況猿推，需要關(guān)閉協(xié)議跟隨回源功能，或設(shè)置為HTTP回源捌肴。

三.源站開啟了SNI校驗(yàn)蹬叭，但是CDN沒有開啟“回源SNI”

CDN回源默認(rèn)是不帶SNI信息的，如果您的源站IP綁定了多個(gè)域名状知，當(dāng)CDN節(jié)點(diǎn)以HTTPS協(xié)議訪問您的源站時(shí)秽五，由于沒有帶SNI信息，會(huì)導(dǎo)致源站無法正確響應(yīng)HTTPS證書饥悴，導(dǎo)致回源失敗坦喘。因?yàn)檫@個(gè)問題導(dǎo)致的錯(cuò)誤，一般是503 Service Temporarily Unavailable錯(cuò)誤西设，而且很快就會(huì)返回這個(gè)錯(cuò)誤瓣铣。您可以在CDN控制臺(tái)設(shè)置開啟回源SNI，指明具體訪問域名贷揽。具體SNI的介紹以及配置方法參考這里棠笑。

四.源站存在安全防護(hù)規(guī)則

源站的相關(guān)安全防護(hù)規(guī)則導(dǎo)致的CDN回源異常，通常會(huì)在10秒以內(nèi)就返回5xx錯(cuò)誤禽绪，大部分情況會(huì)返回503 Service Temporarily Unavailable的錯(cuò)誤蓖救，具體的排查方法和解決方案可以參考文檔源站安全策略導(dǎo)致5xx。

（1）源站服務(wù)器開啟了安全組限制印屁，限制了CDN節(jié)點(diǎn)的訪問

（2）源站服務(wù)器配置了單IP訪問次數(shù)限制循捺，把CDN的回源IP當(dāng)成了異常IP

（3）源站存在云鎖、安全狗雄人、防火墻等安全策略巨柒，攔截了CDN的回源IP

（4）源站W(wǎng)eb服務(wù)異常或服務(wù)器超載

五. 源站超時(shí)無響應(yīng)導(dǎo)致CDN回源超時(shí)

CDN 回源有嚴(yán)格的超時(shí)時(shí)間柠衍，四層 TCP 是 10 秒超時(shí)，七層HTTP / HTTPS是 30 秒超時(shí)晶乔，當(dāng)超過該時(shí)間時(shí)即使后續(xù)源站響應(yīng)正常也是會(huì)返回 5xx錯(cuò)誤珍坊，通常因CDN回源超時(shí)導(dǎo)致的問題，會(huì)響應(yīng)504Gateway Time-out錯(cuò)誤正罢≌舐可以綁定源站去測(cè)試源站的響應(yīng)速度，如果超過30秒，需要檢查源站服務(wù)履怯，優(yōu)化源站的響應(yīng)速度回还，確保源站返回請(qǐng)求時(shí)間控制在一個(gè)較短的時(shí)間內(nèi)，另外也可以申請(qǐng)延長(zhǎng)CDN域名的默認(rèn)超時(shí)時(shí)長(zhǎng)叹洲，詳細(xì)請(qǐng)參考配置回源請(qǐng)求超時(shí)時(shí)間柠硕。

六. 跨境回源或源站側(cè)網(wǎng)絡(luò)異常

回源存在跨境鏈路導(dǎo)致的CDN回源超時(shí)，響應(yīng)5xx錯(cuò)誤运提。例如源站在境外蝗柔，中國(guó)大陸的用戶訪問的時(shí)候，是先訪問到中國(guó)大陸的CDN節(jié)點(diǎn)民泵，然后中國(guó)大陸的CDN節(jié)點(diǎn)走跨境鏈路癣丧，回源到境外的源站；亦或者源站在中國(guó)大陸栈妆，境外用戶訪問的時(shí)候先請(qǐng)求到境外的CDN節(jié)點(diǎn)胁编，境外的CDN節(jié)點(diǎn)走跨境鏈路，回源到中國(guó)大陸的源站鳞尔。由于CDN回源走的都是公網(wǎng)嬉橙，這種情況涉及到跨境鏈路，需要走國(guó)際互聯(lián)網(wǎng)出口以及境外運(yùn)營(yíng)商的鏈路铅檩，本身就存在一定的不穩(wěn)定因素憎夷。還有一種情況是源站側(cè)機(jī)房的網(wǎng)絡(luò)差，或源站側(cè)網(wǎng)絡(luò)不穩(wěn)定昧旨。

CDN緩存相關(guān)問題及命中率優(yōu)化

提升緩存命中率的意義

CDN在靜態(tài)資源加速場(chǎng)景的應(yīng)用拾给，是將靜態(tài)資源緩存在距離客戶端最近的CDN節(jié)點(diǎn)上。用戶訪問該資源時(shí)兔沃，直接從緩存中獲取資源蒋得，避免通過較長(zhǎng)的鏈路回源。如果CDN緩存命中率低乒疏，則會(huì)導(dǎo)致源站壓力大额衙，靜態(tài)資源訪問效率低。因此怕吴，CDN緩存命中率的高低直接影響用戶體驗(yàn)窍侧，而保證較高的緩存命中率也成為了CDN的核心課題∽粒可以針對(duì)導(dǎo)致CDN緩存命中率低的具體原因伟件，選擇對(duì)應(yīng)的優(yōu)化策略，來優(yōu)化CDN的緩存命中率议经。CDN緩存命中率包括字節(jié)緩存命中率和請(qǐng)求緩存命中率斧账。

字節(jié)緩存命中率 = CDN緩存命中響應(yīng)的字節(jié)數(shù) / CDN所有請(qǐng)求響應(yīng)的字節(jié)數(shù)

請(qǐng)求緩存命中率 = CDN緩存命中的請(qǐng)求數(shù) / CDN所有的請(qǐng)求數(shù)

如何判斷緩存是否成功

我們可以通過打開瀏覽器審查元素來分析CDN返回的Response Header谴返，其中X-Cache字段來判斷是否命中緩存，具體可以參見如何通過瀏覽器的審查元素判斷CDN緩存是否成功咧织。

在 Response Headers 字段內(nèi)嗓袱，可以查看詳細(xì)的請(qǐng)求和返回的報(bào)文信息。

Age：為CDN返回的頭部字段习绢，表示該文件在CDN節(jié)- 點(diǎn)上緩存的時(shí)間渠抹，單位為秒。只有文件存在于節(jié)點(diǎn)上Age字段才會(huì)出現(xiàn)毯炮，當(dāng)文件被刷新后或者文件被清除的首次訪問逼肯，在此前文件并未緩存，無Age頭部字段桃煎，需要注意當(dāng)Age為0時(shí)篮幢，表示節(jié)點(diǎn)已有文件的緩存，但由于緩存已過期为迈，本次無法直接使用該緩存三椿，需回源校驗(yàn)。

X-Swift-SaveTime：CDN節(jié)點(diǎn)上的緩存RS（swift）的時(shí)間葫辐，即該文件是在什么時(shí)間緩存到CDN節(jié)點(diǎn)上搜锰。

X-Swift-CacheTime：CDN節(jié)點(diǎn)上的允許緩存時(shí)間，即該文件可以在CDN節(jié)點(diǎn)上緩存多久耿战，是指文件在CDN節(jié)點(diǎn)緩存的總時(shí)間蛋叼。計(jì)算還有多久需要回源刷新= ’X-Swift-CacheTime’ – ‘Age’。

X-Cache："HIT"表示已緩存剂陡，"MISS"表示節(jié)點(diǎn)上無該文件的緩存狈涮，回源請(qǐng)求。

為什么無法命中緩存

（1）客戶端請(qǐng)求是動(dòng)態(tài)請(qǐng)求

如果請(qǐng)求是動(dòng)態(tài)請(qǐng)求鸭栖，則無法命中CDN緩存歌馍。當(dāng)客戶端訪問這些動(dòng)態(tài)內(nèi)容時(shí)，每次都需要訪問用戶的服務(wù)器晕鹊，由服務(wù)器動(dòng)態(tài)生成實(shí)時(shí)的數(shù)據(jù)并返回給客戶端松却。

（2）源站返回強(qiáng)制不緩存的HTTP頭

當(dāng)源站配置了以下響應(yīng)頭時(shí)，即使配置了緩存規(guī)則溅话，CDN也不會(huì)對(duì)該資源進(jìn)行緩存晓锻，因?yàn)檫@些響應(yīng)頭在CDN緩存規(guī)則中的優(yōu)先級(jí)較高。

1：有s-maxage=0飞几、max-age=0带射、no-cache、no-store循狰、private中的任一種窟社。

2：有s-maxage或s-maxage=0。

3：有Pragma: no-cache绪钥。

（3）未返回響應(yīng)頭Etag和Last-modified

當(dāng)CDN未配置緩存規(guī)則時(shí)灿里，如果靜態(tài)文件未返回響應(yīng)頭Etag和Last-modified，則該靜態(tài)文件不能緩存在CDN節(jié)點(diǎn)上程腹。解決方案就是源站配置返回Etag和Last-modified或者直接在CDN上配置緩存規(guī)則匣吊。

（4）全站加速未配置靜態(tài)加速

全站加速默認(rèn)走了動(dòng)態(tài)加速，動(dòng)態(tài)加速是每次回源的寸潦。如果需要走緩存的話色鸳，需要配置靜態(tài)加速。目前配置靜態(tài)加速支持按照文件類型见转、URI以及路徑方式配置命雀。如果全站加速?zèng)]有配置靜態(tài)加速的情況，則都是走動(dòng)態(tài)加速的斩箫，全站加速節(jié)點(diǎn)響應(yīng)的HTTP頭沒有X-Cache吏砂、X-Swift-CacheTime等字段的，類似如下圖

影響CDN緩存命中率下降的因素：

（1）刷新緩存乘客，可能導(dǎo)致短時(shí)間內(nèi)命中率下降狐血。

（2）帶寬突增，會(huì)導(dǎo)致CDN節(jié)點(diǎn)回源較多易核，命中率會(huì)表現(xiàn)有下降趨勢(shì)匈织。

（3）CDN節(jié)點(diǎn)訪問新內(nèi)容，導(dǎo)致CDN節(jié)點(diǎn)回源較多牡直，命中率會(huì)表現(xiàn)有下降趨勢(shì)缀匕。

（4）緩存規(guī)則調(diào)整，可能會(huì)影響命中率井氢。

緩存命中率低分析及優(yōu)化

CDN控制臺(tái)統(tǒng)計(jì)的緩存命中率僅僅是CDN L1層的命中率弦追，實(shí)際情況L2層的緩存數(shù)據(jù)也是從CDN節(jié)點(diǎn)獲取，并不會(huì)從源站獲取數(shù)據(jù)花竞，所以真實(shí)的CDN命中率是略高于CDN控制臺(tái)顯示的命中率劲件。

另外查看CDN加速域名流量情況，在加速域名流量不高的情況下约急，即便MISS狀態(tài)的URL不多零远，但是對(duì)命中率的統(tǒng)計(jì)計(jì)算影響很大。例如厌蔽，某CDN加速域名一共對(duì)外提供了10個(gè)可以訪問的URL牵辣，其中有一個(gè)URL源站上設(shè)置了no-cache，導(dǎo)致不緩存奴饮，在其他URL訪問都命中的情況下纬向，命中率也僅有90%择浊。

在之前檢查正常的情況下，有如下幾種可能導(dǎo)致命中率低的情況逾条，請(qǐng)逐一進(jìn)行排查：

（1）源站上緩存Header設(shè)置不當(dāng)琢岩，或者缺少必要的Header，如果CDN的緩存規(guī)則是不緩存师脂，那么每次訪問都是MISS狀態(tài)担孔，影響命中率，具體請(qǐng)參考前文“為什么無法命中緩存”的描述吃警。

（2）CDN控制臺(tái)設(shè)置了不緩存的規(guī)則糕篇，即某目錄或者某種后綴的文件設(shè)置的緩存時(shí)間為0秒，相關(guān)信息可以在CDN控制臺(tái)查看酌心。

（3）源站動(dòng)態(tài)內(nèi)容較多拌消，目前CDN主要是加速靜態(tài)資源，例如CSS谒府、JS拼坎、HTML、圖片完疫、txt泰鸡、視頻等資源，針對(duì)動(dòng)態(tài)資源PHP壳鹤、JSP盛龄、包含內(nèi)部邏輯處理甚至Cookie等資源都會(huì)回源數(shù)據(jù)。

（4）CDN的加速URL中帶有可變參數(shù)芳誓。例如URL地址為http://XXX.XXX.cn/1.txt?timestamp=14378923?余舶，其中timestamp值為時(shí)間戳，每次訪問此值均不同锹淌。CDN針對(duì)第一次訪問的URL匿值，即之前未預(yù)熱的URL，無論該URL是否符合CDN的緩存規(guī)則赂摆，由于節(jié)點(diǎn)上還沒有這個(gè)文件挟憔，第一次訪問肯定都是MISS狀態(tài)。但是timestamp參數(shù)會(huì)變化烟号，所以每次訪問都是一個(gè)全新的URL绊谭，則每次都返回MISS狀態(tài)，從而影響命中率汪拥。

（5）檢查是否存在頻繁刷新緩存的操作达传。

（6）文件熱度不夠。不經(jīng)常被用戶訪問到的URL，即使符合所有緩存規(guī)則宪赶，但是經(jīng)常有被節(jié)點(diǎn)去除緩存的風(fēng)險(xiǎn)宗弯。CDN節(jié)點(diǎn)上緩存的文件，可以理解為按照熱度屬性采取末尾淘汰制逊朽，熱度就是該文件在該節(jié)點(diǎn)上被訪問的頻率罕伯，文件熱度不夠，其實(shí)一定程度上跟這個(gè)域名本身的流量不高有關(guān)系叽讳。

針對(duì)以上情況，可以考慮通過"預(yù)熱URL"坟募、"配置資源緩存規(guī)則"岛蚤、"過濾URL中可變參數(shù)"來優(yōu)化緩存命中率，具體操作請(qǐng)參見優(yōu)化CDN緩存命中率懈糯。