02HTTP协议

## 一、URI

URI（Uniform Resource Identifier） 是唯一标识资源的字符串，用于定位或命名网络中的资源（如网页、图片、接口等），最常见的形式是 URL（统一资源定位符）。

URI（Uniform Resource Identifier） 是用于唯一标识互联网中资源的字符串，无论资源是网页、图片、API 接口还是文件，都可通过 URI 唯一定位或命名。其核心作用是解决 “如何在网络中唯一标识一个资源” 的问题。

**URI 是一个抽象概念，包含两个具体子集：**

- URL（Uniform Resource Locator，统一资源定位符）：通过 “位置” 标识资源（如https://www.example.com/path?query=1），包含访问资源的协议、主机、路径等信息，可直接用于定位和访问资源。
- URN（Uniform Resource Name，统一资源命名符）：通过 “名称” 标识资源（与位置无关），如urn:isbn:9787115546081（ISBN 图书编号），仅命名资源，不包含访问方式。

简言之：URI = URL + URN，但实际应用中 99% 的 URI 都是 URL（因为网络中更需要 “定位” 资源而非单纯 “命名”），因此常将 URI 和 URL 混用。

### 1.1 结构

通用格式：scheme://authority/path?query#fragment

- **scheme（协议）**：资源访问协议。

案例：https://（HTTPS 协议）、ftp://（文件传输协议）、mailto:user@example.com（邮件协议）。

- **authority（权限）**：包含主机和端口（host:port）。
  案例：www.taobao.com:8080（主机为www.taobao.com，端口 8080；默认端口可省略，如https://www.taobao.com隐含端口 443）。

- **path（路径）**：资源在服务器上的位置。
  案例：/category/electronics（电商网站中 “电子产品分类” 的资源路径）。

- **query（查询参数）**：向资源传递的参数（?key=value&key2=value2）。
  案例：/search?keyword=手机&price=1000-3000（电商搜索 “1000-3000 元的手机”）。

- **fragment（片段）**：资源内部的子部分（仅客户端解析）。
  案例：https://example.com/article#section3（直接跳转到文章的 “第三节”）。

### 1.2 编解码

URL 编码（Percent-Encoding）是一种将 URL 中不符合规范的字符转换为特定格式（%XX，其中XX为字符的 ASCII 十六进制值）的编码方式，目的是确保 URL 能被正确传输和解析。

URL 的设计基于 ASCII 字符集，且部分字符（如/、?、&）有特殊含义（例如?分隔路径和查询参数，&分隔多个查询参数）。如果 URL 中包含以下字符，会导致解析错误或歧义：

1. 非 ASCII 字符（如中文、日文、俄文等）；
2. 有特殊含义的 “保留字符”（如&、=、?）在非指定位置使用；
3. 控制字符（如换行符、制表符）或空格。

因此，这些字符必须通过编码转换为 URL 规范允许的格式。

**编码规则**

不需要编码的字符：

- 字母：A-Z、a-z；
- 数字：0-9；
- 部分符号：-、_、.、~（这些符号在 URL 中无特殊含义，可直接使用）。

需要编码的字符：

- 保留字符（Reserved Characters），RFC 规范定义的保留字符包括：:、/、?、#、[、]、@、!、$、&、'、(、)、*、+、,、;、=；

- 非 ASCII 字符，所有非 ASCII 字符（如中文、 emoji 等）必须编码。编码时需先将字符转换为 UTF-8 字节序列，再将每个字节转换为%XX格式（现代 URL 默认使用 UTF-8 编码，避免乱码）；

例如：中文 “你好” 的 UTF-8 字节序列为E4 BD A0 E5 A5 BD（十六进制），因此编码后为%E4%BD%A0%E5%A5%BD。

- 空格，空格是特殊字符，通常编码为%20；在查询参数中，也可简化为+（但+仅在查询参数中有效，路径中需用%20）；

- 控制字符，不可见的控制字符（如换行符\n、制表符\t）需编码。控制字符的 ASCII 值通常为 0-31，编码时直接转换为对应十六进制。

例如：换行符（ASCII 码为 10，十六进制0A）编码为%0A。若 URL 需要传递包含换行的文本 “line1\nline2”，编码后为line1%0Aline2，对应 URL：http://example.com/log?msg=line1%0Aline2。

