HTTP RFC解析

HTTP协议（HyperText Transfer Protocol，超文本传输协议）HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。

HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

流程：

一次HTTP操作称为一个事务，其工作过程可分为四步： 1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。 2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。 3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。
如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。HTTP是基于传输层的TCP协议，而TCP是一个端到端的面向连接的协议。所谓的端到端可以理解为进程到进程之间的通信。所以HTTP在开始传输之前，首先需要建立TCP连接，而TCP连接的过程需要所谓的“三次握手”。在TCP三次握手之后，建立了TCP连接，此时HTTP就可以进行传输了。一个重要的概念是面向连接，既HTTP在传输完成之间并不断开TCP连接。

RFC(Request For Comments意即“请求注解”， 包含了关于Internet的几乎所有重要的文字资料。通常，当某家机构或团体开发出了-套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet 上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见;绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识。

RFC分类检索:

以下根据RFC被公布时的状态把RFC索引划分成几类:

Standards(标准) 
Draft Standards(草 案标准)  Proposed Standards(提 案标准)

OTHER
RFCS(其他RFC)

Experimental(实验性的) 
Informational(知识性的)  Historic(历史性的)Early
RFCs (before IETF standards track早期的， 在IETF标准化之前)

RFC
SUB- SERIES(RFC子集)

Standards
(标准，STD)

STD
RFC：按照RFC1311的定义，STD RFC是指那些已经或者致力于成为Internet标准的RFC。只有经过完全Internet标准化过程的RFC才可以有STD编号，STD编号是不变的，而其涉及到的 RFC文档可能不只一个，其RFC编号也会更新。如STD13(Domain Name System）就涉及RFC1 034和RFC1035。STD的标准化过程要经过几个步骤，首先由IETF起草标准（也可能是其他组织和个人，但一般都是和IETF共同完成的），形成Internet Draft(ID),ID没有RFC编号。如果ID在6个月内IESG没有建议成为RFC，则取消此ID。成为RFC后，还要经过一系列的审查、修订、测试等才能最终成为Internet标准。

Best
Current Practice(最优当前实现，BCP)

BCP RFC：由于Internet应用领域广泛，各种不同的组织有不同的使用目的和使用规则，IETF除了建议STD以外，也有必要对于Internet的使用和管理提供一些一般性的指导，同时也为I ETF、IAB、IESG提供一种渠道，以便推动某一方面的工作，反映其技术趋向，反映这些组织本身的工作进展。于是，1995年以RFC1818定义了BCP，即Best Current Practice。BCP同时有一个BCP编号和一个RFC编号，一旦约定了一个BCP编号，就不会再变，而其RFC编号则可能会经过修订不断更新。例如反映Internet标准化工作程序的BCP9的RFC编号就从RFC16 02上升到RFC2026，相应地就废弃了RFC1602。BCP在发表以前，以电子邮件的形式广泛征求IETF的意见，经过IESG的审查，通过后即正式发表。但是BCP本身不是Internet标准。

For
Your Information (FYI)

FYI
RFC：FYI是For Your Information的简写，1990年发表的RFC1150(FYI1）定义了FYI,FYI也同时有一个FYI编号和一个RFC编号，FYI编号是固定的。FYI主要是提供有关Internet的知识性内容。如FYI4(RFC1594),"Answers to Commonly asked New Internet User
Quest ions"。所有的FYI在提交到RFC编辑以前，必须先经过IETF的User Services WorkingGro up审查。

其他RFC

除了STD、BCP、FYI以外还有其他一些RFC。从RFC899开始，所有以99结尾的RFC都是对此前99个RFC的一个概括。如RFC1999就是对RFC1900到RFC1999的一个简单概括。除了上述分类以外，还有一些描述RFC的方法。与Internet标准化过程（Internet Standards Process）有关的规范可以分为两类，即Technical
Specification(TS),Applicability Statement(AS）。TS是对协议、规则、格式、实用程序的描述。AS是描述在何种环境，以及怎样在Internet中使用TS;AS所涉及的并不一定全是Internet标准，比如IEEE、ITU、ISO组织的一些标准，大家所熟悉的ASCII标准就是一例。AS应该对其涉及的TS规定相应的级别"Requirement Level",这些"Require ment Level"如下：
·Required(Req），相当于必须实现，如IP ICMP; ·Recommended(Rec），鼓励使用，如TELNET; ·Elective(Elc），可选择的； ·Limited Use，只限于特定的用户，一般说来用于对一些新的协议做试验； ·Not Recommended，不要使用，很可能是过时的。"Maturity
Level"也是用来描述TS和AS的一种方式，它反映这些标准是否成熟。对于致力于成为STD的TS和AS有三种"Maturity Level"。·Proposed
Standard，基本成熟，但还需要进一步的试验证实其可行性。除非是用来验证该协议的可行性，不要将其视为标准实现。·Draft Standard，需要两个独立的，而且具有相互操作性的实例验证该协议的每一个方面。可以将其视为最终的标准草案； ·Internet Standard，最终的Internet标准，同时赋予一个STD编号。除此之外的TS和AS分为以下几种"Maturity Level"。·Experimental，一般是反映一些研究和开发的成果，只应将此看作是一般性的信息。·Informational，反映与Internet标准有关的一般性信息。有些也是有关非Intern et组织开发的一些协议，但必须得到协议开发者的许可。·Historic，是一些被新的标准取代或者是已经过时废弃不用的标准。STD1(RFC2200）——Internet Official Protocol
Standards，定期更新，反映最新的 Internet标准。另外，对于关注Internet的人来说，应该经常注意查阅BCP9的最新内容。