HTTP请求浏览器缓存

一：HTTP请求

HTTP(HyperText Transfer Protocol)是一套计算机通过网络进行通信的规则。计算机专家设计出HTTP，使HTTP客户（如Web浏览器）能够从HTTP服务器(Web服务器)请求信息和服务，HTTP目前协议的版本是1.1.HTTP是一种无状态的协议，无状态是指Web浏览器和Web服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后Web服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP遵循请求(Request)/应答(Response)模型。Web浏览器向Web服务器发送请求，Web服务器处理请求并返回适当的应答。所有HTTP连接都被构造成一套请求和应答。

HTTP使用内容类型，是指Web服务器向Web浏览器返回的文件都有与之相关的类型。所有这些类型在MIME　Internet邮件协议上模型化，即Web服务器告诉Web浏览器该文件所具有的种类，是HTML文档、GIF格式图像、声音文件还是独立的应用程序。大多数Web浏览器都拥有一系列的可配置的辅助应用程序，它们告诉浏览器应该如何处理Web服务器发送过来的各种内容类型。

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

（1）建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80

（2） Web浏览器向Web服务器发送请求命令

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令

例如：GET/sample/hello.jsp HTTP/1.1

（3） Web浏览器发送请求头信息

浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

（4） Web服务器应答

客户机向服务器发出请求后，服务器会客户机回送应答，

HTTP/1.1 200 OK

应答的第一部分是协议的版本号和应答状态码

（5） Web服务器发送应答头信息

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

（6） Web服务器向浏览器发送数据

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

（7） Web服务器关闭TCP连接

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP请求

HTTP请求的格式如下所示：

<request-line>
<headers>
<blank line>
[<request-body>]

在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之后是一个空行，再此之后可以添加任意的其他数据[称之为主体（body）]。

在HTTP中，定义了多种请求类型，通常我们关心的只有GET请求和POST请求。只要在Web浏览器上输入一个URL，浏览器就将基于该URL向服务器发送一个GET请求，以告诉服务器获取并返回什么资源。对于www.baidu.com的GET请求如下所示：

GET / HTTP/1.1
Host: www.baidu.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

请求行的第一部分说明了该请求是GET请求。该行的第二部分是一个斜杠（/），用来说明请求的是该域名的根目录。该行的最后一部分说明使用的是HTTP 1.1版本（另一个可选项是1.0）。那么请求发到哪里去呢？这就是第二行的内容。

第2行是请求的第一个首部，HOST。首部HOST将指出请求的目的地。结合HOST和上一行中的斜杠（/），可以通知服务器请求的是www.baidu.com/（HTTP 1.1才需要使用首部HOST，而原来的1.0版本则不需要使用）。第三行中包含的是首部User-Agent，服务器端和客户端脚本都能够访问它，它是浏览器类型检测逻辑的重要基础。该信息由你使用的浏览器来定义（在本例中是Firefox 1.0.1），并且在每个请求中将自动发送。最后一行是首部Connection，通常将浏览器操作设置为Keep-Alive（当然也可以设置为其他值）。注意，在最后一个首部之后有一个空行。即使不存在请求主体，这个空行也是必需的。

要发送GET请求的参数，则必须将这些额外的信息附在URL本身的后面。其格式类似于：

URL ? name1=value1&name2=value2&..&nameN=valueN

该信息称之为查询字符串（query string），它将会复制在HTTP请求的请求行中，如下所示：

GET /books/?name=Professional%20Ajax HTTP/1.1
Host: www.baidu.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

注意，为了将文本“Professional Ajax”作为URL的参数，需要编码处理其内容，将空格替换成%20，这称为URL编码（URL encoding），常用于HTTP的许多地方（JavaScript提供了内建的函数来处理URL编码和解码）。“名称—值”（name—value）对用 & 隔开。绝大部分的服务器端技术能够自动对请求主体进行解码，并为这些值的访问提供一些逻辑方式。当然，如何使用这些数据还是由服务器决定的。

另一方面，POST请求在请求主体中为服务器提供了一些附加的信息。通常，当填写一个在线表单并提交它时，这些填入的数据将以POST请求的方式发送给服务器。

以下就是一个典型的POST请求：

POST / HTTP/1.1
Host: www.baidu.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

从上面可以发现， POST请求和GET请求之间有一些区别。首先，请求行开始处的GET改为了POST，以表示不同的请求类型。你会发现首部Host和User-Agent仍然存在，在后面有两个新行。其中首部Content-Type说明了请求主体的内容是如何编码的。浏览器始终以application/ x-www-form- urlencoded的格式编码来传送数据，这是针对简单URL编码的MIME类型。首部Content-Length说明了请求主体的字节数。在首部Connection后是一个空行，再后面就是请求主体。与大多数浏览器的POST请求一样，这是以简单的“名称—值”对的形式给出的，其中name是Professional Ajax，publisher是Wiley。你可以以同样的格式来组织URL的查询字符串参数。

