一. 分块编码
分块编码传输应该是和持久连接配合使用的.因为如果不是持久连接的话那也不需要知道长度等信息了,只需要读到连接关闭即可.
在持久连接的情况下,如果是服务器动态创建内容可能无法提前知道主体的长度,Content-Length也就无法明确,自然也就无法确认某次响应需要读取多少数据了.这时候就可以利用分块编码传输解决这个问题.同时分块的方式也可以提高效率,比如传输过程中需要使用压缩技术,分块可以实现一边压缩一边传输.
分块编码基本格式如下(这里以应答为例子):
|
|
首先第一部分和常规的HTTP应答一致,协议版本 ,应答码以及短语,各响应头.其中需要注意的是如果是分块编码则Transfer-Encoding必须指定chunked.然后以一个<CR><LF>
和主体部分分隔.接下去就是一个个数据分块了,其中每个分块的格式都是一致的:
length是十六进制的数据长度.
然后最后一个分块比较特殊,他是一个0长度的分块,表示数据结束.这时候接收端就认为这次的数据已经读取完成了.
其中分块传输除了上面提到的优点之外还有一个好处就是方便在主体内容传输完成之后再补充一些Header信息.如同示例里的Content-MD5.因为一开始无法知道主体的全部内容自然也是无法计算数据校验信息.这时候如果使用chunked再配合Trailer头就可以在分块数据的末尾补充一些Header信息.
二. Trailer
首先添加Trailer头信息说明后续补充的Header列表.
Trailer: Content-MD5<CR><LF>
不过客户端并不一定会处理分块数据尾部的Header信息.所以一般配合Te
头信息使用。
比如:
这时候如果有尾部挂载信息的话,上面的格式就得修改下:
|
|
补充信息紧跟在0块后面,然后格式和头信息一致.
三.Go代码实现Demo
知道了传输的一个格式,那自然是需要自己尝试以下.
其中核心代码如下:
|
|
完整代码在这里
四. Go标准库如何发送chunked数据以及查看挂载信息
发送chunked代码同样是调用Flush方法即可
|
|
查看挂载信息则需要在读取完主体内容后才可以操作
|
|
五. 补充
理论上挂载的信息应该是需要在Trailer头中指明的.但是实际测试却发现不是这样,翻阅标准库代码发现如果fixTrailer
方法预先处理的Trailer为空,但是报文仍旧含有挂载信息的话,那么就会直接将读取到的挂载信息作为Trailer使用,而不去依照key做value的匹配.
部分代码如下:
|
|
结论就是在使用go标准库的时候,如果没有指定Trailer头的值,go标准库还是可以完全读取解析全部挂载信息的.如果指定了Trailer头信息,那么只会匹配指定的field.