代理缓存，也就是众所周知的Web代理或Web缓存，它是将客户端和服务端连接在一起的，作为用户和
Web服务器的中间人。当客户端浏览器通过代理发起一个Http请求时，响应可以直接来自代理中缓存
的内容，或代理先从目标服务器获取响应，然后将其发送给客户端，也许在这个过程中还会缓存该响
应。
代理也有可能与用户的电脑位于同一个地方，比如在一个公司环境中，或在一个ISP中。前一种情况
下，代理通常是可见的，而在后一种情况下往往是透明的。可见代理的意思是浏览器知道它的存在，
并显示的通过它发送HTTP请求。透明代理意味着浏览器不知道它的存在，它会透明的拦截所有到达80
端口(HTTP)的TCP连接，而不管目标IP地址是什么
从性能的角度看，代理很有帮助，因为它们可以在与用户更近的位置缓存内容。如果代理中保存了这
些内容，与从源Web服务器分发这些内容相比，它会带来更高的分布带宽，更少的延迟。如果内容不
在代理中，那么延迟就会增加，因为代理必须将HTTP请求发送给Web服务器。
安装代理的其他目的还包括减少带宽的需求，以及应用各种类型的过滤和日志的能力。
你应该合理地规划网站，让代理可以尽可能的缓存内容。缓存帮助网站的方式和它帮助用户的方式类
似：提高性能(将网站的工作负载转移)并且减少带宽的使用。
代理首先是通过评估HTTP响应头确定缓存哪些内容的。HTTP1.1标准提供了一些关于缓存的准则，但
是大多数代理在它们的决策过程中还实现了一系列试探法。你可以通过设置HTTP头来清晰地表明意图
以去除歧义。
代理不会缓存SSL请求的响应，或使用HTTP PUT、DELETE或TRACE请求的响应。代理不会缓存临时的跳
转响应或Post请求的响应，除非该响应的HTTP头显式表明应该缓存。
尽管有少数代理仍然只支持HTTP1.0,但根据我的经验，它们大多是私有代理，而不是公用代理。其他
HTTP1.0请求的主要来源大多是来自不常见的蜘蛛或其他罕见情况。因为潜在的安全性和网站的性能
问题，如果现在创建一个大型网站，我或许会阻止所有HTTP1.0请求。因为这类请求的数量非常少，
阻止它们可以将有限的资源用在更有效、更有影响的领域，这要比实现并测试HTTP1.0兼容性更划算
。
①使用Cache-Control HTTP头
在代理中控制缓存的主要HTTP头是Cache-Control。当设置为private时，代理不会缓存
该响应。当设置为public时，代理可以缓存该响应，虽然这不是必须的。
ASP.NET运行时默认将所有动态内容标记为Cache-Control:private所有代理不会缓存它们。它们通过
将其标记为Cache-Control:piblic。为动态内容覆盖该设置，让内容对于所有用户都是一样的。下面
的示例配置Cache-Control头，告诉代理和浏览器可以缓存页面60秒。
Protected void Page_Load(object sender,EventArgs e)
{
TimeSpan age=TimeSpan.FromSeconds(60.0);
This.Response.Cache.SetMaxAge(age);
This.Response.Cache.SetCacheability(HttpCacheability.public);
This.Response.Cache.SetNoServerCaching();
}
调用SetCacheability(HTTPCacheability.public)，除了可以打开客户端和代理缓存外，还可以打开
服务器端输出缓存。SetServerNoCaching()关闭服务器端缓存，不会影响客户端和代理缓存。
可以使用OutputCache指令，通过声明的方式达到相同的目的
<% @page. . .%>
<%@ OutputCache Duration=”60” Location=”Downstream” VaryByparm=”None” %>
将Location设置为Any(默认)效果相似，但必须禁用服务器缓存。通常，如果页面可以存储在代理缓
存里，那它也可以存储在服务器缓存里。
1.使用Cookie和代理
当在公共的页面上设置Cookie时要谨慎。即使该页面的内容对于所有用户都是一样的，但
Cookie也许不是。随缓存的内容一起，代理还会缓存响应的HTTP头，这包括Set-Cookie.尽管有代理
不会缓存包含有Cookie的响应，但是有些代、代理会，特别是在该响应包含用户特别的Cookie时会带
来安全性漏洞，因为代理可能会将缓存的Cookie 分布给一个不是你期望的用户。
由于这个限制，应该再三考虑在频繁被引用的页面(比如主页)上设置Cookie，因为这可能会阻止代理
缓存这些页面。实际上，如果设置Cookie，ASP.NET会关闭所有输出缓存，以避免将一个用户Cookie
发送给其他用户的这种意外情况。这是只在真正需要Cookie时才设置它的另一理由。特别地，不要直
接地为每个页面设置回话Cookie。如果使用内置的会话机制，ASP.NET在没有在Session对象中存储任
何东西之前不会设置Cookie.
运行时会强制在那些要求身份验证的页面使用Cache-Control:private,以阻止意外将私有内容缓存在
共有代理上。
2.静态内容
如果为静态文件分配一个过期时间，那么结果的头一般会允许代理缓存它们，而不用任何其他操作
。
但是，也有充分的个案促使你为静态内容标记Cache-Control:public。比如，没有该头时，有些代理
不会缓存响应，如果该请求包含Cookie 或 URL包含查询字符串。可以为静态内容生成该头。
代理不会缓存的内容客户端也不会缓存，通过设置Cache-Control:no-cache同时阻止代理和客户端缓
存。
②管理相同内容不同版本
可以指示代理保存相同内容的多个不同版本，如果这些不同版本可以根据HTTP请求头区别出来。比如
，Accept-Language 头指定了用户的语言首选项。这就告诉代理不应该为不用语言首选项缓存该内容
的不同版本，可以通过调用SetVaryByCustom()做到：
This.Response.Cache.SetVaryByCustom(“Accept-Language”);
将HTTP 头 vary设置为Accept-Language.
使用Vary: *是特殊情况，这是告诉代理必须考虑不同的响应，但与请求头无关。Vary:*或
Vary:Cookie都是很有用的深度防御技术，他们的响应都不应该被缓存，这样可以避免偶然将用户专
有的内容保存在代理上。深度防御是使用多种不同的技术，在一种分层的方法中防御攻击或修补漏洞
的一种策略。
在某些情况下，运行时会自动设置Vary头。比如，当启用压缩时会设置Vary:Accept-Encoding.
本文由上海蓝友信息科技有限公司(www.lanyousoft.com)提供，转载请注明出处，谢谢!