下面是一些最常见的请求头：

    Accept：浏览器可接受的MIME类型。
    Accept - Charset：浏览器可接受的字符集。
    Accept - Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。
    Accept - Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
    Authorization：授权信息，通常出现在对服务器发送的WWW - Authenticate头的应答中。
    Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep - Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content - Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
    Content - Length：表示请求消息正文的长度。
    Cookie：这是最重要的请求头信息之一，参见后面《Cookie处理》一章中的讨论。
    From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
    Host：初始URL中的主机和端口。
    If - Modified - Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
    Pragma：指定“no - cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
    Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
    User - Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
    UA - Pixels，UA - Color，UA - OS，UA - CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。

HTTP响应

如下所示，HTTP响应的格式与请求的格式十分类似：

<status-line>
<headers>
<blank line>
[<response-body>]

正如你所见，在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。以下就是一个HTTP响应的例子：

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

<html>
<head>
<title>Wrox Homepage</title>
</head>
<body>
<!-- body goes here -->
</body>
</html>

在本例中，状态行给出的HTTP状态代码是200，以及消息OK。状态行始终包含的是状态码和相应的简短消息，以避免混乱。最常用的状态码有：

◆200 (OK): 找到了该资源，并且一切正常。
◆304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常用于浏览器的缓存机制。
◆401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。
◆403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。
◆404 (NOT FOUND): 在指定的位置不存在所申请的资源。

在状态行之后是一些首部。通常，服务器会返回一个名为Data的首部，用来说明响应生成的日期和时间（服务器通常还会返回一些关于其自身的信息，尽管并非是必需的）。接下来的两个首部大家应该熟悉，就是与POST请求中一样的Content-Type和Content-Length。在本例中，首部Content-Type指定了MIME类型HTML（text/html），其编码类型是ISO-8859-1（这是针对美国英语资源的编码标准）。响应主体所包含的就是所请求资源的HTML源文件（尽管还可能包含纯文本或其他资源类型的二进制数据）。浏览器将把这些数据显示给用户。

注意，这里并没有指明针对该响应的请求类型，不过这对于服务器并不重要。客户端知道每种类型的请求将返回什么类型的数据，并决定如何使用这些数据。

安全连接

Web应用最常见的用途之一是电子商务，可以利用Web服务器端程序使人们能够网络购物，需要指出一点是，缺省情况下，通过Internet发送信息是不安全的，如果某人碰巧截获了你发给朋友的一则消息，他就能打开它，假想在里面有你的信用卡号码，这会有多么糟糕，幸运的是，很多Web服务器以及Web浏览器都有创立安全连接的能力，这样它们就可以安全的通信了。

通过Internet提供安全连接最常见的标准是安全套接层(Secure Sockets layer,SSl)协议。SSL协议是一个应用层协议(和HTTP一样)，用于安全方式在Web上交换数据，SSL使用公开密钥编码系统。从本质讲，这意味着业务中每一方都拥有一个公开的和一个私有的密钥。当一方使用另一方公开密钥进行编码时，只有拥有匹配密钥的人才能对其解码。简单来讲，公开密钥编码提供了一种用于在两方之间交换数据的安全方法，SSL连接建立之后，客户和服务器都交换公开密钥，并在进行业务联系之前进行验证，一旦双方的密钥都通过验证，就可以安全地交换数据。

GET
通过请求URI得到资源
POST,
用于添加新的内容
PUT
用于修改某个内容
DELETE,
删除某个内容
CONNECT,
用于代理进行传输，如使用SSL
OPTIONS
询问可以执行哪些方法
PATCH,
部分文档更改
PROPFIND, (wedav)
查看属性
PROPPATCH, (wedav)
设置属性
MKCOL, (wedav)
创建集合（文件夹）
COPY, (wedav)
拷贝
MOVE, (wedav)
移动
LOCK, (wedav)
加锁
UNLOCK (wedav)
解锁
TRACE
用于远程诊断服务器
HEAD
类似于GET, 但是不返回body信息，用于检查对象是否存在，以及得到对象的元数据

二：HTTP请求中的浏览器缓存机制

流程

　　当资源第一次被访问的时候，HTTP头部如下

(Request-Line)  GET /a.html HTTP/1.1
Host    127.0.0.1
User-Agent  Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept              text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language     zh-cn,zh;q=0.5
Accept-Encoding     gzip,deflate
Accept-Charset      gb2312,utf-8;q=0.7,;q=0.7
Keep-Alive          300
Connection          keep-alive

HTTP返回头部如下

