HTTP缓存ETAG和Last-Modified
基础知识
????????1)?什么是”Last-Modified”??
????????在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样：?
????????Last-Modified:?Fri,?12?May?2006?18:53:33?GMT?
????????客户端第二次请求此URL时，根据?HTTP?协议的规定，浏览器会向服务器传送?If-Modified-Since?报头，询问该时间之后文件是否有被修改过：?
????????If-Modified-Since:?Fri,?12?May?2006?18:53:33?GMT?
????????如果服务器端的资源没有变化，则自动返回?HTTP?304?（Not?Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。?
????????2)?什么是”Etag”??
????????HTTP?协议规格说明定义ETag为“被请求变量的实体值”?（参见?——?章节?14.19）。?另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式：?
????????ETag:?"50b1c1d4f775c61:df3"?
????????客户端的查询更新格式是这样的：?
????????If-None-Match:?W/"50b1c1d4f775c61:df3"?
????????如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。
????????
??????Last-Modified和Etags如何帮助提高性能?
????????聪明的开发者会把Last-Modified?和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生?Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。?
????????过程如下:
????????????????1.?客户端请求一个页面（A）。?
????????????????2.?服务器返回页面A，并在给A加上一个Last-Modified/ETag。?
????????????????3.?客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。?
????????????????4.?客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。?
????????????????5.?服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。
?
?
?
也就是告诉你的浏览器5秒之后自动跳转到我的c++博客首页http://www.cppblog.com/cool-liangbing/。
??????????重定向常常用于自动跳转，从活动空间来看大概分两类：服务器内部跳转和服务器之间跳转。
服务器内部跳转常见于“登陆成功！5秒之后将自动进入首页”这种应用。而服务器之间跳转，种类稍微
多一些：(1)从服务器内跳往外部服务器; (2)从A服务器跳转到B服务器，接着跳转到C服务器;
(3) 从A服务器跳转到B服务器, 业务处理完毕之后又跳转到A服务器; (4) 从用户浏览器向A服务器
发送请求，在出口网关处进行重定向，如通过iptable之类，重定向到一个认证服务器B，返回一个
认证登陆的页面，当用户输入了正确的用户名和密码等，认证服务器B再通过http重定向到A服务器.
??????????以上所说的4种模式，前3种不值一提，而第4种则有些问题，不是那么容易跳转成功的。
不管你的认证服务器B是用现在的tomcat还是resin，或者其它流行的web服务器，最后发现总是
不能从认证服务器B跳到A服务器. 刚开始怀疑html那种方法不行，就改用javascript写法，改用jsp调用
方法，甚至直接在servlet里调用重定向接口，一一试遍，都失败了，这才怀疑可能不是程序写法上
的问题。
??????????在万般无奈情况下，使用CommView工具来抓包看看，从tcp包本身、http request和http response
包内容来看，看不出什么不对。但发现整个跳转只在一个tcp连接上进行，这使我想到iptable把向A服务器
的请求偷偷转发到认证服务器B, 而浏览器还认为认证服务器B就是A服务器, 所以只要这条tcp连接不断，
浏览器就一直认为这种映射关系正确，所以你怎么也跳转不到真正的目的地-A服务器.
??????????但是我们用老版本httpd或thttpd做web服务器，则可以正常跳转，何故？http协议版本差别：
老版本httpd或thttpd采用http1.0协议，而tomcat和resin这些jsp容器最新版本，大都已经实现了http1.1
协议了，对我们这个问题就是connection是采用非持久的还是持久模式，提取两个版本协议说明:
??????(1) http1.0:?
?????原文：Except for experimental applications, current practice requires that
??????the connection be established by the client prior to each request and
??????closed by the server after sending the response.?
?????翻译：实验室应用除外，当前的做法是客户端在每次请求之前建立连接，而服务器端在发送回应后关闭此连接。
??????(2) http1.1:
?????原文：In HTTP/1.0, most implementations used a new connection for each request/response exchange.?
????In HTTP/1.1, a connection may be used for one or more request/response exchanges,?
????although connections may be closed for a variety of reasons (see section 8.1).?
?????翻译：在HTTP/1.0协议下，大多数HTTP服务器实现对每一个请求/应答使用一个新连接.?而在HTTP/1.1协议下，一个或多个请求/应答使用同一个连接。
?????(section 8.1详细说明了为什么这么做)
???????从协议上分析清楚之后，我们怎么解决上面那个现实问题？肯定不能使用http1.1这种持久性连接。
查了下tomcat docment说明，默认实现了http1.1，现在版本的connector已经早不提供http1.0支持了，
难道我们要退回到http1.0的版本？那是多么痛苦的事情。再查查tomcat/conf/server.xml里关于connector
的配置,有一个参数connecttimeout,默认是20000ms, 作为服务器不可能争对socket accept()的，应该是
socket recv()的超时，那么我们设置它为比我们<meta http-equiv="refresh" content="5;url=xxx">里
秒数小就可以了，保证在跳转之前以前的tcp连接被tomcat服务器断开就可以了，当然iptable应该在认证成功
之后不再对这个上网用户发出的http请求重定向到认证服务器, 这个很容易做到，暂不提细节。
???????最后附上UML图以方便理解：
?????? 