**解码**

解码是编码的逆过程：服务器或客户端收到 URL 后，会将%XX转换为对应的字符。例如：

- %20 → 空格；
- %26 → &；
- %E4%BD%A0 → “你”（UTF-8 解码）。

URL 编码是保证 URL 正确传输和解析的基础，核心是将 “不安全” 或 “有歧义” 的字符转换为%XX格式。实际使用中，需注意区分保留字符的使用场景、统一编码格式（UTF-8），避免因编码问题导致功能异常。

# 二、HTTP协议

### 2.1 定义

HTTP（Hypertext Transfer Protocol，超文本传输协议）是一种用于在客户端（如浏览器）和服务器之间传输超文本（如 HTML、图片、视频等）的**应用层协议**。

HTTP协议是基于 “请求 - 响应” 模式：客户端发起请求，服务器接收后返回响应，实现数据交换。其核心特点是**简单、灵活、无状态**（每次请求独立，不保留历史交互信息）。

### 2.2 发展历史

HTTP 的版本迭代反映了对性能、安全性和功能的优化：

| 版本     | 发布时间 | 核心特性                                                     |
| -------- | -------- | ------------------------------------------------------------ |
| HTTP/0.9 | 1991 年  | 仅支持 GET 方法，无状态码和请求头，响应仅为 HTML 文本。      |
| HTTP/1.0 | 1996 年  | 新增 POST、HEAD 等方法；引入状态码（如 200、404）；支持请求头 / 响应头（如Content-Type）；允许传输图片、视频等非文本数据。但每次请求需新建 TCP 连接（短连接），效率低。 |
| HTTP/1.1 | 1999 年  | 支持**长连接（Keep-Alive）**（默认开启，复用 TCP 连接）；新增 PUT、DELETE 等方法；支持管道化（Pipelining，同一连接并发发送多个请求）；引入Host头（实现虚拟主机）。成为长期主流版本。 |
| HTTP/2   | 2015 年  | 采用**二进制帧**（替代文本格式，减少解析开销）；支持**多路复用**（同一连接中并行处理多个请求，解决 1.1 管道化的 “队头阻塞” 问题）；服务器推送（Server Push，主动推送关联资源）；头部压缩（HPACK 算法）。 |
| HTTP/3   | 2022 年  | 基于**QUIC 协议**（替代 TCP，基于 UDP），彻底解决队头阻塞；更快的握手（0-RTT/1-RTT 建立连接）；原生支持多路复用；连接迁移（网络切换时保持连接）。 |

### 2.3 特点

**请求 - 响应模式**：客户端（如浏览器）向服务器发送请求，服务器处理后返回响应，一次交互结束。

**基于 TCP 连接**（HTTP/1.1 及之前）：每次请求前需通过 TCP 三次握手建立连接，请求完成后可能断开（短连接）或复用（长连接）。

**无状态**：服务器不保存客户端的历史请求信息，每次请求独立。如需维持状态（如登录状态），需通过 Cookie、Session 等机制实现。

**媒体无关**：可传输任意格式数据（如 HTML、JSON、图片），通过Content-Type头标识数据类型。

### 2.4 HTTP状态码

状态码是服务器对请求的处理结果标识，由 3 位数字组成，分为 5 类：

| 类别              | 含义                           | 常见状态码及说明                                             |
| ----------------- | ------------------------------ | ------------------------------------------------------------ |
| 1xx（信息性）     | 服务器已接收请求，需进一步处理 | - 100 Continue：服务器同意客户端继续发送请求体（常用于 POST 大文件前确认）。 |
| 2xx（成功）       | 请求被正常处理                 | - 200 OK：请求成功（如 GET 返回数据）。 - 201 Created：POST 请求成功创建资源（如新建用户）。 - 204 No Content：请求成功但无响应体（如 DELETE 删除资源）。 |
| 3xx（重定向）     | 需要客户端进一步操作以完成请求 | - 301 Moved Permanently：资源永久迁移（如域名更换，浏览器会缓存重定向）。 - 302 Found：资源临时迁移（如登录后跳转到首页）。 - 304 Not Modified：资源未修改（客户端可使用本地缓存，减少传输）。 |
| 4xx（客户端错误） | 请求存在错误，服务器无法处理   | - 400 Bad Request：请求格式错误（如参数无效）。 - 401 Unauthorized：需身份验证（如未登录访问受保护资源）。 - 403 Forbidden：服务器拒绝请求（如无权限访问）。 - 404 Not Found：资源不存在。 - 405 Method Not Allowed：请求方法不支持（如用 POST 访问仅允许 GET 的接口）。 |
| 5xx（服务器错误） | 服务器处理请求时出错           | - 500 Internal Server Error：服务器内部错误（如代码 bug）。 - 502 Bad Gateway：服务器作为网关时，上游服务器响应无效。 - 503 Service Unavailable：服务器暂时不可用（如维护中）。 |

