在CDN中，我們?cè)?jīng)的疑惑：

1. 為什么在瀏覽器中訪問是304，而通過linux下curl進(jìn)行測試，卻是200？

2. 304究竟是源站返回的？還是CDN節(jié)點(diǎn)返回的？

3. 如果源站返回304，那么客戶端收到的會(huì)是304么？

4. ？？？？？

304的名詞解釋

狀態(tài)碼304百度百科結(jié)果：如果客戶端發(fā)送了一個(gè)帶條件的GET 請(qǐng)求且該請(qǐng)求已被允許，而文檔的內(nèi)容（自上次訪問以來或者根據(jù)請(qǐng)求的條件）并沒有改變，則服務(wù)器應(yīng)當(dāng)返回這個(gè)304狀態(tài)碼。簡單的表達(dá)就是：客戶端已經(jīng)執(zhí)行了GET，但文件未變化。

一一解答：

首先需要清楚304的請(qǐng)求原理：之所以會(huì)有304，是因?yàn)樵凑臼盏搅藖碜钥蛻舳说膶?duì)比需求（是否對(duì)比是客戶端提的需求）。換句話說，只有當(dāng)客戶端在請(qǐng)求的時(shí)候提供了雙方早已商榷好的對(duì)比參數(shù)，服務(wù)端才會(huì)進(jìn)行參數(shù)對(duì)比，進(jìn)而判斷是否需要返回文件內(nèi)容給客戶端，若客戶端未提供這些參數(shù)，那么服務(wù)端將直接返回200（文件內(nèi)容）。而這些參數(shù)就是：

if-none-match：當(dāng)服務(wù)端收到的request header中包含這個(gè)頭部信息時(shí)，將獲取其中的參數(shù)值（客戶端緩存的文件的Etag值），與文件本身的Etag值進(jìn)行對(duì)比，若一致，則返回304。

if-modified-since：當(dāng)服務(wù)端收到的request header中包含這個(gè)頭部信息時(shí)，將獲取其中的參數(shù)值（客戶端緩存的文件的Last-modified值），與文件本身的Last-modified時(shí)間進(jìn)行對(duì)比，若一致，則返回304。

為什么在瀏覽器中訪問是304，而通過linux下curl進(jìn)行測試，卻是200？

請(qǐng)仔細(xì)對(duì)比下方兩個(gè)request header的區(qū)別，上為瀏覽器請(qǐng)求頭（前提是瀏覽器已訪問過該文件），下為linux請(qǐng)求頭，你將發(fā)現(xiàn)瀏覽器的請(qǐng)求頭中包含很多文件與CDN的信息，其中便包括下方紅色方框的兩個(gè)頭部信息。

當(dāng)服務(wù)端接收到這兩個(gè)頭部信息后，便會(huì)進(jìn)行對(duì)比，發(fā)現(xiàn)文件未變化，則返回304。
如上例子，CDN節(jié)點(diǎn)若過期回源，源站返回304，那是否linux端也會(huì)接收到304呢？

不會(huì)。由于CDN的節(jié)點(diǎn)均為代理訪問，因此CDN的中心節(jié)點(diǎn)接收到的304為源站返回，而邊緣節(jié)點(diǎn)接收到的304為中心節(jié)點(diǎn)返回，客戶端接收到的304為邊緣節(jié)點(diǎn)返回。CDN節(jié)點(diǎn)過期回源時(shí)，將帶著if-none-match if-modified-since兩個(gè)頭部進(jìn)行驗(yàn)證，若文件未經(jīng)修改，則返回304，但linux客戶端在請(qǐng)求時(shí)并未帶上if-none-match if-modified-since，因此CDN節(jié)點(diǎn)將直接返回200（并同時(shí)返回源文件數(shù)據(jù)包）。