ASP.NET 缓存技术（一）——启用页面输出缓存_ASP.NET_编程语言

作者寄语：MSDN 是最好的老师，互联网是最智慧的生命体，分享是最重要的成长途径，技术的进步在于学习、实践和创新！

本系列所讲述的技术和展示的代码适用于 .NET Framework 4.0 和 IIS7 下的 ASP.NET 4.0，所附示例代码使用 Visual Studio 2010 开发，并可能需要使用 SQL Express 服务。作者在学习 MSDN 和参考网络文献的基础上对相关技术进行了归纳整理，如有不足和错误，欢迎大家指正。

为什么使用缓存技术？

这可能是一个很好回答的问题，那就是为了提升应用程序的性能。但更多的人并不十分清楚应该在什么时候，怎样去应用缓存技术。通常来说，一般的 ASP.NET 应用程序很少有人去关注缓存的使用，但是当这样的应用程序因为需求的扩大，需要处理更多的数据，需要承载更多的用户，需要采用更复杂的部署时，普通的方法绝对会让你对系统的性能表现感到束手无策。在现在内存并不昂贵的时代，良好的缓存应用将会比优化程序代码为系统带来的性能提升更为廉价。在这里提到了良好的缓存应用这种说法，因为缓存技术并不是万能的，如何使用取决于系统的各种需求和指标。

ASP.NET 缓存技术中的两个层面

在 ASP.NET 的应用程序中，可以在页面输出和应用程序数据两个层面应用缓存技术。

对页面输出进行缓存是指在内存中保存处理后的 ASP.NET 页面。通常对 ASP.NET 页面的请求都会导致 IIS7 经历如下过程：

ASP.NET 缓存技术（一）——启用页面输出缓存

当对页面输出进行缓存后，如果当前请求的页面的服务器缓存已经存在，则以上的执行过程在“解析缓存”这一步完成后就会停止并返回缓存的页面内容，由此也导致了页面的相关事件不会得到执行，直到该页面的服务器缓存失效。ASP.NET 为页面输出缓存提供了两种服务器缓存模型，整页缓存和部分页缓存，而部分页缓存又可采用两种工作方式：控件缓存和缓存后替换。更为出色的是，ASP.NET 还可以根据请求参数的不同而创建同一页面的不同缓存。更多关于页面输出的缓存将在后文详细讲述。

对应用程序数据进行缓存是通过 ASP.NET 提供的一种编程方式来访问可以是任意数据的键/值对，这些键/值对存储在内存中，使用方式与应用程序状态（System.Web.HttpApplicationState）类似，只是它们是易失的。更多关于应用程序数据的缓存将在后文详细讲述。

开启页面输出缓存

通过在 ASPX 页面文件中包含 @ OutputCache 指令，并设置它的 Duration 和 VaryByParam 属性就可非常方便的启用页面输出缓存。Duration 属性用于指定页面输出缓存的缓存时间，以秒为单位；VaryByParam 属性这里先设置为 none，有关它的更多信息将在后文讲述。以下代码演示了如何将页面输出内容缓存 60 秒：

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ OutputCache Duration="60" VaryByParam="none" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <script runat="server">
        protected void Page_Load(object sender, EventArgs e)
        {
            lblNowTime.Text = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
        }
    </script>
    <form id="form1" runat="server">
    <div>
        <asp:Label ID="lblNowTime" runat="server" />
    </div>
    </form>
</body>
</html>

到这里，我们就已经开启了页面输出缓存，该段代码中的 Page_Load 方法在每次执行后，至少会过 60 秒才会再次执行（为什么用了“至少”这个词，结合后面的讲述想想吧）。

页面输出缓存的本质

在继续深入之前，我们要先问问，页面输出缓存是怎样实现的呢？页面输出缓存的定义可以这样来说，在页面的响应生命周期之内，将页面的内容存储在可缓存设备上，在页面过期之前，使用该存储的内容提供给用户。可缓存设备包括发出请求的浏览器、响应请求的 Web 服务器以及在请求和响应流中其它任何具有缓存功能的设备，如代理服务器。在最基本的层面，HTTP 1.0 协议就已经定义了简单的缓存机制，现在流行的最新浏览器所支持的 HTTP 1.1 协议更是在这个基础上进行了扩展并消除了 HTTP 1.0 协议的缺陷。

HTTP 协议通过在头部添加 Cache-Control 标头来控制页面的缓存动作。HTTP 1.1 协议中的 Cache-Control 标头有以下设置：

参数	说明
public	数据内容皆被储存起来，就连有密码保护的网页也储存，安全性很低。
private	数据内容只能被储存到私有的缓存中，通常是浏览器的本地缓存。这是 Cache-Control 标头的默认值。
no-cache	数据内容永远不会被储存，代理服务器和浏览器读到此标头就不会将数据内容存入缓存。
no-store	数据内容除不存入缓存中，也不能存入暂时的磁盘中，这个标头防止敏感性数据被复制。
must-revalidate	用户在每次读取数据时，会再次和原来的服务器确定是否为最新数据，而不是和中间的代理服务器。
proxy-revalidate	这个参数很像 must-revalidate，不过中间接收的代理服务器可以互相分享缓存。
max-age=xxx	数据内容在 xxx 秒后失效，这个标头就像 Exires 标头（HTTP 1.0 协议定义的缓存过期机制）的功能一样，不过 max-age=xxx 只能服务于支持 HTTP 1.1 协议的浏览器。假设两者都有，max-age 优先。

