HTTP模块方案设计

1、超文本协议模块方案介绍 HTTP协议WWW的基础协议是HTTP(Hyper Text Transfer Protocol), 它是TCP/IP协议集中的一个应用层协议,是基于端对端连接的TCP协议. 是一种面向分布,协作的超媒体信息系统的协议.它具有通用,无状态,面向对象等特点:l HTTP是一种通用协议.它所描述的是一种通用的语义和语法结构.因此除了用于WWW,还用于用户代理(User Agent,通常指浏览器等)和通向其他Internet系统的服务代理(Proxy)/网关(Gateway)间的通讯.后者一般连接其他的Internet协议模块,如那些基于SMTP,NNTP,FTP, 

2、;Gopher和WAIS的应用系统,从而实现各类Internet应用资源超媒体访问的集成.通过协议转换,可以对来自不同应用的资源进行超媒体访问,以简化用户代理的设计和实现.l HTTP是一种无状态的协议.通信双方(客户和服务器)都不必为互相通信而建立起的TCP连接存储任何状态信息,双方都可以根据它们之间交换的消息来确定如何响应.而不必存储状态,所以当接收到对方的消息后只要做一个响应便可以不再理它,知道它下一次发出消息为止,这样对与服务器而言,可以很容易为多个客户服务.l 作为一个通用的面向对象的协议,在HTTP中,资源对资源操作的方法是一起发送的.通过其请求/应答方法(命令),为许多系统如DN

3、S服务器,分布式对象管理系统所采用.以其简便快速而成为超媒体信息系统的基本协议.l 灵活性与内容-类型(content-type)标识 HTTP允许任意类型数据的传送，因此可以利用HTTP传送任何类型的对象，并让客户程序能够恰当地处理它们，内容-类型标识指示了所传输数据的类型。打个比方，如果数据是罐头，内容-类型标识就是罐头上的标签。 HTTP协议的发展历史HTTP作为WWW的支撑协议始于1990年,最早的HTTP/0.9只是一个简单的原始数据传输协议.经过几年的使用与发展,如今的WWW中广泛采用的是HTTP/1.0,即RFC1945.它通过引入类MIME(Multipurpose Inter

4、net Mail Extensions)格式消息,数据的元信息表示以及请求/响应语义修师符等改进了HTTP/0.9,但它不能对超媒体信息传输所需要的层次代理,缓冲,持续连接和虚拟主机提供足够的支持.为此Internet工程部IETF在1996年6月提交了新版的HTTP/1.1草案,它在HTTP/1.0的基础上增加了对层次代理,缓冲,持续连接和虚拟逐级的充分支持.以下讲解均以HTTP/1.1规范作为基础. RFC 2616 (HTTP1.1协议)的内容目前在Web中采用的HTTP协议的1.1版,即 RFC2616,它对HTTP协议的内容进行了详细规范的描述,其基本内容包括:(1) 一般语法和标识

