在CDN中，我們曾經(jīng)的疑惑：

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

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

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

4. ？？？？？

304的名詞解釋

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

一一解答：

首先需要清楚304的請求原理：之所以會有304，是因為源站收到了來自客戶端的對比需求（是否對比是客戶端提的需求）。換句話說，只有當(dāng)客戶端在請求的時候提供了雙方早已商榷好的對比參數(shù)，服務(wù)端才會進(jìn)行參數(shù)對比，進(jìn)而判斷是否需要返回文件內(nèi)容給客戶端，若客戶端未提供這些參數(shù)，那么服務(wù)端將直接返回200（文件內(nèi)容）。而這些參數(shù)就是：

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

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

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

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

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

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