http协议以及chunked编码分析


Http协议


Http协议 -- 格式

    HTTP消息包括浏览器向服务器的请求消息和服务器向浏览器的响应消息。这两种类型的消息都由一个起始行,一个或者多个头域,一个头域结束的空行和可选的消息体组成。HTTP头域一般包括通用头,请求头,响应头,实体头。每个头域由域名、冒号(:)、域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符。头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。
 
    先来看一个标准的HTTP请求消息和响应消息,使用IE 7.0访问google。
               - - - - - - - - 访问google: - - - - - - - -
GET / HTTP/1.1\r\n
Accept: application/x-shockwave-flash, image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-silverlight, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*\r\n
Accept-Language: zh-cn\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;QQDownload 528; InfoPath.2; .NET CLR 2.0.50727)\r\n
Accept-Encoding: gzip, deflate\r\n
Host:
www.google.com\r\n
Connection: Keep-Alive\r\n
Cookie: PREF=ID=bbd19f9992b2c394:TM=1239870831:LM=1239870831:S=yJs2fykR2UkMKub8\r\n
 
              - - - - - - - - -  google返回内容 - - - - - - - - -
HTTP/1.1 200 OK\r\n
Cache-Control: private, max-age=0\r\n
Date: Tue, 21 Apr 2009 02:30:02 GMT\r\n
Expires: -1\r\n
Content-Type: text/html; charset=UTF-8\r\n
Server: gws\r\n
Content-Encoding: gzip\r\n
Transfer-Encoding: chunked\r\n
 

Http协议中的HeaderBody

Header的每行最后要加\r\n

HeaderBody之间要用\r\n隔开

Body后无需加\r\n

ACSII码中

'\n' 10 换行

'\r' 13 回车

也可以表示为'\x0a''\x0d'.(16进制)

示例:HTTP开始部分为header<html>部分为body

HTTP/1.1 200 OK\r\n

Content-Encoding: gzip\r\n

Content-Type: text/xml\r\n

Content-Length: 399\r\n

Connection: keep-alive\r\n

X-Varnish-Cache: HIT\r\n

X-Varnish-Cache-Hits: 1241\r\n

\r\n

<html.....</html>


HTTP协议请求方法

http请求由三部分组成,分别是:请求方法、消息报头、请求正文。
 
请求方法以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本。格式如下:
Method Request-URI HTTP-Version CRLF  
Method   请求方法
Request-URI   统一资源标识符
HTTP-Version   请求的HTTP协议版本
CRLF   回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。
请求方法有多种,各个方法的用处:
GET         请求获取Request-URI所标识的资源
POST       在Request-URI所标识的资源后附加新的数据
HEAD       请求获取由Request-URI所标识的资源的响应消息报头
PUT         请求服务器存储一个资源,并用Request-URI作为其标识
DELETE     请求服务器删除Request-URI所标识的资源
TRACE      请求服务器回送收到的请求信息,主要用于测试或诊断
CONNECT  保留将来使用
OPTIONS   请求查询服务器的性能,或者查询与资源相关的选项和需求
GET方法用来向服务器获取资源,POST方法要求被请求服务器接受附在消息头域后面的数据,常用于提交表单。HEAD方法和GET方法类似,HEAD不用服务器返回实体内容。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。


HTTP协议 -- 响应

在收到浏览器的资源请求后,服务器返回一个HTTP响应消息。HTTP响应也是由三个部分组成:状态行、消息报头、响应正文。 
1、状态行格式如下:
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version    服务器HTTP协议的版本
Status-Code     服务器发回的响应状态代码
Reason-Phrase  状态代码的文本描述

状态代码有三位数字组成,第一个数字定义了响应的类别,并有五种可能取值:
1xx:指示信息--表示请求已接收,继续处理
2xx:成功--表示请求已被成功接收、理解、接受
3xx:重定向--要完成请求必须进行更进一步的操作
4xx:客户端错误--请求有语法错误或请求无法实现
5xx:服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明:
200 OK               //客户端请求成功
400 Bad Request  //客户端请求有语法错误,不能被服务器所理解
401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden     //服务器收到请求,但是拒绝提供服务
404 Not Found    //请求资源不存在,eg:输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable  //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
2、响应的消息头域下面会细述
3、响应正文就是服务器返回的资源的内容