5、符约定.其语法使用BNF(RFC822中的扩展巴科斯范式(Augmented Backus-Naur Form,BNF)描述.(2) 协议参数.包括协议的版本号,URI,字符集,编码方式以及媒体类型等.这些参数主要设在HTTP的请求/应答格式的各种头标域中.(3) HTTP消息.包括HTTP请求和应答,每种又分为简单式和完整式.协议对请求/应答的格式以及各域的相关内容,进行了详细的说明.这部分是协议的主要内容.(4) 访问权限.目前一般仅支持Basic访问方案,即用户名/用户口令方式.(5) 安全考虑.HTTP协议的工作模式HTTP协议的实现基于请求/应答模式.它是一种请求/响应协议.其基本运

6、作方式见下图. 建立TCP/IP连接客户->服务器 发送请求消息客户->服务器 发送响应消息客户<-服务器 关闭连接客户<-服务器 图1: HTTP的基本运作过程一个客户首先于服务器建立一个连接,并向服务器发送请求服务的消息,服务器收到请求消息后进行相应操作,然后发出一个响应消息给客户,最后关闭连接.其中客户与服务器是一个相对的概念,只存在于某个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器,这也就是说,对于HTTP中的程序它应具有客户与服务器的双重功能.HTTP的服务器还可以使其他类型的网关或服务代理,通过它们HTTP允许超媒体访问现存的Intern

7、et协议,如SMTP,NNTP,FTP,Gopher,WAIS等.在Internet上的通讯一般是建立在TCP/IP连接上的,HTTP的连接也不例外,其缺省端口是TCP 80端口,当然其他端口也可以使用.正常的握手过程要求客户在每一次发送请求之前建立连接,并由服务器在发送响应消息后关闭,但客户和服务器还必须具有处理任意一方因突发事件(如用户强制,自动超时或程序失败等)而发生关闭连接的能力.在这些情况下,通常不论当前状态怎样都中止当前请求.图1只是HTTP正常的运作过程,对突发情况并没有体现.从图1我们可以看出,当客户和服务器的一次请求/响应完成后,将断开它们之间的连接.在WWW服务中,经常会碰

8、到这样的情况:常常要求客户程序在一段较短时间内向同一服务器发送多个请求,如WWW页面中有内插图表(Inline Image)时.然而,在持续连接出现之前,每取回一个URL都需要重新建立一个独立的TCP连接,很显然,这样增加了HTTP服务器一端的开销,并且可能导致网络阻塞.为了解决这个问题,HTTP/1.1提供了持续连接功能,持续连接的好处有:l 减少了TCP连接建立和关闭的次数,从而节约了CPU时间和TCP协议控制块消耗的内存.l 减少了TCP连接建立时所发送的报文数,并给TCP控制进程足够的时间已确定网络的阻塞状态,从而减少了整个网络阻塞的发生次数.l 在一个TCP连接之上就可以实现HTTP

9、请求和相应的流水作业,这意味着程序可以不必等待响应就可以连续发出多个请求,减少了系统延迟,提高了单个TCP连接的使用效率.l 没有关闭TCP连接的负担就可以报告差错,从而促进HTTP平稳地发展.未来版本的HTTP客户可能为了优化而采用新的协议特性,如果这些客户和旧版本的服务器通信并收到差错报告,由于有了持续性连接,就可以在不关闭连接的情况下,采用旧的语义和语法规范重试. 客户与服务器建立连接后向服务器发出一个请求,其请求具有一定的格式.一个请求一般包括这些内容:请求方法,请求资源的 URI和协议的版本号的请求行;有关请求的其他信息和客户本身的信息;实体头和可能的实体内容.服务器应答客户端发来的

10、请求,其应答也具有一定的格式.一个应答一般包括这样的一些内容:HTTP协议版本号,状态代码和状态说明的状态行;服务器信息和进一步访问资源的URI以及WWW权限识别;实体头和可能的实体内容.决大多数HTTP通讯是从客户代理(通常为客户浏览器)发出对某资源的请求开始的,在最简单的情况下,这只需在客户代理和源服务器(存放请求资源的服务器)间建立一条连接即可.当请求/应答链路中有中介系统时,情况会复杂一些.一般由三种形式中介系统,即代理Proxy,网关Gataway和通道Tunnel.Proxy是客户端转发代理(既是服务器又是客户).它接受客户端的请求,必要时重写部分或全部请求信息,然后将重新格式化的

11、请求转发给请求所指的服务器.Gataway是源服务器的接受代理(是服务器).作为其他源服务器的上一层,在必要时,转换客户端的请求,以适应下层源服务器所采用的协议(一般为非HTTP协议,如FTP,Gopher等).Tunnel作为连接链路中的中继接点,它不改变消息内容.当连接链路要通过一中介(如防火墙.该中介可以不理解传送消息的内容)时,Tunnel才被使用.HTTP消息两种分类HTTP消息包括客户端请求消息和服务器应答消息:HTTP-message=Request|Response这两种类型的消息都由一个起始行,一个或多个头标域,一个空行(表示头标域结束)和一个可选的消息净荷组成:消息头标:H

12、TTP消息头标包括通用头标,请求头标,响应头标和实体头标等类型.每个头标字段由一个字段,加上冒号,而后跟一个值组成.一个消息的不同头标的接收顺序并不重要,然而,一般情况下最好按下列顺序发送:通用头标,请求头标,响应头标和实体头标.消息体:一个消息的消息体是用于运载请求或响应消息的实体内容.实体是请求或响应消息携带的数据,它包括实体头标和实体内容.消息体于实体内容的区别在于,消息体不仅包括实体内容,而且还包括经过传输编码处理的实体内容.generic_message=start_line *message_header CRLF message_body start_line=Request_l

13、ine|Status_line这里的*message_header表示形式符,message_header可以出现若干次(可以为0次).方括号表示可选;CRLF表示回车,换行符.HTTP的请求消息的扩展BNF表示如下:Request=Request_line *(general_header |request_header |entity_header CRLF message_body例如:_GET /test/mh-email.asp HTTP/1.0Referer: Connection: Keep-AliveUser-Agent: Mozilla/4.51 en (Win95; I)H

14、ost: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*Accept-Encoding: gzipAccept-Language: enAccept-Charset: iso-8859-1,*,utf-8Cookie: ASPSESSIONIDQGQGQQAD=AIHJBHPBNDLGGKPBPOGKDHOB _ 请求行有一个操作字段(token)开始,接着是Request-URI和协议版本号,最后以CRLF结尾.个项内容之间用空格分开,除了最后的CRLF外,Request-URI

15、中其他地方不能出现CR和LF: Request_line=Method Request_URI HTTP_VersionCRLF Method ="OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Sectio

16、n 9.8 | "CONNECT" ; Section 9.9 | extension-methodHTTP应答消息的扩展BNF表示如下:Response=Status_line *(general_header) |response_header |entity_header) CRLF message_body例如:_/1HTTP/1.1 200 OKServer: Microsoft-IIS/4.0Connection: keep-aliveDate: Wed, 12 May 1999 09:14:17 GMTContent-Type: image/gifAccept

17、-Ranges: bytesLast-Modified: Wed, 24 Jun 1998 02:58:00 GMTETag: "0ec86e51b9fbd1:10c0"Content-Length: 5357 (blank line)GIF89a?薜蕲蕙汁?鼢 /GIF图片余下部分省略_ 应答消息的头一行是状态行,其定义如下: Status_line=HTTP_Version Status_Code Reason_PhraseCRLF其中的状态代码Status_Code是一个3位数字的结果代码:原因短语Reason_Phrase是对状态代码的简短文字陈述.状态码供协议自动

18、机使用,而原因短语是为用户使用的.有时我们可以在浏览器的服务器返回状态中看到状态代码.状态代码的第一个数字定一个应答的类别,其余的两位数字只起编号作用.一共有5种应答类别:1xx:Informational 提示,收到并接受请求,继续请求其他部分;2xx:Success - 请求成功,操作指令被成功的接收到,理解和接受; 3xx:Redirection - 请求未完成,为了完成请求,必须采取进一步的操作;4xx:ClientError - 客户错,请求语法错或无法完成;5xx:ServerError - 服务器错,服务器无法完成有效的请求. HTTP状态码列表 Status-Code = &q

19、uot;100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "2

20、04" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303

21、" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402"

22、; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required |

23、 "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entit

24、y Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal

25、 Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-co

26、deHTTP的操作(全部共7种)1. OPTIONSOPTIONS操作说明了由Request-URI所标识的HTTP请求/应答链上有关通讯功能选项.客户使用该操作可以在对不同实体操作或传送实体的情况下获得某个实体的操作要求,功能选项,服务器的能力.对OPTIONS的应答是不能被缓存的.2. GETGET操作表示以实体的形式取回由Request-URI所标识的任何信息.如果Request-URI指向一个数据处理进程,那么该进程运行结果将作为应答消息包中的实体而返回.如果请求消息带有 If-Modified-Since,If-Unmodified-Since,If-Match,If-None-Ma

27、tch或If-Range头标域,则GET就变成”条件GET”;如果请求消息中含有Range头标域,这相当于一个”部分GET”.部分 GET只要求传送实体的一部分内容,这样就不必传送客户已拥有的数据,从而减轻网络负载.3. HEADHEAD操作和GET语义基本相同,但是HEAD规定应答消息包中不能含有消息净荷.使用该操作可以在不传送实体净荷的情况下获取实体的元信息,因此它经常被用来测试超文本链的有效性,可访问性和最近修改状态.4. POSTPOST操作用于请求目的服务器接收请求消息包中的实体,作为Request-URI所标识资源的一个新的从属.有了POST,可以在实体应用中完成如下的功能:.注解

28、已存在的资源.向BBS,新闻组或邮件列表张贴消息.向数据处理进程提供一组数据,如表格(form)提交结果.实现数据库的添加操作.(POST:用于客户向服务器传送数据,以便服务器作出相应的处理。POST方法经常用于向HTTP服务器提交HTML表格以便处理.例如,网上的联机就业服务中就是靠提交简历表格来找工作.当你填写了一份WWW页面表格后,浏览器通常就使用POST方法向服务器提交你输入的数据.)5. PUTPUT操作请求把携带的实体存放于Request-URI处,请注意它和POST的区别.如果Request-URI指向一个已经存在的资源,请求消息包中携带的实体将作为起始服务其上原资源的一个更新版

29、本;如果Request-URI所指向的资源不存在,而且该URI能被请求用户进程定义为一个新资源,那么服务器将用该URI创建一个新资源.POST操作和PUT操作的最根本的差别反映在Request-URI的含义中POST的URI标识了将对被携带实体进行处理的某个资源,该资源可能是一个数据处理进程,一个多协议网关或者一个接收注解信息的独立实体.而PUT请求中的URI标识了该请求所携带的实体本身,只有客户知道URI的确切含义,服务器绝不对其他资源实施被请求的操作.6. DELETEDELETE操作请求服务器删除由Request-URI标识的资源.不过DELETE操作可能受到服务器一端认为干预而不予执行

30、,所以即使从服务器返回的状态代码表明删除成功完成,客户也不能据此确认真正执行了删除.7. TRACETRACE操作用于引发请求消息包的远程应用自环测试.如果成功,请求消息的最后一个接收者应该把整个请求消息包作为相应消息的实体内容部分发送还给客户端.TRACE是客户可以了解到请求/响应链另一端数据接收的情况,并把接收的数据作为测试或诊断信息送回.HTTP的协议参数1. URI(Uniform Resource Identifiers)统一资源标识符URI是一种格式化字符串,可以用名字,地点或其他特征标识某个资源,因此URI有许多别名,如WWW地址,Universal Document Ideni

31、fiers(全局文档标识符),Uniform Resourct Names(统一资源名),以及大家很熟悉的统一资源定位器Uniform Resource Locators.2. 实体标记(Entity Tags)实体标记用于区分同一个被请求资源的不同实体.头标域 Etag,If-Match,If-None-Match和If-Range中使用了实体标记.3. 实体域单元(Entity-Range Unit)HTTP/1.1允许客户端请求服务器发送的应答消息中只包含原应答实体的一部分(实体域).头标域Range和Content-Range中用到了该协议参数.在当前版本中,HhHHTTP/1.1定义

32、实体域单元为一个字节.HTTP的头标域对实体头标域来说,术语发送方sender和接收recipient可能指客户或者服务器任何一方,这取决于发送或接收实体的当前实际行为.同样实体头标域即可用于请求消息,也可用于应答消息,但是不能用于被传输的实体.所以下面的通用头标域只能用于消息本身.消息中被表示的头标域可以认为是实体头标域.HTTP/1.1头标域的语法如下:genner_header=cache_control |Connection |Date |Program |Transfer_Encoding |Upgrade |Via主要的头标域包括Content_Base,Content_Leng

33、th,Content_Location,Content_Range,Content_Type,Date,Etag,Host,If_modified_Since,If_Range,Last_modified,Location,Pragma,Proxy_authenticate,Range等.头标域列表RFC#2616 14章 Header Field Definitions general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Sec

34、tion 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization

35、; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ;

36、 Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 response-header = Accept-Ranges ; Section 14.5 | Age ; Section 14.6 | ETag ; Section 14.19 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Retry-After ; Section 14.37

37、| Server ; Section 14.38 | Vary ; Section 14.44 | WWW-Authenticate ; Section 14.47 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Ra

38、nge ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header快速理解HTTP协议HTTP协议使Web服务器和浏览器可以通过Web交换数据.它是一种请求/响应协议,即服务器等待并响应客户请求.HTTP不维护与客户方的连接,它使用可靠的TCP连结,通常采用TCP 80端口. Web服务器运行着一个守护进程(HTTPDaemon),它始终在端

39、口80监听着来自远端客户的请求.当一个请求发来时,它就会产生一个子进程来处理当前请求,守护进程继续以后台方式运行,在端口80继续监听来自远端的连接请求.客户/服务器传输过程可以分为四个基本步骤:1)浏览器与服务器建立连接;2)浏览器向服务器请求文档;3)服务器响应浏览器请求;4)断开连接.HTTP是一种无状态协议,它不维护连接的状态信息.(注:最新RFC中有关HTTP协议概述RFC2616可在/Protocols/中找到)每个资源都有其特定的URL标识,经由各种不同的协议,对Internet上任何地方的信息都可以用URL定位或取回.URL可以指定FTP文件传输

40、,寻找新闻信息,定义用户的Email地址,标识HTTP文件和其他类型数据.URL中的字符不区分大小写.为了使客户端和服务器通信成为可能,HTTP协议建立了一种由请求和响应消息组成的Web语言.1) 客户请求客户请求包括如下信息:l 请求方法l 请求头l 请求数据请求方法是用于特定URL或Web页面的程序.表 快速理解-表1列出了可用的请求方法. 表1 HTTP请求方法=- 请求操作方法(共7种)描述=- (1) GET 请求指定文档 (2) HEAD 仅请求文档头 (3) POST 请求服务器接收指定文当作为可执行的信息 (4) PUT 用从客户端传送的数据取代指定文档中的内容 (5) DELETE 请求服务器删除指