一、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 中包含以下字符，会导致解析错误或歧义：
- 非 ASCII 字符（如中文、日文、俄文等）；
- 有特殊含义的 “保留字符”（如
&、=、?）在非指定位置使用； - 控制字符（如换行符、制表符）或空格。
因此，这些字符必须通过编码转换为 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 line2。
解码
解码是编码的逆过程：服务器或客户端收到 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 报文（请求 / 响应）由起始行、头部、空行、体部四部分组成.
请求报文
请求报文用于客户端向服务器发送请求，结构如下：
<请求行>
<请求头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 数据）。
响应报头
响应报头用于服务器向客户端返回结果，结构如下：
<状态行>
<响应头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 结果、图片二进制流等）。
常见请求头
| 头字段 | 作用说明 |
|---|---|
| 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）；
- 服务器公钥；
- 证书签发机构（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 明文传输的安全问题，成为现代互联网（尤其是支付、登录等场景）的标准传输协议。