### 2.5 HTTP报文

HTTP 报文（请求 / 响应）由**起始行、头部、空行、体部**四部分组成.

**请求报文**

请求报文用于客户端向服务器发送请求，结构如下：

```http
<请求行>  
<请求头1>: <值1>  
<请求头2>: <值2>  
...  
(空行)  
<请求体>  # 可选，如POST请求的参数  
```

详细描述：

- 请求行：包括请求方法 URL HTTP版本。

请求方法：表示请求目的

例：GET /api/user HTTP/1.1（用 HTTP/1.1 协议获取/api/user资源）

- 请求头：键值对，描述请求属性（如客户端信息、请求条件等）。常见请求头：

Host: example.com：指定服务器域名（HTTP/1.1 必需）。

User-Agent: Mozilla/5.0...：客户端类型（如浏览器版本）。

Accept: application/json：客户端可接受的响应数据类型。

Cookie: sessionid=xxx：携带客户端 Cookie（用于身份识别）。

- 请求体：仅在POST、PUT等方法中存在，用于传递数据（如表单参数、JSON 数据）。

**响应报头**

响应报头用于服务器向客户端返回结果，结构如下：

```url
<状态行>  
<响应头1>: <值1>  
<响应头2>: <值2>  
...  
(空行)  
<响应体>  # 可选，如返回的HTML、JSON数据  
```

详细描述：

- 状态行：包括HTTP版本 状态码 原因短句 。

- 响应头：描述响应属性（如数据类型、缓存策略等）。常见响应头：

Content-Type: application/json; charset=utf-8：响应体类型及编码。

Content-Length: 1024：响应体长度（字节）。

Set-Cookie: sessionid=xxx; Path=/：服务器向客户端设置 Cookie。

Cache-Control: max-age=3600：缓存控制（如资源有效期 1 小时）。

- 响应体：服务器返回的实际数据（如 HTML 页面、JSON 结果、图片二进制流等）。

