HTTP协议及其请求头分析

 

HTTP协议及其请求头分析

HTTP协议及其请求头分析 

 
众所周知，Internet的基本协议是TCP/IP协议，目前广泛采用的FTP、Archie Gopher等是建立在TCP/IP协议之上的应用层协议，不同的协议对应着不同的应用。 
 
WWW服务器使用的主要协议是HTTP协议，即超文体传输协议。由于HTTP协议支持的服务不限于WWW，还可以是其它服务，因而HTTP协议允许用 户在统一的界面下，采用不同的协议访问不同的服务，如FTP、Archie、SMTP、NNTP等。另外，HTTP协议还可用于名字服务器和分布式对象管 理。 
 
HTTP的早期版本为HTTP/0.9，它适用于各种数据信息的简洁快速协议，但是其远不能满足日益发展各种应用的需要。但HTTP/0.9作为HTTP 协议具有典型的无状态性：每个事务都是独立进行处理的，当一个事务开始就在客户与服务器之间建立一个连接，当事务结束时就释放这个连接。HTTP/0.9 包含Simple-Request&Simple-Responsed的报文结构。但是客户无法使用内容协商，所以服务器也无法返回实体的媒体类 型。  
 
1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不断丰富和发展中，HTTP/1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响 应，建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。其缺点是仍会发生下列问题：对用户请求响应慢、网络拥塞严 重、安全性等。  
 
1997年形成的HTTP/1.1，也就是现在普遍使用的协议，在持续连接操作机制中实现流水方式，即客户端需要对同一服务器发出多个请求时，其实现 在多数的网页都是有多部分组成（比如多张图片），可用流水线方式加快速度，流水机制就是指连续发出多个请求并等到这些请求发送完毕，再等待响应。这样就大 大节省了单独请求对响应的等待时间，使我们得到更快速的浏览。  
 
另外，HTTP/1.1服务器端处理请求时按照收到的顺序进行,这就保证了传输的正确性。当然，服务器端在发生连接中断时，会自动的重传请求，保证数据的完整性。  
 
HTTP/1.1还提供了身份认证、状态管理和Cache缓存等机制。这里，我想特别提一下关于HTTP/1.1中的Cache缓存机制对HTTP /1.0的不足之处的改进，它严格全面，既可以减少时间延迟、又节省了带宽。HTTP/1.1采用了内容协商机制，选择最合适的用户的内容表现形式。  
 
2.1　HTTP协议简介 
 
HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到 不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 
 
HTTP协议的主要特点可概括如下： 
 
1.支持客户/服务器模式。 
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。 
由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 
 
2.2　HTTP协议的几个重要概念 
 
1.连接(Connection)：一个传输层的实际环流，它是建立在两个相互通讯的应用程序之间。 
2.消息(Message)：HTTP通讯的基本单位，包括一个结构化的八元组序列并通过连接传输。 
3.请求(Request)：一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号 
4.响应(Response)：一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如"成功"或"没找到")和文档的MIME类型。 
5.资源(Resource)：由URI标识的网络数据对象或服务。 
6.实体(Entity)：数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。一个实体包括实体头信息和实体的本身内容。 
7.客户机(Client)：一个为发送请求目的而建立连接的应用程序。 
8.用户代理(User agent)：初始化一个请求的客户机。它们是浏览器、编辑器或其它用户工具。 
9.服务器(Server)：一个接受连接并对请求返回信息的应用程序。 
10.源服务器(Origin server)：是一个给定资源可以在其上驻留或被创建的服务器。 
11.代理(Proxy)：一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。 
代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处理没有被用户代理完成的请求。 
12.网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。 
网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。 
13.通道(Tunnel)：是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化 的。当被中继的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使 用。 
14.缓存(Cache)：反应信息的局域存储。 
 
2.3　HTTP协议的运作方式 
 
HTTP协议是基于请求／响应范式的。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是 MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误 的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 
 
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理(UA)和源服务器(O)之间通过一个单独的连接来完成(见图2-1)。 
 
图2-1 
 
当一个或多个中介出现在请求／响应链中时，情况就变得复杂一些。中介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)。一 个代理根据URI(Uniform Resource Identifier)的绝对格式来接受请求，重写全部或部分消息，通过URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它 服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防 火墙等)或者是中介不能识别消息的内容时，通道经常被使用。  
 
图2-2 
 
上面的图2-2表明了在用户代理(UA)和源服务器(O)之间有三个中介(A,B和C)。一个通过整个链的请求或响应消息必须经过四个连接段。这个区 别是重要的，因为一些HTTP通讯选择可能应用于最近的连接、没有通道的邻居，应用于链的终点或应用于沿链的所有连接。尽管图2-2是线性的，每个参与者 都可能从事多重的、并发的通讯。例如，B可能从许多客户机接收请求而不通过A，并且／或者不通过C把请求送到A，在同时它还可能处理A的请求。 
 
