14.http 304优化，了解客户端缓存

很多人首先会想从服务器缓存方面着手对程序进行 优化,许多不同的服务器缓存方式都有他们自己的特点,
像我曾经参与的一些项目中,根据缓存的命中率不同使用过 Com+/Enterprise Libiary Caching/Windows服务,
静态文件等方式的服务器端缓存和 HTTP Compression技术,但客户端缓存往往却被人们忽略了,
即使服务器的缓存让你的页面访问起来非常地快,但她依然需要依赖浏览器下载并输出,
而当你 加入客户端缓存时,会给你带来非常多的好处.因为她可以对站点中访问最频繁的页进行缓存充分地提高
Web 服务器的吞吐量（通常以每秒的请求数计算）以提升应用程序性能和可伸缩性。
一个在线购物调查显示，大多数人愿意去商店排队，但在在线购物时却不愿意等待。
Websense调查公司称多达70%的上网者表示不愿意在页面读取上超过10秒钟。
超过70%的人会因为中途速度过慢而取消当前的订单。

在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，
同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样：
Last-Modified: Fri, 12 May 2006 18:53:33 GMT

客户端第二次请求此URL时，根据 HTTP 协议的规定，浏览器会向服务器传送 If-Modified-Since 报头，
询问该时间之后文件是否有被修改过：
If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT
如 果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed.）状态码，内容为空，
这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。
从而保证不向客户端重复发出资源，也保证当服务器有变化时，
客户端能够得到最新的资源。

HTTP 协议规格说明定义ETag为“被请求变量的实体值” （参见 —— 章节 14.19）。 另一种说法是，
ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。
服务器单 独负责判断记号是什么及其含义，
并在HTTP响应头中将其传送到客户端，
以下是服务器端返回的格式：
ETag: "50b1c1d4f775c61:df3"
客户端的查询更新格式是这样的：
If-None-Match: W/"50b1c1d4f775c61:df3"
如果ETag没改变，则返回状态304然后不返回，
这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。

Last-Modified和Etags如何帮助提高性能?
聪 明的开发者会把Last-Modified 和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。
因为服务器首先产生 Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。
本质上，客户端通过将该记号传回服务器要求服务器验证其（客 户端）缓存。
过程如下:
1. 客户端请求一个页面（A）。
2. 服务器返回页面A，并在给A加上一个Last-Modified/ETag。
3. 客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。
4. 客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
5. 服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，
直接返回响应304和一个空的响应体。
下面的例子描述如何使用服务器端代码去操作客户端缓存:

Not Modified 客户端有缓冲的文档并发出了一个条件性的请求
（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，
原来缓冲的文档还可以继续使用。

如果客户端在请求一个文件的时候，发现自己缓存的文件有 Last Modified ，那么在请求中会包含 If Modified Since ，
这个时间就是缓存文件的 Last Modified 。因此，如果请求中包含 If Modified Since，
就说明已经有缓存在客户端。只要判断这个时间和当前请求的文件的修改时间就可以确定是返回 304 还是 200 。
对于静态文件，例如：CSS、图片，服务器会自动完成 Last Modified 和 If Modified Since 的比较，完成缓存或者更新。
但是对于动态页面，就是动态产生的页面，往往没有包含 Last Modified 信息，
这样浏览器、网关等都不会做缓存，也就是在每次请求的时候都完成一个 200 的请求。

因此，对于动态页面做缓存加速，首先要在 Response 的 HTTP Header 中增加 Last Modified 定义，
其次根据 Request 中的 If Modified Since 和被请求内容的更新时间来返回 200 或者 304 。
虽然在返回 304 的时候已经做了一次数据库查询，但是可以避免接下来更多的数据库查询，
并且没有返回页面内容而只是一个 HTTP Header，从而大大的降低带宽的消耗，对于用户的感觉也是提高。

当这些缓存有效的时候，通过 HttpWatch 查看一个请求会得到这样的结果：
第一次访问 200
鼠标点击二次访问 (Cache)
按F5刷新 304
按Ctrl+F5强制刷新 200

如果客户端发送的是一个条件验证(Conditional Validation)请求,则web服务器可能会返回HTTP/304响应,
这就表明了客户端中所请求资源的缓存仍然是有效的,也就是说该资源从上次缓存到现在并没有被修改过.
条件请求可以在确保客户端的资源是最新的同时避免因每次都请求完整资源给服务器带来的性能问题.

当客户端缓存了目标资源但不确定该缓存资源是否是最新版本的时候,就会发送一个条件请求.在Fiddler中,你可以在Headers Inspector查找相关请求头,这样就可以辨别出一个请求是否是条件请求.

在进行条件请求时,客户端会提供给服务器一个If-Modified-Since请求头,其值为服务器
上次返回的Last-Modified响应头中的日期值,还会提供一个If-None-Match请求头,值为服务器上次返回的ETag响应头的值:

服务器会读取到这两个请求头中的值,判断出客户端缓存的资源是否是最新的,如果是的话,
服务器就会返回HTTP/304 Not Modified响应,但没有响应体.客户端收到304响应后,就会从缓存中读取对应的资源.

另一种情况是,如果服务器认为客户端缓存的资源已经过期了,那么服务器就会返回HTTP/200 OK响应,
响应体就是该资源当前最新的内容.客户端收到200响应后,就会用新的响应体覆盖掉旧的缓存资源.

只有在客户端缓存了对应资源且该资源的响应头中包含了Last-Modified或ETag的情况下,
才可能发送条件请求.如果这两个头都不存在,则必须无条件(unconditionally)请求该资源,服务器也就必须返回完整的资源数据.

当用户访问一个网页时,条件请求可以加速网页的打开时间(因为可以省去传输整个响应体的时间),
但仍然会有网络延迟,因为浏览器还是得为每个资源生成一条条件请求,并且等到服务器返回HTTP/304响应,
才能读取缓存来显示网页.更理想的情况是,服务器在响应上指定Cache-Control或Expires指令,
这样客户端就能知道该资源的可用时间为多长,也就能跳过条件请求的步骤,直接使用缓存中的资源了.
可是,即使服务器提供了这些信息,在下列情况下仍然需要使用条件请求:

在超过服务器指定的过期时间之后
如果用户执行了刷新操作的话
在上节给出的图片中,请求头中包含了一个Pragma: no-cache.这是由于用户使用F5刷新了网页.
如果用户按下了CTRL-F5 (有时称之为“强刷-hard refresh”),
你会发现浏览器省略了If-Modified-Since和If-None-Match请求头,
也就是无条件的请求页面中的每个资源.

通常来说,缓存是个好东西.如果你想提高自己网站的访问速度,缓存是必须要考虑的.
可是在调试的时候,有时候需要阻止缓存,这样才能确保你所访问到的资源是最新的.

你也许会有个疑问:“如果不改变网站内容,我怎么才能让Fiddler
不返回304而返回一个包含响应体的HTTP/200响应呢?”

你可以在Fiddler中的网络会话(Web Sessions)列表中选择一条响应为HTTP/304的会话,
然后按下U键.Fiddler将会无条件重发(Unconditionally reissue)这个请求.
然后使用命compare命令对比一下两个请求有什么不同,对比结果如下,从中可以得知,
Fiddler是通过省略条件请求头来实现无缓存请求的: