HTTP1.1中CHUNKED编码解析(转载)

HTTP1.1中CHUNKED编码解析

一般HTTP通信时,会使用Content-Length头信息性来通知用户代理(通常意义上是浏览器)服务器发送的文档内容长度,该头信息定义于HTTP1.0协议RFC  1945  10.4章节中。浏览器接收到此头信息后,接受完Content-Length中定义的长度字节后开始解析页面,但如果服务端有部分数据延迟发送吗,则会出现浏览器白屏,造成比较糟糕的用户体验。

解决方案是在HTTP1.1协议中,RFC  2616中14.41章节中定义的Transfer-Encoding: chunked的头信息,chunked编码定义在3.6.1中,所有HTTP1.1 应用都支持此使用trunked编码动态的提供body内容的长度的方式。进行Chunked编码传输的HTTP数据要在消息头部设置:Transfer-Encoding: chunked表示Content Body将用chunked编码传输内容。根据定义,浏览器不需要等到内容字节全部下载完成,只要接收到一个chunked块就可解析页面.并且可以下载html中定义的页面内容,包括js,css,image等。

采用chunked编码有两种选择,一种是设定Server的IO buffer长度让Server自动flush buffer中的内容,另一种是手动调用IO中的flush函数。不同的语言IO中都有flush功能:

l         php:    ob_flush(); flush();

l         perl:   STDOUT->autoflush(1);

l         java:  out.flush();

l         python:  sys.stdout.flush()

l         ruby:  stdout.flush

采用HTTP1.1的Transfer-Encoding:chunked,并且把IO的buffer flush下来,以便浏览器更早的下载页面配套资源。当不能预先确定报文体的长度时,不可能在头中包含Content-Length域来指明报文体长度,此时就需要通过Transfer-Encoding域来确定报文体长度。

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

上述解释过于官方,简而言之,chunked编码的基本方法是将大块数据分解成多块小数据,每块都可以自指定长度,其具体格式如下(BNF文法):

Chunked-Body   = *chunk            //0至多个chunk

last-chunk         //最后一个chunk

trailer            //尾部

CRLF               //结束标记符

chunk          = chunk-size [ chunk-extension ] CRLF

chunk-data CRLF

chunk-size     = 1*HEX

last-chunk     = 1*("0") [ chunk-extension ] CRLF

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

chunk-ext-name = token

chunk-ext-val  = token | quoted-string

chunk-data     = chunk-size(OCTET)

trailer        = *(entity-header CRLF)

解释:

l         Chunked-Body表示经过chunked编码后的报文体。报文体可以分为chunk, last-chunk,trailer和结束符四部分。chunk的数量在报文体中最少可以为0,无上限;

l         每个chunk的长度是自指定的,即,起始的数据必然是16进制数字的字符串,代表后面chunk-data的长度(字节数)。这个16进制的字符串第一个字符如果是“0”,则表示chunk-size为0,该chunk为last-chunk,无chunk-data部分。

l         可选的chunk-extension由通信双方自行确定,如果接收者不理解它的意义,可以忽略。

l         trailer是附加的在尾部的额外头域,通常包含一些元数据(metadata, meta means "about information"),这些头域可以在解码后附加在现有头域之后

下面分析用ethereal抓包使用Firefox与某网站通信的结果(从头域结束符后开始):

Address  0..........................  f

000c0                       31

000d0    66 66 63 0d 0a ...............   // ASCII码:1ffc/r/n, chunk-data数据起始地址为000d5

显然,“1ffc”为第一个chunk的chunk-size,转换为int为8188。由于1ffc后,马上就是CRLF,因此没有chunk-extension。chunk-data的起始地址为000d5, 计算可知下一块chunk的起始

地址为000d5+1ffc + 2=020d3,如下:

020d0    .. 0d 0a 31 66 66 63 0d 0a .... // ASCII码:/r/n1ffc/r/n

前一个0d0a是上一个chunk的结束标记符,后一个0d0a则是chunk-size和chunk-data的分隔符。

此块chunk的长度同样为8188, 依次类推,直到最后一块

100e0                          0d 0a 31

100f0    65 61 39 0d 0a......            //ASII码:/r/n/1ea9/r/n

此块长度为0x1ea9 = 7849, 下一块起始为100f5 + 1ea9 + 2 = 11fa0,如下:

11fa0    30 0d 0a 0d 0a                  //ASCII码:0/r/n/r/n

