ITPub博客

首页 > IT基础架构 > 网络安全 > 浅谈HTTP协议

浅谈HTTP协议

原创 网络安全 作者:zhkl0228 时间:2006-06-28 16:35:37 0 删除 编辑
浅谈HTTP协议[@more@]

浅谈HTTP协议(一)--结构

Internet是由各个协议连接起来的,而我们现在使用最广的莫过于HTTP协议了,也就是超文本传输协议,与FTP(文件传输协议)不同,由于主要用于超文本传输,因此HTTP协议显得更简单一点。今天我们来介绍一下HTTP协议的基本格式。
  在这里,我们所谈及的HTTP协议以HTTP/1.1为标准,并且使用NetVampirePro4.0来取得与HTTP服务器的通信Log,您也可以使用其它的HTTP下载工具来取得通信Log。
   在HTTP协议中,服务端是指提供HTTP服务的部分,客户端是指你使用的浏览器或者下载工具等等。在通讯时,由客户端发出请求连接,服务端建立连接; 然后,客户端发出HTTP请求(Request),服务端返回响应信息(Respond),由此完成一个HTTP操作。我们来通过一个例子来了解这个过 程:(以下是NetVampire进行的一次连接,以下红色字体为作者添加)
P01-5-2616:10:43Connectingtogo2.163.com...         //连接服务器
P01-5-2616:10:44Connectedtogo2.163.com[61.129.65.148]    //解析IP地址,以下为HTTP操作
S01-5-2616:10:44GET/~minift/epretty/pretty.zipHTTP/1.1   //请求行(RequestLine),表示使用GET方式取得文件,使用HTTP/1.1协议
//以下为请求头部(RequestHead)
S01-5-2616:10:44Connection:close               //表示非持续性连接
S01-5-2616:10:44Host:go2.163.com               //主机名称
S01-5-2616:10:44Accept:*/*                  //接受的数据类型
S01-5-2616:10:44Pragma:no-cache               //参数(与以前的服务器兼容)
S01-5-2616:10:44Cache-Control:no-cache            //不使用缓存
S01-5-2616:10:44Referer:http://go2.163.com/~minift/epretty  //从该网址转来
S01-5-2616:10:44User-Agent:Mozilla/4.04[en](Win95;I;Nav) //客户端标识
S01-5-2616:10:44Cookie:AdId=ACDDAAAAAAA
S01-5-2616:10:44                        //以下为Respond
R01-5-2616:10:47HTTP/1.0200OK                //响应行(RespondLine),服务器使用HTTP/1.0协议,状态值(StatusCode)为200,状态为OK,表示文件可以读取
R01-5-2616:10:47Date:Sat,26May200108:15:54GMT      //现在的时间,用格林威治时间表示
R01-5-2616:10:47Server:Apache/1.3.14(Unix)mod_layout/2.9.9 //服务器类型
R01-5-2616:10:47Last-Modified:Fri,04May200102:42:56GMT  //文件最后更新时间
R01-5-2616:10:47ETag:"e614cf-37965-3af21730"
R01-5-2616:10:47Accept-Ranges:bytes             //接受的范围单位
R01-5-2616:10:47Content-Length:227685            //文件长度
R01-5-2616:10:47Content-Type:application/zip         //MIME类型
R01-5-2616:10:47X-Cache:MISSfromshca8
R01-5-2616:10:47X-Cache-Lookup:MISSfromshca8:80
R01-5-2616:10:47Connection:close               //表示文件传输完毕就关闭连接。
R01-5-2616:10:47                        //以下为文件传输
P01-5-2616:10:47Datatransferstarted
  下面来讲解使用的格式(LRCF=@13@10,即回车,SP=SPACE,即空格)
Request:
协议方式SP文件URISP协议版本LRCF(请求行)
(以下为头部)
头部类型:头部值LRCF
头部类型:头部值LRCF
头部类型:头部值LRCF
......
LRCF表示头部结束
(如果有体部,以下为体部)

Respond:
协议版本SP状态值SP状态描述LRCF(响应行)
(以下为头部)
头部类型:头部值LRCF
头部类型:头部值LRCF
头部类型:头部值LRCF
......
LRCF表示头部结束
(如果有体部,以下为体部)


  由上可见,请求与相应的格式只有部分不同,是很容易理解的,现在你应该基本了解HTTP协议了吧,也能看懂那些通信Log了吧,下一次我们讲专门讲解在响应行中的状态值含义及一些特殊情况。

浅谈HTTP协议(二)--返回值

在一个协议中,最重要的是判断协议是否进行的成功,而在HTTP中是根据响应状态值来确定的,今天就来介绍一些状态码的含义。
200OK
这是最普遍的吧,也就是表示协议一切正常,凡是2开头的代码表示的都是成功进行中。

404NotFound
这也是最普遍的吧,其实大多数错误就是所要求的资源无法得到,通常表示文件不存在。

403Forbidden
表示服务器无法满足现在的请求,有可能是现在连接数太多等原因。

401Unauthorized
未认证的请求,通常浏览器接受到这个状态值,就会弹出一个对话框,要求你输入密码。

500InternalServerError
服务器内部错误,一般的原因是因为所执行的程序有错误,无法返回正确应答。

206PartialContent
部分的内容,这个状态码表示下面传递的是部分的内容,也是断点续传的标准返回码。

HTTP协议三--断点续传

断点续传是我们现在经常接触的概念,那么HTTP协议是如何支持断点续传的呢。我们先从一个例子来看看。
下面是一个断点续传的例子:(使用NetVampire得到)
I01-7-1219:19:23-------------------------Attempt1-------------------------
P01-7-1219:19:24Connectingto127.0.0.3...
P01-7-1219:19:24Connectedto127.0.0.3[127.0.0.3]
S01-7-1219:19:24GET/VS0515AI.EXEHTTP/1.1
S01-7-1219:19:24Connection:close
S01-7-1219:19:24Host:127.0.0.3
S01-7-1219:19:24Accept:*/*
S01-7-1219:19:24Pragma:no-cache
S01-7-1219:19:24Cache-Control:no-cache
S01-7-1219:19:24Referer:http://127.0.0.3/
S01-7-1219:19:24User-Agent:Mozilla/4.04[en](Win95;I;Nav)
S01-7-1219:19:24
R01-7-1219:19:24HTTP/1.1200OK
R01-7-1219:19:24Server:ZeroHttpServer/1.0
R01-7-1219:19:24Date:Thu,12Jul200111:19:24GMT
R01-7-1219:19:24Cache-Control:no-cache
R01-7-1219:19:24Last-Modified:Tue,30Jan200113:11:30GMT
R01-7-1219:19:24Content-Type:application/octet-stream
R01-7-1219:19:24Content-Length:15143086
R01-7-1219:19:24Connection:close
R01-7-1219:19:24
P01-7-1219:19:25Datatransferstarted
I01-7-1219:19:32JobStoppedbyuser
I01-7-1219:19:33Received5275648bytesin0:00:07(691435bytes/s)
I01-7-1219:19:40-------------------------Attempt2-------------------------
P01-7-1219:19:40Connectingto127.0.0.3...
P01-7-1219:19:40Connectedto127.0.0.3[127.0.0.3]
S01-7-1219:19:40GET/VS0515AI.EXEHTTP/1.1
S01-7-1219:19:40Connection:close
S01-7-1219:19:40Host:127.0.0.3
S01-7-1219:19:40Accept:*/*
S01-7-1219:19:40Pragma:no-cache
S01-7-1219:19:40Cache-Control:no-cache
S01-7-1219:19:40Referer:http://127.0.0.3/
S01-7-1219:19:40User-Agent:Mozilla/4.04[en](Win95;I;Nav)
S01-7-1219:19:40Range:bytes=5275648-
S01-7-1219:19:40
R01-7-1219:19:40HTTP/1.1206PartialContent
R01-7-1219:19:40Server:ZeroHttpServer/1.0
R01-7-1219:19:40Date:Thu,12Jul200111:19:40GMT
R01-7-1219:19:40Cache-Control:no-cache
R01-7-1219:19:40Last-Modified:Tue,30Jan200113:11:30GMT
R01-7-1219:19:40Content-Type:application/octet-stream
R01-7-1219:19:40Content-Range:bytes5275648-15143085/15143086
R01-7-1219:19:40Content-Length:9867438
R01-7-1219:19:40Connection:close
R01-7-1219:19:40
P01-7-1219:19:40Datatransferstarted
I01-7-1219:19:41JobStoppedbyuser
I01-7-1219:19:41Received1124756bytesin0:00:01(969617bytes/s)
第一次是普通的传输;第二次由于没有传完全,就发出了Range这个头部,从5275648字节开始传输(默认是按字节算),回应使用206状态值,表示现在开始部分传输,回复Content-Length头部,表示传输的部分,用字节记,然后就与普通传输没有区别了。
通过上面的例子,你应该了解HTTP断点续传的原理了吧。

HTTP协议四--关于Chunked编码

在有时服务器生成HTTP回应是无法确定消息大小的,这时用Content-Length就无法事先写入长度,而需要实时生成消息长度,这时服务器一般采用Chunked编码。
  在进行Chunked编码传输时,在回复消息的头部有transfer-coding并定为Chunked,表示将用Chunked编码传输内容。采用以下方式编码:
  Chunked-Body=*chunk
         "0"CRLF
         footer
         CRLF
  chunk=chunk-size[chunk-ext]CRLF
      chunk-dataCRLF

  hex-no-zero=

  chunk-size=hex-no-zero*HEX
  chunk-ext=*(";"chunk-ext-name["="chunk-ext-value])
  chunk-ext-name=token
  chunk-ext-val=token|quoted-string
  chunk-data=chunk-size(OCTET)

  footer=*entity-header
   编码使用若干个Chunk组成,由一个标明长度为0的chunk结束,每个Chunk有两部分组成,第一部分是该Chunk的长度和长度单位(一般不 写),第二部分就是指定长度的内容,每个部分用CRLF隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些没有写的头部内 容。
  下面给出一个Chunked的解码过程(RFC文档中有)
  length:=0
  readchunk-size,chunk-ext(ifany)andCRLF
  while(chunk-size>0){
  readchunk-dataandCRLF
  appendchunk-datatoentity-body
  length:=length+chunk-size
  readchunk-sizeandCRLF
  }
  readentity-header
  while(entity-headernotempty){
  appendentity-headertoexistingheaderfields
  readentity-header
  }
  Content-Length:=length
  Remove"chunked"fromTransfer-Encoding
  下一次将会讨论一些小问题,如POST方法的数据传输等。
  最后,还有一点要说的是,好像NetAnt的一个版本不支持Chunked编码,会显示无法确定内容长度,或许是版本太低的缘故,如果你也遇到这种问题,可以改用NetVampire或其它支持Chunked编码的下载程序试试。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/419718/viewspace-846145/,如需转载,请注明出处,否则将追究法律责任。

上一篇: Lucene 的包结构
请登录后发表评论 登录
全部评论
  • 博文量
    44
  • 访问量
    183680