http协议中content-length 以及chunked编码分析

最新推荐文章于 2024-09-13 09:59:21 发布

stevenzqzq

最新推荐文章于 2024-09-13 09:59:21 发布

阅读量3.9k

点赞数

分类专栏： Java Web

Java Web 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

转载请注明出处 http://blog.csdn.net/yankai0219/article/details/8269922

0.序

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

1）Entity Body

2）Content-length

3）Message Length

4）content-length字段的作用

2.chunked编码

1）定义

2）说明：

3）格式：

4）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://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的目的

一边产生数据，一边发给客户端。

2.chunked编码

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组成。