通过 HTTP 协议控制页面的缓存动作，通常可以像如下示例一样添加 Cache-Control 标头在响应流的头部：

HTTP 标头	说明
Cache-Control:max-age=3600	指示页面应在 60 分钟后过期，内容不应在代理服务器上缓存。
Cache-Control:no-cache	指示页面应每次向原来的服务器请求并获取内容。
Cache-Control:public,max-age=3600	指示页面应在 60 分钟后过期，内容可以在浏览器的本地区域和代理服务器上缓存。

但是通过 Cache-Control 标头的控制作用还取决于用户不同的浏览方式：

（1）打开新窗口：如果 Cache-Control 的值为 private、no-cache、must-revalidate，那么打开新窗口访问时都会重新访问服务器。而如果指定了 max-age=xxx 值，则在 xxx 秒时间内都不会重新访问服务器。

（2）地址栏回车：如果 Cache-Control 的值为 private 或 must-revalidate，则只有第一次访问时会访问服务器，以后就不再访问。如果值为 no-cache，那么每次都会访问服务器。如果指定了 max-age，则在过期之前不会访问服务器。

（3）按后退按钮：如果 Cache-Control 的值为 private、must-revalidate、max-age，则不会重新访问服务器。如果值为 no-cache，则每次都重新访问服务器。

（4）按刷新按钮：无论 Cache-Control 为何值，都会重新访问服务器。

通过 Cache-Control 标头设置了缓存的页面，再次向服务器请求时（比如按刷新按钮），浏览器发出的请求头部会添加 If-Modified-Since 标头，该标头向服务器询问从指定的日期后该页面是否已经修改。对于 ASP.NET 而言，根据页面是否开启了服务器端缓存，响应这样的请求会有两种结果，一种是该页面开启了服务器端缓存并且该页面缓存还未过期，则返回 304 的响应，这时浏览器使用本地缓存向用户呈现页面；其它情况则是重新处理该请求并启动新的 ASP.NET 页面生命周期，返回 200 的响应和新的页面内容。注意，请区别这里返回 304 响应的情况和前述的不会重新访问服务器的情况的不同，后者根本就不向服务器发出请求。

话题说到这里，我们已经把基于 HTTP 协议实现的页面缓存进行了说明，但 ASP.NET 同样也给我们提供了服务器端的缓存，这种缓存前面多次提到。为了说明这点，我们先把 HTTP 协议实现的缓存放到一边，就是说我们现在使用了 Cache-Control:no-cache 标头来进行响应。当请求被 IIS 收到时，ASP.NET 会根据页面的缓存设置来决定如何响应，如果页面没有设置服务器缓存，则接下来的事情大家都是知道的；如果页面设置了服务器缓存并且缓存没有过期，则返回 200 的响应和从服务器缓存中存储的页面内容；如果页面设置了服务器缓存但缓存已经过期，则为该页面启动新的 ASP.NET 页面生命周期进行处理，然后缓存新的页面处理内容并响应到客户端。

使用 ASP.NET 开发应用程序，我们完全可以结合由 HTTP 协议实现的缓存和 ASP.NET 自身提供的缓存，具体的应用当然就得看实际的情况了。

关于 @ OutputCache 指令

对于 @ OutputCache 指令已经介绍了 Duration 和 VaryByParam 属性，与“页面输出缓存的本质”小节有关的属性还有 Location 和 NoStore 属性。NoStore 属性接受一个布尔值，如果指定为 true，则向 Cache-Control 标头添加 no-store 设置。Location 属性接受 OutputCacheLocation 枚举值之一，用于控制资源的输出缓存 HTTP 响应的位置。

成员名称	说明
Any	输出缓存可位于产生请求的浏览器客户端、参与请求的代理服务器（或任何其它服务器）或处理请求的服务器上。此值对应于 Cache-Control:public，并开启服务器端缓存。
Client	输出缓存位于产生请求的浏览器客户端上。此值对应于 Cache-Control:private，并关闭服务器端缓存。
Downstream	输出缓存可存储在任何 HTTP 1.1 可缓存设备中，源服务器除外，这包括代理服务器和发出请求的客户端。此值对应于 Cache-Control:public，并关闭服务器端缓存。
Server	输出缓存位于处理请求的 Web 服务器上。此值对应于 Cache-Control:no-cache，并开启服务器端缓存。
None	对于请求的页面，禁用输出缓存。此值对应于 Cache-Control:no-cache，并关闭服务器端缓存，这与在 ASPX 页面上不包含 @ OutputCache 指令没区别。
ServerAndClient	输出缓存只能存储在源服务器或发出请求的客户端中，代理服务器不能缓存响应。此值对于 Cache-Control:private，并开启服务器端缓存。

现在针对 @ OutputCache 指令的基本设置已经介绍完成了，有关它的更多控制细节将在下一讲中阐述，现在我们已经可以与“页面输出缓存的本质”小节中所讲述的内容结合起来，有效的控制页面输出缓存了，如果仅是应付一般的情况，到这样就基本足够了。

小结

本节初步揭开了 ASP.NET 缓存技术的面纱，介绍了开启 ASPX 页面输出缓存的基本方法，但这不是本节的重点，最需要关注的是 ASP.NET 缓存技术的实现细节，“页面输出缓存的本质”小节中对此有了说明，但限于篇幅和作者的水平，并不详尽。大家可以多多实践，并使用 Fiddler 这样的 HTTP 嗅探工具来深入研究这些细节。