HTTP协议 -- 消息头域

HTTP的头域的主要功能是完成浏览器和服务器之间的协作。相当于一个协商和控制的作用。比如浏览器高速服务器自己可以接受的文件类型,可以接受何种方式的字符编码,本地的浏览器版本。

通用头域

  通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。
1. Cache-Control头域
  Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached,响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下:
  Public指示响应可被任何缓存区缓存。
  Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。
  no-cache指示请求或响应消息不能缓存
  no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
  max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。
  min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
  max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。
2. Date头域
  Date头域表示消息发送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。
3. Pragma头域
  Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache-Control:no-cache相同。

请求头域

1. Host头域
  Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。
2. Referer头域
  Referer头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址,Referer不能被发送。如果指定的是部分uri地址,则此地址应该是一个相对地址。
3. Range头域
  Range头域可以请求实体的一个或者多个子范围。例如,
  表示头500个字节:bytes=0-499
  表示第二个500字节:bytes=500-999
  表示最后500个字节:bytes=-500
  表示500字节以后的范围:bytes=500-
  第一个和最后一个字节:bytes=0-0,-1
  同时指定几个范围:bytes=500-600,601-999
  但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206(PartialContent)返回而不是以200(OK)。在迅雷等HTTP下载软件中就是使用这个头域来完成多线程的下载的。
4. User-Agent头域
  User-Agent头域的内容包含发出请求的用户信息,比如 浏览器的内核版本。

响应头域

响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头域,一般将会作为实体头域处理。
1. Location响应头
 Location响应头用于重定向接收者到一个新URI地址。
2. Server响应头
 Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。

实体头域

请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头,但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-Encoding或Content-Type定义,它的长度由Content-Length或Content-Range定义。
1. Content-Type实体头
  用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型Content-Range实体头
2. Content-Range实体头
  用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。一般格式:
3. Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
  例如,传送头500个字节次字段的形式:Content-Range:bytes0-499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。
4. Last-modified实体头
  指定服务器上保存内容的最后修订时间。


HTTP协议 -- 状态码

1xx-信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个1xx响应。
100-继续。
101-切换协议。
2xx-成功
这类状态代码表明服务器成功地接受了客户端请求。
200-确定。客户端请求已成功。
201-已创建。
202-已接受。
203-非权威性信息。
204-无内容。
205-重置内容。
206-部分内容。
3xx-重定向
客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。
301-对象已永久移走,即永久重定向。
302-对象已临时移动。
304-未修改。
307-临时重定向。
4xx-客户端错误
发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。
400-错误的请求。
401-访问被拒绝。IIS定义了许多不同的401错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在IIS日志中显示:
401.1-登录失败。
401.2-服务器配置导致登录失败。
401.3-由于ACL对资源的限制而未获得授权。
401.4-筛选器授权失败。
401.5-ISAPI/CGI应用程序授权失败。
401.7–访问被Web服务器上的URL授权策略拒绝。这个错误代码为IIS6.0所专用。
403-禁止访问:IIS定义了许多不同的403错误,它们指明更为具体的错误原因:
403.1-执行访问被禁止。
403.2-读访问被禁止。
403.3-写访问被禁止。
403.4-要求SSL。
403.5-要求SSL128。
403.6-IP地址被拒绝。
403.7-要求客户端证书。
403.8-站点访问被拒绝。
403.9-用户数过多。
403.10-配置无效。
403.11-密码更改。
403.12-拒绝访问映射表。
403.13-客户端证书被吊销。
403.14-拒绝目录列表。
403.15-超出客户端访问许可。
403.16-客户端证书不受信任或无效。
403.17-客户端证书已过期或尚未生效。
403.18-在当前的应用程序池中不能执行所请求的URL。这个错误代码为IIS6.0所专用。
403.19-不能为这个应用程序池中的客户端执行CGI。这个错误代码为IIS6.0所专用。
403.20-Passport登录失败。这个错误代码为IIS6.0所专用。
404-未找到。
404.0-(无)–没有找到文件或目录。
404.1-无法在所请求的端口上访问Web站点。
404.2-Web服务扩展锁定策略阻止本请求。
404.3-MIME映射策略阻止本请求。
405-用来访问本页面的HTTP谓词不被允许(方法不被允许)
406-客户端浏览器不接受所请求页面的MIME类型。
407-要求进行代理身份验证。
412-前提条件失败。
413–请求实体太大。
414-请求URI太长。
415–不支持的媒体类型。
416–所请求的范围无法满足。
417–执行失败。
423–锁定的错误。
5xx-服务器错误
服务器由于遇到错误而不能完成该请求。
500-内部服务器错误。
500.12-应用程序正忙于在Web服务器上重新启动。
500.13-Web服务器太忙。
500.15-不允许直接请求Global.asa。
500.16–UNC授权凭据不正确。这个错误代码为IIS6.0所专用。
500.18–URL授权存储不能打开。这个错误代码为IIS6.0所专用。
500.100-内部ASP错误。
501-页眉值指定了未实现的配置。
502-Web服务器用作网关或代理服务器时收到了无效响应。 phperz.com
502.1-CGI应用程序超时。
502.2-CGI应用程序出错。application.
503-服务不可用。这个错误代码为IIS6.0所专用。
504-网关超时。
505-HTTP版本不受支持。


