分块传输编码（Chunked Transfer Encoding）是 HTTP/1.1 协议中的一项核心特性，它允许服务器在不预先知道响应体总大小的情况下，高效地传输数据。这项技术解决了传统 Content-Length 机制的局限性，使得 HTTP 协议能够完美地支持流式传输和动态生成内容。

在 HTTP/1.0 时代，服务器必须在发送响应之前计算出内容的精确字节数，并通过 Content-Length 头部告知客户端。这种模式在处理静态、大小固定的文件时非常有效，但在处理动态内容、大型文件流或实时数据推送时则无能为力。

分块传输正是为此而生。它通过在协议层引入一种灵活的“分块”模式，让服务器可以在数据生成的同时，立即开始向客户端发送。

分块传输的实现依赖于客户端与服务器之间的严格报文约定。整个响应流分为两个主要部分：响应头和响应体。

1. 响应头：宣告分块模式

服务器首先在响应头中包含 Transfer-Encoding: chunked 字段，以此明确告知客户端，接下来的响应体将以分块方式编码。这个字段会取代传统的 Content-Length。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

2. 响应体：数据块序列

响应体由一个或多个数据块组成，每个数据块都遵循一个精确的格式：[十六进制长度]\r\n[数据内容]\r\n。

3. 传输结束：零长度标记

当所有数据块都发送完毕后，服务器必须发送一个长度为 0 的特殊数据块，以标志响应体的结束。这个结束标记的格式是 0\r\n\r\n。

一个完整的、精确的报文示例：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked4\r\n
Wiki\r\n
5\r\n
pedia\r\n
B\r\nin chunks.\r\n
0\r\n
\r\n

第一个数据块: 4\r\n + Wiki\r\n。长度 4（十六进制）对应内容 Wiki，共 4 个字节。
第二个数据块: 5\r\n + pedia\r\n。长度 5（十六进制）对应内容 pedia，共 5 个字节。
第三个数据块: B\r\n + in chunks.\r\n。长度 B（十六进制）即十进制 11，对应内容 in chunks.，共 11 个字节。
结束标记: 0\r\n\r\n。长度为 0 的数据块，表示数据传输结束。

对于客户端来说，处理分块传输并非一个简单的文件下载过程，而是一个分阶段的流式解析和重组过程。这项任务通常由客户端底层的 HTTP 库或浏览器引擎自动完成，对上层应用是透明的。

当客户端收到服务器的响应头，发现 Transfer-Encoding: chunked 时，它会立即改变其数据接收模式，进入一个专门用于处理分块编码的状态机。这个状态机的工作流程可以分为以下几个关键步骤：

读取块大小：客户端会持续从网络套接字（socket）中读取数据，直到遇到第一个 \r\n 序列。它将这之前的所有字节解析为一个十六进制的数字，这个数字就是即将到来的数据块的字节长度。
读取数据内容：一旦确定了数据块的大小，客户端就会精确地从套接字中读取相应数量的字节。这些字节就是该数据块的实际内容。这个过程是阻塞的，客户端会等待所有字节都到达，然后才继续下一步。
读取块结束标记：在读取完数据内容后，客户端会继续从流中读取两个字节 (\r\n)。这只是一个分隔符，用于将数据内容和下一个块的长度隔开。客户端会简单地丢弃这两个字节。
循环与终止判断：在完成上述三个步骤后，客户端会根据上一步读取到的块大小进行判断：
- 如果块大小不为零，客户端会回到第 1 步，继续读取下一个块的长度，并重复整个过程。
- 如果块大小为零，这意味着服务器已经发送了所有数据。客户端会再读取最后的 \r\n，然后将整个流标记为结束。