http协议之chunked解析
网上使用chunked编码的网站似乎并不是很多，除了那些使用gzip压缩的网站，例：google.com，还有就是大部分打开gzip压缩的php论坛。根据本人的理解，使用chunked编码的主要好处就在于一些程序的运算出过程中，可以动态的输出内容。
例如，要在后台处理一个小时的运算，但又不希望用户等一个小时才能看到结果。这时就可采用chunked编码将内容分块输出，用户随时都可以接收到最新的处理结果。
asp关闭了缓存的输出模式，就是chunked编码的。(response.buffer = false)
而每一次的response.write，都是一个chunked，所以不要使用的太频繁哦，否则chunk数量太多，额外的数据太浪费空间了。
若想了解chunked的具体编码结构，用asp关闭缓存调试蛮方便的。:)
我们先来看看rfc2616中对chunked的定义：
chunked-body = *chunk
last-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)
我们来模拟一下数据结构：
[回车][回车][回车][回车][回车]
注意chunk-size是以十六进制的ascii码表示的，比如86ae（实际的十六进制应该是：38366165），计算成长度应该是：34478，表示从回车之后有连续的34478字节的数据。
跟踪了的返回数据，发现在chunk-size中，还会多一些空格。可能是固定长度为7个字节，不满7个字节的，就以空格补足，空格的ascii码是0x20。
以下是解码过程的伪代码：
length := 0//用来记录解码后的数据体长度
read chunk-size, chunk-extension (if any) and crlf//第一次读取块大小
while (chunk-size > 0) {//一直循环，直到读取的块大小为0
read chunk-data and crlf//读取块数据体，以回车结束
append chunk-data to entity-body//添加块数据体到解码后实体数据
length := length + chunk-size//更新解码后的实体长度
read chunk-size and crlf//读取新的块大小
}
read entity-header//以下代码读取全部的头标记
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
content-length := length//头标记中添加内容长度
remove chunked from transfer-encoding//头标记中移除transfer-encoding
有空再研究一下gzip＋chunked是如何编码的，估计是每个chunk块进行一次gzip独立压缩。
使用了chunked，自然会在性能上稍微打点折扣，因为比正常的数据体多出了一些额外的消耗。
但是有一些情况下，必需要使用分块输出，这也是不得已而为之.
更多网页制作信息请查看： 网页制作 楼猪.重量级人物阿. 笨点也好~~~~ 我又回复了 cd:遮~~~~~~ 这话从何说起那~~~ 唉!猪!你怎么了? 这就是我斗胆的一点粗略分析，每天睡觉以前，我都会把您的帖子再三拜读，拜读。 你该这么说~~
页:
[1]