任何针对不作为通道的汇聚可能为处理请求启用一个内部缓存。缓存的效果是请求／响应链被缩短，条件是沿链的参与者之一具有一个缓存的响应作用于那个请求。下图说明结果链，其条件是针对一个未被UA或A加缓存的请求，B有一个经过C来自O的一个前期响应的缓存拷贝。 
 
图2-3 
 
在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。 
 
以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。 
 
首先，简单介绍基于HTTP协议的客户/服务器模式的信息交换过程，如图2-4所示，它分四个过程，建立连接、发送请求信息、发送响应信息、关闭连接。 
 
图2-4 
 
在WWW中，"客户"与"服务器"是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。WWW服务器运行时，一直在TCP80端口(WWW的缺省端口)监听，等待连接的出现。 
 
下面，讨论HTTP协议下客户/服务器模式中信息交换的实现。 　　 
 
1.建立连接  
连接的建立是通过申请套接字(Socket)实现的。客户打开一个套接字并把它约束在一个端口上，如果成功，就相当于建立了一个虚拟文件。以后就可以在该虚拟文件上写数据并通过网络向外传送。 
 
2.发送请求 
打开一个连接后，客户机把请求消息送到服务器的停留端口上，完成提出请求动作。 
HTTP/1.0　　请求消息的格式为： 
请求消息=请求行(通用信息|请求头|实体头) CRLF[实体内容] 
请求行=方法　请求URL　HTTP版本号　CRLF 
方法=GET|HEAD|POST|扩展方法 
URL=协议名称+宿主名+目录与文件名 
请求行中的方法描述指定资源中应该执行的动作，常用的方法有GET、HEAD和POST。不同的请求对象对应GET的结果是不同的，对应关系如下： 
对象　　　　　　GET的结果 
文件　　　　　　文件的内容 
程序　　　　　　该程序的执行结果 
数据库查询　　　查询结果 
HEAD--要求服务器查找某对象的元信息，而不是对象本身。 
POST--从客户机向服务器传送数据，在要求服务器和CGI做进一步处理时会用到POST方法。POST主要用于发送HTML文本中FORM的内容，让CGI程序处理。 
一个请求的例子为： 
GET http://networking.zju.edu.cn/zju/index.htm HTTP/1.0 
头信息又称为元信息，即信息的信息，利用元信息可以实现有条件的请求或应答 。 
请求头--告诉服务器怎样解释本次请求，主要包括用户可以接受的数据类型、压缩方法和语言等。 
实体头--实体信息类型、长度、压缩方法、最后一次修改时间、数据有效期等。 
实体--请求或应答对象本身。 
 
3.发送响应 
服务器在处理完客户的请求之后，要向客户机发送响应消息。 
HTTP/1.0的响应消息格式如下： 
响应消息=状态行(通用信息头|响应头|实体头)　CRLF　〔实体内容〕 
状 态 行=HTTP版本号　状态码　原因叙述 
状态码表示响应类型 
1××　　保留 
2××　　表示请求成功地接收 
3××　　为完成请求客户需进一步细化请求 
4××　　客户错误 
5××　　服务器错误  
响应头的信息包括：服务程序名，通知客户请求的URL需要认证，请求的资源何时能使用。 
 
4.关闭连接 
客户和服务器双方都可以通过关闭套接字来结束TCP/IP对话 
 
二．http协议请求头格式分析 
 
http协议的请求头分为10个部分。 
 
1.From: 
以internet邮件的形式，这一字段给出了正在请求的用户的名字。这一字段也许被用来登陆和一种存取保护的不安全形式。这一字段的解释是代表被给定用户的要求正在被执行，这个用户接受被执行方法的回应。 
这一字段里的因特网邮件地址并非一定要对发出请求的主机回应.例如，当一个请求正通过一个网关时，开始的发布者的地址应该被使用。 
假如能的话，邮件地址应该时一个有效的邮件地址而不管它实际上是否是一个internet邮件地址。 
 
