HTTP RFC (2019/2/26)

HTTP协议描述的是发送方与接收方的通信协议，通过两方的自觉遵守而存在，当然有不少的浏览器并没有百分百遵守这份协议。HTTP是运行于应用层的协议，基于TCP协议而运作。基本上是客户/服务器对答模式，其中也包括在传输过程中的代理，网关，通道，缓存等都需要遵守这份协议。

HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统
灵活性及速度的要求。它是一个一般的、无状态的、基于对象的协议，通过对其请求方法
（request methods）进行扩展，可以被用于多种用途，比如命名服务器（name server）及分
布式对象管理系统。HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输
的数据。
HTTP自从1990年就在WWW上被广泛使用。该规范反映了“HTTP/1.0”的普通用法。
该规范描述了在大多数HTTP/1.0客户机及服务器上看起来已经实现的特性。规范将被
分成两个部分：HTTP特性的实现是本文档的主要内容，而其它不太通行的实现将被列在附
录D中。
实用的信息系统需要更多的功能，而不仅仅是数据的获取，包括搜索、前端更新及注解。
HTTP允许使用开放的命令集来表示请求的目的，它使用基于URI[2]（Uniform Resource
Identifier），即统一资源标识的规则来定位（URL[4]）或命名（URN[16]）方法所用到的资
源。HTTP使用与邮件（Internet Mail [7]）和MIME（Multipurpose Internet Mail Extensions [5]）
相似的格式来传递消息。
HTTP也作为用户代理、代理服务器/网关与其它Internet协议进行通讯的一般协议，这
些协议是，SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8]等。HTTP允许不同的
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消息在传输层如何使用的。