我很困惑。我有两台笔记本电脑通过同一个调制解调器设备连接到互联网。gzip例如，对于在其中启用的 Web 服务器，microsoft.com我的系统之一（64 位）使用Transfer-Encoding:chunked. 另一个以正确的形式获取响应标头Content-Encoding:gzip。为什么？两个系统都有 Windows 7 SP1（其中一个是 32 位，另一个是 64 位）。我在两个系统上使用相同版本的 Chrome 进行了测试。我还用 FireFox 和 IE 进行了测试。
问问题
3057 次
1 回答
0
因为在传输编码中不需要将要传输的分块内容长度。数据被分割成碎片并通过网络发送。
从维基百科页面：
块传输编码是超文本传输协议 (HTTP) 1.1 版中的一种数据传输机制，其中数据以一系列“块”的形式发送。它使用 Transfer-Encoding HTTP 标头代替 Content-Length 标头，否则早期版本的协议将需要该标头。因为没有使用 Content-Length 标头，所以发送方在开始向接收方发送响应之前不需要知道内容的长度。发件人可以在知道内容的总大小之前开始传输动态生成的内容。
每个块的大小在块本身之前发送，以便接收者可以知道它何时完成接收该块的数据。数据传输由长度为零的最终块终止。
编码数据
在下面的示例中，每隔一行是一个新块的开始，块大小为十六进制数字，后跟 \r\n 作为行分隔符。
4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
in\r\n\r\nchunks.\r\n
0\r\n
\r\n
注意：chunk size 仅表示 chunk 数据的大小。这不包括计数字符末尾的尾随 CRLF ("\r\n")。在此特定示例中，“in”之后的 CRLF 在 0xE (14) 的块长度中计为 2，而在其自己的行中的 CRLF 在 0xE (14) 的块长度中也计为 2。“块”末尾的句点字符是第 14 个字符，因此它是长度为 0xE (14) 的块的最后一个字符。句点后面的 CRLF 是尾随 CRLF，因此它不计入 0xE (14) 的块长度。
解码数据
Wikipedia in
chunks.
于 2015-08-25T12:55:51.963 回答