“0”说明当前chunk为last-chunk, 第一个0d 0a为chunk结束符。第二个0d0a说明没有trailer部分,整个Chunk-body结束。

解码流程:

对chunked编码进行解码的目的是将分块的chunk-data整合恢复成一块作为报文体,同时记录此块体的长度。

RFC2616中附带的解码流程如下:(伪代码)

length := 0         //长度计数器置0

read chunk-size, chunk-extension (if any) and CRLF      //读取chunk-size, chunk-extension和CRLF

while(chunk-size > 0 )

{            //表明不是last-chunk

read chunk-data and CRLF            //读chunk-size大小的chunk-data,skip CRLF

append chunk-data to entity-body     //将此块chunk-data追加到entity-body后

length := length + chunk-size

read chunk-size and CRLF          //读取新chunk的chunk-size 和 CRLF

}

read entity-header      //entity-header的格式为name:valueCRLF,如果为空即只有CRLF

while (entity-header not empty)   //即,不是只有CRLF的空行

{

append entity-header to existing header fields

read entity-header

}

Content-Length:=length      //将整个解码流程结束后计算得到的新报文体length,作为Content-Length域的值写入报文中

Remove "chunked" from Transfer-Encoding  //同时从Transfer-Encoding中域值去除chunked这个标记

length最后的值实际为所有chunk的chunk-size之和,在上面的抓包实例中,一共有八块chunk-size为0x1ffc(8188)的chunk,剩下一块为0x1ea9(7849),加起来一共73353字节。
      注:对于上面例子中前几个chunk的大小都是8188,可能是因为:"1ffc" 4字节,""r"n"2字节,加上块尾一个""r"n"2字节一共8字节,因此一个chunk整体为8196,正好可能是发送端一次TCP发送的缓存大小。

最后提供一段PHP版本的chunked解码代码:

$chunk_size = (integer)hexdec(fgets( $socket_fd, 4096 ) );

while(!feof($socket_fd) && $chunk_size > 0)

{

$bodyContent .= fread( $socket_fd, $chunk_size );

fread( $socket_fd, 2 ); // skip /r/n
    $chunk_size = (integer)hexdec(fgets( $socket_fd, 4096 ) );

}

 

其C语言的解码如下,java思路相同

int nBytes;

char* pStart = a;    // a中存放待解码的数据

char* pTemp;

char strlength[10];   //一个chunk块的长度

chunk  : pTemp =strstr(pStart,"/r/n");

if(NULL==pTemp)

{

free(a);

a=NULL;

fclose(fp);

return -1;

}

length=pTemp-pStart;

COPY_STRING(strlength,pStart,length);

pStart=pTemp+2;

nBytes=Hex2Int(strlength); //得到一个块的长度,并转化为十进制

if(nBytes==0)//如果长度为0表明为最后一个chunk

{

free(a);

fclose(fp);

return 0;

}

fwrite(pStart,sizeof(char),nBytes,fp);//将nBytes长度的数据写入文件中

pStart=pStart+nBytes+2; //跳过一个块的数据以及数据之后两个字节的结束符

fflush(fp);

goto chunk; //goto到chunk继续处理

如何将一个十进制数转化为十六进制

char *buf = (char *)malloc(100);

char *d = buf;

int shift = 0;

unsigned long copy = 123445677;

while (copy) {

copy >>= 4;

shift++;

}//首先计算转化为十六进制后的位数

if (shift == 0)

shift++;

shift <<= 2; //将位数乘于4,如果有两位的话 shift为8

while (shift > 0) {

shift -= 4;

*(buf) = hex_chars[(123445677 >> shift) & 0x0F];

buf++;

}

*buf = ‘/0‘;

原文链接:http://blog.csdn.net/zhangboyj/article/details/6236780

HTTP1.1中CHUNKED编码解析(转载),布布扣,bubuko.com

时间: 08-14

HTTP1.1中CHUNKED编码解析(转载)的相关文章

Android中XML数据解析

转载请注明出处:http://blog.csdn.net/yegongheng/article/details/38296207 XML初步 今天我们来学习另一种非常重要的数据交换格式-XML.XML(Extensible Markup Language的缩写,意为可扩展的标记语言),它是一种元标记语言,即定义了用于定义其他特定领域有关语义的.结构化的标记语言,这些标记语言将文档分成许多部件并对这些部件加以标识.XML 文档定义方式有:文档类型定义(DTD)和XML Schema.DTD定义了文

转:在java中使用dom4j解析xml

