HTTP的持续与非持续连接，HTTP报文格式

1.引言

在 HTTP 通信中，客户端与服务器之间如何建立和维护 TCP 连接，直接影响网络性能。因为在互联网应用中，客户端和服务器往往需要长时间保持通信。例如当我们浏览网页时，浏览器（客户端）会不断向服务器请求网页内容、图片、视频等资源。 这种交互过程中，开发者需要决定一个关键问题：每次请求都建立新的网络连接，还是复用已有连接？  这一设计决策分为两种模式：非持续连接和持续连接。

2.非持续连接

非持续连接要求每个 HTTP 请求-响应对（如请求一个 HTML 文件、一张图片）都使用独立的 TCP连接。完成请求后，连接立即关闭。

这种模式在早期 HTTP/1.0 中广泛使用。 他的工作流程是：

1. 客户端发起请求 → 建立 TCP 连接 → 发送 HTTP 请求报文 → 服务器返回响应 → 关闭 TCP 连 接。

2. 若需请求第二个资源（如图片），需重新建立新的 TCP 连接，重复上述过程。

3.举例

HTTP 响应时间的估算 HTTP 响应时间：建立连接起 到 收到响应报文止。

请求一个数据的HTTP响应时间约等于 2RTT+一个文件数据的传输时间 注意 通常在第三次握手的报文段中携带客户的请求

4.非持续连接的现状与优化

非持续连接无需管理连接状态，适合早期网络环境，十分简单。而且资源隔离，每个连接独立，避免资源竞争。

但是频繁建立/关闭连接消耗服务器和客户端资源，会造成资源浪费。而且服务器需频繁创建和销毁连接，增加 CPU 和内存开销

尽管非持续连接在现代 Web 中已被持续连接取代，但在以下场景仍可能使用： 某些物联网设备或嵌入式系统因资源限制，采用非持续连接减少内存占用。以及旧系统或特定协议（如某些 API）可能强制要求非持续连接。当然了，如果仅包含 HTML 文本的静态页面，无需多次请求，也可以使用。

非持续连接的 HTTP 协议（HTTP/1.0）通过简单性实现了早期 Web 的基本功能，但其高延迟和资源浪费暴露了设计局限性。这一模式揭示了网络协议演进的核心原则：在复杂性与性能之间寻找平衡。 随着 Web 页面复杂度的提升，HTTP/1.1 引入持续连接（Keep-Alive），并通过复用 TCP（非持续连接） 连接显著优化了性能。

举例：

假如还是一个HTTP文件和10个图片=》但采用复用TCP连接

2RTT-------》传输HTTP文件（只有知道了它才能请求图片）

2RTT-------》传输8个图片

2RTT-------》传输最后两个图片

5.持续连接

非持续连接（Non-Persistent Connection）虽然简单直观，但存在两大显著缺点：

1. 资源浪费与服务器负担 每个请求都需要建立和关闭独立的 TCP 连接，服务器需为每个连接分配缓冲区、维护状态变量。当服务器同时处理成百上千个请求时，这种开销会迅速累积，导致性能下降。

2. 延迟过高 每个对象的请求需经历 2 × RTT 的延迟（1 次用于 TCP 握手，1 次用于请求-响应）。对于复杂网页（如包含 20 个资源），总延迟可达 40 × RTT，严重影响用户体验。

为解决这些问题，HTTP/1.1 引入了持续连接，通过复用 TCP 连接大幅优化性能。

HTTP持续连接通过复用TCP连接实现资源高效传输，是当代Web性能优化的基石。其设计哲学可概括为："一次握手，多次通信"，显著降低网络延迟与服务器负载。持续连接允许客户端与服务器在 单个 TCP 连接 上发送多个请求和响应。连接在完成所有请求后才关闭，而非每次请求后立即断开。

举例：

假设一个网页包含 1 个 HTML 文件 + 10 个 JPEG 图片，且所有资源位于同一服务器：

1.建立 TCP 连接 客户端与服务器建立 1 个 TCP 连接（1 × RTT）。

2.发送请求与接收响应 客户端连续发送 11 个 HTTP 请求（HTML + 10 张图片），服务器按顺序返回响应。无需重复握手，所有请求共用 1 个 TCP 连接。

3.连接关闭 所有资源传输完成后，服务器关闭连接（或等待超时）。

这样一来，仅需 1 × RTT 建立连接，后续请求无需额外握手。避免频繁创建/销毁连接，降低服务器负载，节省资源。

6.持续连接的优化（流水线）

HTTP/1.1 在持续连接基础上引入了 流水线，技术，进一步减少延迟。

