最快的办法，不是去啃书，而是多看大网站的http头。
Keep-Alive:
HTTP是一个请求<->响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端->服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和编程实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。
Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。市场上 的大部分Web服务器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连 接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep- Alive功能对资源利用的影响尤其突出。 此功能为HTTP 1.1预设的功能，HTTP 1.0加上Keep-Aliveheader也可以提供HTTP的持续作用功能。
Keep-Alive: timeout=5, max=100
timeout：过期时间5秒（对应httpd.conf里的参数是：KeepAliveTimeout），max是最多一百次请求，强制断掉连接
就是在timeout时间内又有新的连接过来，同时max会自动减1，直到为0，强制断掉。见下面的四个图，注意看Date的值（前后时间差都是在5秒之内）！
HTTP/1.0
在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接
HTTP/1.1
在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close ，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它
Not reliable（不可靠）
HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果
Keep-Alive和POST
在HTTP1.1细则中规定了在一个POST消息体后面不能有任何字符，还指出了对于某一个特定的浏览器可能并不遵循这个标准（比如在POST消息体的后面放置一个CRLF符）。而据我所知，大部分浏览器在POST消息体后都会自动跟一个CRLF符再发送，如何解决这个问题呢？根据上面的说明在POST请求头中禁止使用Keep-Alive，或者由服务器自动忽略这个CRLF，大部分服务器都会自动忽略，但是在未经测试之前是不可能知道一个服务器是否会这样做。
Keep-Alive 在 Java实现--客户端
在客户端，Java抽象了Keep-Alive，和程序员分享离开来，HttpURLConnection类自动实现了Keep-Alive，如果程序员没有介入去操作Keep-Alive，Keep-Alive会通过客户端内部的一个HttpURLConnection类的实例对象来自动实现。也就是说，在java中keep-alive是由一个Java类库来实现的，但在其他类库中不一定可用。
Keep-Alive 在Java实现--服务器端
在服务器端，Java依然是将Keep-Alive抽象出来，HttpServlet、HttpServletRequest、和HttpServletResponse类自动实现 了Keep-Alive。这种情况下一些由第三方控制的操作是可能的，如在KeepAliveServlet中提到的JavaWebServer，Keep-Alive是否启用由两个因素决定，内容长度和输出大小，如果内容长度是响应的一部分（即这段内容长度输出后还有内容需要输出），则Keep-Alive被启用（当然需要客户端支持的情况下）；如果内容长度未设定，则Servlet会试着计算响应缓冲区长度以确定内容长度，在Javasoft实现中，使用一个4KB的缓冲区（相当于上面说的响应）。也就是说如果内容长度未设定，并且返回数据超过4KB，此时相当于内容长度大于响应长度，而不是响应长度一部分，Keep-Alive就不会被启用 。
================================================================================
指定“Vary: Accept-Encoding”标头
概览
指定Vary: Accept-Encoding标头可告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。
由于一些公共代理的错误，可能会导致你的压缩版本资源被服务到不支持压缩的用户。指定Vary: Accept-Encoding标头可指示代理来存储压缩和非压缩的版本资源。
指定标头“Vary:Accept-Encoding”的重要意义
指定“Vary: Accept-Encoding”标头，用一句话来说明它的意义，就是“告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。”不过我想很多人都不理解这句话是什么意思，所以需要更详细的解释。请移步到：标头“Vary:Accept-Encoding”指定方法及其重要性分析
标头“Vary:Accept-Encoding”的指定方法
Apache/.htaccess
- <IfModule mod_headers.c>
- <FilesMatch ".(js|css|xml|gz|html)$">
- Header append Vary: Accept-Encoding
- </FilesMatch>
- </IfModule>
Nginx
- gzip_vary on
IIS
在web.config里加上如下配置，web.config位置在：%windir%\Microsoft.NET\Framework\.net版本号\CONFIG\Web.config 。
- <system.webServer>
- <httpProtocol>
- <customHeaders>
- <remove name="Vary"></remove>
- <add name="Vary" value="Accept-Encoding"></add>
- </customHeaders>
- </httpProtocol>
- </system.webServer>
================================================================================
P3P是一种被称为个人隐私安全平台项目（the Platform for Privacy Preferences）的标准，能够保护在线隐私权，使Internet冲浪者可以选择在浏览网页时，是否被第三方收集并利用自己的个人信息。
Date : Tue, 11 Aug 2015 00:27:59 GMT
Location : http://www.taobao.com/
Location : https://www.baidu.com/
Content-Type : text/html; charset=gbk
Content-Length : 258
Connection : keep-alive
Cache-Control : max-age=120
Expires : Tue, 11 Aug 2015 00:34:40 GMT
Age : 17
Content-Encoding : gzip
Via : http/1.1 zats-101518467 (zcache-101518467 [cRs f ])
Transfer-Encoding : chunked
================================================================================
via 值为: 下面是一些Demo
WTP/1.1 GDSZ-PS-GW010-WAP05.gd.chinamobile.com (Nokia WAP Gateway 4.0 CD3/ECD13_C/NWG4.0 CD3 ECD13_C 4.1.03)
下面是解释
列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用
什么协议（和版本）发送的请求。
当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面
添加 Via 头部，并填上自己的相关信息，当下一个代理服务器 收到第一个代理
服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via
头部，并把自己的相关信息加到后面， 以此类推，当 OCS 收到最后一个代理服
务器的请求时，检查 Via 头部，就知道该请求所经过的路由。
例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)
================================================================================
HTTP 协议中 Vary 的一些研究
文章目录
经常抓包看 HTTP 请求的同学应该对 Vary 这个响应头字段并不陌生，它有什么用？用 PageSpeed 工具检查页面时，经常看到「Specify a Vary: Accept-Encoding header（请指定一个 Vary: Accept-Encoding 标头）」这样的建议，为什么要这样做？本文记录我对 Vary 的一些研究，其中就包含这些问题的答案。
HTTP 内容协商
要了解 Vary 的作用，先得了解 HTTP 的内容协商机制。有时候，同一个 URL 可以提供多份不同的文档，这就要求服务端和客户端之间有一个选择最合适版本的机制，这就是内容协商。
协商方式有两种，一种是服务端把文档可用版本列表发给客户端让用户选，这可以使用 300 Multiple Choices 状态码来实现。这种方案有不少问题，首先多一次网络往返；其次服务端同一文档的某些版本可能是为拥有某些技术特征的客户端准备的，而普通用户不一定了解这些细节。举个例子，服务端通常可以将静态资源输出为压缩和未压缩两个版本，压缩版显然是为支持压缩的客户端而准备的，但如果让普通用户选，很可能选择错误的版本。
所以 HTTP 的内容协商通常使用另外一种方案：服务端根据客户端发送的请求头中某些字段自动发送最合适的版本。可以用于这个机制的请求头字段又分两种：内容协商专用字段（Accept 字段）、其他字段。
首先来看 Accept 字段，详见下表：
| 请求头字段 | 说明 | 响应头字段 |
|---|---|---|
| Accept | 告知服务器发送何种媒体类型 | Content-Type |
| Accept-Language | 告知服务器发送何种语言 | Content-Language |
| Accept-Charset | 告知服务器发送何种字符集 | Content-Type |
| Accept-Encoding | 告知服务器采用何种压缩方式 | Content-Encoding |
例如客户端发送以下请求头：
BASHAccept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:zh-CN,en-US;q=0.8,en;q=0.6
表示它可以接受任何 MIME 类型的资源；支持采用 gzip、deflate 或 sdch 压缩过的资源；可以接受 zh-CN、en-US 和 en 三种语言，并且 zh-CN 的权重最高（q 取值 0 - 1，最高为 1，最低为 0，默认为 1），服务端应该优先返回语言等于 zh-CN 的版本。
浏览器的响应头可能是这样的：
BASHContent-Type: text/javascript
Content-Encoding: gzip
表示这个文档确切的 MIME 类型是 text/javascript；文档内容进行了 gzip 压缩；响应头没有 Content-Language 字段，通常说明返回版本的语言正好是请求头 Accept-Language 中权重最高的那个。
有时候，上面四个 Accept 字段并不够用，例如要针对特定浏览器如 IE6 输出不一样的内容，就需要用到请求头中的 User-Agent 字段。类似的，请求头中的 Cookie 也可能被服务端用做输出差异化内容的依据。
由于客户端和服务端之间可能存在一个或多个中间实体（如缓存服务器），而缓存服务最基本的要求是给用户返回正确的文档。如果服务端根据不同 User-Agent 返回不同内容，而缓存服务器把 IE6 用户的响应缓存下来，并返回给使用其他浏览器的用户，肯定会出问题 。
所以 HTTP 协议规定，如果服务端提供的内容取决于 User-Agent 这样「常规 Accept 协商字段之外」的请求头字段，那么响应头中必须包含 Vary 字段，且 Vary 的内容必须包含 User-Agent。同理，如果服务端同时使用请求头中 User-Agent 和 Cookie 这两个字段来生成内容，那么响应中的 Vary 字段看上去应该是这样的：
Vary: User-Agent, Cookie
也就是说 Vary 字段用于列出一个响应字段列表，告诉缓存服务器遇到同一个 URL 对应着不同版本文档的情况时，如何缓存和筛选合适的版本。
有 BUG 的缓存服务
再来看 PageSpeed 的「Specify a Vary: Accept-Encoding header」这个提示，按照上面的说明，Accept-Encoding 属于内容协商专用字段，服务端只需要在响应头中增加 Content-Encoding 字段，用来指明内容压缩格式；或者不输出 Content-Encoding 表明内容未经过压缩就可以了。而缓存服务器，应该针对不同的 Content-Encoding 缓存不同内容，再根据具体请求中的 Accept-Encoding 字段返回最合适的版本。
但是有些实现得有 BUG 的缓存服务器，会忽略响应头中的 Content-Encoding，从而可能给不支持压缩的客户端返回缓存的压缩版本。有两个方案可以避免这种情况发生：
- 将响应头中的 Cache-Control 字段设为 private，告诉中间实体不要缓存它；
- 增加 Vary: Accept-Encoding 响应头，明确告知缓存服务器按照 Accept-Encoding 字段的内容，分别缓存不同的版本；
通常为了更好的利用中间实体的缓存功能，我们都用第二种方案。
对于 css、js 这样的静态资源，只要客户端支持 gzip，服务端应该总是启用它；同时为了避免有 BUG 的缓存服务器给用户返回错误的版本，还应该输出 Vary: Accept-Encoding。
Nginx 和 SPDY
通常，上面说的这些工作，Web Server 都可以帮我们搞定。对于 Nginx 来说，下面这个配置可以自动给启用了 gzip 的响应加上 Vary: Accept-Encoding：
gzip_vary on;
用 curl 验证我博客的 js 文件，响应头如下：
BASH[email protected]:~$ curl --head http://imququ.com/.../xx.js
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 31 Dec 2013 16:34:48 GMT
Content-Type: application/x-javascript
Content-Length: 66748
Last-Modified: Tue, 31 Dec 2013 14:30:52 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "52c2d51c-104bc"
Expires: Fri, 29 Dec 2023 16:34:48 GMT
Cache-Control: max-age=315360000
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes
可以看到，服务端正确输出了「Vary: Accept-Encoding」，一切正常。
但是用 Chrome 自带抓包工具看下，这个响应头却是这样：
BASHHTTP/1.1 200 OK
cache-control: max-age=315360000
content-encoding: gzip
content-type: application/x-javascript
date: Tue, 31 Dec 2013 16:35:27 GMT
expires: Fri, 29 Dec 2023 16:35:27 GMT
last-modified: Tue, 31 Dec 2013 14:30:52 GMT
server: nginx
status: 200
strict-transport-security: max-age=31536000
version: HTTP/1.1
我的博客支持 SPDY/2 协议，用 Chrome 访问我博客会走 SPDY，所以上面的响应头看上有点不同寻常，例如字段名都变成了小写；多了 status、version 等字段，这些变化下次专门介绍（注：见「SPDY 3.1 中的请求 / 响应头」）。神奇的是尽管服务端没任何变化，但响应中的 Vary: Accept-Encoding 却不见了。
SPDY 规定客户端必须支持压缩，这意味着 SPDY 服务器可以直接启用压缩而不用关心请求头中的 Accept-Encoding 字段。下面这段来自 Nginx 支持的 SPDY/2 协议：
User-agents are expected to support gzip and deflate compression. Regardless of the Accept-Encoding sent by the user-agent, the server may select gzip or deflate encoding at any time. [via]
于是，对于支持 SPDY 的客户端来说，Vary: Accept-Encoding 没有用途，Nginx 选择直接去掉它，可以节省一点流量。curl 或其他不支持 SPDY 协议的客户端还是走 HTTP 协议，所以看到的响应头是常规的。
Nginx 的这个做法是否合适一直有争论，实际上并不是所有支持 SPDY 的 Web Server 都会这么做。例如即使通过 SPDY 协议访问 Google 首页的 js 文件，依然可以看到 vary: Accept-Encoding：
BASHHTTP/1.1 200 OK
status: 200 OK
version: HTTP/1.1
age: 25762
alternate-protocol: 443:quic
cache-control: public, max-age=31536000
content-encoding: gzip
content-length: 154614
content-type: text/javascript; charset=UTF-8
date: Tue, 31 Dec 2013 23:23:51 GMT
expires: Wed, 31 Dec 2014 23:23:51 GMT
last-modified: Mon, 16 Dec 2013 21:54:35 GMT
server: sffe
vary: Accept-Encoding
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
另外，现阶段 Chrome 和 Firefox 都支持 SPDY 协议，但 PageSpeed Chrome 版和 Firefox 版都没有针对 SPDY 协议做特别处理，所以用它们测试我的博客，还是会提示「Specify a Vary: Accept-Encoding header」，这有点让人哭笑不得。不过 PageSpeed 在线版 已经更新规则，估计扩展版也快了。
PS：Vary 在 IE 下有很多坑，使用时要格外小心。网上这部分文章比较多，例如 hax 早年写的 IE 与 Vary 头，可以点过去了解下。
================================================================================
Expires是RFC 2616（HTTP/1.0）协议中和网页缓存相关字段。用来控制缓存的失效日期，要注意的是，HTTP/1.0有一个功能比较弱的缓存控制机制：Pragma，使用HTTP/1.0的缓存将忽略Expires和Cache-Control头。
1. Accept：告诉WEB服务器自己接受什么介质类型，*/* 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。
2. Accept-Charset：浏览器申明自己接收的字符集
Accept-Encoding：浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法 （gzip，deflate）
Accept-Language：浏览器申明自己接收的语言语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等。
3. Accept-Ranges：WEB服务器表明自己是否接受获取其某个实体的一部分（比如文件的一部分）的请求。bytes：表示接受，none：表示不接受。
4. Age：当代理服务器用自己缓存的实体去响应请求时，用该头部表明该实体从产生到现在经过多长时间了。
5. Authorization：当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，该头部来回应自己的身份验证信息给WEB服务器。
6. Cache-Control：
请求：no-cache（不要缓存的实体，要求现在从WEB服务器去取）
max-age：（只接受 Age 值小于 max-age 值，并且没有过期的对象）
max-stale：（可以接受过去的对象，但是过期时间必须小于max-stale 值）
min-fresh：（接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象）
响应：public(可以用 Cached 内容回应任何用户)
private（只能用缓存内容回应先前请求该内容的那个用户）
no-cache（可以缓存，但是只有在跟WEB服务器验证了其有效后，才能返回给客户端）
max-age：（本响应包含的对象的过期时间）
ALL: no-store（不允许缓存）
7. Connection：
请求：close（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，断开连接，不要等待本次连接的后续请求了）。
keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）。
响应：close（连接已经关闭）。
keepalive（连接保持着，在等待本次连接的后续请求）。
Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持连接多长时间（秒）。例如：Keep-Alive：300
8. Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。
例如：Content-Encoding：gzip
Content-Language：WEB 服务器告诉浏览器自己响应的对象的语言。
Content-Length： WEB 服务器告诉浏览器自己响应的对象的长度。
例如：Content-Length: 26012
Content-Range： WEB 服务器表明该响应包含的部分对象为整个对象的哪个部分。
例如：Content-Range: bytes 21010-47021/47022
Content-Type： WEB 服务器告诉浏览器自己响应的对象的类型。
例如：Content-Type：application/xml
9. ETag：就是一个对象（比如URL）的标志值，就一个对象而言，比如一个 html 文件，如果被修改了，其 Etag 也会别修改，所以，ETag 的作用跟 Last-Modified 的作用差不多，主要供 WEB 服务器判断一个对象是否改变了。比如前一次请求某个 html 文件时，获得了其 ETag，当这次又请求这个文件时，浏览器就会把先前获得的 ETag 值发送给 WEB 服务器，然后 WEB 服务器会把这个 ETag 跟该文件的当前 ETag 进行对比，然后就知道这个文件有没有改变了。
10. Expired：WEB服务器表明该实体将在什么时候过期，对于过期了的对象，只有在跟WEB服务器验证了其有效性后，才能用来响应客户请求。是 HTTP/1.0 的头部。
例如：Expires：Sat, 23 May 2009 10:02:12 GMT
11. Host：客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。
例如：Host：rss.sina.com.cn
12. If-Match：如果对象的 ETag 没有改变，其实也就意味著对象没有改变，才执行请求的动作。
If-None-Match：如果对象的 ETag 改变了，其实也就意味著对象也改变了，才执行请求的动作。
13. If-Modified-Since：如果请求的对象在该头部指定的时间之后修改了，才执行请求的动作（比如返回对象），否则返回代码304，告诉浏览器该对象没有修改。
例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT
If-Unmodified-Since：如果请求的对象在该头部指定的时间之后没修改过，才执行请求的动作（比如返回对象）。
14. If-Range：浏览器告诉 WEB 服务器，如果我请求的对象没有改变，就把我缺少的部分给我，如果对象改变了，就把整个对象给我。浏览器通过发送请求对象的ETag 或者自己所知道的最后修改时间给 WEB 服务器，让其判断对象是否改变了。总是跟 Range 头部一起使用。
15. Last-Modified：WEB 服务器认为对象的最后修改时间，比如文件的最后修改时间，动态页面的最后产生时间等等。
例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT
16. Location：WEB 服务器告诉浏览器，试图访问的对象已经被移到别的位置了，到该头部指定的位置去取。
例如：Location：http://i0.sinaimg.cn/dy/deco/2008/0528/sinahome_0803_ws_005_text_0.gif
17. Pramga：主要使用 Pramga: no-cache，相当于 Cache-Control： no-cache。
例如：Pragma：no-cache
18. Proxy-Authenticate：代理服务器响应浏览器，要求其提供代理身份验证信息。
Proxy-Authorization：浏览器响应代理服务器的身份验证请求，提供自己的身份信息。
19. Range：浏览器（比如 Flashget 多线程下载时）告诉 WEB 服务器自己想取对象的哪部分。
例如：Range: bytes=1173546-
20. Referer：浏览器向 WEB 服务器表明自己是从哪个网页/URL 获得/点击当前请求中的网址/URL。
例如：Referer：http://www.sina.com/
21. Server: WEB 服务器表明自己是什么软件及版本等信息。
例如：Server：Apache/2.0.61 (Unix)
22. User-Agent: 浏览器表明自己的身份（是哪种浏览器）。
例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
23. Transfer-Encoding: WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）作了怎样的编码，比如是否分块（chunked）。
例如：Transfer-Encoding: chunked
24. Vary: WEB服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应所返回的对象响应后续的请求。假如源WEB服务器在接到第一个请求消息时，其响应消息的头部为：Content-Encoding: gzip; Vary: Content-Encoding 那么 Cache 服务器会分析后续请求消息的头部，检查其 Accept-Encoding，是否跟先前响应的 Vary 头部值一致，即是否使用相同的内容编码方法，这样就可以防止 Cache 服务器用自己Cache 里面压缩后的实体响应给不具备解压能力的浏览器。
例如：Vary：Accept-Encoding
25. Via：列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用什么协议（和版本）发送的请求。当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面添加 Via 头部，并填上自己的相关信息，当下一个代理服务器收到第一个代理服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via部，并把自己的相关信息加到后面，以此类推，当 OCS 收到最后一个代理服务器的请求时，检查 Via 头部，就知道该请求所经过的路由。
例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)
================================================
HTTP 请求消息头部实例：
Host：rss.sina.com.cn
User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Accept：text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
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
Cookie：userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW <-- Cookie
If-Modified-Since：Sun, 01 Jun 2008 12:05:30 GMT
Cache-Control：max-age=0
HTTP 响应消息头部实例：
Status：OK - 200 <-- 响应状态码，表示 web 服务器处理的结果。
Date：Sun, 01 Jun 2008 12:35:47 GMT
Server：Apache/2.0.61 (Unix)
Last-Modified：Sun, 01 Jun 2008 12:35:30 GMT
Accept-Ranges：bytes
Content-Length：18616
Cache-Control：max-age=120
Expires：Sun, 01 Jun 2008 12:37:47 GMT
Content-Type：application/xml
Age：2
X-Cache：HIT from 236-41.D07071951.sina.com.cn <--反向代理服务器使用的 HTTP 头部
Via：1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13)
Connection：close
================================================
HTTP头部信息简单说明
2008-02-28 03:13
一、HTTP响应码响应码由三位十进制数字组成，它们出现在由HTTP服务器发送的响应的第一行。
响应码分五种类型，由它们的第一位数字表示：
1xx：信息，请求收到，继续处理
2xx：成功，行为被成功地接受、理解和采纳
3xx：重定向，为了完成请求，必须进一步执行的动作
4xx：客户端错误，请求包含语法错误或者请求无法实现
5xx：服务器错误，服务器不能实现一种明显无效的请求
下表显示每个响应码及其含义：
100 继续 101 分组交换协 200 OK 201 被创建 202 被采纳
203 非授权信息 204 无内容 205 重置内容 206 部分内容
300 多选项 301 永久地传送 302 找到 303 参见其他
304 未改动 305 使用代理 307 暂时重定向 400 错误请求
401 未授权 402 要求付费 403 禁止 404 未找到
405 不允许的方法 406 不被采纳 407 要求代理授权408 请求超时
409 冲突 410 过期的 411 要求的长度 412 前提不成立
413 请求实例太大 414 请求URI太大 415 不支持的媒体类型
416 无法满足的请求范围 417 失败的预期 500 内部服务器错误
501 未被使用 502 网关错误 503 不可用的服务 504 网关超时
505 HTTP版本未被支持
二、HTTP头标头标由主键/值对组成。它们描述客户端或者服务器的属性、被传输的资源以及应该实现连接。
四种不同类型的头标：
1.通用头标：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。
2.请求头标：允许客户端传递关于自身的信息和希望的响应形式。
3.响应头标：服务器和于传递自身信息的响应。
4.实体头标：定义被传送资源的信息。即可用于请求，也可用于响应。
头标格式：<name>:<value><CRLF>
下表描述在HTTP/1.1中用到的头标
Accept 定义客户端可以处理的媒体类型，按优先级排序；在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept: image/jpeg,image/png,*/*Accept-Charset 定义客户端可以处理的字符集，按优先级排序；在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding 定义客户端可以理解的编码机制。例如：Accept-Encoding:gzip,compress
Accept-Language 定义客户端乐于接受的自然语言列表。例如：Accept-Language: en,de
Accept-Ranges 一个响应头标，它允许服务器指明：将在给定的偏移和长度处，为资源组成部分的接受请求。该头标的值被理解为请求范围的度量单位。例如Accept-Ranges: bytes或Accept-Ranges: none
Age 允许服务器规定自服务器生成该响应以来所经过的时间长度，以秒为单位。该头标主要用于缓存响应。例如：Age: 30
Allow 一个响应头标，它定义一个由位于请求URI中的次源所支持的HTTP方法列表。例如：Allow: GET,PUT
aUTHORIZATION 一个响应头标，用于定义访问一种资源所必需的授权（域和被编码的用户ID与口令）。例如：Authorization: Basic YXV0aG9yOnBoaWw=
Cache-Control 一个用于定义缓存指令的通用头标。例如：Cache-Control: max-age=30
Connection 一个用于表明是否保存socket连接为开放的通用头标。例如：Connection: close或Connection: keep-alive
Content-Base 一种定义基本URI的实体头标，为了在实体范围内解析相对URLs。如果没有定义Content-Base头标解析相对URLs，使用Content- Location URI（存在且绝对）或使用URI请求。例如：Content-Base: http://www.myweb.com
Content-Encoding 一种介质类型修饰符，标明一个实体是如何编码的。例如：Content-Encoding: zipContent-Language 用于指定在输入流中数据的自然语言类型。例如：Content-Language: en
Content-Length 指定包含于请求或响应中数据的字节长度。例如：Content-Length:382
Content-Location 指定包含于请求或响应中的资源定位（URI）。如果是一绝。对URL它也作为被解析实体的相对URL的出发点。例如：Content-Location: http://www.myweb.com/news
Content-MD5 实体的一种MD5摘要，用作校验和。发送方和接受方都计算MD5摘要，接受方将其计算的值与此头标中传递的值进行比较。例如：Content-MD5: <base64 of 128 MD5 digest>
Content-Range 随部分实体一同发送；标明被插入字节的低位与高位字节偏移，也标明此实体的总长度。例如：Content-Range: 1001-2000/5000
Contern-Type 标明发送或者接收的实体的MIME类型。例如：Content-Type: text/html
Date 发送HTTP消息的日期。例如：Date: Mon,10PR 18:42:51 GMT
ETag 一种实体头标，它向被发送的资源分派一个唯一的标识符。对于可以使用多种URL请求的资源，ETag可以用于确定实际被发送的资源是否为同一资源。例如：ETag: ‘208f-419e-30f8dc99‘
Expires 指定实体的有效期。例如：Expires: Mon,05 Dec 2008 12:00:00 GMT
Form 一种请求头标，给定控制用户代理的人工用户的电子邮件地址。例如：From: [email protected]
Host 被请求资源的主机名。对于使用HTTP/1.1的请求而言，此域是强制性的。例如：Host: www.myweb.com
If-Modified-Since 如果包含了GET请求，导致该请求条件性地依赖于资源上次修改日期。如果出现了此头标，并且自指定日期以来，此资源已被修改，应该反回一个304响应代码。例如：If-Modified-Since: Mon,10PR 18:42:51 GMT
If-Match 如果包含于一个请求，指定一个或者多个实体标记。只发送其ETag与列表中标记区配的资源。例如：If-Match: ‘208f-419e-308dc99‘
If-None-Match 如果包含一个请求，指定一个或者多个实体标记。资源的ETag不与列表中的任何一个条件匹配，操作才执行。例如：If-None-Match: ‘208f-419e-308dc99‘
If-Range 指定资源的一个实体标记，客户端已经拥有此资源的一个拷贝。必须与Range头标一同使用。如果此实体自上次被客户端检索以来，还不曾修改过，那么服务器只发送指定的范围，否则它将发送整个资源。例如：Range: byte=0-499<CRLF>If-Range:‘208f-419e-30f8dc99‘
If-Unmodified-Since 只有自指定的日期以来，被请求的实体还不曾被修改过，才会返回此实体。例如：If-Unmodified-Since:Mon,10PR 18:42:51 GMT
Last-Modified 指定被请求资源上次被修改的日期和时间。例如：Last-Modified: Mon,10PR 18:42:51 GMT
Location 对于一个已经移动的资源，用于重定向请求者至另一个位置。与状态编码302（暂时移动）或者301（永久性移动）配合使用。例如：Location: http://www2.myweb.com/index.jsp
Max-Forwards 一个用于TRACE方法的请求头标，以指定代理或网关的最大数目，该请求通过网关才得以路由。在通过请求传递之前，代理或网关应该减少此数目。例如：Max-Forwards: 3
Pragma 一个通用头标，它发送实现相关的信息。例如：Pragma: no-cache
Proxy-Authenticate 类似于WWW-Authenticate，便是有意请求只来自请求链（代理）的下一个服务器的认证。例如：Proxy-Authenticate: Basic realm-admin
Proxy-Proxy-Authorization 类似于授权，但并非有意传递任何比在即时服务器链中更进一步的内容。例如：Proxy-Proxy-Authorization: Basic YXV0aG9yOnBoaWw=
Public 列表显示服务器所支持的方法集。例如：Public: OPTIONS,MGET,MHEAD,GET,HEAD
Range 指定一种度量单位和一个部分被请求资源的偏移范围。例如：Range: bytes=206-5513
Refener 一种请求头标域，标明产生请求的初始资源。对于HTML表单，它包含此表单的Web页面的地址。例如：Refener: http://www.myweb.com/news/search.html
Retry-After 一种响应头标域，由服务器与状态编码503（无法提供服务）配合发送，以标明再次请求之前应该等待多长时间。此时间即可以是一种日期，也可以是一种秒单位。例如：Retry-After: 18
Server 一种标明Web服务器软件及其版本号的头标。例如：Server: Apache/2.0.46(Win32)
Transfer-Encoding 一种通用头标，标明对应被接受方反向的消息体实施变换的类型。例如：Transfer-Encoding: chunked
Upgrade 允许服务器指定一种新的协议或者新的协议版本，与响应编码101（切换协议）配合使用。例如：Upgrade: HTTP/2.0
User-Agent 定义用于产生请求的软件类型（典型的如Web浏览器）。例如：User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT; DigExt)
Vary 一个响应头标，用于表示使用服务器驱动的协商从可用的响应表示中选择响应实体。例如：Vary: *Via 一个包含所有中间主机和协议的通用头标，用于满足请求。例如：Via: 1.0 fred.com, 1.1 wilma.com
Warning 用于提供关于响应状态补充信息的响应头标。例如：Warning: 99 www.myweb.com Piano needs tuning
www-Authenticate 一个提示用户代理提供用户名和口令的响应头标，与状态编码401（未授权）配合使用。响应一个授权头标。例如：www-Authenticate: Basic realm=zxm.mgmt