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的长度。
在具体的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));
|
参考文章
1)http://zh.wikipedia.org/wiki/%E5%88%86%E5%9D%97%E4%BC%A0%E8%BE%93%E7%BC%96%E7%A0%81
2)http://blog.xiuwz.com/tag/content-length/
3)http://wuhua.iteye.com/blog/673841