先說說HTTP請求
對于所有開發(fā)者來說扣蜻，HTTP協(xié)議應該非常熟悉累颂。在HTTP返回的狀態(tài)中诫欠，304是一個非常常用的標準艰赞。304的意思是，告訴瀏覽器提佣，你所請求的文件并沒有變動吮蛹，你可以繼續(xù)使用上次緩存下來的文件荤崇，減少重復數據的再次傳輸。
304狀態(tài)碼
304狀態(tài)碼一般會由瀏覽器客戶端潮针，和服務器程序（如：nginx术荤，apache）根據一定的協(xié)議去協(xié)作完成。對用戶透明每篷，有時候甚至對開發(fā)者也透明瓣戚。因為很多服務器程序會自動處理靜態(tài)文件（如：js，css）焦读，達到優(yōu)化請求的效果子库。
啟發(fā)
實際上，我們可以在程序里面實現一套我們自己所實現的“304”狀態(tài)碼矗晃，以達到減少重復數據傳輸的時間仑嗅。
開始
APP端
這里我們需要實現一個庫，去維護我們請求的緩存张症。
大致需求如下：
1.請求(URL)的時候仓技，帶上上次響應數據摘要(HASH)，并鎖住緩存俗他，不允許刪除操作脖捻，沒有則不帶。
2.獲得響應的時候兆衅，有兩種情況：返回完整數據和數據未變動標記(304)
3.返回完整數據的時候：那么生成hash地沮，并更新緩存，可以用于下次請求羡亩。
4.返回未變動標記(304)：那么直接從緩存獲取數據诉濒，并更新有效期。
這里后面還可以根據相關的緩存淘汰策略夕春，根據用戶行為去選擇所需要淘汰的緩存數據集，節(jié)省空間专挪，這里后面有時間可以再發(fā)個帖講講自己的想法及志。
服務端
這里服務端需要做的很簡單：
1.計算結果（這里和往常一樣）
2.若客戶端上傳HASH則計算結果HASH。
3.結果HASH 與 客戶端上傳HASH對比寨腔。
4.不一致則返回完整數據集速侈，一致則返回未變動標記。
先說說缺點
缺點也比較明顯迫卢，就是每次請求和響應都需要進行一個hash的運算倚搬，hash的運算不太適合于數據比較大情況。
MD5運算1G文件大約需要20-30s乾蛤，極其影響響應速度每界。
今天測試了一下捅僵，PHP5.3，100W次的8192個數字md5運算眨层，大約是10.545665979385秒庙楚。感覺性能也還行吧。不過對于性能極致追求的人還是要保持時刻謹慎的態(tài)度趴樱。
也說說優(yōu)點
優(yōu)點其實也很容易發(fā)現：
尤其適合于那種頻繁請求的中小型數據量且數據不會經常變動同步的接口馒闷，能夠減少二次傳輸延時。
對于大數據量且數據量不常變的異步接口其實也是同樣適用叁征，對于大數據量纳账，這個二次傳輸的優(yōu)化速度也同樣很明顯。在不影響用戶體驗的情況下捺疼，達到速度優(yōu)化的效果疏虫。
