HTTP 协议解析 • Atri Website

HTTP（HyperText Transfer Protocol，超文本传输协议）是运行在应用层的一种网络协议，最初设计用于分布式、协作式和超媒体信息系统。它是万维网数据通信的基础，定义了客户端与服务器之间如何格式化和交换数据，例如 HTML 文档、图片、JSON 数据。HTTP 默认基于底层传输层的 TCP 协议，常用 80 端口，而 HTTPS 则是建立在 TLS/SSL 安全层之上的 HTTP，常用 443 端口。

工作原理#

HTTP 的核心工作机制可由以下几点给出：

请求与响应模型：通信永远由客户端发起。客户端构建一个 HTTP 请求报文并发送给目标服务器，服务器接收、解析并处理该请求后，返回一个包含处理结果（状态码）和可能的数据负载的 HTTP 响应报文。
无状态 stateless：HTTP 协议下服务器不会去维护与客户交互的相关信息，因此它对于事务处理没有记忆能力。服务器不会记录前一次请求的任何信息，每一个请求都是完全独立。例如，客户端通过服务器认证后成功请求了一个资源，紧接着再次请求这一资源时，服务器仍旧会要求你表明身份。
连接管理：现代普遍才用 1.1 版本以上的 HTTP，默认开启长连接 Keep-Alive，即允许在同一个 TCP 连接上复用、传输多个 HTTP 请求和响应，显著降低建立和拆除底层网络连接的延迟开销。

架构设计#

HTTP 采用 C/S 架构，但在现代的互联网拓扑中，客户端和源服务器之间一般不会直连，而是存在多个中间节点，进行客户端和服务端之间的流量转发。一般来说，HTTP 通信的架构为：

客户端：发起请求的端点，最常见的是 Web 浏览器，也可以是移动端 App、爬虫程序、或服务间的 RPC 调用客户端。
源服务器：实际保存请求资源或执行核心业务逻辑的物理或虚拟主机，例如 Nginx 反向代理背后的应用服务器或数据库端点。
中间节点：
- 代理 Proxy：在遇到流量审查、访问控制或网络限制，例如防火墙时，便需要代理代表客户端接收请求并将其转发给服务器。
- 网关：作为其他服务器的中间人，经常负责协议转换，例如接收 HTTP 请求，但在内部网段将其转换为其他协议。
- 缓存：存储常用资源的副本，例如各地的 CDN 节点。当请求到达时，如果缓存命中，直接由缓存节点返回响应，极大减轻源站压力并降低用户访问延迟。
- 隧道：在两个连接之间盲目转发原始报文流的中继点，常用于穿越防火墙，例如建立 HTTPS 连接时的协商过程。

工作流程#

开始客户首先发起一个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。
客户向它的套接字接口发送 HTTP 请求报文并从它的套接字接口接收 HTTP 响应报文
服务器从它的套接字接口接收 HTTP 请求报文和向它的套接字接口发送 HTTP 响应报文
一旦客户向它的 socket 发送了一个请求报文，该报文就脱离了客户的控制并进入 TCP 的控制

报文格式#

请求报文#

报文文本使用 ASCII 文本书写，第一行叫做请求行（request line），有三个字段：方法字段、URI 字段和 HTTP 版本字段。

方法字段一般有以下五种：

GET：向指定的 URL 请求获取资源。GET 请求的数据通常附加在 URL 的查询字符串中，例如 “?id=123”，只应当用于请求数据，而不应该用于提交会改变服务器状态的操作。
POST：向指定资源提交数据，请求服务器进行处理。通常用于表单提交、文件上传。提交的数据被包含在 HTTP 报文的实体体里。
PUT：向指定位置上传最新内容，用于整体替换目标资源。客户端必须提供指定资源的完整数据。如果该 URL 指定的资源不存在，PUT 通常会创建该资源；如果存在，则用新数据完全覆盖旧数据。
DELETE：请求服务器删除 Request-URI 所标识的资源，客户端发出删除指令，服务器响应该指令并移除对应的数据。
HEAD：请求获取与 GET 请求相同的响应，但服务器不返回响应体，只返回起始行和首部字段。

Request-URI：请求统一资源标识符，查看上图的请求行格式，Request-URI 就是 URI 字段。当访问 http://www.example.com/api/users?id=123 ↗ 时，浏览器发出的 HTTP 请求行为 GET /api/users?id=123 HTTP/1.1，其中 /api/users?id=123 就是 Request-URI。

后面的所有行总称叫做首部行（header line），包含以下关键字段：

