服务端缓存页面及IIS缓存设置

　　缓存信息基本概念

我们在看网页的header信息时，经常看到这几个参数：Expires、Cache-Control、Last-Modified、ETag，它们是RFC 2616（HTTP/1.1）协议中和网页缓存相关的几个字段。前两个用来控制缓存的失效日期，后两个用来验证网页的有效性。要注意的是， HTTP/1.0有一个功能比较弱的缓存控制机制：Pragma，使用HTTP/1.0的缓存将忽略Expires和Cache-Control头。

Expires

Expires字段声明了一个网页或URL地址不再被浏览器缓存的时间，一旦超过了这个时间，浏览器都应该联系原始服务器。RFC告诉我们：“由于推断的失效时间也许会降低语义透明度，应该被谨慎使用，同时我们鼓励原始服务器尽可能提供确切的失效时间。”

Cache-Control

Cache-Control字段中可以声明多些元素，例如no-cache, must-revalidate, max-age=0等。这些元素用来指明页面被缓存最大时限，如何被缓存的，如何被转换到另一个不同的媒介，以及如何被存放在持久媒介中的。但是任何一个 Cache-Control指令都不能保证隐私性或者数据的安全性。“private”和“no-store”指令可以为隐私性和安全性方面提供一些帮助，但是他们并不能用于替代身份验证和加密。

Last-Modified

Last-Modified和ETag是条件请求(Conditional Request)相关的两个字段。如果一个缓存收到了针对一个页面的请求，它发送一个验证请求询问服务器页面是否已经更改，在HTTP头里面带上” ETag”和”If Modify Since”头。服务器根据这些信息判断是否有更新信息，如果没有，就返回HTTP 304（NotModify）；如果有更新，返回HTTP 200和更新的页面内容，并且携带新的”ETag”和”LastModified”。

使用这个机制，能够避免重复发送文件给浏览器，不过仍然会产生一个HTTP请求。

ETag

既然有了Last-Modified，为什么还要用ETag字段呢？因为如果在一秒钟之内对一个文件进行两次更改，Last-Modified就会不正确。因此，HTTP/1.1利用Entity Tag头提供了更加严格的验证。

　　IIS下的缓存

　　有两种模式，一种是用户模式，一种是内核模式！

　　在操作系统中，cup的处理速度最快最稳定了，其次是一级二级三级缓存，然后就是磁盘了。所以我们会把主要页面缓存起来以提高网站的性能，尽量减小数据库操作（毕竟读取磁盘的数据太慢了）。

　　另外一个需要注意的问题

　　对ASP和ASP.NET进行缓存的时候要小心。

1. 当用户A访问一个ASP页面(假设test.asp)，如果这个ASP页面里面用到session的话，在Response里面会有一个"Set-Cookie"的header，这个字段里面保存的就是SessionId。如果用户A后面继续访问别的ASP页面的话，会把这个SessionId传到服务器去，只有这样，服务器才能确定你这个请求还是来自于同一个用户A。简而言之，SessionId是用来唯一表示一个客户端。

2. 启用了Kernel mode cache之后，IIS服务就把test.asp的Response放到http.sys(kernel mode cache)

3. 此时，如果用户B访问了同一个页面(test.asp)，IIS就直接把Cache里面的页面结果返回到客户端，也就是传回了跟用户A一样的SessionId

　　现在，就很好解释登录问题了。

1) User A登录了并做了一些操作，User B也登录进来了，这个时候User A看到的就是 User B的信息了。

2) User A登录了并做了一些操作，User B也登录进来了，User A又登出了，User B就发现自己“未登录”

这个问题，在IIS6里面的ASP.NET应用有被描述过(http://support.microsoft.com/kb/917072)。当时对于ASP并没有这种cache的功能，所以没有描述。