HTTP缓存控制参数.docx

HTTP缓存控制参数.docx

《HTTP缓存控制参数.docx》由会员分享，可在线阅读，更多相关《HTTP缓存控制参数.docx（8页珍藏版）》请在冰点文库上搜索。

HTTP缓存控制参数

万维网架构用超文本技术HTML实现信息与信息的连接，用统一资源标志符URI实现全球信息的精确定位，用应用层协议HTTP实现分布式的信息共享。

HTTP超文本传输协议描述了Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户的过程和相关消息。

一个HTTP请求和响应的基本过程是当用户通过点击某个HTML页面中的超链接或者直接在浏览器中输人网址来请求一个Web页面时，浏览器把该页面中各个对象的HTTP请求消息发送给服务器，服务器收到请求后，将这些对象包含在HTTP响应消息中作为响应反馈给服务器。

通常情况下HTTP协议由TCP传输协议承载，现网中大量HTTP连接还需要经过TLS或者SSL层封装，架构在SSL层之上的HTTP协议通常称为HTTPS（HypertextTransferProtocoloverSecureSocketLayer）协议。

HTTP浏览器首先发起建立与服务器的TCP连接，连接建立，客户端和服务器的HTTP进程就可以通过各自的套接字（Socket）来访问下层的TCP进程。

客户端可以通过套接字发送HTTP清求消息也可以从自己的套接字接收HTTP响应消息;服务器从自己的套接字接收HTTP请求消息也可以往自己的套接字发送HTTP响应消息。

客户端或服务器端HTTP进程一旦把某个消息送入各自的套接字，这个消息就由TCP进程来控制发送。

TCP给HTTP提供一个可靠的数据传输服务。

HTTP协议是一个无状态的协议，即客户端向服务器端发送出请求时，服务器并没有存储关于该客户端和请求的任何状态信息。

即便同个客户端在几秒钟内再次请求同一个对象，服务器也不会响应说自己刚刚给它发送了这个对象。

相反，服务器会重新发送这个对象，因为它并没有存储该客户端的任何状态信息，同一个客户端的多次请求之间没有任何关系。

HTTP协议是一个标准的‘请求+响应”协议，即客户端与服务器建立连接后，就向服务器发送一个HTTP请求，HTTP协议规定请求消息中包含请求方法，如获取某个对象、删除某个对象，统一资源标识符（操作对象的位置和名称），HTTP协议版本以及其它相关信息。

服务器收到请求消息后发送响应消息，响应消急中包含了HTTP协议版本、成功或者错误的代码以及其它相关信息。

HTTP协议定义了各种各样的缓存控制方法，缓存可以按照以下的基本原则工作：

如果响应消息的头信息告诉缓存不要保留副本，缓存就不会缓存相应内容。

如果请求信息需要源服务器认证或者涉及安全协议，相应的请求内容也不会被缓存。

如果缓存的内容含有以下信息，内容将会被认为是足够新的，因此不需要从源服务器重新获取内容

1）含有过期时间和寿命信息。

并且此时内容仍没有过期。

2）缓存内容近期被用来提供过服务，并且内容的最后更新时间相对于最近使用的时间较久。

如果缓存的内容已经过期，缓存服务器将向源服务器发出验证请求（通过ETag头信息或者Lest-Modified头信息），用于确定是否可以继续使用当前内容直接提供服务。

在某些情况下（比如源服务器从网络中断开了），缓存的内容在过期的情况下也可以直接提供服务。

如果在响应消息中不存在用于判断内容是否变化的验证值（ETag头信息或者Last-Modified头信息），并月也没有其他任何明显的新鲜度信息，内容通常不会被缓存。

以上原则告诉我们新鲜度和验证是确定内容是否可直接提供服务的最重要依据。

如果缓存内容足够新鲜，缓存的内容就能直接满足HTTP访问的需求了;如果内容过期，而经源服务器验证后发现内容没有发生变化，缓存服务器也会避免将内容从源服务器重新传输一遍。

一、常用控制缓存参数：

（1）HTMLMETA标签和HTTP头信息HTML文件的编写者会在文档的区域中加人描述文档的各种属性，这些META标签常常被用于标记文档可不可以被缓存或者标记多长时间后过期。