Host 指明了对象所在的主机。
User-agent：首部行用来指明用户代理，即向服务器发送请求的浏览器的类型，这里是火狐浏览器。
Accept：指定客户端接受哪些类型的信息，图中的 “text/html” 表明用户希望接收 text/html 格式的资源。
Accept-Charset：指定客户端接受的字符集，缺省是任何字符集都可以接受。
Accept-Encoding：指定可接受的内容编码，缺省是各种内容编码都可以接受。
Connection：keep-alive 字段告诉服务器请求建立持续连接。如果是 close，则不要麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。

请求报文的通用格式

sp 表示空格，crlf 表示回车和换行，除了作为结尾的 crlf 外，不允许出现单独的 cr 或 lf 字符。

实体体 entity body：使用 GET 方法时实体体为空，而使用 POST 方法时才使用该实体体。

用户提交表单时，HTTP 客户常常使用 POST 方法，例如用户向搜索引擎提供搜索关键词。使用 POST 报文时，用户仍可以向服务器请求一个 Web 页面，但 Web 页面的特定内容依赖用户在表单字段中输入的内容。如果字段方法是 POST，那么 entity body 里面的内容就是用户在表单字段中的输入值。比如在搜索框内输入一个字符串 abcdefg，然后点击搜索，这时候会使用 POST 方法，而 entity body 的内容就是 abcdefg。

响应报文#

在接收和解释请求消息后，服务器返回一个 HTTP 响应消息。

第一行叫做状态行 status line，具有三个重要字段：协议版本字段、状态码、响应状态信息。

后面的所有行都叫做首部行 head line。图中包含了一些关键字段：

Connection：close 告诉客户这是一次非持续性连接。
Date：首部行指示服务器产生并发送该报文的日期和时间。注意：这并不是这个 entity body 创建或最后修改的时间，而是服务器将该对象插入到这个响应报文并把这个报文发送给客户的时间。
Server：类似请求报文的 User-Agent。
Last-Modified：entity body 创建或者最后修改的日期和时间。
Content-Length：被发送对象中的字节数，图中为 6821 个字节。
Content-type：实体体中的对象属性，图中为 html 格式。

括号中的 data 便是 entity body，即实体体。

HTTP 状态码#

HTTP 状态码的作用：Web 服务器用来告诉客户端，发生了什么事。状态代码的第一个数字代表当前响应的类型：

1xx 消息：请求已被服务器接收，继续处理。
2xx 成功：请求已成功被服务器接收、理解、接受。
3xx 重定向：需要后续操作才能完成这一请求。
4xx 客户端错误：请求含有词法错误或者无法被执行。
5xx 服务器错误：服务器在处理某个正确请求时发生错误。

常见的状态码有：

200：OK 服务器成功处理了请求。
206：Partial Content（部分内容）代表服务器已经成功处理了部分 GET 请求。
301：Moved Permanently（永久重定向）请求的 URL 已移走。Response 中应该包含一个 Location URL, 说明资源现在所处的位置。
302：Moved Temporarily（临时重定向）。
304：Not Modified（未修改）客户的缓存资源是最新的，要客户端使用缓存。
400：Bad Request（坏请求）告诉客户端，它发送了一个错误的请求。
401：Unauthorized（未授权）需要客户端对自己认证。
404：Not Found 未找到资源。
500：Internal Server Error 服务器遇到一个错误，使其无法对请求提供服务。

HTTPS 协议#

前文提到，HTTP 协议本身不提供任何加密机制，客户端与服务器之间的所有数据均以明文形式在 TCP 连接上传输。这意味着在网络中传输的敏感信息——如密码、Cookie、请求参数——可以被同一网段内的任何中间节点轻易截获和读取。HTTPS（HyperText Transfer Protocol Secure）正是为了解决这一安全问题而提出的，它在 HTTP 与 TCP 之间插入了一个安全层，即 TLS（Transport Layer Security）协议，对所有应用层数据进行加密传输。

与 HTTP 的关系#

HTTPS 并非一个全新的协议，而是 HTTP over TLS。其协议栈结构为：

应用层：    HTTP
安全层：    TLS / SSL
传输层：    TCP
网络层：    IP

plaintext

与 HTTP 相比，HTTPS 仅在传输层之上多了一层 TLS。HTTP 的请求报文格式、方法、状态码等均保持不变，差别在于这些报文在交给 TCP 之前，会先被 TLS 层加密。HTTPS 默认使用 443 端口，而 HTTP 使用 80 端口。浏览器通过 URL 的协议前缀 https:// 来识别并发起 TLS 握手。

