就算是流的概念也得需要某种机制来判断是不是某一段传输结束了吧。
不可能浏览器在接受类似于res.write(<a>ssss</a>)
的时候每接收到一位就跳一下吧。
那么是怎么判断结束的呢,常规情况下是有 content-length 的,但是 chunked 话是没有这个头的。
1
vevlins OP 刚才在一个博客里面看到了这样一段话:
Chunked 编码一般使用若干个 chunk 串连而成,最后由一个标明长度为 0 的 chunk 标示结束。每个 chunk 分为头部和正文两部分,头部内容指定下一段正文的字符总数(非零开头的十六进制的数字)和数量单位(一般不写,表示字节).正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF)隔开。在最后一个长度为 0 的 chunk 中的内容是称为 footer 的内容,是一些附加的 Header 信息(通常可以直接忽略)。 问题 1:这样的话是指在每一次传输的 chunk 里面加上包括长度信息和实体信息的内容一起传输对吗? 问题 2:那第一个 chunk 怎么确定传输完毕呢? 问题 3:发起请求方开始是不知道所有的块的数量吗? |
2
vevlins OP `transfer-encoding:chunked`是流水一样的‘流’还是扔东西一样的‘流’。每一个 chunk 自身是一个整体还是是以一个流的概念。
|
3
clearbug 2018-05-04 15:37:50 +08:00
先了解下 Chunked 编码格式吧。参考我之前的提问: https://www.v2ex.com/t/417634#reply15,15 楼里面有几个参考资料。
还不理解的话,就自己使用 socket 模拟一个 chunked 编码的请求,然后输出内容来看下,或者自己手动解析下 chunked 编码的响应信息 |
4
snBDX1b0jJM4ogKd 2018-05-04 22:05:32 +08:00 via Android 1
chunk 的好处就是不用知道整个 body 的长度,比如压缩的时候,就边压缩边传输。
想确认一个 chunk 传输完毕,只需要先读 16 进制的表示 chunk 长度的数字,再按照这个数字读取给定长度,当然这个 chunk 就读取完毕了 一起不一起传输不用管,那是传输层负责的,你只需要知道,整个 body 的组成是 size CRLF data 这样的形式就 ok 了 |