HTTP 协议（包体的传输方式&缓存的工作原理）

HTTP 协议（包体的传输方式&缓存的工作原理）

1.HTTP 包体

1.1 HTTP 包体格式

请求或者响应都可以携带包体，基于 ABNF 描述的格式如下：

#message-body = *OCTET:二进制字节流
HTTP-message = start-line *(header-field CRLF) CRLF [message-body]

1.2 不能携带包体的请求或响应

• HEAD 方法请求时对应的响应不能携带包体。
• 1xx、204、304 状态码对应的响应。
• CONNECT 方法对应的 2xx 响应。

1.3 发送定长包体格式

在发送 HTTP 消息时已经能够确定包体的全部长度，格式如下：

#使用 Content-Length 头部明确指明包体长度
Content-Length = 1*DIGIT

Tips：1*DIGIT 表示用 1 个 十进制（不是十六进制）数表示包体中的字节个数，必须与实际传输的包体长度一致，它的优点是接收端处理简单。

1.4 发送不定长包体格式

发送 HTTP 消息时不能确定包体的全部长度，需要使用 Transfer-Encoding 头部指明使用 Chunk 传输方式，含有 Transfer-Encoding 头部后 Content-Length 头部会被忽略。不定长包体优点如下：

• 基于长连接持续推送动态内容。
• 压缩体积较大的包体时，不必完全压缩完（计算出头部）再发送，可以边发送边压缩。
• 传递必须在包体传输完才能计算出的 Trailer 头部。

transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-extension

Chunked transfer encoding 分块传输编码：Transfer-Encoding:chunked

chunked-body = *chunk
				last-chunk
				trailer-part
				CRLF
				
chunk = chunk-size[chunk-ext] CRLF chunk-data CRLF

#chunk-size-1*HEXDIG:注意这里是十六进制

chunk-data-1*OCTET

last-chunk = 1*("0")[chunk-ext] CRLF

trailer-part = *(header-field CRLF)

2.常用 HTTP 缓存应用场景

如下图所示，以百度首页为例，展示了 HTTP 缓存场景：

Tips：disk cache 表示磁盘缓存，下次访问的时候不需要下载，可以直接去磁盘获取，memory cache 表示缓存存在内存中，当浏览器退出进程时，内存中的数据会被清空。