先说说HTTP请求
对于所有开发者来说，HTTP协议应该非常熟悉。在HTTP返回的状态中，304是一个非常常用的标准。304的意思是，告诉浏览器，你所请求的文件并没有变动，你可以继续使用上次缓存下来的文件，减少重复数据的再次传输。
简书某接口返回304状态
304状态码
304状态码一般会由浏览器客户端，和服务器程序（如：nginx，apache）根据一定的协议去协作完成。对用户透明，有时候甚至对开发者也透明。因为很多服务器程序会自动处理静态文件（如：js，css），达到优化请求的效果。
启发
实际上，我们可以在程序里面实现一套我们自己所实现的“304”状态码，以达到减少重复数据传输的时间。
开始
APP端
这里我们需要实现一个库，去维护我们请求的缓存。
大致需求如下：
1.请求(URL)的时候，带上上次响应数据摘要(HASH)，并锁住缓存，不允许删除操作，没有则不带。
2.获得响应的时候，有两种情况：返回完整数据和数据未变动标记(304)
3.返回完整数据的时候：那么生成hash，并更新缓存，可以用于下次请求。
4.返回未变动标记(304)：那么直接从缓存获取数据，并更新有效期。
这里后面还可以根据相关的缓存淘汰策略，根据用户行为去选择所需要淘汰的缓存数据集，节省空间，这里后面有时间可以再发个帖讲讲自己的想法。
服务端
这里服务端需要做的很简单：
1.计算结果（这里和往常一样）
2.若客户端上传HASH则计算结果HASH。
3.结果HASH 与 客户端上传HASH对比。
4.不一致则返回完整数据集，一致则返回未变动标记。
先说说缺点
缺点也比较明显，就是每次请求和响应都需要进行一个hash的运算，hash的运算不太适合于数据比较大情况。
MD5运算1G文件大约需要20-30s，极其影响响应速度。
今天测试了一下，PHP5.3，100W次的8192个数字md5运算，大约是10.545665979385秒。感觉性能也还行吧。不过对于性能极致追求的人还是要保持时刻谨慎的态度。
也说说优点
优点其实也很容易发现：
尤其适合于那种频繁请求的中小型数据量且数据不会经常变动同步的接口，能够减少二次传输延时。
对于大数据量且数据量不常变的异步接口其实也是同样适用，对于大数据量，这个二次传输的优化速度也同样很明显。在不影响用户体验的情况下，达到速度优化的效果。