META标签使用很简单，但是效率并不高，因为能够读懂这个标记的浏览器只有少数几种，同时由于中间缓存几乎完全不解析文档中的HTML内容，所以也没有什么中间缓存（代理缓存和网关缓存）能读懂这个规则。

如果要通过META标签来控制页面不缓存，一般情况下会在Web页面的区域中增加“Poagma:

no-cache”的META标记。

（2）使用Expires（过期时间）头信息来控制保鲜期，通常情况下，主要通过HTTP头信息来指示缓存和控制内容是否缓存。

这些控制信息在HTML代码中是看不见的，一般由Web服务器自动生成，并在HTTP消息中进行标识。

Expires方式是HTTP控制缓存的基本手段，这个属性告诉缓存相关内容在多长时间内是新鲜的。

过了这个时间，如果客户端向缓存请求这个内容，缓存就会向源服务器发送请求，检查文档是否发生了变化。

几乎所有的缓存服务器都支持Expires方式。

大部分Web服务器设置Expires方式有多种，最常用的是设置成一个绝对的时间值，比如将内容最后被修改的时间点加上一个特定的时间段（比如1个小时）所得到的时间值。

Expires头信息对于控制静态图片文件的缓存特别有用，因为这些图片修改很少，可以给它们设置一个特别长的过期时间，这样会使得你的网站访问速度非常快。

Expire，头信息属性值只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，即表示此内容已经过期，HTTP的日期时间必须是格林尼治时间（OMT），而不是本地时间。

虽然过期属性非常有用，但它还是有些局限，首先是源服务器的时间和中间缓存的时间必须是同步的。

如果彼此不同步，则会出现应该缓存的内容提前过期了、或者已经过期的结果没有及时更新。

其次是过期时间的设置也存在一定的问题。

如果设置的过期时间是一个固定的时间，而返回内容的时候没有更新下次过期的时间，那么之后所有访问请求都需要重新发给源Web服务器，这样反而增加了服务器的负载以及响应时间。

（3）验证在NTTP1.1中对缓存提出了验证的概念，验证的目的就是检验缓存内容是否可用。

当中间缓存存在一个过期的缓存内容，并且对应的访问请求到达时，缓存应该首先向源服务器或者其他保存有未过期的缓存服务器请求验证来确定本地的缓存内容是否可用。

这个过程就是一个缓存消息的验证过程。

HTTP1.1把这种验证后再决定是否返回消息内容的方式叫“有条件”的请求返回方法，这样可以避免从源服务器或其他缓存服务器获取整个内容的信息，从而减少网络流量。

当源服务器生成了一个完整的响应消息时，它会附带一个验证信息，中间缓存在缓存内容时可以保存这个验证信息，当缓存内容过期以后，中间缓存可以使用它生成一个“有条件”的请求来向源服务器请求验证。

而源服务器或者在与源服务器通信的路径上的其他缓存服务器（如果保存有未过期的内容）在收到这样的请求以后就可以将请求中包含的验证信急与自己本地的验证信息进行比较。

如果两个验证信息相等，那么返回一个带有特定状态码（比如304NotModified,表示内容未修改过）且消息主体内容为空的响应消息，在这种情况下就减少了网络流量;如果两个验证信息不相等就需要传输一个包含新内容的完整响应消息。

（4）Cache-Control（缓存控制）HTTP头信息，指定过期时间和验证是HTTP1.1的基本缓存机制，也是缓存的隐含指令。

但是在某些情况下，服务器或客户端可能需要给HTTP缓存提供显式的指令。

Cache-Control响应头信息包括如下几项：

max-age缓存内容保持新鲜状态的最长时间。

这个属性类似于过期时间，是基于请求时间的相对时间间隔，而不是绝对过期时间，单位是秒，即从请求时间开始到过期时间之间的秒数。

s-maxage类似于max-age属性，它应用于共享缓存。

public此属性标记认证内容也可以被缓存，一般来说，经过HTTP认证才能访问的内容是默认不能缓存的。

no-cache强制将每次访问请求直接发送给源服务器，而不经过中间缓存进行前面提到的验证。

这对那些需要在源服务器进行用户认证的应用非常有用，也适用于那些严格要求使用最新数据的应用。

no-store强制缓存在任何情况下都不要缓存任何内容。

must-revalidate告诉缓存必须遵循源服务器赋予的内容新鲜度。