content-length 以及chunked编码分析


0.序

       在研究百度云盘的响应过程中,发现其响应采用chunked编码形式,并且没有Content-length字段,因为项目需要,就需要研究一下http/1.1协议中的chunked编码。
首先介绍与chunked编码相关的几个概念,从而引出chunked编码

1.http/1.1协议中与chunked编码的相关字段

1)Entity Body: entity-body只有在message-body出现时才会出现。通过对message-body的解码获得entity-body。transfer-encoding用于确保安全和信息的恰当传输。
     Entity-length:在应用任何transfer-encoding之前的message-body的长度。即没有编码之前message-body的长度。
2)Content-length :用于描述HTTP消息实体的传输长度。(the transfer-length of the message-body
消息实体长度:即Entity-length,压缩之前的message-body的长度
消息实体的传输长度:Content-length,压缩后的message-body的长度。
3)Message Length :这部分的解释必须得看看大牛的解释 http://blog.xiuwz.com/tag/content-length/


在具体的HTTP交互中,客户端是如何获取消息长度的呢,主要基于以下几个规则:

  • 响应为1xx,204,304相应或者head请求,则直接忽视掉消息实体内容。
  • 如果有Transfer-Encoding,则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式
  • “如果head中有Content-Length,那么这个Content-Length既表示实体长度,又表示传输长度。如果实体长度和传输长度不相等(比如说设置了Transfer-Encoding),那么则不能设置Content-Length。如果设置了Transfer-Encoding,那么Content-Length将被忽视”。这句话翻译的优点饶,其实关键就一点:有了Transfer-Encoding,则不能有Content-Length。
  • Range传输。不关注,没详细看了:)
  • 通过服务器关闭连接能确定消息的传输长度。(请求端不能通过关闭连接来指明请求消息体的结束,因为这样可以让服务器没有机会继续给予响应)。这种情况主要对应为短连接,即非keep-alive模式。
  • HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候,可以通过chunk机制来处理这种情况。
  • 在包含消息内容的header中,如果有content-length字段,那么该字段对应的值必须完全和消息主题里面的长度匹配。
    “The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
    也就是有chunk就不能有content-length 。
  • 其实后面几条几乎可以忽视,简单总结后如下:
  • 1、Content-Length如果存在并且有效的话,则必须和消息内容的传输长度完全一致。(经过测试,如果过短则会截断,过长则会导致超时。)

    2、如果存在Transfer-Encoding(重点是chunked),则在header中不能有Content-Length,有也会被忽视

    3、如果采用短连接,则直接可以通过服务器关闭连接来确定消息的传输长度。(这个很容易懂)

    结合HTTP协议其他的特点,比如说Http1.1之前的不支持keep alive。那么可以得出以下结论:

    1、在Http 1.0及之前版本中,content-length字段可有可无。

    2、在http1.1及之后版本。如果是keep alive,则content-length和chunk必然是二选一。若是非keep alive,则和http1.0一样。content-length可有可无。