![image-20250806223219614](https://oss.maolin101.com/image-20250806223219614.png-101.webp)

**常见请求头**

| 头字段          | 作用说明                                                     |
| --------------- | ------------------------------------------------------------ |
| Host            | 指定请求的服务器域名和端口，HTTP/1.1 强制要求，用于虚拟主机区分不同站点。 |
| User-Agent      | 标识客户端的类型，如浏览器、爬虫、应用程序等。               |
| Accept          | 客户端可接受的响应数据格式（MIME 类型）。                    |
| Accept-Encoding | 客户端支持的压缩算法，用于服务器压缩响应数据。               |
| Accept-Language | 客户端期望的自然语言，如中文、英文。                         |
| Authorization   | 用于身份认证，如 HTTP Basic Auth、Bearer Token。             |
| Cookie          | 客户端存储的 Cookie，服务器通过 Set-Cookie 设置后，客户端在后续请求中回传。 |
| Content-Type    | 当请求有 body 时，指定 body 的数据格式，如表单、JSON。       |
| Content-Length  | 当请求有 body 时，指定 body 的字节长度，帮助服务器判断数据是否完整。 |
| Referer         | 标识当前请求的来源页面，即从哪个页面跳转到当前请求。         |
| Cache-Control   | 客户端的缓存策略，如是否允许缓存、缓存有效期。               |
| Connection      | 控制连接是否保持，HTTP/1.1 默认 keep-alive，用于复用连接。   |
| Range           | 用于断点续传，指定请求的部分数据范围，如文件的某一段。       |

**常见响应头**

| 头字段                      | 作用说明                                                     |
| --------------------------- | ------------------------------------------------------------ |
| Server                      | 标识服务器的软件类型，如 Nginx、Apache。                     |
| Content-Type                | 指定响应 body 的数据格式（MIME 类型），客户端据此解析数据。  |
| Content-Length              | 响应 body 的字节长度，客户端用于判断数据是否完整。           |
| Content-Encoding            | 服务器对响应 body 使用的压缩算法，客户端需按此解压。         |
| Content-Language            | 响应内容的自然语言。                                         |
| Date                        | 服务器生成响应的时间，采用 GMT 格式。                        |
| Cache-Control               | 服务器指定的缓存策略，客户端应如何缓存此响应。               |
| Expires                     | 响应的过期时间（GMT 格式），与 Cache-Control 配合使用，优先级低于后者。 |
| Set-Cookie                  | 服务器向客户端设置 Cookie，客户端后续请求会通过 Cookie 头回传。 |
| Location                    | 用于重定向，配合 3xx 状态码，告知客户端新的 URL。            |
| ETag                        | 资源的唯一标识，用于缓存验证，可与 If-None-Match 请求头对比。 |
| Last-Modified               | 资源最后修改时间，用于缓存验证，可与 If-Modified-Since 请求头对比。 |
| Access-Control-Allow-Origin | 跨域资源共享（CORS）中，允许访问的源，解决跨域问题。         |
| Transfer-Encoding           | 当响应长度不确定时，指定传输编码，如 chunked 分块传输。      |
| Vary                        | 告知客户端，响应可能因某些请求头（如 Accept-Encoding）不同而变化。 |

## 三、HTTPS协议

### 3.1 定义

HTTPS（Hypertext Transfer Protocol Secure）即**超文本传输安全协议**，是在 HTTP 基础上加入**加密层**的安全传输协议。其核心作用是通过加密技术保护客户端与服务器之间的数据传输，防止数据被窃听、篡改或伪造，从而解决 HTTP 明文传输的安全隐患（如数据泄露、中间人攻击等）。

### 3.2 Secure

HTTPS 中的 “S” 代表 “Secure”，其安全性依赖于**SSL（Secure Sockets Layer，安全套接层）** 或 **TLS（Transport Layer Security，传输层安全协议）**。简单来说，HTTPS = HTTP + SSL/TLS，即通过 SSL/TLS 协议在 HTTP 传输层之上建立加密通道，所有 HTTP 数据均通过该加密通道传输。

**SSL 与 TLS 的关系**

- **SSL** 由网景公司（Netscape）于 1994 年推出，早期版本（SSL 1.0 未公开，SSL 2.0/3.0）存在安全漏洞，已被淘汰。
- **TLS** 是 IETF（互联网工程任务组）在 SSL 3.0 基础上标准化的协议，1999 年发布  TLS 1.0，后陆续更新为 TLS 1.1（2006）、TLS 1.2（2008）、TLS 1.3（2018）。目前 TLS 1.2  是主流，TLS 1.3 因性能优化（握手更快）逐渐普及，而 SSL 协议已被完全废弃（存在严重安全风险）。

通常 “SSL/TLS” 会被统称为 “SSL”，但实际现代 HTTPS 均使用 TLS 协议。

### 3.3 核心作用

HTTPS 通过 SSL/TLS 实现三大安全目标：

**机密性（Confidentiality）**：数据传输过程中被加密，即使被窃听也无法解密（防止 “窃听”）。

**完整性（Integrity）**：数据传输中若被篡改，接收方可检测到（防止 “篡改”）。

**身份认证（Authentication）**：验证服务器（或客户端）身份，确保通信对象是真实的（防止 “伪装” 或 “中间人攻击”）。

### 3.4 工作原理

HTTPS 的通信过程可分为**TLS 握手阶段**（协商加密规则、交换密钥、验证身份）和 **数据传输阶段**（加密传输 HTTP 数据）。

以常见的 “服务器认证” 场景为例（客户端认证较少见，如银行 U 盾），步骤如下：

> TLS 握手阶段（核心步骤）

- **步骤 1：客户端发起请求（Client Hello）**
  客户端向服务器发送 “客户端问候”，包含：支持的 TLS 版本（如 TLS 1.2）、支持的加密套件（如 ECDHE-RSA-AES256-GCM-SHA384，包含密钥交换算法、对称加密算法、哈希算法）、一个随机数（Client Random）。
- **步骤 2：服务器回应（Server Hello）**
  服务器从客户端支持的选项中选择：确定 TLS 版本、加密套件，生成一个随机数（Server Random），并返回服务器证书（包含服务器公钥、域名、证书颁发机构 CA 等信息）。
- **步骤 3：客户端验证证书**
  客户端验证服务器证书的合法性：
  - 检查证书是否由可信 CA 签发（操作系统 / 浏览器内置可信 CA 列表）；
  - 检查证书是否过期、域名是否与当前访问的域名一致；
  - 验证证书链（若证书是中间 CA 签发，需逐级验证至根 CA）。
    若验证失败，浏览器会提示 “证书不安全”；验证通过则提取证书中的服务器公钥。
- **步骤 4：客户端生成并发送会话密钥**
  客户端生成一个 “预主密钥（Pre-Master Secret）”，用服务器公钥加密后发送给服务器（非对称加密，仅服务器私钥可解密）。
- **步骤 5：服务器解密并生成会话密钥**
  服务器用自身私钥解密 “预主密钥”，再结合客户端和服务器之前生成的两个随机数（Client Random + Server Random），通过加密套件的算法生成**会话密钥（对称密钥）**。
- **步骤 6：确认握手完成**
  客户端和服务器分别用会话密钥加密一条 “握手完成” 消息发送给对方，若能成功解密，则说明双方已持有相同的会话密钥，TLS 握手结束。

> 数据传输阶段

握手完成后，客户端与服务器之间的所有 HTTP 数据（请求 / 响应）均通过**会话密钥进行对称加密**传输（如 AES 算法），同时通过哈希算法（如 SHA）确保数据完整性（防止篡改）。

### 3.5 加密技术

HTTPS 结合了**非对称加密**和**对称加密**，兼顾安全性与效率：

- **非对称加密**（用于握手阶段）：有公钥（公开）和私钥（保密），公钥加密的数据仅私钥可解密，反之亦然。用于传输 “预主密钥”（避免密钥在传输中泄露）。
- **对称加密**（用于数据传输阶段）：加密和解密使用同一密钥（会话密钥），效率远高于非对称加密，适合传输大量数据。

### 3.6 CA证书

证书是 HTTPS 实现 “身份认证” 的核心，由**CA（Certificate Authority，证书颁发机构）** 签发，本质是一份 “数字身份证”，包含：

- 服务器域名（如 [www.example.com](https://www.example.com)）；
- 服务器公钥；
- 证书签发机构（CA）名称；
- 证书有效期；
- CA 的数字签名（用 CA 私钥对证书内容加密，客户端可用 CA 公钥验证签名，确保证书未被篡改）。

常见 CA 包括 Let's Encrypt（免费）、DigiCert、GlobalSign 等。

### 3.7 区别

HTTPS 与 HTTP 的核心区别如下：

| 维度     | HTTP                          | HTTPS                               |
| -------- | ----------------------------- | ----------------------------------- |
| 端口     | 默认 80 端口                  | 默认 443 端口                       |
| 安全性   | 明文传输，数据易被窃听 / 篡改 | 加密传输，保障机密性 / 完整性       |
| 身份认证 | 无，无法验证服务器身份        | 依赖证书验证服务器身份              |
| 性能     | 无额外开销，速度快            | TLS 握手有额外耗时（约 1-2 个 RTT） |
| 证书     | 无需证书                      | 需 CA 签发的证书（免费 / 付费）     |
| SEO 影响 | 搜索引擎优先级低              | 搜索引擎（如 Google）优先收录       |

### 3.8 总结

HTTPS 是 HTTP 的安全升级版，其安全性由 TLS 协议（取代了早期的 SSL）保障。TLS 通过 “握手阶段协商密钥 +  数据阶段对称加密” 实现数据机密性，通过 CA 证书实现身份认证，最终解决了 HTTP  明文传输的安全问题，成为现代互联网（尤其是支付、登录等场景）的标准传输协议。