由于HTTP允许缓存在某些特定情况下返回过期数据，所以通过指定这个属性，源服务器可以告诉缓存，如果缓存内容处于过期状态，则在对访问请求进行响应前必须到源服务器进行重新验证。

proxy-revalidate,proxy-revalidate和must-revalidate基本相同，只是它不能应用于非共享的代理缓存。

它允许在客户端缓存中保存那些经过权限认证的响应消息（包含有"public'来保证它们可以被缓存），在缓存内容没有过期之前，遇到相同的访问请求则可以返回缓存的数据而无须经过源服务器的验证，如果内容过期则仍需经过服务器重新验证。

对于服务于多个用户的代理缓存来说，为了保证每个用户都是被授权的，仍需每次都去服务器进行验证〔这样的授权响应同样需要使用public指令来允许它们能够被缓存）。

（5）PragmaHTTP头信息，除了以上提到的几种典型缓存控制机制以外，还有一种使用PragmaHTTP头信息的方式。

Pragma属于通用头，用来包含特定的执行指令。

这些指令可以适应于客户端、代理、网关、源服务器中的任何接收者，但是HTTP协议中认为Pragma指令规定的行为是可选的。

当"Pragma:

no-cache'’出现在请求消息中时，即使缓存设备中缓存了此请求响应所需的内容，也会直接将此请求转发到源服务器上。

虽然在HTTP1.1中提到了通过Pragma控制缓存的方法，但这主要是为了向HTTP1.0兼容，因为支待HTTP1.0的缓存主要还是通过这种方法来控制内容缓存的。

HTTP1.1中主要还是通过前面讲到的Cache-Control头信息来控制缓存，所以协议要求当一个HTTP1.1的请求从客户端发出时，既应该包含Pragma指令，也应该包含Cache-control的控制指令，这样请求从客户端发给源服务器的过程中，分别支持HTTP1.1和HTTP1.0的缓存设备都可以读懂指令的信息。

如果发送请求的客户端本身只支持HTTP1.0,那么支持HTTP1.1的中间缓存在收到请求消息后必须以Pragma中的指令来控制缓存。

很多人认为在HTTP头信息中设置了“Pragma.：

no-cache"后会让内容无法被缓存。

但事实并非如此，HTTP的规范并没有任何关于响应信息头Pragma属性的说明，而讨论的都是请求头信息的Pragma属性，即头信息由浏览器发送给服务器，实际上只有少数几种缓存服务器会遵循请求消息中的这个头信息。

所以，在很多情况下，使用Pragma属性不一定管用。

二、缓存内容更新机制

一般来说，WebCache会遵循以下基本规则进行内容更新：

（1）如果HTTP响应头信息告诉Cache不要缓存，那么Cache就不会缓存相应内容。

（2）如果对某内容的请求信息是需要认证或者安全加密的，Cache也不会缓存相应内容。

（3）如果在HTTP响应中没有ETag或者Last-Modified头信息，Cache会认为缺乏直接的更新度信息。

默认该内容不可缓存。

（4）一个缓存的副本如果含有以下信息，Cache会认为它是足够新的，会直接从缓存中送出，而不会向源服务器发送请求：

✓含有完整的过期时间和寿命控制的头信息，并且内容仍在生存期内。

✓浏览器已经使用过这个缓存副本，并且在同一个会话中已经检查过内容的新鲜度。

（5）如果缓存的内容副本已经旧了，Cache将向源站服务器请求校验，用于确定是否可以继续使用当前副本继续服务。

如果经校验后发现副本的原件没有变化，Cache会避免从源站服务器重新获取副本。

内容更新需要对内容进行校验，HTTP1.1把这种验证后再决定是否返回消息内容的方式叫“有条件，，的请求返回方法。

校验的工作原理如下

（1）源站服务器向Cache返回内容响应消息时，会附带一个验证信息，Cache在缓存内容时保存这个验证信息。

（2）当有用户请求该内容时，如果Cache发现缓存内容过期，就使用验证信息生成一个“有条件”的请求来向源服务器请求验证。

（3）源服务器在收到这样的请求以后，将请求中包含的验证信息与自己本地的验证信息进行比较。

如果两个验证信息相等.那么返回一个带有特定状态码（比如304NotModiFed,表示内容未修改过）且消息主体内容为空的响应消息，表示副本可以继续使用;如果两个验证信息不相等，源站服务器就会向Cache传输一个包含新内容的完整响应消息。

