HTTP协议的概要设计
- 格式：doc
- 大小：452.50 KB
- 文档页数：7
HTTP协议的概要设计
一. 功能需求
对以太网中通过http协议（80端口）传输的数据包进行分析、解析、组合,最后再现用户通过浏览器所看到的页面(因为时间紧迫,暂不进行动态页面的重组),若是不能重组的页面（或者暂时不能重组页面）及相关的资源保存到一个特定的目录下。
二. 实现的原理及过程
HTTP协议的工作模式
HTTP协议的实现基于请求/应答模式.它是一种请求/响应协议.其基本运作方式见下图.
建立TCP/IP连接
客户------------------------------------------------------->服务器
发送请求消息
客户------------------------------------------------------->服务器
发送响应消息
客户<-------------------------------------------------------服务器
关闭连接
客户<-------------------------------------------------------服务器
图1: HTTP的基本运作过程
一个客户首先于服务器建立一个连接,并向服务器发送请求服务的消息,服务器收到请求消息后进行相应操作,然后发出一个响应消息给客户,最后关闭连接.其中客户与服务器是一个相对的概念,只存在于某个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器,这也就是说,对于HTTP中的程序它应具有客户与服务器的双重功能.HTTP的服务器还可以使其他类型的网关或服务代理,通过它们HTTP允许超媒体访问现存的Internet协议,如SMTP,NNTP,FTP,Gopher,WAIS等.
在Internet上的通讯一般是建立在TCP/IP连接上的,HTTP的连接也不例外,其缺省端口是TCP 80端口,当然其他端口也可以使用.
正常的握手过程要求客户在每一次发送请求之前建立连接,并由服务器在发送响应消息后关闭,但客户和服务器还必须具有处理任意一方因突发事件(如用户强制,自动超时或程序失败等)而发生关闭连接的能力.在这些情况下,通常不论当前状态怎样都中止当前请求.图1只是HTTP正常的运作过程,对突发情况并没有体现.
HTTP消息两种分类
HTTP消息包括客户端请求消息和服务器应答消息:
HTTP-message=Request|Response
这两种类型的消息都由一个起始行,一个或多个头标域,一个空行(表示头标域结束)和一个可选的消息净荷组成:
消息头标:
HTTP消息头标包括通用头标,请求头标,响应头标和实体头标等类型.每个头标字段由一个字段,加上冒号,而后跟一个值组成.一个消息的不同头标的接收顺序并不重要,然而,一般情况下最好按下列顺序发送:通用头标,请求头标,响应头标和实体头标.
消息体:
一个消息的消息体是用于运载请求或响应消息的实体内容.实体是请求或响应消息携带的数据,它包括实体头标和实体内容.消息体于实体内容的区别在于,消息体不仅包括实体内容,而且还包括经过传输编码处理的实体内容.
HTTP的请求消息的扩展BNF表示如下:
Request=Request_line
*(general_header
|request_header
|entity_header
CRLF
[message_body]
例如:
__________________________________________________________________
GET /test/mh-email.asp HTTP/1.0
Referer: /test/mh-index.htm
Connection: Keep-Alive
User-Agent: Mozilla/4.51 [en] (Win95; I)
Host:
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: ASPSESSIONIDQGQGQQAD=AIHJBHPBNDLGGKPBPOGKDHOB
___________________________________________________________________
请求行有一个操作字段(token)开始,接着是Request-URI和协议版本号,最后以CRLF结尾.个项内容之间用空格分开,除了最后的CRLF外,Request-URI中其他地方不能出现CR和LF:
HTTP应答消息的扩展BNF表示如下:
Response=Status_line
*(general_header)
|response_header
|entity_header)
CRLF
[message_body]
例如:
_______________________________________________________________
/1HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Connection: keep-alive Date: Wed, 12 May 1999 09:14:17 GMT
Content-Type: image/gif
Accept-Ranges: bytes
Last-Modified: Wed, 24 Jun 1998 02:58:00 GMT
ETag: "0ec86e51b9fbd1:10c0"
Content-Length: 5357
(blank line)
GIF89a?”薜蕲蕙汁?鼢 //…GIF图片余下部分省略
________________________________________________________________
应答消息的头一行是状态行,其定义如下:
Status_line=HTTP_Version Status_Code Reason_PhraseCRLF
其中的状态代码Status_Code是一个3位数字的结果代码:原因短语Reason_Phrase是对状态代码的简短文字陈述.状态码供协议自动机使用,而原因短语是为用户使用的.
重组页面所面临的问题
问题1. 与其它协议不同的是,在通过HTTP协议进行数据的传送时,可能要使用多个TCP连接,(例如： 当用户用IE浏览器浏览页面时所看到的一个新浪首页的页面就是通过二十多个TCP连接传送到浏览器的,然后IE浏览器再把这二十多个（包括源HTML文件,.gif、.jpg 图片及其他各种类型的文件）组合成一个页面.所以要想重组页面,就必须找出这多个TCP连接传送的数据包之间的内在联系.
问题2. 因为因特网上流动的是海量数据,所以怎样采用合理的缓冲技术,把所截获
的数据缓存起来,以免造成因无法及时处理而引起数据的丢失也是一个很关键的问题.
问题 3. 有的HTTP请求不是请求一个具体的资源,而是需要执行一个在WWW服务器后台运行的cgi等程序.在这种情况下,在响应中返回的内容是动态的,是不确定的,怎样把这个不确定的内容放到一个合适的位置也是一个很重要的问题.
HTTP协议解析的实现方法
1.采用的新技术
在进行协议解析时,采用了当今流行的面向对象的程序设计的方法确保了程序设计的合理性,正确性;采用c++语言实现,确保程序的通用性、可移植性及执行的速度;另外还采用了缓冲区技术、内存共享技术等深层技术来确保程序执行的高效性.
2.关键问题的解决
问题1的解决：
在解决一个页面通过多个TCP连接传送这个问题时,首先通过对所截获的数据包进行解析分析出是请求还是响应,然后对请求响应进行进一步的解析从请求、响应的首部字段中解析出有用的信息,然后把这些信息通过一定的规则映射成文件名和文件的保存路径.在保存一个页面时,把它的子页面保存到与它相同的目录下,每一个页面相关的资源保存到与源文件对应的目录下,最后解析源文件,把源文件中资源的路径替换为本地路径.这样处理后,再用浏览器打开时就能再现用户原来浏览时的页面了.
问题2的解决： 在解决数据包丢失的问题上,底层采用了硬件截包技术,把获取的数据保存到内存的一特定缓冲区内,在解析完一个数据包后,再到缓冲队列中取下一个数据包,这样可以防止数据包的丢失;另外,还可以在底层设置过滤器,过滤掉大量无用的数据包,从而提高处理的效率.
问题3的解决：
在处理动态页面的问题上,暂时先把返回的内容保存到一个特定的目录下，并且不修改源文件中与此相对应的资源的路径，这样在打开重组的页面时，只要网络没有断开，浏览器就能自动的取得相应的资源.（这部分的处理可以根据用户的需求而作相应处理）
HTTP协议解析的实现过程
1.
建立TCP/IP连接
客户------------------------------------------------------->服务器
(初始化一个CHTTP对象)
2.
发送请求消息
客户------------------------------------------------------->服务器
(解析请求,保存文件)
3.
发送响应消息
