服务端缓存页面及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的功能，因此没有描述。