这几天，阅读RFC2616认真学习一遍HTTP/1.1协议，一直认为要做互联网开发的话，一定要对于HTTP协议烂熟于胸，于是下定决心要将这个协议好好理解一遍。这两天，工作之余，拿着RFC就在那里读，对于HTTP协议有了不错的理解，对于其中的字段与机制有了一定的理解，于是静下心来，好好总结一下这两天的阅读收获，同时也是一个回顾复习。
HTTP协议描述的是发送方与接收方的通信协议，通过两方的自觉遵守而存在，当然有不少的浏览器并没有百分百遵守这份协议。HTTP是运行于应用层的协议，基于TCP协议而运作。基本上是客户/服务器对答模式，其中也包括在传输过程中的代理，网关，通道，缓存等都需要遵守这份协议。
阅读完RFC之后，较为难以理解的部分是关于连接机制与缓存机制，其他都基本上是字段与头部格式的定义，在里面就不一一列举，提供一个快查的网址：Quick reference to HTTP headers;
主要有两种比较重要的机制，在这里总结一下：
一， 连接机制;
HTTP/1.1支持两种连接机制，一种是非持久连接，第二种是持久连接。基本上默认是使用持久连接，因为这样能够减少建立连接时候的网络延时与CPU消耗。其中服务器与客户端都会假定连接没有关闭，除非对方传来的头文件包含" Connection:close"，不然连接将继续保持。客户端，服务器与代理都可以随时结束连接，而他们也应该有一套机制去重新搭建起连接，并保持正确性。每个客户端也只能与一个服务器保持两条连接。代理也只能保持2N条连接，N 为代理的活跃用户数。对于连接的时候，由用户向服务器端发送一个带有"Expect"的信息到服务器端，服务器端如果连接正常则返回一个100 ( continue )的信息到客户端，提示客户端可以继续发送。
HTTP对于传输道路上的元素也有一定的要求。也规定了不透明代理可以改变哪些字段，而不能改变哪些字段。
二．缓存机制;
HTTP中使用缓存主要有两个作用，一个是在很多情况下可以减少发送包，减少网络IO，使用“过期”机制来处理；第二个是可以减少发送整包的操作，减少带宽需求，使用“验证”机制来处理。
(1)“过期”机制(Expiration Model)，用于服务器端制定一个“过期时间”，主要有两种计算方式，按优先级顺序，第一种是年龄(Age)，第二种是过期时间(Expiration)。对于第一种，服务器会提供一个年龄字段（Age)与一个有效年龄(max-age)，而年龄的计算，则是采用服务器生成时的初始年龄再加上从服务器生成至缓存的时间。如果有Age 这个字段的存在，则说明这个消息不是第一手的，中间有缓存的存在。而要计算一个消息是否过期，则需要采用以下的方法：
if( max_age_value )
Freshness_lifetime = max_age_value ;
Else
Freshness_lifetime = expires_value - date_value ;
Response_is_fresh = ( freshness_lifetime > current_age ) ;
总体计算方法都比较直观与简单，而如果需要更新缓存的话，则可以加入以下字段：
Cache-Control : max-age = 0 ; OR Cache-Control : no-cache ;
(2)验证机制(Validation Model ) ,采用这种机制的时候，缓存先向服务器验证当前的缓存条目是否最新的，则收到304的提示表示 Not Modified，条目是最新的。否则则会收到服务器返回的新缓存条目。而进行验证的时候，可以使用两个标准，一个是使用服务器在原条目上的"Last-Modified"，使用条件GET(If-Modified-Since OR If-Not-Modified-Since)去查询。第二个是使用服务器为每个条目生成的"Entity Tag"，这个Tag如何生成完成由服务器去决定，因此也衍生出两种验证策略，一种是强验证，即如果一个条目发生了改变之后"Entity Tag"也马上变化的，第二种是使用弱验证，即条目变化了"Entity Tag"仍然保持不变，相对验证条件更弱。而对于是使用强验证还是弱验证则是取决于服务器端了。
接下来，就要做一个偷菜外挂了，尽量不看网上现有的资料，自己去分析HTTP协议通信过程~~~