2.Accept: 
这一字段包含了一个分隔的请求方案列表，它将在这个请求的回应中被接受。这一字段可能会根据RCFC822被包装成几行，并且这个字段不仅仅一次的发生也是被接受的，好像所有的入口已经在一个域种了。列表中每个入口的模式如下： 
<field> =   Accept: <entry> *[ , <entry> ] 
<entry> =   <content type> *[ ; <param> ] 
<param> =   <attr> = <float> 
<attr>   =   q / mxs / mxb 
<float> =   <ANSI-C floating point text represntation> 
注意在上述语法中分号的优先级高于逗号，这是为了符合多用途的忘记邮件扩充协议。 
记入没有Accept字段出现，那么假定无格式正文和html正文被接受。 
Example 
Accept: text/plain, text/html 
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c 
为了节省时间，并且也允许客户接受他们可能不会意识到的content type一个星号也许被使用在下面的地方，either the second half of the content-type value, or both halves。这仅仅被应用于Accept，而且不是对于content-type field of course的。 
Example 
Accept: *.*, q=0.1 
Accept: audio/*, q=0.2 
Accept: audio/basic q=1 
上面的例子可以这样解释：假如你有基本音频，那么传送它，否则传送给我一些其他的声音，或者不能那样作，那么仅仅给我你所得到的。 
Type parameters 
  在（content type）中参数对于描述决议，颜色深度等等是特别重要的。他们将允许一个客户来在Accept字段中指定它的设备的决议。这也许允许server在传输 时通过减少一个图片的resultion来大大的节约。并且使一个更适合的用户时间的黑白图象被选中而不是给客户一个彩色图片来转换成单色的。 
These parameters are to be specified when types are registered.. @@ TBS.Sugestions include the following. Please feed back any references to existing improved abbreviations for these: 
下面这些参数是当类型被注册时而被具体详细说明的。 
  Dpi 
  Dots per inch: pixels per inch [cm?!]  
  pxmax  
  Maximum width in pixels (image or video)  
  pymax  
  Maximum height in pixels  
  bits  
  Bits per sample (sound) or pixels (graphics)  
  mchrome  
  Grayscale or black and white (no value)  
  sps  
  Samples (sound) or frames (video) per second  
  Length  
  Total size of object in bytes [bits?]  
 
3.Accept-Encoding: 
和Accept一样，但是仅列出了在响应中是可接受的Content-Encoding types 
<field> =   Accept-Encoding: <entry> *[ , <entry> ] 
<entry> =   <content transfer encoding> *[ , <param> ] 
Example： 
Accept-Encoding: x-compress; x-zip 
 
4。Accept-Language: 
和Accept一样但是列出了在响应中更好的Language values。在一个未详细说明的语言中一个响应不是非法的。 
 
5．User-Agent： 
假如存在的话，这一行给出了被原始用户使用的软件程序。这是为了统计和protocol violations的追踪而给出的。第一个白色空格划定了单词必须是软件产品名有一个可选的斜线和版本说明。其他形成了用户代理的部分产品也许被作为分开的单词被安排。 
<field>   =   User-Agent: <product>+ 
<product> =   <word> [/<version>] 
<version> =   <word> 
Example: 
User-Agent: LII-Cello/1.0 libwww/2.5 
 
6．Referer: 
这个可选的header field允许客户详细说明，为了server的好处，文档的地址或者文档中的元素，URI通过文档的地址或者文档中的元素在请求中被获得。 
这允许一个服务器来产生向后对文档的链接，它允许坏链接为了维护而被跟踪。 
假如一个部分的URI被给出那么它应该被解析到相应的请求对象的URI。 
Example: 
Referer: http://www.w3.org/hypertext/DataSources/Overview.html 
 
7．Authorization: 
假如这一行存在的话它包含了授权信息。格式也是被指定的。这一字段的格式是在可扩展的形式。第一个单词是一个使用中的被授权的系统的规范。 
Basic 
Specification for current one implemented by AL Sep 1993. 
  PGP/PEM Encryption（pgp/增强的加密电子邮件 密码术） 
  People at NCSA are designing a PGP/PEM based protection system. 
  User/Password scheme 
  Authorization: user fred:mypassword 
  设计名是"user"。第二个单词是一个用户名，有一个被冒号分开的可选的密码，就好像在ftp的URL语法一样。没有密码的话这提供了一个非常低级的安全保证，有了密码，它提供了一个低级安全保证作为未定义的FTP,Telnet等等。 
  Koreros 
  Authorization: kerberos kerberos authentications parameters 
  Kerberos的确认参数格式被具体指定。 
 
  8．ChargeTo: 
  假如这一行存在地话，它包括了被请求的方法的程序的帐户信息。格式是TBS 
  （To Be Specified）这个字段的格式必须是在扩展模式的。第一个单词以一个namespaces的说明开始。这和扩展URLㄒ搴芟瘛５鼻懊挥衝amespaces被定义。Namespaces见被随着注册确认而注册。 
  这行的其余部分的格式是一个系统有关的函数但是它被推荐这包含了一个被用户确认得本次事务的最大花费和一个花费单元。 
  If-Modified-Since: date 
  这个请求头被随着get方法使用使之有条件。假如请求文档直到被定义还没改变得花那么文档不会被发送，但是会有一个Not Modified 304 回应。 
  这个字段的格式和日期的一样。 
   
  9.Pragma: 
  语法和其它的http中的多值字段一样，就像Accept字段，名以上是一个冒号分开的入口列表对他来说可选的参数是被汉欧挚摹? 
  Pragma 指示应该被服务器理解，对它来说是相对的，例如，一个代理服务器当前仅仅一个pragma被定义：no-cache  
  当当前的代理不应该从缓存返回一个文档时，即使它还没有被到期，但是它总应该从实际存在地服务器请求文档。 
  Pragma应该被通过代理实现，甚至他们也许对代理本身有意义。当请求不得不通过许多代理时，这在事件中是必须的，而且pragma应该队所有的他们有效。 
 
以下是用jetcar在亦多下载网络吸血鬼的信息 
 
Thu Mar 14 14:36:56 2002 正在连接 202.113.29.120 [IP=202.113.29.120:80] 
//正在连接主机，解析ip地址 
Thu Mar 14 14:36:57 2002 已连接. 
Thu Mar 14 14:36:57 2002 GET /index.dhtml?op=download&ino=2941&type=file HTTP/1.1 //请求行，表示用get方式取得文件，并且是HTTP1.1版本 
Thu Mar 14 14:36:57 2002 HOST: 202.113.29.120 //主机名 
Thu Mar 14 14:36:57 2002 ACCEPT: */*   //accept字段，接受的数据类型 
Thu Mar 14 14:36:57 2002 Referer: http://202.113.29.120//从该网址转发而来 
Thu Mar 14 14:36:57 2002 User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)//客户端标识 
Thu Mar 14 14:36:57 2002 Pragma: no-cache //参数，表示与以前的服务器兼容 
Thu Mar 14 14:36:57 2002 Cache-Control: no-cache //不使用缓存 
Thu Mar 14 14:36:57 2002 Connection: close //表示非持续性连接。 
以下为response字段 
Thu Mar 14 14:36:58 2002 HTTP/1.1 302 Found 
服务器使用HTTP/1.0协议，状态值（Status Code）为200，状态为OK，表示文件可以读取 
Thu Mar 14 14:36:58 2002 Date: Thu, 14 Mar 2002 06:52:16 GMT//现在的时间，用格林威治时间表示 
Thu Mar 14 14:36:58 2002 Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 
//服务器类型 
Thu Mar 14 14:36:58 2002 X-Powered-By: PHP/4.0.4pl1 
Thu Mar 14 14:36:58 2002 Set-Cookie: PHPSESSID=6cf938f3c6ce551971c787ac8b3c0f5b; path=/ 
Thu Mar 14 14:36:58 2002 Expires: Thu, 19 Nov 1981 08:52:00 GMT//请求文档过期时间 
Thu Mar 14 14:36:58 2002 Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Thu Mar 14 14:36:58 2002 Pragma: no-cache 
Thu Mar 14 14:36:58 2002 Content-Disposition: inline; filename=netvampire33.zip 
Thu Mar 14 14:36:58 2002 Location: ftp://202.113.29.120/pub/Dos_Windows/Internet/Client/Download/Net Vampire/3.3/netvampire33.zip 
Thu Mar 14 14:36:58 2002 Connection: close 
Thu Mar 14 14:36:58 2002 Transfer-Encoding: chunked 
Thu Mar 14 14:36:58 2002 Content-Type: text/html 
 
备注：服务器返回的各类错误 
当服务器响应时，其状态行的信息为HTTP的版本号，状态码，及解释状态码的简单说明。现将5类状态码详细列出：  
① 客户方错误  
100　 继续  
101　 交换协议  
② 成功  
200 　OK  
201 　已创建  
202　 接收  
203　 非认证信息  
204　 无内容  
205 　重置内容  
206　 部分内容  
③ 重定向  
300 　多路选择  
301　 永久转移  
302　 暂时转移  
303　 参见其它  
304 　未修改（Not Modified）  
305　 使用代理  
④ 客户方错误  
400　 错误请求（Bad Request）  
401 　未认证  
402 　需要付费  
403　 禁止（Forbidden）  
404　 未找到（Not Found）  
405　 方法不允许  
406　 不接受  
407　 需要代理认证  
408　 请求超时  
409　 冲突  
410 　失败  
411 　需要长度  
412　 条件失败  
413 　请求实体太大  
414 　请求URI太长  
415 　不支持媒体类型  
⑤ 服务器错误  
500　 服务器内部错误  
501　 未实现（Not Implemented）  
502　 网关失败  
504 　网关超时  
505 　HTTP版本不支持