真实面经题目 · 原创解析
HTTP 并不是简单把数据塞进 TCP 发送，而是在 TCP 提供的可靠、有序、面向字节流的传输能力之上，定义了一整套应用层封装：报文格式、请求响应语义、头部元数据、消息体边界、连接管理、缓存协商、Cookie 状态、代理转发、安全传输以及不同版本的分帧和复用机制。TCP 只负责把字节可靠送达，不理解“请求”“响应”“URL”“状态码”“缓存”“Cookie”，这些都是 HTTP 在应用层补上的语义。
可以从分层角度回答：TCP 提供可靠、有序、面向连接的字节流，HTTP 在这个字节流上封装出应用层协议。具体包括：第一，定义请求报文和响应报文格式，例如起始行、头部、空行和消息体；第二，定义请求响应语义，例如方法、URI、状态码和原因短语；第三，定义头部机制，用键值对表达内容类型、长度、缓存、连接、认证、Cookie、代理等元信息；第四，解决 TCP 字节流没有天然消息边界的问题，通过 Content-Length、Transfer-Encoding: chunked 或连接关闭来确定消息体边界；第五，定义连接复用和连接管理，例如 HTTP/1.1 默认长连接，HTTP/2 在单个 TCP 连接上做多路复用；第六，围绕 Web 访问补充缓存、Cookie、代理、内容协商、压缩、范围请求等能力；第七，HTTPS 不是替换 TCP，而是在 HTTP 与 TCP 之间加 TLS，提供加密、完整性和身份认证；第八，HTTP/3 不再基于 TCP，而是基于 QUIC，说明 HTTP 语义和底层传输可以解耦。
TCP 是传输层协议，它提供可靠传输、有序交付、丢包重传、流量控制、拥塞控制和面向连接的全双工字节流。对 HTTP 来说，TCP 只保证字节按顺序到达，不会保留应用层消息边界。也就是说，发送端写入一次 HTTP 请求，接收端不一定一次 read 就完整读到这个请求；多个 HTTP 报文也可能在接收端表现为连续字节流。因此，HTTP 必须在 TCP 字节流之上自己定义报文边界和语义。
HTTP/1.x 在 TCP 字节流上定义了文本形式的请求报文和响应报文。请求报文通常由请求行、请求头、空行和可选消息体组成；响应报文通常由状态行、响应头、空行和可选消息体组成。请求行包含方法、请求目标和协议版本；状态行包含协议版本、状态码和原因短语。头部使用键值对表达元信息，空行用于区分头部和消息体。这个格式让 TCP 中连续的字节拥有了应用层结构。
TCP 不知道客户端是在查询资源、提交表单还是下载文件。HTTP 在 TCP 之上定义了请求响应模型：客户端发起请求，服务端返回响应。方法用于表达操作意图，例如 GET 通常表示获取资源，POST 通常表示提交数据，PUT 常用于整体更新，DELETE 常用于删除资源，HEAD 只获取响应头。状态码用于表达处理结果，例如 2xx 表示成功，3xx 表示重定向，4xx 表示客户端侧请求有问题，5xx 表示服务端处理失败。
HTTP 头部是 HTTP 相比裸 TCP 很重要的封装层。它把内容描述、连接策略、缓存策略、认证信息、Cookie、代理信息、压缩能力、语言偏好、范围请求等都抽象成统一的键值对。比如 Content-Type 表示消息体类型，Content-Length 表示消息体长度，Host 表示目标主机，User-Agent 表示客户端信息，Accept 系列头表示内容协商能力，Cache-Control 和 ETag 参与缓存控制，Cookie 和 Set-Cookie 让无状态请求可以携带会话状态。
TCP 是字节流，没有天然的“这一段是一个 HTTP 请求体”的概念。HTTP 必须定义消息体如何结束。常见方式有三种：使用 Content-Length 明确声明消息体字节数；使用 Transfer-Encoding: chunked 将消息体拆成多个分块，每个分块带长度，最后用长度为 0 的分块结束；在某些场景下通过关闭连接表示消息结束。这个边界定义非常关键，否则接收方无法判断当前报文何时结束、下一个报文何时开始。
早期 HTTP 可以每个请求使用一个 TCP 连接，但建立 TCP 连接有握手成本，频繁创建连接会增加延迟和资源消耗。HTTP/1.1 默认使用持久连接，同一个 TCP 连接可以承载多个请求响应，减少握手开销。它也支持通过 Connection 相关头部表达连接关闭或保持。HTTP/1.1 管线化尝试在同一连接连续发送多个请求，但响应仍需按顺序返回，容易受到队头阻塞影响，实际使用受限。
HTTP/2 仍然可以运行在 TCP 之上，但它不再使用 HTTP/1.x 的纯文本报文格式，而是把 HTTP 语义映射到二进制帧。HTTP/2 引入流、帧、多路复用、头部压缩和优先级等机制。多个请求响应可以在同一个 TCP 连接上并发交错传输，减少 HTTP/1.1 多连接和顺序响应带来的开销。不过由于底层仍是 TCP，一旦 TCP 层发生丢包，同一连接上的所有 HTTP/2 流都可能被阻塞，这属于 TCP 层队头阻塞。
HTTP 还在 TCP 之上封装了大量 Web 应用所需的通用机制。缓存机制通过 Cache-Control、Expires、ETag、Last-Modified 等头部减少重复传输；Cookie 通过客户端携带状态标识，让服务端可以识别会话；代理机制允许请求经过中间节点转发、缓存、鉴权或负载均衡；Via、Forwarded、X-Forwarded-For 等头部常用于表达中间链路信息。这些能力都不是 TCP 具备的，而是 HTTP 面向应用场景提供的协议语义。
HTTPS 可以理解为 HTTP over TLS over TCP。TCP 仍负责可靠传输，TLS 位于 HTTP 和 TCP 之间，提供加密、完整性校验和服务器身份认证。HTTP 报文在进入 TCP 之前先被 TLS 加密封装，网络中间节点只能看到连接元信息，无法直接读取 HTTP 明文内容。TLS 不改变 HTTP 的方法、状态码、头部和消息体语义，但会改变传输安全属性。
HTTP/3 不基于 TCP，而是基于 QUIC，QUIC 通常运行在 UDP 之上。HTTP/3 保留 HTTP 的核心语义，例如方法、状态码、头部和内容语义，但把传输层能力交给 QUIC，例如连接建立、加密、多路复用、流控制和拥塞控制。这个演进说明：HTTP 的应用语义可以和底层传输解耦；HTTP/1.1 和 HTTP/2 常见部署依赖 TCP，而 HTTP/3 则不再使用 TCP。
因为 TCP 只保证字节可靠、有序到达，不保证发送端一次 write 对应接收端一次 read。接收端可能一次读到半个 HTTP 请求，也可能一次读到多个请求的连续字节。因此 HTTP 必须通过协议格式判断头部在哪里结束、消息体有多长、当前报文何时结束。
Content-Length 在发送消息体前就声明总字节数，接收方按这个长度读取。Transfer-Encoding: chunked 适合发送方一开始不知道总长度的场景，消息体被拆成多个分块，每个分块先声明当前块长度，最后用结束块表示传输完成。二者本质上都是为了解决 TCP 字节流上的消息体边界问题。
它减少了频繁建立和关闭 TCP 连接的成本。没有长连接时，每个请求都可能经历 TCP 握手、慢启动和连接释放。长连接允许多个请求响应复用同一个 TCP 连接，降低延迟和资源消耗。
没有彻底解决。HTTP/2 解决的是 HTTP/1.1 应用层顺序响应导致的队头阻塞，因为多个流可以在同一个连接中交错传输。但 HTTP/2 常运行在 TCP 上，如果 TCP 层丢包，后续字节都要等待重传，连接上的多个流仍可能一起被阻塞。
HTTPS 不是新的应用语义协议，而是 HTTP 加 TLS。HTTP 的方法、状态码、头部、消息体等语义仍然存在；TLS 负责在传输前加密 HTTP 数据，并提供完整性保护和身份认证；TCP 继续负责可靠传输。
因为 HTTP/3 基于 QUIC，而 QUIC 通常运行在 UDP 之上。HTTP/3 保留 HTTP 的请求响应语义，但连接建立、加密、多路复用、流控和拥塞控制由 QUIC 提供，不再依赖 TCP。
典型是 Cookie、认证和缓存。TCP 连接本身不理解用户身份、登录状态、资源版本或缓存有效期；HTTP 通过 Cookie、Authorization、Cache-Control、ETag 等头部让应用能够表达状态、权限和资源新鲜度。
