304狀態碼是什么?
如果客戶端發送了一個帶條件的GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個304狀態碼。簡單的表達就是：客戶端已經執行了GET，但文件未變化。
什么情況下會返回304狀態碼?
客戶端是怎么知道這些內容沒有更新的呢？其實這並不是客戶端的事情，而是你服務器的事情，大家都知道服務器可以設置
緩存機制，這個功能是為了提高網站的訪問速度，當你發出一個GET請求的時候服務器會從緩存中調用你要訪問的內容，這個時候服務器就可以判斷這個頁面是不是更新過了，如果未更新過那么他會給你返回一個304狀態碼。
例如：一些搜索引擎是如何知道我們的網站是否有更新。判斷網頁是否發生變化最直接的方法是設置頁面的某一處為監控區域，每次都抓取該部分區域的內容，然后與本地保存的或最 近一次抓取內容比較，如果有差異就表明網頁發生了變化，才可以進行解析。這種方法比較穩妥，幾乎可達到萬無一失的效果。但是，這種方式在每次掃描時都要下載頁面內容，並且要去截取監控區域的內容，最后還要進行字符串比較，整個過程比較耗時。其實在眾多網頁中，有一部分網站的網頁內容是
靜態頁面，如圖片，html，js等，這些靜態頁面往往可能是服務器早已准備好的，用戶訪問時僅僅是下載而已。那么針對這種靜態頁面，就可以僅僅通過304狀態碼來判斷，內容是否發生了變化。
如何解決?
如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭后的第一個空行結尾。
該響應必須包含以下的頭信息：
Date，除非這個服務器沒有時鍾。假如沒有時鍾的服務器也遵守這些規則，那么代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制將會正常工作。
ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。
Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。
假如本響應請求使用了強緩存驗證，那么本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。
假如某個304響應指明了當前某個實體沒有緩存，那么緩存系統必須忽視這個響應，並且重復發送不包含限制條件的請求。
假如接收到一個要求更新某個緩存條目的304響應，那么緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值
在進行條件請求時,客戶端會提供給服務器一個If-Modified-Since請求頭,其值為服務器上次返回的Last-Modified響應頭中的Date日期值,還會提供一個If-None-Match請求頭,值為服務器上次返回的ETag響應頭的值。
當網站的狀態碼是304的時候 ，爬蟲或返回705的狀態信息。說明WAP網關與遠端服務器建立連接失敗。
參考狀態碼信息：
http://tool.oschina.net/commons?type=5
https://wenku.baidu.com/view/4e06018483d049649b66581c.html