流水线请求即户端连续发送多个请求，无需等待前一个请求的响应。服务器按接收顺序返回结果。 如此一来，请求-响应不再“串行排队”，而是“并行推进”。

11 个请求仅需 1 × RTT（握手） + 1 × RTT（请 求-响应序列），节省了RTT。相比于之前，延迟降低 90% 以上。

7.对于持续连接总结

持续连接的配置与默认行为 HTTP/1.1 默认使用 带流水线的持续连接，但是这个是我们可以配置的。

客户端/服务器可手动关闭持续连接（如 Connection: close ）。当然我们也可以配置超时时间，若连接空闲超过配置的超时时间（如 30 秒），服务器自动关闭连接。

尽管持续连接显著优化了性能，但仍存在局限性：

比如某个请求的响应较慢，后续请求需等待，导致整体延迟。 为了解决这个问题，HTTP/2 引入 多路复用，在单个连接中并行传输多个请求/响应。也会有长时间保持连接会占用服务器内存和端口对的问题，常见的处理办法是通过动态调整超时时间和连接池技术（Connection Pooling）缓解资源压力。

HTTP/2：基于持续连接的多路复用，彻底消除队头阻塞。

HTTP/3：基于 QUIC 协议，进一步降低延迟，适应移动端网络环境 持续连接避免多次握手，尤其适合复杂网页（如现代网站包含数十个资源）。而且服务器无需频繁创建和销毁连接，降低负载。但是长期保持连接会占用服务器内存和端口，服务器资源占用问题显著。而且需要处理连接超时、错误恢复等问题。

当然，持续连接也通过 复用 TCP 连接 和 流水线技术，解决了非持续连接的高延迟与资源浪费问题

8.HTTP的报文格式

HTTP 报文是 HTTP 客户端与服务器之间通信的核心载体，分为 请求报文和响应报文。

HTTP是面向文本的，其报文中的每一个字段都是一些ASCII码串，并且每个字段的长度都是不确定的。

8.1请求报文格式

                          

主要来看一下请求行的方法字段，看一下常见的方法：

HTTP 方法不仅是技术规范，更是设计哲学的体现：

GET 代表“只读”，适合获取数据；

POST 代表“写入”，适合提交数据；

PUT/DELETE 代表“修改/删除”，适合资源管理。

理解这些方法的语义与适用场景，是构建高效、安全 Web 应用的基础。

8.2首部行

HTTP请求首部行如同邮件信封上的附加信息，虽然不直接传递核心内容，却包含着控制通信行为 的关键指令。是请求报文或响应报文中传递元信息的关键部分。它们通过字段名与字段值的键值对形 式，向服务器或客户端传递附加指令。构成了Web通信的"智能调节器。 首部行通过组合使用，实现更复杂的交互逻辑。

例如，浏览器发送请求时包含：

Host: www.someschool.edu （指定目标站点）；

Accept-Language: fr （请求法语资源）；

Connection: close （一次性请求后关闭连接）。

服务器根据 Host 确定站点，根据 Accept-Language 返回法语版页面，最后按 Connection:close 断开连接。 每个首部行以 冒号加空格（ : ）分隔字段名与值；首部行以 回车换行符（CRLF，即 \r\n ）结束；最后一行首部行后必须添加 空行（即单独的 CRLF），表示首部结束。

实体主体： 仅在POST/PUT请求中存在，用于传输表单数据、文件等二进制内容，比如 username=admin&password=123456 。

8.3响应报文格式

8.4状态行

状态行是响应报文的第一行，包含三个关键字段：

协议版本（HTTP 版本）：声明使用的 HTTP 协议版本（如 HTTP/1.1 ）。

状态码：三位数字，表示请求的处理结果（如 200 表示成功，404 表示未找到）。

状态短语：对状态码的简要描述（如 OK 、 Not Found ）。 比如例子中的 HTTP/1.1 200 OK 表示服务器成功处理请求，返回资源

首部行： 每行由字段名与字段值组成，用于传递服务器的附加信息。

实体主体： 实体体是响应报文的核心部分，包含客户端请求的资源内容（如 HTML 文件、图片数据）。

在示例中， data data data data data ... 是占位符，实际内容可能是完整的 HTML 代码或二进制数据。实体主题没有固定格式，内容类型由 Content-Type 字段定义（如 text/html 、image/jpeg ）。部分响应（如 HEAD 方法）不包含实体主体，所以是否需要实体部分是可以选择的。实体主题通过 TCP 流式传输，客户端逐步接收并解析。