看到很多关于HTTP协议的文章，大多都有点云里雾里的感觉，总觉得没有看透，也谈不上理解，也不知道怎么去利用协议知识去改善WEB体验，关于http协议还有很多的疑问。这些或许浅显，网上一直都没有确切的答案，比如这个协议到底是谁在遵守，协议做了哪些规定，request header 和response header到底做了些什么，是否可以控制request header,如何使用PHP的header()函数去控制response header.
我之前隐隐约约知道response header里面有个头域:Cache-Control:no-cache, 我一直理解为此次响应不会被缓存，如果我要此响应缓存，就需要使用Cache-Control:public,这样响应就可以被缓存了，当时，我理解的“缓存”就是客户端(浏览器)保存了上次的请求内容，如果重新发起同一请求的时候，浏览器就不需要再向服务器请求数据了。这是完全错的。
http协议是请求|响应协议
因为没有写过socket通信，我一度对【协议】理解的很抽象，总觉得协议是一个高大上的东西，是代码可以写得来的？是某种规定？后来做游戏，封装了一套客户端和服务器端通信的“协议”, 才恍然大悟，【协议】就是一种规定。比如A和B交流，A约定好：“123”意思就是“爱你”, ‘234’表示“请不要”。约定好后，A,B用之前的协议交流，A发送“123”, B回复“234”， 这样A, B都知道了双方的心意。
【用户代理】：发起请求的客户端，通常包括浏览器， 网络爬虫等
【主机】：服务器所在的电脑
【服务器】：处理请求，返回响应数据的处理程序，通常指apache,nignx
【实体】：作为请求或者响应负载的信息，包括头部域和主体(response body)两部分
http协议是请求和响应的协议，我的理解就是, 【用户代理】向服务器发送请求，【WEB服务器】响应本次请求，并返回信息给【用户代理】。为了让【用户代理】，【WEB服务器】都能理解彼此，然后就出了一个规定，只要所有【用户代理】，【web服务器】都遵守这个协议，那么他们之间就能通信啦。
也就是说，http协议就是规定【用户代理】，【服务器】如何通信的，【用户代理】，【服务器】都必须遵守（实现）HTTP协议。http协议发展到现在为止，有很多的版本，现在使用的大都是http1.1
http协议规定了哪些内容
http说的通俗一点，就是用户想去服务器拿点东西【html】，于是他通过浏览器【用户代理】发起一个请求， 服务器收到请求后给它响应的内容。如果要实现这一点，我们需要了解的是：
1, 用户想要的东西在服务器哪里，即【URL】
2, 浏览器要事先告诉服务器，我能接受哪些格式的东西，例如页面编码，传输编码，可以解析的媒体类型，于是浏览器就通过request header，告知服务器相关信息【request header】
3，服务器收到请求后，找到相应内容，按照浏览器可以接受的格式，把数据传输给浏览器，他通过response header的信息，告知浏览器【response header】
4, 客户端和服务器是怎样连接起来的 涉及指令：connection, 同时还涉及到TCP协议的一些内容。【connection】
5, 为了使客户端和浏览器更高效的交流，于是设计了缓存，涉及到指令：Cache-Control,expires等【cache-control】
6， 服务器把信息返回给客户端的时候，告诉了客户端处理此次请求的状态，比如处理成功，返回了200， 处理失败可能返回502等，【status code】
把以上六点搞清楚之后，就会对http协议有一个直观的认识，下面我将分别以上六点
和URL有关的内容
URL:统一资源标识符, 指出了资源在【服务器】上面的位置
URL = "HTTP://"主机名[":"端口号][绝对路径["?" 查询]]
如果端口号为空，则默认是80
例如：http://www.hellosunnyge.com/wordpress/?p=546
需要注意的是:
1 http://www.hellosunnyge.com///wordpress/?p=546 这样的请求也是合法的，等价于：http://www.hellosunnyge.com/wordpress/?p=546
2 http://www.hellosunnyge.com/../wordpress/?p=546 这样的请求也是合法的，等价于http://www.hellosunnyge.com/?p=546
明白这两点之后你可以看一下通过URL改写从而到达攻击网站的目的。这样的文章在coolshell.cn中有很多.
浏览器事先可以告诉服务器什么信息 request header
首先我们需要确定一个观点：浏览器可以【告诉】服务器很多很多的信息，但是不是每次请求都会把所有能告诉给服务器的内容都发给服务器。我们是否可以控制浏览器给服务器的内容.答案是可以的,比如浏览器可以设置不保存cookie，这样浏览器就不会在头部域中发送cookie到服务器了。
这么多头部域，至于我们可以控制哪些东西，我也不大清楚，希望得到高人指点。
先贴一段请求的代码，先直观的认识一下request header头域, 每个指令代表的意思我会依依解答.（在浏览器中按F12,就可以调出浏览器调试模式）
[php]
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:wp-settings-1=mfold%3Do%26ed_size%3D805%26editor%3Dhtml%26dfw_width%3D822%26hidetb%3D1%26libraryContent%3Dbrowse%26imgsize%3Dlarge; wp-settings-time-1=1409909807; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_1bb8d6dd50838df58104ee01f5b88ba7=sunliinboke%7C1411719317%7C7cb2746b6d97421200a3c22472e875f0; saeut=180.175.160.197.1407379950410183
Host:www.hellosunnyge.com
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
[/php]
Accept:告诉服务器，我可以接受的媒体类型， Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8就是告诉服务器，可以发送text/html， application/xml等类别的信息给我，至于类似于q=0.8代表的是浏览器的喜好，也就是浏览器更愿意接受的媒体类型。
Accept-Encoding: 内容编码，内容编码主要用来允许文档压缩或其它不丢失其底层媒体类型特征和信息有用的转换，实体常常存储为编码形式.常见的压缩算法有gzip,compress等
Accept-Language: 浏览器能识别的自然语言 q=0.8也是浏览器的一个喜好
Cache-Control: 缓存，下面会详细说明
Connection:连接，下面会详细说明
Cookie:此域名下保存在浏览器的cookie值会会自动传输到服务器上
Host:请求的服务器名
User-Agent:来用标示客户端的相关信息。
还有一些常见的选项：
Accept-Chareset:浏览器可以接受的编码, 如果不存在Accept-Chareset选项，表示浏览器可以接受任何字符集
Accept-Language:浏览器可以接受的自然语言，比如en
服务器如何把信息传输给客户端response header response body
我们需要知道的是，服务器把传给客户端的信息分为两部分：response header 响应头域信息 response body 响应体。我们可使用PHP的header()函数传递给客户端的相应的头域信息。
[php]
Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Fri, 12 Sep 2014 09:10:29 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Link:<http://www.hellosunnyge.com/wordpress/?p=546>; rel=shortlink
Pragma:no-cache
Server:nginx/1.2.6
Transfer-Encoding:chunked
Via:10.67.15.48
X-Pingback:http://www.hellosunnyge.com/wordpress/xmlrpc.php
X-Powered-By:PHP/5.3.27
[/php]
Content-Encoding:此次响应体的内容编码，这个就是与客户端的Accept-Encoding对应的
Content-Type:响应的信息的类别，与客户端Accept-Type对应的
Transfer-Encoding:传输编码，注意传输编码是为了在网络上传送更快，注意和内容编码的区别
Chareset=UTF-8: 响应的信息的字符集
Date:此次响应的时间
Expires: 缓存有关，下面会详细说明
link:此次请求的URL
server: 处理此次请求的服务器的信息
via:服务器的IP
永久连接
我们需要知道的是 http协议是基于TCP协议的，客户端和服务器建立连接的时候，需要三次握手，不过http是无状态的，短连接，也就是当数据请求完整后，就会断开连接。第二点我们需要了解的是，在发起一个URL请求一个html页面, html页面中的类似于<img src="/path/to">， <script src=""></script>需要自动向服务器服务器请求图片，css，js文，也就是说，向服务器发起一个请求，可能需要多次请求服务器，才能把完整的信息请求完整。
如果每次请求都建立一个tcp连接，这样无疑增加http服务器的压力，于是就有了永久连接，只需要建立一次tcp请求，并保持此连接直到所有的数据都请求完整。
那么客户端是如何与服务器协商来保持永久连接的呢。
首先，在http/1.1协议中，作为服务器的一方，假设客户端打算每次请求都是永久连接，除非客户端不想发起永久链接，那他就给服务器发一个信息，说我不想和你链接了，我们断开吧。这个信息就是Connection头部中包括连接符"close"。服务器收到这个Connection指令后，就和客户端断开链接了
如果服务器不打算和客户端保持永久链接了，他也会给客户端发同样的信息，告诉客户端，这样，永久链接就不存在了。也就是说，客户端和服务器都可以决定到底是否要维持永久链接。
如果保持了永久链接后，客户端可以向服务器发送多个请求，而不需要等待每个响应，服务器接收到请求后，依次响应这些请求，这就是为什么有时候请求一个html，发现图片没有请求成功，当网页依然可以显示其他成功请求的内容。
Connection: keep-alive
那我们是否需要手动的设置这个指令呢，答案是不需要，在http/1.1中，Connection的属性默认是keep-alive,也就是说，当response header中如果没有这个指令，则默认是keep-alive。我们并不需要去设置这样的属性，理解即可。
缓存
Web缓存位于Web服务器之间（1个或多个，内容源服务器）和客户端之间（1个或多个）：缓存会根据进来的请求保存输出内容的副本，例如html页面， 图片，文件（统称为副本），然后，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。
减少相应延迟：因为请求从缓存服务器（离客户端更近）而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快；
减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。
浏览器缓存
对于新一代的Web浏览器来说（例如：IE，Firefox）：一般都能在设置对话框中发现关于缓存的设置，通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作：在同一个会话过程中（在当前浏览器没有被关闭之前）会检查一次并确定缓存的副本足够新。这个缓存对于用户点击“后退”或者点击刚访问过的链接特别有用，如果你浏览过程中访问到同一个图片，这些图片可以从浏览器缓存中调出而即时显现。
代理服务器缓存
Web代理服务器使用同样的缓存原理，只是规模更大。代理服务器群为成百上千用户服务使用同样的机制；大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备；
由于带路服务器缓存并非客户端或者源服务器的一部分，而是位于原网络之外，请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器：告诉浏览器使用 那个代理，另外一个是通过中间服务器：这个中间服务器处理所有的web请求，并将请求转发到后台网络，而用户不必配置代理，甚至不必知道代理的存在；
代理服务器缓存：是一个共享缓存，不只为一个用户服务，经常为大量用户使用，因此在减少相应时间和带宽使用方面很有效：因为同一个副本会被重用多次。
网关缓存
也被称为反向代理缓存或间接代理缓存，网关缓存也是一个中间服务器，和内网管理员部署缓存用于节省带宽不同：网关缓存一般是网站管理员自己部署：让他们的网站更容易扩展并获得更好的性能；
请求有几种方法被路由到网关缓存服务器上：其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器；
我的理解是，关于代理服务器，服务器等缓存是管理员设置的，比如nginx可以通过缓存设置配置缓存一些静态文件，当访问这些文件的时候，直接从缓存里面获取，并返回状态not modified 304
HTML meta标签和HTTP 头信息
HTML的编写者会在文档的区域中加入描述文档的各种属性，这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期；
META标签使用很简单：但是效率并不高，因为只有几种浏览器会遵循这个标记（那些真正会“读懂”HTML的浏览器），没有一种缓存代理服务器能遵循这个 规则（因为它们几乎完全不解析文档中HTML内容）；有事会在Web页面中增加：Pragma: no-cache这个META标记，如果要让页面保持刷新，这个标签其实完全没有必要。
如果你的网站托管在ISP机房中，并且机房可能不给你权限去控制HTTP的头信息（如：Expires和Cache-Control），大声控诉：这些机制对于你的工作来说是必须的；
另外一方面： HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的，一般由Web服务器自动生成。但是，根据 你使用的服务，你可以在某种程度上进行控制。在下文中：你将看到一些有趣的HTTP头信息，和如何在你的站点上应用部署这些特性。
HTTP头信息发送在HTML代码之前，只有被浏览器和一些中间缓存能看到，一个典型的HTTP 1.1协议返回的头信息看上去像这样：
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html
在头信息空一行后是HTML代码的输出，关于如何设置HTTP头信息请参考实现章节；
Pragma HTTP头信息 (为什么它不起作用)
很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此：HTTP的规范中，响应型头信息没有任何关于Pragma属性的说明，而讨论了的是请求型头信息 Pragma属性（头信息也由浏览器发送给服务器），虽然少数集中缓存服务器会遵循这个头信息，但大部分不会。用了Pragma也不起什么作用，要用就使 用下列头信息：
使用Expires（过期时间）HTTP头信息来控制保鲜期
Expires（过期时间） 属性是HTTP控制缓存的基本手段，这个属性告诉缓存器：相关副本在多长时间内是新鲜的。过了这个时间，缓存器就会向源服务器发送请求，检查文档是否被修改。几乎所有的缓存服务器都支持Expires（过期时间）属性；
大部分Web服务器支持你用几种方式设置Expires属性；一般的：可以设计一个绝对时间间隔：基于客户最后查看副本的时间（最后访问时间）或者根据服务器上文档最后被修改的时间；
Expires头信息：对于设置静态图片文件（例如导航栏和图片按钮）可缓存特别有用；因为这些图片修改很少，你可以给它们设置一个特别长的过期时间，这会使你的网站对用户变得相应非常快；他们对于控制有规律改变的网页也很有用，例如：你每天早上6点更新新闻页，你可以设置副本的过期时间也是这个时间，这样缓存 服务器就知道什么时候去取一个更新版本，而不必让用户去按浏览器的“刷新”按钮。
过期时间头信息属性值只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，副本会过期，记住：HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：
Expires: Fri, 30 Oct 1998 14:19:41 GMT
所以使用过期时间属性一定要确认你的Web服务器时间设置正确，一个途径是通过网络时间同步协议（Network Time Protocol NTP），和你的系统管理员那里你可以了解更多细节。
虽然过期时间属性非常有用，但是它还是有些局限，首先：是牵扯到了日期，这样Web服务器的时间和缓存服务器的时间必须是同步的，如果有些不同步，要么是应该缓存的内容提前过期了，要么是过期结果没及时更新。
还有一个过期时间设置的问题也不容忽视：如果你设置的过期时间是一个固定的时间，如果你返回内容的时候又没有连带更新下次过期的时间，那么之后所有访问请求都会被发送给源Web服务器，反而增加了负载和响应时间；
Cache-Control（缓存控制） HTTP头信息
HTTP 1.1介绍了另外一组头信息属性：Cache-Control响应头信息，让网站的发布者可以更全面的控制他们的内容，并定位过期时间的限制。
有用的 Cache-Control响应头信息包括：
max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
public — 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
no-store — 强制缓存在任何情况下都不要保留任何副本
must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用
举例:
Cache-Control: max-age=3600, must-revalidate
如果你计划试用Cache-Control属性，你应该看一下这篇HTTP文档，详见参考和深入阅读；
校验参数和校验
在Web缓存如何工作： 我们说过：校验是当副本已经修改后，服务器和缓存之间的通讯机制；使用这个机制：缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
校验参数非常重要，如果1个不存在，并且没有任何信息说明保鲜期（Expires或Cache-Control）的情况下，缓存将不会存储任何副本；
最常见的校验参数是文档的最后修改时间，通过最后Last-Modified头信息可以，当一份缓存包含Last-Modified信息，他基于此信息，通过添加一个If-Modified-Since请求参数，向服务器查询：这个副本从上次查看后是否被修改了。
HTTP 1.1介绍了另外一个校验参数： ETag，服务器是服务器生成的唯一标识符ETag，每次副本的标签都会变化。由于服务器控制了ETag如何生成，缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
所有的缓存服务器都使用Last-Modified时间来确定副本是否够新，而ETag校验正变得越来越流行；
所有新一代的Web服务器都对静态内容（如：文件）自动生成ETag和Last-Modified头信息，而你不必做任何设置。但是，服务器对于动态内容（例如：CGI,ASP或数据库生成的网站）并不知道如何生成这些信息，参考一下编写利于缓存的脚本章节；
创建利于缓存网站的窍门
除了使用新鲜度信息和校验，你还有很多方法使你的网站缓存友好。
保持URL稳定： 这是缓存的金科玉律，如果你给在不同的页面上，给不同用户或者从不同的站点上提供相同的内容，应该使用相同的URL，这是使你的网站缓存友好最简单，也是 最高效的方法。例如：如果你在页面上使用 “/index.html” 做为引用，那么就一直用这个地址；
使用一个共用的库存放每页都引用的图片和其他页面元素；
对于不经常改变的图片/页面启用缓存，并使用Cache-Control: max-age属性设置一个较长的过期时间；
对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间；
如果数据源（特别是下载文件）变更，修改名称，这样：你可以让其很长时间不过期，并且保证服务的是正确的版本；而链接到下载文件的页面是一个需要设置较短过期时间的页面。
万不得已不要改变文件，否则你会提供一个非常新的Last-Modified日期；例如：当你更新了网站，不要复制整个网站的所有文件，只上传你修改的文件。
只在必要的时候使用Cookie，cookie是非常难被缓存的，而且在大多数情况下是不必要的，如果使用cookie，控制在动态网页上；
减少试用SSL，加密的页面不会被任何共享缓存服务器缓存，只在必要的时候使用，并且在SSL页面上减少图片的使用；
使用可缓存性评估引擎，这对于你实践本文的很多概念都很有帮助；
编写利于缓存的脚本
脚本缺省不会返回校验参数（返回Last-Modified或ETag头信息）或其他新鲜度信息（Expires或Cache-Control），有些动态脚本的确是动态内容（每次相应内容都不一样），但是更多（搜索引擎，数据库引擎网站）网站还是能从缓存友好中获益的。
一般说来，如果脚本生成的输出在未来一段时间（几分钟或者几天）都是可重复复制的，那么就是可缓存的。如果脚本输出内容只随URL变化而变化，也是可缓存的；但如果输出会根据cookie，认证信息或者其他外部条件变化，则还是不可缓存的。
最利于缓存的脚本就是将内容改变时导出成静态文件，Web服务器可以将其当作另外一个网页并生成和试用校验参数，让一些都变得更简单，只需要写入文件即可，这样最后修改时间也有了；
另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息，虽然通过Expires头信息也可以实现，但更容易的是用Cache-Control: max-age属性，它会让首次请求后一段时间内缓存保持新鲜；
如果以上做法你都做不到，你可以让脚本生成一个校验属性，并对 If-Modified-Since 和/或If-None-Match请求作出反应，这些属性可以从解析HTTP头信息得到，并对符合条件的内容返回304 Not Modified（内容未改变），可惜的是，这种做法比不上前2种高效；
其他窍门：
尽量避免使用POST，除非万不得已，POST模式的返回内容不会被大部分缓存服务器保存，如果你发送内容通过URL和查询（通过GET模式）的内容可以缓存下来供以后使用；
不要在URL中加入针对每个用户的识别信息：除非内容是针对每个用户不同的；
不要统计一个用户来自一个地址的所有请求，因为缓存常常是一起工作的；
生成并返回Content-Length头信息，如果方便的话，这个属性让你的脚本在可持续链接模式时：客户端可以通过一个TCP/IP链接同时请求多个副本，而不是为每次请求单独建立链接，这样你的网站相应会快很多；
status code
100 Continue
初始的请求已经接受，客户应当继续发送请求的其余部分
101 Switching Protocols
服务器将遵从客户的请求转换到另外一种协议
200 OK
一切正常，对GET和POST请求的应答文档跟在后面
201 Created
服务器已经创建了文档，Location头给出了它的URL。
202 Accepted
已经接受请求，但处理尚未完成。
203 Non-Authoritative Information
文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝
204 No Content
没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的
205 Reset Content
没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容
206 Partial Content
客户发送了一个带有Range头的GET请求，服务器完成了它
300 Multiple Choices
客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
302 Found
类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
303 See Other
类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy
客户请求的文档应该通过Location头所指明的代理服务器提取
307 Temporary Redirect
和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码： 当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
400 Bad Request
请求出现语法错误。
401 Unauthorized
客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
403 Forbidden
资源不可用。
404 Not Found
无法找到指定位置的资源
405 Method Not Allowed
请求方法（GET、POST、HEAD、Delete、PUT、TRACE等）对指定的资源不适用。
406 Not Acceptable
指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容
407 Proxy Authentication Required
类似于401，表示客户必须先经过代理服务器的授权。
408 Request Timeout
在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。
409 Conflict
通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。
410 Gone
所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。
411 Length Required
服务器不能处理请求，除非客户发送一个Content-Length头。
412 Precondition Failed
请求头中指定的一些前提条件失败
413 Request Entity Too Large
目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头
414 Request URI Too Long
URI太长
416 Requested Range Not Satisfiable
服务器不能满足客户在请求中指定的Range头
500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求
501 Not Implemented
服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求
502 Bad Gateway
服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答
503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头
504 Gateway Timeout
由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答
505 HTTP Version Not Supported
服务器不支持请求中所指明的HTTP版本
我之前隐隐约约知道response header里面有个头域:Cache-Control:no-cache, 我一直理解为此次响应不会被缓存，如果我要此响应缓存，就需要使用Cache-Control:public,这样响应就可以被缓存了，当时，我理解的“缓存”就是客户端(浏览器)保存了上次的请求内容，如果重新发起同一请求的时候，浏览器就不需要再向服务器请求数据了。这是完全错的。
所以，我要决定好好看看http协议。到目前为止，还要很多概念，术语，不是很清楚，只是记录一个自己对http协议的理解，我尽量使用通俗的语言去描述，如有错误的地方，希望指出来，共同交流,这篇文章页参考了很多文章。
http协议是请求|响应协议
因为没有写过socket通信，我一度对【协议】理解的很抽象，总觉得协议是一个高大上的东西，是代码可以写得来的？是某种规定？后来做游戏，封装了一套客户端和服务器端通信的“协议”, 才恍然大悟，【协议】就是一种规定。比如A和B交流，A约定好：“123”意思就是“爱你”, ‘234’表示“请不要”。约定好后，A,B用之前的协议交流，A发送“123”, B回复“234”， 这样A, B都知道了双方的心意。
【用户代理】：发起请求的客户端，通常包括浏览器， 网络爬虫等
【主机】：服务器所在的电脑
【服务器】：处理请求，返回响应数据的处理程序，通常指apache,nignx
【实体】：作为请求或者响应负载的信息，包括头部域和主体(response body)两部分
http协议是请求和响应的协议，我的理解就是, 【用户代理】向服务器发送请求，【WEB服务器】响应本次请求，并返回信息给【用户代理】。为了让【用户代理】，【WEB服务器】都能理解彼此，然后就出了一个规定，只要所有【用户代理】，【web服务器】都遵守这个协议，那么他们之间就能通信啦。
也就是说，http协议就是规定【用户代理】，【服务器】如何通信的，【用户代理】，【服务器】都必须遵守（实现）HTTP协议。http协议发展到现在为止，有很多的版本，现在使用的大都是http1.1
http协议规定了哪些内容
http说的通俗一点，就是用户想去服务器拿点东西【html】，于是他通过浏览器【用户代理】发起一个请求， 服务器收到请求后给它响应的内容。如果要实现这一点，我们需要了解的是：
1, 用户想要的东西在服务器哪里，即【URL】
2, 浏览器要事先告诉服务器，我能接受哪些格式的东西，例如页面编码，传输编码，可以解析的媒体类型，于是浏览器就通过request header，告知服务器相关信息【request header】
3，服务器收到请求后，找到相应内容，按照浏览器可以接受的格式，把数据传输给浏览器，他通过response header的信息，告知浏览器【response header】
4, 客户端和服务器是怎样连接起来的 涉及指令：connection, 同时还涉及到TCP协议的一些内容。【connection】
5, 为了使客户端和浏览器更高效的交流，于是设计了缓存，涉及到指令：Cache-Control,expires等【cache-control】
6， 服务器把信息返回给客户端的时候，告诉了客户端处理此次请求的状态，比如处理成功，返回了200， 处理失败可能返回502等，【status code】
把以上六点搞清楚之后，就会对http协议有一个直观的认识，下面我将分别以上六点
和URL有关的内容
URL:统一资源标识符, 指出了资源在【服务器】上面的位置
URL = "HTTP://"主机名[":"端口号][绝对路径["?" 查询]]
如果端口号为空，则默认是80
例如：http://www.hellosunnyge.com/wordpress/?p=546
需要注意的是:
1 http://www.hellosunnyge.com///wordpress/?p=546 这样的请求也是合法的，等价于：http://www.hellosunnyge.com/wordpress/?p=546
2 http://www.hellosunnyge.com/../wordpress/?p=546 这样的请求也是合法的，等价于http://www.hellosunnyge.com/?p=546
明白这两点之后你可以看一下通过URL改写从而到达攻击网站的目的。这样的文章在coolshell.cn中有很多.
浏览器事先可以告诉服务器什么信息 request header
首先我们需要确定一个观点：浏览器可以【告诉】服务器很多很多的信息，但是不是每次请求都会把所有能告诉给服务器的内容都发给服务器。我们是否可以控制浏览器给服务器的内容.答案是可以的,比如浏览器可以设置不保存cookie，这样浏览器就不会在头部域中发送cookie到服务器了。
这么多头部域，至于我们可以控制哪些东西，我也不大清楚，希望得到高人指点。
先贴一段请求的代码，先直观的认识一下request header头域, 每个指令代表的意思我会依依解答.（在浏览器中按F12,就可以调出浏览器调试模式）
[php]
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:wp-settings-1=mfold%3Do%26ed_size%3D805%26editor%3Dhtml%26dfw_width%3D822%26hidetb%3D1%26libraryContent%3Dbrowse%26imgsize%3Dlarge; wp-settings-time-1=1409909807; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_1bb8d6dd50838df58104ee01f5b88ba7=sunliinboke%7C1411719317%7C7cb2746b6d97421200a3c22472e875f0; saeut=180.175.160.197.1407379950410183
Host:www.hellosunnyge.com
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
[/php]
Accept:告诉服务器，我可以接受的媒体类型， Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8就是告诉服务器，可以发送text/html， application/xml等类别的信息给我，至于类似于q=0.8代表的是浏览器的喜好，也就是浏览器更愿意接受的媒体类型。
Accept-Encoding: 内容编码，内容编码主要用来允许文档压缩或其它不丢失其底层媒体类型特征和信息有用的转换，实体常常存储为编码形式.常见的压缩算法有gzip,compress等
Accept-Language: 浏览器能识别的自然语言 q=0.8也是浏览器的一个喜好
Cache-Control: 缓存，下面会详细说明
Connection:连接，下面会详细说明
Cookie:此域名下保存在浏览器的cookie值会会自动传输到服务器上
Host:请求的服务器名
User-Agent:来用标示客户端的相关信息。
还有一些常见的选项：
Accept-Chareset:浏览器可以接受的编码, 如果不存在Accept-Chareset选项，表示浏览器可以接受任何字符集
Accept-Language:浏览器可以接受的自然语言，比如en
服务器如何把信息传输给客户端response header response body
我们需要知道的是，服务器把传给客户端的信息分为两部分：response header 响应头域信息 response body 响应体。我们可使用PHP的header()函数传递给客户端的相应的头域信息。
[php]
Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Fri, 12 Sep 2014 09:10:29 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Link:<http://www.hellosunnyge.com/wordpress/?p=546>; rel=shortlink
Pragma:no-cache
Server:nginx/1.2.6
Transfer-Encoding:chunked
Via:10.67.15.48
X-Pingback:http://www.hellosunnyge.com/wordpress/xmlrpc.php
X-Powered-By:PHP/5.3.27
[/php]
Content-Encoding:此次响应体的内容编码，这个就是与客户端的Accept-Encoding对应的
Content-Type:响应的信息的类别，与客户端Accept-Type对应的
Transfer-Encoding:传输编码，注意传输编码是为了在网络上传送更快，注意和内容编码的区别
Chareset=UTF-8: 响应的信息的字符集
Date:此次响应的时间
Expires: 缓存有关，下面会详细说明
link:此次请求的URL
server: 处理此次请求的服务器的信息
via:服务器的IP
永久连接
我们需要知道的是 http协议是基于TCP协议的，客户端和服务器建立连接的时候，需要三次握手，不过http是无状态的，短连接，也就是当数据请求完整后，就会断开连接。第二点我们需要了解的是，在发起一个URL请求一个html页面, html页面中的类似于<img src="/path/to">， <script src=""></script>需要自动向服务器服务器请求图片，css，js文，也就是说，向服务器发起一个请求，可能需要多次请求服务器，才能把完整的信息请求完整。
如果每次请求都建立一个tcp连接，这样无疑增加http服务器的压力，于是就有了永久连接，只需要建立一次tcp请求，并保持此连接直到所有的数据都请求完整。
那么客户端是如何与服务器协商来保持永久连接的呢。
首先，在http/1.1协议中，作为服务器的一方，假设客户端打算每次请求都是永久连接，除非客户端不想发起永久链接，那他就给服务器发一个信息，说我不想和你链接了，我们断开吧。这个信息就是Connection头部中包括连接符"close"。服务器收到这个Connection指令后，就和客户端断开链接了
如果服务器不打算和客户端保持永久链接了，他也会给客户端发同样的信息，告诉客户端，这样，永久链接就不存在了。也就是说，客户端和服务器都可以决定到底是否要维持永久链接。
如果保持了永久链接后，客户端可以向服务器发送多个请求，而不需要等待每个响应，服务器接收到请求后，依次响应这些请求，这就是为什么有时候请求一个html，发现图片没有请求成功，当网页依然可以显示其他成功请求的内容。
Connection: keep-alive
那我们是否需要手动的设置这个指令呢，答案是不需要，在http/1.1中，Connection的属性默认是keep-alive,也就是说，当response header中如果没有这个指令，则默认是keep-alive。我们并不需要去设置这样的属性，理解即可。
缓存
Web缓存位于Web服务器之间（1个或多个，内容源服务器）和客户端之间（1个或多个）：缓存会根据进来的请求保存输出内容的副本，例如html页面， 图片，文件（统称为副本），然后，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。
减少相应延迟：因为请求从缓存服务器（离客户端更近）而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快；
减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。
浏览器缓存
对于新一代的Web浏览器来说（例如：IE，Firefox）：一般都能在设置对话框中发现关于缓存的设置，通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作：在同一个会话过程中（在当前浏览器没有被关闭之前）会检查一次并确定缓存的副本足够新。这个缓存对于用户点击“后退”或者点击刚访问过的链接特别有用，如果你浏览过程中访问到同一个图片，这些图片可以从浏览器缓存中调出而即时显现。
代理服务器缓存
Web代理服务器使用同样的缓存原理，只是规模更大。代理服务器群为成百上千用户服务使用同样的机制；大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备；
由于带路服务器缓存并非客户端或者源服务器的一部分，而是位于原网络之外，请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器：告诉浏览器使用 那个代理，另外一个是通过中间服务器：这个中间服务器处理所有的web请求，并将请求转发到后台网络，而用户不必配置代理，甚至不必知道代理的存在；
代理服务器缓存：是一个共享缓存，不只为一个用户服务，经常为大量用户使用，因此在减少相应时间和带宽使用方面很有效：因为同一个副本会被重用多次。
网关缓存
也被称为反向代理缓存或间接代理缓存，网关缓存也是一个中间服务器，和内网管理员部署缓存用于节省带宽不同：网关缓存一般是网站管理员自己部署：让他们的网站更容易扩展并获得更好的性能；
请求有几种方法被路由到网关缓存服务器上：其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器；
我的理解是，关于代理服务器，服务器等缓存是管理员设置的，比如nginx可以通过缓存设置配置缓存一些静态文件，当访问这些文件的时候，直接从缓存里面获取，并返回状态not modified 304
HTML meta标签和HTTP 头信息
HTML的编写者会在文档的区域中加入描述文档的各种属性，这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期；
META标签使用很简单：但是效率并不高，因为只有几种浏览器会遵循这个标记（那些真正会“读懂”HTML的浏览器），没有一种缓存代理服务器能遵循这个 规则（因为它们几乎完全不解析文档中HTML内容）；有事会在Web页面中增加：Pragma: no-cache这个META标记，如果要让页面保持刷新，这个标签其实完全没有必要。
如果你的网站托管在ISP机房中，并且机房可能不给你权限去控制HTTP的头信息（如：Expires和Cache-Control），大声控诉：这些机制对于你的工作来说是必须的；
另外一方面： HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的，一般由Web服务器自动生成。但是，根据 你使用的服务，你可以在某种程度上进行控制。在下文中：你将看到一些有趣的HTTP头信息，和如何在你的站点上应用部署这些特性。
HTTP头信息发送在HTML代码之前，只有被浏览器和一些中间缓存能看到，一个典型的HTTP 1.1协议返回的头信息看上去像这样：
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html
在头信息空一行后是HTML代码的输出，关于如何设置HTTP头信息请参考实现章节；
Pragma HTTP头信息 (为什么它不起作用)
很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此：HTTP的规范中，响应型头信息没有任何关于Pragma属性的说明，而讨论了的是请求型头信息 Pragma属性（头信息也由浏览器发送给服务器），虽然少数集中缓存服务器会遵循这个头信息，但大部分不会。用了Pragma也不起什么作用，要用就使 用下列头信息：
使用Expires（过期时间）HTTP头信息来控制保鲜期
Expires（过期时间） 属性是HTTP控制缓存的基本手段，这个属性告诉缓存器：相关副本在多长时间内是新鲜的。过了这个时间，缓存器就会向源服务器发送请求，检查文档是否被修改。几乎所有的缓存服务器都支持Expires（过期时间）属性；
大部分Web服务器支持你用几种方式设置Expires属性；一般的：可以设计一个绝对时间间隔：基于客户最后查看副本的时间（最后访问时间）或者根据服务器上文档最后被修改的时间；
Expires头信息：对于设置静态图片文件（例如导航栏和图片按钮）可缓存特别有用；因为这些图片修改很少，你可以给它们设置一个特别长的过期时间，这会使你的网站对用户变得相应非常快；他们对于控制有规律改变的网页也很有用，例如：你每天早上6点更新新闻页，你可以设置副本的过期时间也是这个时间，这样缓存 服务器就知道什么时候去取一个更新版本，而不必让用户去按浏览器的“刷新”按钮。
过期时间头信息属性值只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，副本会过期，记住：HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：
Expires: Fri, 30 Oct 1998 14:19:41 GMT
所以使用过期时间属性一定要确认你的Web服务器时间设置正确，一个途径是通过网络时间同步协议（Network Time Protocol NTP），和你的系统管理员那里你可以了解更多细节。
虽然过期时间属性非常有用，但是它还是有些局限，首先：是牵扯到了日期，这样Web服务器的时间和缓存服务器的时间必须是同步的，如果有些不同步，要么是应该缓存的内容提前过期了，要么是过期结果没及时更新。
还有一个过期时间设置的问题也不容忽视：如果你设置的过期时间是一个固定的时间，如果你返回内容的时候又没有连带更新下次过期的时间，那么之后所有访问请求都会被发送给源Web服务器，反而增加了负载和响应时间；
Cache-Control（缓存控制） HTTP头信息
HTTP 1.1介绍了另外一组头信息属性：Cache-Control响应头信息，让网站的发布者可以更全面的控制他们的内容，并定位过期时间的限制。
有用的 Cache-Control响应头信息包括：
max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
public — 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
no-store — 强制缓存在任何情况下都不要保留任何副本
must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用
举例:
Cache-Control: max-age=3600, must-revalidate
如果你计划试用Cache-Control属性，你应该看一下这篇HTTP文档，详见参考和深入阅读；
校验参数和校验
在Web缓存如何工作： 我们说过：校验是当副本已经修改后，服务器和缓存之间的通讯机制；使用这个机制：缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
校验参数非常重要，如果1个不存在，并且没有任何信息说明保鲜期（Expires或Cache-Control）的情况下，缓存将不会存储任何副本；
最常见的校验参数是文档的最后修改时间，通过最后Last-Modified头信息可以，当一份缓存包含Last-Modified信息，他基于此信息，通过添加一个If-Modified-Since请求参数，向服务器查询：这个副本从上次查看后是否被修改了。
HTTP 1.1介绍了另外一个校验参数： ETag，服务器是服务器生成的唯一标识符ETag，每次副本的标签都会变化。由于服务器控制了ETag如何生成，缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
所有的缓存服务器都使用Last-Modified时间来确定副本是否够新，而ETag校验正变得越来越流行；
所有新一代的Web服务器都对静态内容（如：文件）自动生成ETag和Last-Modified头信息，而你不必做任何设置。但是，服务器对于动态内容（例如：CGI,ASP或数据库生成的网站）并不知道如何生成这些信息，参考一下编写利于缓存的脚本章节；
创建利于缓存网站的窍门
除了使用新鲜度信息和校验，你还有很多方法使你的网站缓存友好。
保持URL稳定： 这是缓存的金科玉律，如果你给在不同的页面上，给不同用户或者从不同的站点上提供相同的内容，应该使用相同的URL，这是使你的网站缓存友好最简单，也是 最高效的方法。例如：如果你在页面上使用 “/index.html” 做为引用，那么就一直用这个地址；
使用一个共用的库存放每页都引用的图片和其他页面元素；
对于不经常改变的图片/页面启用缓存，并使用Cache-Control: max-age属性设置一个较长的过期时间；
对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间；
如果数据源（特别是下载文件）变更，修改名称，这样：你可以让其很长时间不过期，并且保证服务的是正确的版本；而链接到下载文件的页面是一个需要设置较短过期时间的页面。
万不得已不要改变文件，否则你会提供一个非常新的Last-Modified日期；例如：当你更新了网站，不要复制整个网站的所有文件，只上传你修改的文件。
只在必要的时候使用Cookie，cookie是非常难被缓存的，而且在大多数情况下是不必要的，如果使用cookie，控制在动态网页上；
减少试用SSL，加密的页面不会被任何共享缓存服务器缓存，只在必要的时候使用，并且在SSL页面上减少图片的使用；
使用可缓存性评估引擎，这对于你实践本文的很多概念都很有帮助；
编写利于缓存的脚本
脚本缺省不会返回校验参数（返回Last-Modified或ETag头信息）或其他新鲜度信息（Expires或Cache-Control），有些动态脚本的确是动态内容（每次相应内容都不一样），但是更多（搜索引擎，数据库引擎网站）网站还是能从缓存友好中获益的。
一般说来，如果脚本生成的输出在未来一段时间（几分钟或者几天）都是可重复复制的，那么就是可缓存的。如果脚本输出内容只随URL变化而变化，也是可缓存的；但如果输出会根据cookie，认证信息或者其他外部条件变化，则还是不可缓存的。
最利于缓存的脚本就是将内容改变时导出成静态文件，Web服务器可以将其当作另外一个网页并生成和试用校验参数，让一些都变得更简单，只需要写入文件即可，这样最后修改时间也有了；
另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息，虽然通过Expires头信息也可以实现，但更容易的是用Cache-Control: max-age属性，它会让首次请求后一段时间内缓存保持新鲜；
如果以上做法你都做不到，你可以让脚本生成一个校验属性，并对 If-Modified-Since 和/或If-None-Match请求作出反应，这些属性可以从解析HTTP头信息得到，并对符合条件的内容返回304 Not Modified（内容未改变），可惜的是，这种做法比不上前2种高效；
其他窍门：
尽量避免使用POST，除非万不得已，POST模式的返回内容不会被大部分缓存服务器保存，如果你发送内容通过URL和查询（通过GET模式）的内容可以缓存下来供以后使用；
不要在URL中加入针对每个用户的识别信息：除非内容是针对每个用户不同的；
不要统计一个用户来自一个地址的所有请求，因为缓存常常是一起工作的；
生成并返回Content-Length头信息，如果方便的话，这个属性让你的脚本在可持续链接模式时：客户端可以通过一个TCP/IP链接同时请求多个副本，而不是为每次请求单独建立链接，这样你的网站相应会快很多；
status code
100 Continue
初始的请求已经接受，客户应当继续发送请求的其余部分
101 Switching Protocols
服务器将遵从客户的请求转换到另外一种协议
200 OK
一切正常，对GET和POST请求的应答文档跟在后面
201 Created
服务器已经创建了文档，Location头给出了它的URL。
202 Accepted
已经接受请求，但处理尚未完成。
203 Non-Authoritative Information
文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝
204 No Content
没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的
205 Reset Content
没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容
206 Partial Content
客户发送了一个带有Range头的GET请求，服务器完成了它
300 Multiple Choices
客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
302 Found
类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
303 See Other
类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy
客户请求的文档应该通过Location头所指明的代理服务器提取
307 Temporary Redirect
和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码： 当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
400 Bad Request
请求出现语法错误。
401 Unauthorized
客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
403 Forbidden
资源不可用。
404 Not Found
无法找到指定位置的资源
405 Method Not Allowed
请求方法（GET、POST、HEAD、Delete、PUT、TRACE等）对指定的资源不适用。
406 Not Acceptable
指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容
407 Proxy Authentication Required
类似于401，表示客户必须先经过代理服务器的授权。
408 Request Timeout
在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。
409 Conflict
通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。
410 Gone
所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。
411 Length Required
服务器不能处理请求，除非客户发送一个Content-Length头。
412 Precondition Failed
请求头中指定的一些前提条件失败
413 Request Entity Too Large
目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头
414 Request URI Too Long
URI太长
416 Requested Range Not Satisfiable
服务器不能满足客户在请求中指定的Range头
500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求
501 Not Implemented
服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求
502 Bad Gateway
服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答
503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头
504 Gateway Timeout
由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答
505 HTTP Version Not Supported
服务器不支持请求中所指明的HTTP版本
缓存部分参考文章：http://www.chedong.com/tech/cache_docs.html
个人博客：www.hellosunnyge.com
5065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