前面提到了“有条件”的请求，其实所谓‘有条件”的请求和普通的请求是一样的，只是它包含了一个特殊的验证信息。

并且“有条件”的验证包括正验证和负验证，如果请求中要求服务器与消息附带的验证信息必须相等（使用请求消息的“If-Match”头）的则是正验证，如果要求两者不相等（使用请求消息的“If-None-Match”头）的是负验证。

HTTP1.1协议描述的验证信息主要包括Last-Modified和EntityTag两种，分别对应了“Last-Modified”和“ETag”两个头信息，其中“Last-ModiFed”属于实体头，ETag属于响应头。

通常，不管是“Last-Modified”还是“Etag”，这些验证信息都是由源服务器在产生实体内容或者内容更新时一起产生的，然后在返回内容时一起返回给提出请求的Cache。

在对内容是否发生变化进行验证时，如果缓存内容在标识的时间之后没有被修改过，一种有效的验证信息一般则认为它是有效的。

所以Last-Modified是一种有效的验证信息，一般“Last-Modified”头的值可以被包含在请求头“If-Modified-Since”和“If-Unmodified-Since”，中。

“Last-Modified”在时间精度上有一定的缺陷，因为HTTP协议的时间值是以秒为单位的，如果一个响应消息在一秒内被修改了两次，那么通过这个来验证某个内容是否发生变化就不准确了。

在这种情况下可以用另外一个验证信息"ETag"。

"ETag"可以由源服务器指定计算方法，根据访问的内容来生成，它是一个不透明的验证信息。

请求消息在要求源服务器进行验证时，可以将"ETag"的值包含在请求头"If-Match"、"If-None-Match"或'If-Range'中。

验证可以分为强验证或弱验证。

强验证是要验证所访问内容的每一个字节都没有变化，因为有任何的变化都会使相应的验证信息发生变化;而弱验证只验证所访问内容的语义有没有发生大的变化，验证信息只有在内容语义有明显改变时才会发生变化。

弱验证信息可以应用于不要求精确一致的情况下，通常一个访问内容的修改时间可以被认为是弱验证信息。

强验证信息应用比较广泛，比如使用ETag，儿乎所有的场合都可以用。

如果用户提交的请求只需要验证实体内容的一部分是否发生了改变，那次应该使用强验证以获得正确的数据。

标准的缓存消息头

●Etag,Cache-Control,Age是标准的缓存消息头，用于控制内容的缓存策略。

●Cache-Control:

max-age=0,s-maxage=0,private,must-revalidate

●Cache-Control消息头可包括一组控制变量，具体包括：

1）max-age：

这个参数告诉浏览器将页面缓存多长时间，超过这个时间后才再次向服务器发起请求检查页面是否有更新。

对于静态的页面，比如图片、CSS、Javascript，一般都不大变更，因此通常我们将存储这些内容的时间设置为较长的时间，这样浏览器会不会向浏览器反复发起请求，也不会去检查是否更新了。

2）s-maxage：

这个参数告诉缓存服务器（proxy，如Squid）的缓存页面的时间。

如果不单独指定，缓存服务器将使用max-age。

对于动态内容（比如文档的查看页面），我们可告诉浏览器很快就过时了（max-age=0），并告诉缓存服务器（Squid）保留内容一段时间（比如，s-maxage=7200）。

一旦我们更新文档，我们将告诉Squid清除老的缓存版本。

3）must-revalidate：

这告诉浏览器，一旦缓存的内容过期，一定要向服务器询问是否有新版本。

4）proxy-revalidate：

proxy上的缓存一旦过期，一定要向服务器询问是否有新版本。

5）no-cache：

不做缓存。

6）no-store：

数据不在硬盘中临时保存，这对需要保密的内容比较重要。

7）public：

告诉缓存服务器,即便是对于不该缓存的内容也缓存起来，比如当用户已经认证的时候。

所有的静态内容（图片、Javascript、CSS等）应该是public的。

8）private：

告诉proxy不要缓存，但是浏览器可使用privatecache进行缓存。

一般登录后的个性化页面是private的

9）no-transform:

告诉proxy不进行转换，比如告诉手机浏览器不要下载某些图片。