在CDN中，我們曾經的疑惑：

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

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

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

4. ？？？？？

304的名詞解釋

狀態碼304百度百科結果：如果客戶端發送了一個帶條件的GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）并沒有改變，則服務器應當返回這個304狀態碼。簡單的表達就是：客戶端已經執行了GET，但文件未變化。

一一解答：

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

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

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

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

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

當服務端接收到這兩個頭部信息后，便會進行對比，發現文件未變化，則返回304。
如上例子，CDN節點若過期回源，源站返回304，那是否linux端也會接收到304呢？

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