使用netcat发送HTTP请求时响应体前的十六进制数是什么？

你看到的十六进制数是HTTP/1.1 Transfer-Encoding: chunked（分块传输编码）机制下的单个数据块的有效载荷长度，单位为字节。

分块传输编码的基本规则 #

当响应头携带Transfer-Encoding: chunked时，服务器不需要提前计算整个响应体的总长度（也就不需要返回Content-Length头），可以边生成内容边发送，响应体的结构会按照如下规则拆分：

• 每个数据块都以十六进制数字开头，该数字表示当前块有效载荷的字节长度
• 长度标记后紧跟\r\n，再后跟对应长度的实际载荷数据
• 载荷数据后再跟\r\n，标志当前块结束
• 所有有效数据块发送完成后，会发送一个值为0的十六进制长度标记，代表整个响应体传输结束，标记后可跟可选的尾部响应头，最后以空行收尾

数值匹配偏差的原因 #

你是将单个块的长度当成了整个响应体的总长度，才会出现换算后数值和实际响应体总长度不符的情况：

• 你示例中看到的5172换算为十进制是20850，代表紧随该标记之后的20850个字节都是当前块的有效内容
• 该块传输完成后，后续还会有其他带自身长度标记的新数据块，所有块的有效载荷长度累加才是整个响应体的总长度

举个简化的分块响应示例便于理解：

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
0\r\n
\r\n

上述示例中两个数据块的有效载荷分别为4字节和5字节，拼接后完整响应体为Wikipedia，总长度9字节。

内容的提问来源于stack exchange，提问作者Nick Bull