其中比较重要的一点如下所述:
          如果存在Transfer-encoding存在,则在header中不能由content-length,有也会被忽略。
          如果Content-length存在并且有效的话,则必须和消息内容的传输长度完全一致。
4)content-length字段的作用   
     Conent-Length表示实体内容长度,客户端(服务器)可以根据这个值来判断数据是否接收完成。但是如果消息中没有Conent-Length,那该如何来判断呢?又在什么情况下会没有Conent-Length呢?

没有Content-length时,客户端如何来判断数据是否接收完成呢?
1)静态页面或者图片:当客户端向服务器请求一个静态页面或者一张图片时,服务器可以很清楚的知道内容大小,然后通过Content-length消息首部字段告诉客户端 需要接收多少数据。
2)动态页面: 如果是动态页面等时,服务器是不可能预先知道内容大小,这时就可以使用Transfer-Encoding:chunk模式来传输 数据了。即如果要一边产生数据,一边发给客户端,服务器就需要使用”Transfer-Encoding: chunked”这样的方式来代替Content-Length。
采用Transfer-encoding的目的
     一边产生数据,一边发给客户端。


1)定义
     分块传输编码(Chunked transfer encoding)是超文本传输协议(HTTP)中的一种数据传输机制,允许HTTP由网页服务器发送给客户端应用( 通常是网页浏览器)的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本(HTTP/1.1)中提供。
2)说明:
     通常,HTTP应答消息中发送的数据是整个发送的,Content-Length消息头字段表示数据的长度。数据的长度很重要,因为客户端需要知道哪里是应答消息的结束,以及后续应答消息的开始。然而,使用分块传输编码,数据分解成一系列数据块,并以一个或多个块发送,这样服务器可以发送数据而不需要预先知道发送内容的总大小。
3)格式:
     如果一个HTTP消息(请求消息或应答消息)的Transfer-Encoding消息头的值为chunked,那么,消息体由数量未定的块组成,并以最后一个大小为0的块为结束。
每一个非空的块都以该块包含数据的字节数(字节数以十六进制表示)开始,跟随一个CRLF (回车及换行),然后是数据本身,最后块CRLF结束。在一些实现中,块大小和CRLF之间填充有白空格(0x20)。
最后一块是单行,由块大小(0),一些可选的填充白空格,以及CRLF。最后一块不再包含任何数据,但是可以发送可选的尾部,包括消息头字段。
消息最后以CRLF结尾。

     chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成,由一个标明长度为0 的chunk标示结束。每个Chunk分为头部和正文两部分,头部内容指定正文的字符总数(十六进制的数字 )和数量单位(一般不写),正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF) 隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些附加的Header信息(通常可以直接忽略)。

Chunk编码的格式如下:

Chunked-Body = *chunk 
“0″ CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF

hex-no-zero = <HEX excluding “0″>

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编码由四部分组成: 1、0至多个chunk块 ,2、“0″ CRLF ,3、footer ,4、CRLF . 而每个chunk块由:chunk-size、chunk-ext(可选)、CRLF、chunk-data、CRLF组成。

4)chunked编码的程序化表示
     (1)c++ 详见http://wuhua.iteye.com/blog/673841
     (2)c语言
char  * chunkpart1 =  "42\r\n"  ;
char  * chunkpart2 = tmpuchar_body_data ;
char  * chunkpart3 =  "\r\n0\r\n\r\n"  ;
int  chunklen = 0;
 chunklen =  strlen (chunkpart1) +  strlen (chunkpart2) +  strlen (chunkpart3);
char  * chunk = ( char *)ngx_pcalloc(r-> pool ,chunklen+1);
strncpy (chunk,chunkpart1, strlen (chunkpart1));
strncpy ((chunk+ strlen (chunkpart1)),chunkpart2,  strlen (chunkpart2) );
strncpy ((chunk+ strlen (chunkpart1) +  strlen (chunkpart2) ),chunkpart3,  strlen (chunkpart3));


参考:

      http://blog.csdn.net/yankai0219/article/details/8269922

     http://ddvcxj.blog.51cto.com/1064441/237731








  • 2
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值