加密原理#

TLS 的核心目标是在不安全的网络上建立一条安全的通信通道。它同时解决了三个问题：

机密性：对称加密保证传输的数据无法被第三方读取。
完整性：消息认证码（MAC）保证数据在传输过程中未被篡改。
身份认证：数字证书保证通信对端的身份是可信的。

TLS 握手阶段采用非对称加密（如 RSA 或 ECDHE）来安全地协商一个对称密钥，后续的应用数据则使用该对称密钥进行加密传输。这种混合加密机制兼顾了安全性与性能——非对称加密仅用于密钥交换阶段，开销较大的对称加密则用于后续大量的数据传输。

TLS 握手过程#

以 TLS 1.2 为例，一次完整的握手过程如下：

客户端                                          服务器
  │                                                │
  │──── ClientHello ──────────────────────────────→│
  │     (支持的TLS版本、加密套件列表、随机数)        │
  │                                                │
  │←─── ServerHello ──────────────────────────────│
  │     (选定的TLS版本、加密套件、随机数)            │
  │←─── Certificate ──────────────────────────────│
  │     (服务器的数字证书，含公钥)                   │
  │←─── ServerHelloDone ──────────────────────────│
  │                                                │
  │──── ClientKeyExchange ────────────────────────→│
  │     (用服务器公钥加密的预主密钥)                 │
  │──── ChangeCipherSpec ─────────────────────────→│
  │──── Finished ─────────────────────────────────→│
  │                                                │
  │←─── ChangeCipherSpec ─────────────────────────│
  │←─── Finished ─────────────────────────────────│
  │                                                │
  │     ═══ TLS 加密通道建立 ═══                    │
  │──── 加密的 HTTP 请求 ─────────────────────────→│
  │←─── 加密的 HTTP 响应 ─────────────────────────│

plaintext

ClientHello：客户端向服务器发送自己支持的 TLS 版本、加密套件列表和一个客户端随机数。
ServerHello：服务器从中选定一个加密套件，返回服务器随机数。
Certificate：服务器将自身的数字证书发送给客户端，证书中包含服务器的公钥和由 CA 签发的数字签名。
密钥交换：客户端验证证书的合法性后，生成一个预主密钥（Pre-Master Secret），用服务器的公钥加密后发送给服务器。双方使用客户端随机数、服务器随机数和预主密钥各自计算出相同的对称会话密钥。
Finished：双方发送 ChangeCipherSpec 通知对方后续通信将使用对称加密，再各发送一个 Finished 消息验证握手过程的完整性。

此后所有 HTTP 数据均通过对称密钥加密传输，直至连接关闭或会话超时重新握手。

TLS 1.3 在此基础上做了显著改进：握手从两个往返减少为一个往返（1-RTT），移除了不安全的加密算法，并支持 0-RTT 恢复模式。

数字证书#

数字证书是 HTTPS 身份认证的核心。它由权威的证书颁发机构（Certificate Authority，CA）签发，本质上是一份将服务器公钥与其身份信息绑定的电子文件，并由 CA 的私钥进行数字签名。

证书的信任链如下：

根证书（Root CA，预装在操作系统/浏览器中）
  └── 中间证书（Intermediate CA）
        └── 服务器证书（End-entity Certificate）

plaintext

浏览器在收到服务器证书后，沿着信任链逐级验证签名，直至根证书。如果验证通过，说明该服务器的公钥是可信的；如果验证失败（如证书过期、域名不匹配、签名无法追溯到受信任的根 CA），浏览器会弹出安全警告。

自签名证书是由服务器自己签发的证书，不经过任何 CA，因此不被浏览器信任。但自签名证书的加密强度与 CA 签发的证书完全一致，其 TLS 握手和数据加密过程没有区别，只是缺少了第三方身份担保。在本地开发和测试环境中，自签名证书足以满足加密需求。

HTTPS 与 HTTP 的对比#

对比项	HTTP	HTTPS
协议栈	HTTP → TCP	HTTP → TLS → TCP
默认端口	80	443
数据加密	无明文传输	TLS 加密
身份认证	无	数字证书
性能开销	低	TLS 握手有额外延迟
SEO	无加权	搜索引擎优先收录
证书	不需要	需要 SSL/TLS 证书

HTTPS 通过 TLS 协议为 HTTP 通信提供了机密性、完整性和身份认证三重保障。在当前的互联网环境中，HTTPS 已成为 Web 安全的事实标准，主流浏览器会对纯 HTTP 站点标记”不安全”警告。