Last-Modifield
当我们第一次请求一个url时，服务端会返回状态码为200，并且返回一个 Last-Modifield 的属性进行标记此文件最后的修改时间，格式如下：
Last-Modified: Fri, 12 May 2006 18:53:33 GMT
当第二次请求时，客户端会向服务端发送一个 If-Modifield-Since报头（这是上一次从服务端请求得到的），查看此文件是否修改过：
Last-Modified: Fri, 12 May 2006 18:53:33 GMT
若此资源没有变化，则返回一个304的状态码，内容为空。否则，若代码变化或者服务器重启，则返回一个200的状态码，并重新获得此资源
Etag
HTTP协议规定它为 “被修改变量的实体值”，它也有其他叫法，web资源的记号或标示。服务端能判断客户请求的资源是什么，把记号放在http的响应头中返回给客户端，如下
ETag: "50b1c1d4f775c61:df3"
客户端能查询更新格式，如下
If-None-Match: W/"50b1c1d4f775c61:df3"
不同的服务端可能生成的方式不一样，如nginx则是把文件的最后修改时间，和文件大小字节的16进制拼接起来的
Etag作用与Last-modifield类似，若资源无变化，则返回304状态码
那么问题来了，已经有了Etag，为什么还需要Last-Modifield呢？
Etag比较的是文件资源的特征值，而Last-Modifield则比较的是文件资源的最后的修改时间。这两个其实是相辅相成的，不是有了Etag就不该有Last-Modifield，有了Last-Modifield就不该有Etag，同时传入服务器时，服务器会根据自己的缓存机制进行选择要使用哪个，甚至可以两个都进行参考。
有什么作用呢？
正是因为它能够判断是否重新请求资源文件，这样最好的结果就是，能够节省一定的带宽和流量，特别是大数据的时候，虽然这小小的变化，但却能起到一个非常好的效果。
以上就是我对Etag和Last-Modifield的理解，如有错误，还望指正。
