HTTP 与 RFC

这几天，阅读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和FTP也是有所了解的，看了一遍英文版的RFC文档，虽然很痛苦，但是感觉是有所不同的。

1，HTTP所表达的控制以及描述性相关的信息都包含在了HTTP的起始行和首部之中。BNF的使用使得自己能够清晰的梳理出起始行和首部中所有类别的元信息。对于每一类的元信息具体包含哪些内容也能够有所了解。这一抽象的方法不仅HTTP协议定义的时候比较严谨之外，在实现HTTP解析器（浏览器）的时候参照BNF写代码是非常容易实现的。这也提醒了我们在编写相关的系统设计方案的时候是可以借鉴类似的方法的。毕竟使用文字表述的设计方案存在这问题遗漏，表述不够清晰，不同人理解有所差异等方面的问题。（我们会看到在FTP之中也有类似的方法，状态图）。HTTP被设计成为一种非常容易扩展的协议，因此协议时松散的。头域可以加入需要的头部名和指定的值，尽管有的头部没有加入RFC标准，但是可能成为约定成俗的标准(虽然这会给HTTP的安全性带来了挑战)，由此可以看出良好的设计方案在一开始的时候就考虑到其以扩展性，这也是HTTP能够长期存在，不断发展的原因。

2，FTP采用的是控制和数据相分离的模式实现文件的传送。首先这一设计思想在程序的设计之中本身就很常见。FTP采用的是命令+响应码的形式来控制文件传输的功能，若干条命令+不同类别的响应码会导致不同的结果，其组合方式多种多样，但是FTP的RFC文档给出了这些组合的状态图。六种类型的状态图覆盖了FTP可能的所有情况。前面我们提到HTTP的BNF表示方法利于编写程序，这里的状态图同样给出了编写完备FTP软件的指导性方法。当然状态图也可以看出有的命令是有先后顺序的，但是大多数的命令是没有此要求的。

3，RTSP可以说基本复用了HTTP的设计思路，从请求和响应的消息组成可以清晰的看出。但是其也借鉴了FTP中相关的优秀思想。比如数据和控制的分离，RTSP的数据传输就是由RTP/RTCP等协议去实现的。在HTTP中，请求响应模式采用的是CS的模式，即客户端发起请求，服务器应答响应。FTP的就发生了变化，首先在FTP的架构之中存在这一个客户端控制这两个服务器的通信。两个SERVER的通信以及在FTP中的Port模式下（数据连接是由服务器发起的），这两种情况跟HTTP就很不相同。至于到了RTSP请求是双向的。

总的来说三种协议都是基于文本的应用层协议，基于文本的协议在需要某些属性、方法或者命令的时候能够比较方便的添加。相对与传输层以及网络层（虽然也有扩展）来说，固定的位置表达的含义是确定的，基于文本的协议比较灵活多变。当然协议最基本的分层原则也在HTTP，FTP以及RTSP中有所体现，即应用层协议应尽量减少其与下层之间的耦合性。虽然常见的HTTP都是基于TCP协议的，但是HTTP并不关心整个HTTP消息在传输层如何使用的。