2026/8/23大约 4 分钟
🔒 HTTP/HTTPS 协议详解
面试高频指数：⭐⭐⭐⭐⭐ 网络协议是面试必考，从 TCP 到 HTTPS 到 HTTP/3 一条线讲透。
1. TCP 三次握手与四次挥手
1.1 三次握手（建立连接）
客户端 服务端
│ SYN=1, seq=x │
│ ─────────────────────────► │
│ │
│ SYN=1, ACK=1, seq=y, ack=x+1
│ ◄───────────────────────── │
│ │
│ ACK=1, seq=x+1, ack=y+1 │
│ ─────────────────────────► │
│ │
│ 连接建立完成 │为什么三次？——确认双方收发能力：
| 次数 | 确认内容 |
|---|---|
| 第 1 次 | 客户端确认"服务端在收" |
| 第 2 次 | 服务端确认"客户端能发能收" |
| 第 3 次 | 客户端确认"服务端能发能收" |
两次不够（客户端可能收不到服务端的 SYN+ACK），四次多余（第三次同时确认双方）。
1.2 四次挥手（断开连接）
客户端 服务端
│ FIN=1, seq=u │
│ ─────────────────────────► │ 客户端不再发送
│ │
│ ACK=1, ack=u+1 │
│ ◄───────────────────────── │ 服务端确认
│ │
│ FIN=1, seq=w │
│ ◄───────────────────────── │ 服务端不再发送
│ │
│ ACK=1, ack=w+1 │
│ ─────────────────────────► │ 客户端确认（TIME_WAIT）为什么四次？——TCP 全双工：发送和接收独立，两端各自关闭。
2. HTTP 报文结构
2.1 请求报文
POST /api/login HTTP/1.1 ← 请求行（方法 URL 版本）
Host: api.example.com ← 请求头
Content-Type: application/json
Authorization: Bearer token
{"username":"tom","password":"***"} ← 请求体2.2 响应报文
HTTP/1.1 200 OK ← 状态行
Content-Type: application/json ← 响应头
Cache-Control: max-age=3600
{"code":0,"data":{"token":"xxx"}} ← 响应体2.3 常见状态码
| 状态码 | 含义 | 典型场景 |
|---|---|---|
| 200 | 成功 | 查询成功 |
| 201 | 已创建 | 创建资源 |
| 301 | 永久重定向 | 域名更换 |
| 302 | 临时重定向 | 登录跳转 |
| 304 | 未修改（缓存） | 协商缓存 |
| 400 | 请求错误 | 参数错误 |
| 401 | 未认证 | Token 失效 |
| 403 | 禁止访问 | 无权限 |
| 404 | 不存在 | 资源缺失 |
| 429 | 请求过多 | 限流 |
| 500 | 服务器错误 | 服务端异常 |
| 502/503 | 网关/服务不可用 | 服务挂了 |
3. HTTPS：HTTP + TLS
3.1 为什么需要 HTTPS
HTTP 明文传输：可被窃听（抓包）、篡改（中间人）、冒充（伪造服务器）。
3.2 TLS 握手流程
客户端 服务器
│ ① ClientHello（支持的加密套件） │
│ ───────────────────────────────► │
│ │
│ ② ServerHello + 证书（公钥） │
│ ◄─────────────────────────────── │
│ │
│ ③ 校验证书（CA 链） │
│ 生成随机 pre-master 密钥 │
│ ④ 用服务器公钥加密发送 │
│ ───────────────────────────────► │
│ │
│ ⑤ 用私钥解密得到 pre-master │
│ 双方各自推导会话密钥 │
│ ⑥ Finished（对称加密通信开始） │
│ ◄─────────────────────────────── │
│ │
│ 之后用对称密钥加密传输 │关键点：
- 非对称加密（RSA/ECDHE）只用于握手阶段交换密钥。
- 实际数据传输用对称加密（AES），性能高。
- 证书：CA 签名的服务器公钥，客户端校验证书链防止冒充。
3.3 Android 中的 HTTPS
// OkHttp 默认信任系统 CA，证书无效直接报错
val client = OkHttpClient.Builder()
.sslSocketFactory(...) // 自定义证书（自签名需谨慎）
.build()
// 注意：不要用信任所有证书的配置（安全隐患）4. HTTP/1.1 vs HTTP/2 vs HTTP/3
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP（TLS 内置） | UDP（QUIC） |
| 多路复用 | ❌ 队头阻塞 | ✅ 单连接多请求 | ✅ 多路复用 |
| 头部压缩 | ❌ | ✅ HPACK | ✅ QPACK |
| 连接建立 | 慢（多次握手） | 快（TLS 合并） | 更快（0-RTT） |
| 队头阻塞 | 有（应用层） | 有（TCP 层） | 无（UDP 层解决） |
4.1 HTTP/2 核心特性
- 二进制分帧：HTTP/1.1 文本 → HTTP/2 二进制帧。
- 多路复用：一个 TCP 连接并发多个请求（解决队头阻塞的请求级问题）。
- 头部压缩：HPACK 静态表+动态表，减少冗余头。
- 服务端推送：服务端可主动推送资源（实际用得少）。
4.2 HTTP/3（QUIC）
- 基于 UDP，自定义可靠传输（QUIC），彻底解决 TCP 队头阻塞。
- 0-RTT 连接建立（首包即可带数据）。
- 连接迁移（网络切换不断连）。
5. 高频面试题
Q1：为什么 TCP 要三次握手？ A：确认双方收发能力。两次无法确认客户端能收到服务端的报文；三次是确保双方 "能发能收"的最少次数，防止失效连接请求导致资源浪费。
Q2：HTTPS 的加密过程？ A：握手阶段用非对称加密（证书公钥）安全交换对称密钥，之后全部用对称加密传输。 证书由 CA 签发，客户端校验证书链保证服务器身份可信。
Q3：HTTP/2 解决了 HTTP/1.1 的什么问题？ A：① 队头阻塞（多路复用解决请求级阻塞）；② 头部冗余（HPACK 压缩）； ③ 连接数过多（单连接多请求）。
Q4：HTTPS 一定安全吗？ A：HTTPS 保证"传输过程"加密与身份可信，但不保证：① 证书被攻击者安装到本机 （信任链被破坏）；② 客户端明文存储密钥；③ 服务端数据泄露。抓包工具（如 Charles） 就是通过安装根证书实现"合法中间人"。
Q5：为什么 HTTP/3 用 UDP 而不是 TCP？ A：TCP 的可靠机制（按序、重传）导致队头阻塞：一个包丢失阻塞后续所有包。 QUIC 在 UDP 上自实现可靠传输 + 多路复用 + 加密 + 连接迁移，包丢失只影响单个流。
6. 小结
- TCP：三次握手确认能力，四次挥手关闭双通道。
- HTTPS：非对称交换密钥 + 对称加密传输 + CA 证书防冒充。
- HTTP/2：多路复用 + 头部压缩；HTTP/3：QUIC 彻底去队头阻塞。
- 面试答题：讲清"为什么"比背结论更重要。