在java中使用dom4j解析xml 虽然Java中已经有了Dom和Sax这两种标准解析方式 但其操作起来并不轻松,对于我这么一个初学者来说,其中部分代码是活生生的恶心 为此,伟大的第三方开发组开发出了Jdom和Dom4j等工具 鉴于目前的趋势,我们这里来讲讲Dom4j的基本用法,不涉及递归等复杂操作 Dom4j的用法很多,官网上的示例有那么点儿晦涩,这里就不写了 首先我们需要出创建一个xml文档,然后才能对其解析 xml文档: <?xml version="1.0" encod

http协议中的编码和解码

http://www.csdn1 2 3.com/html/itweb/20130730/29422_29378_29408.htm ****************************** 一.字符集与文字编码简介 1. 计算机如何显示文字 我们知道,计算机是以二进制的“形式”来保存和处理数据的,也 就是说,不管我们使用键盘进行输入,还是让计算机去读取一个文本文件,计算机得到的原始内容是一些二进制序列,当需要对这些二进制序列进行显示时,计算机 会依照某种“翻译机制”(也就是编码方式),取到

python语言中的编码问题

在编程的过程当中,常常会遇到莫名其妙的乱码问题.很多人选择出了问题直接在网上找答案,把别人的例子照搬过来,这是快速解决问题的一个好办法.然而,作为一个严谨求实的开发者,如果不从源头上彻底理解乱码产生的机制,并由此寻求解决问题的根本路径,那么永远不能从码农的阴影中摆脱出来.下面就来一起了解一下计算机编码问题的来龙去脉. ASCII 众所周知,计算机中的所有数据,不论是文字.图片.视频.还是音频文件,本质上最终都是按照类似 01010101 的二进制形式存储的.然而,计算机中的字符,并不能完全以这种

查看修改mysql编码方式[转载]

MySQL的默认编码是Latin1,不支持中文,要支持中午需要把数据库的默认编码修改为gbk或者utf8. 1.需要以root用户身份登陆才可以查看数据库编码方式(以root用户身份登陆的命令为:>mysql -u root –p,之后两次输入root用户的密码),查看数据库的编码方式命令为: >show variables like 'character%';+--------------------------+----------------------------+| Variable

WebGIS中GeoHash编码的研究和扩展

1.背景 1.1普通地理编码流程 将采集的POI入库后,数据库里保存有该POI的位置描述.X.Y等信息.当需要进行逆编码查询时,前端传入坐标的X.Y值,后台构建查询范围查询,并且对查询出来的值进行距离排序. 1.2普通地理编码的几点劣势 a.前端查询url中的X.Y值为真实值,可能会暴露相关真实信息. b.前端查询的url因为X.Y值的长度而变得比较长. c.后台中,需要同时对X列.Y列做查询判断. d.因为传入的X.Y值总在变化,数据库中的查询很难进行缓存优化. e.数据库中保存的是真实X.Y

HTTP(GET/POST)请求过程中的编码问题

以下内容为转帖内容,很好. 一.问题:    编码问题是JAVA初学者在web开发过程中经常会遇到问题,网上也有大量相关的文章介绍,但其中很多文章并没有对URL中使用了中文等非ASCII的字 符造成服务器后台程序解析出现乱码的问题作出准确的解释和说明.本文将详细介绍由于在URL中使用了中文等非ASCII的字符造成乱码的问题. 1.在URL中中文字符通常出现在以下两个地方:(1).Query String中的参数值,比如http://search.china.alibaba.com/search/

java中的编码问题

一直在试图搞清楚java中的编码问题,也看了网上的一些文章,但还是云里雾里.直到最近看了方立勋老师的web课程,才略略明白一点. 在此记录一下自己的理解,看看自己能不能说清楚. 第一个问题:我在java代码中定义了一个字符串,它是什么编码? 字符串实质是一个char数组.那么char的编码,其实就是字符串的编码.那么char什么编码呢?为什么'中'字转int类型后的值是20013呢? char c = '中'; System.out.println(c); // 中 System.out.pri

java 在JS中的编码问题

在当前的web应用中,js操作页面元素的情况越来越多,尤其是通过js发起异步请求时遇到编码问题的情况经常出现.下面介绍在js中出现编码问题的几种情况. 1.外部引入js文件 在一个单独的js文件中包含字符串输入的情况,如: <html> <head> <script src="statics/javascript/script.js" charset="gbk"></script> 如果引入一个script.js脚本,