(Status-Line)       HTTP/1.1 200 OK
Date                Thu, 26 Nov 2009 13:50:54 GMT
Server              Apache/2.2.11 (Unix) PHP/5.2.9
Last-Modified       Thu, 26 Nov 2009 13:50:19 GMT
Etag                "8fb8b-14-4794674acdcc0"
Accept-Ranges       bytes
Content-Length      20
Keep-Alive          timeout=5, max=100
Connection          Keep-Alive
Content-Type        text/html

当资源第一次被访问的时候，http返回200的状态码，并在头部携带上当前资源的一些描述信息，如

Last-Modified      // 指示最后修改的时间
Etag                // 指示资源的状态唯一标识
Expires             // 指示资源在浏览器缓存中的过期时间

　　接着浏览器会将文件缓存到Cache目录下，并同时保存文件的上述信息

　　当第二次请求该文件时，浏览器会先检查Cache目录下是否含有该文件，如果有，并且还没到Expires设置的时间，即文件还没有过期，那么此时浏览器将直接从Cache目录中读取文件，而不再发送请求

　　如果文件此时已经过期，则浏览器会发送一次HTTP请求到WebServer，并在头部携带上当前文件的如下信息

If-Modified-Since   Thu, 26 Nov 2009 13:50:19 GMT
If-None-Match       "8fb8b-14-4794674acdcc0"

　　即把上一次修改的时间，以及上一次请求返回的Etag值一起发送给服务器。服务器在接收到这个请求的时候，先解析Header里头的信息，然后校验该头部信息。

　　如果该文件从上次时间到现在都没有过修改或者Etag信息没有变化，则服务端将直接返回一个304的状态，而不再返回文件资源，状态头部如下

(Status-Line)       HTTP/1.1 304 Not Modified
Date                Thu, 26 Nov 2009 14:09:07 GMT
Server              Apache/2.2.11 (Unix) PHP/5.2.9
Connection          Keep-Alive
Keep-Alive          timeout=5, max=100
Etag                "8fb8b-14-4794674acdcc0"

　　这样，就能够很大程度上减少网络带宽以及提升用户的浏览器体验。

　　当然，如果服务器经过匹配发现文件修改过了，就会将文件资源返回，并带上新文件状态信息。

　　基本字段

　　Pragma

　　Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。

　　Expires

　　文件在本地缓存的过期时间，如果浏览器发现缓存中的文件没有过期，则不发送请求（有例外，后面介绍）

　　Cache-Control

　　Cache -Control指定请求和响应遵循的缓存机制。

　　在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括

no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached

响应消息中的指令包括

public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age

　　各个消息中的指令含义如下：

Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

　　Etag/If-None-Match

　　一对验证文件实体的标记“Entity Tag”的响应/请求头Apache中，ETag的值，默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后得到的

　　Last-Modified/If-Modified-Since

　　一对验证文件的修改时间的响应/请求头

　　Expires、Cache-Control、Last-Modified、ETag是RFC 2616（HTTP/1.1）协议中和网页缓存相关的几个字段。

　　前两个用来控制缓存的失效日期，浏览器可通过它来判定，需不需要发出HTTP请求；

　　后两个用来验证网页的有效性，服务器端利用它来验证这个文件是否需要重新返回

　　Last-Modified VS Etag

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

　　不同的情况

　　上面描述的是一个普通的浏览器缓存状态，在实际应用中，如页面跳转（点击页面链接跳转，window.open，在地址栏敲回车，刷新页面）等操作，会有一些区别

　　普通页面跳转

　　普通页面跳转包括链接点击跳转，用js脚本打开新页面（window.open）

　　无缓存情况下，请求会返回所有资源结果

　　设置Expires并且未过期时，浏览器将不会发出http请求

　　如果Expires过期，则会发送相应请求，并附带上Last-Modifed等信息，供服务器校验

　　页面刷新(F5)

　　这种情况一下，一般会看到很多304的请求，就是说即便资源设置了Expires且未过期，浏览器也会发送相应请求

　　IE和FF稍有区别

　　IE:

If-Modified-Since   Wed, 18 Nov 2009 15:54:52 GMT
If-None-Match   "2360492659"
Pragma: no-cache    // 禁止缓存

　　FF:

If-Modified-Since   Wed, 18 Nov 2009 15:54:52 GMT
If-None-Match   "2360492659"
Cache-Control   max-age=0   // 文件立即过期

　　强制刷新(Ctrl+F5)

　　效果和无缓存时候一致，返回200的结果

　　一些特殊的资源

　　IFRAME

　　FLASH

　　异步获取的数据

　　待研究……

主要参考：http://www.cnblogs.com/yin-jingyu/archive/2011/08/01/2123548.html

http://blog.csdn.net/kfanning/article/details/6062118

http://kb.cnblogs.com/page/73901/