2、HTTP/HTTPS 协议原理与性能差异归纳总结
说到网络开销，咱们首先得把 HTTP 和 HTTPS 这哥俩儿搞清楚。很多 SDK 开发者觉得 HTTPS 就是加了个锁，慢一点正常。但究竟慢多少？为什么慢？有没有办法优化？这些才是关键。我早年做过一个数据上报 SDK，就因为没处理好 HTTPS 的握手开销，被用户吐槽“一开流量就掉电”。嗯，今天咱们就来掰扯清楚。
2.1 HTTP 协议：无状态、明文、轻快
HTTP（HyperText Transfer Protocol）说白了就是客户端和服务端之间交换文本的约定。它的核心特点：
- 无状态：每次请求独立，服务器不记着你是谁。所以后来才有了 Cookie 和 Session。
- 明文传输：整个请求和响应在网络上裸奔。我抓包看过，真的什么都能看到——你发的密码、，全裸。
- 请求-响应模型：客户端发一个请求，服务器回一个响应。一个往返完成。
- 连接复用：HTTP/1.1 默认开启 Keep-Alive，多个请求共用一条 TCP 连接。HTTP/2 更进一步，多路复用。
💡 实用技巧：在弱网环境下，HTTP 的请求体可以做得非常小。省掉加密头部，对一些低频次的埋点上报很有用——前提是不涉及用户隐私。
2.2 HTTPS 协议：安全第一，代价是什么？
HTTPS = HTTP + TLS/SSL。它在 HTTP 下面加了一层安全隧道。我印象最深的是 HTTPS 的握手流程：
- TCP 三次握手（1.5 RTT）
- TLS 协商（至少 2 次 RTT，TLS 1.3 优化到 1 次）
- 证书验证（客户端要下载和解析证书链，可能涉及 DNS 查询）
- 生成会话密钥（非对称加密交换对称密钥）
- 之后才是真正的 HTTP 请求
你想想看，一个普通 HTTP 请求，如果复用连接，可能只需几百微秒。而 HTTPS 第一次连接，光握手就要消耗 2～3 个 RTT。在移动端高延迟网络下，这差别会被放大。
❗ 核心差异：首包时间
HTTP 首包 = TCP 握手后直接发请求数据。
HTTPS 首包 = TCP 握手 + TLS 握手 + 加密请求数据。多出来的就是安全代价。
HTTP 首包 = TCP 握手后直接发请求数据。
HTTPS 首包 = TCP 握手 + TLS 握手 + 加密请求数据。多出来的就是安全代价。
2.3 性能差异对比表
下面这个表是我做 SDK 压测时经常参考的，你可以直接拿来用：
| 对比维度 | HTTP | HTTPS |
|---|---|---|
| 连接建立时间（首次） | 1 个 RTT（TCP 握手） | 2～3 个 RTT（TCP + TLS 1.2） |
| 连接建立时间（复用） | 几乎为 0 | 会话复用可降到 1 RTT |
| 数据传输开销 | 无加密，原始数据 | 对称加密额外 5%～15% CPU + 少量尾部填充 |
| 头部大小 | 明文头部，极易压缩 | 加密后头部不可压缩，但 TLS 记录头约 20 字节 |
| 代理缓存能力 | 中间代理可直接缓存 | 中间代理不能解密，无法缓存（除非配置信任代理） |
| 安全性 | 无 | 加密、防篡改、身份验证 |
⚠️ 我曾经踩过的坑：有一次为了省流量，我把所有 API 都切成了 HTTP，然后用户密码直接明文被截获了……千万别在涉及登录、支付、用户隐私的任何场景下用 HTTP。节省的几百毫秒流量，远远抵不上一次安全事件。
2.4 流量与性能优化关键点
对于 SDK 开发者来说，我们关心的不是非黑即白的选择，而是 在必要的地方用 HTTPS，在非敏感的地方用短效 HTTP + 签名的组合。不过现在行业趋势是全链路 HTTPS，所以重点还是怎么让 HTTPS 不那么慢。
- 使用 TLS 1.3：握手从 2 RTT 降到 1 RTT，而且 0-RTT 模式可以发送早期数据。我在一个实时语音 SDK 里测过，TLS 1.3 比 1.2 快约 30%。
- 会话复用（Session Resumption）：客户端和服务端缓存上一次的会话票据，下次直接恢复。我们做推送长连接时，这个技巧帮了大忙。
- 加密算法选择：别选 AES-256 这种重算法，AES-128-GCM 在移动端硬件加速下性能更好。对了，ChaCha20-Poly1305 在弱 CPU 设备上更快。
- 压缩与合并：HTTPS 虽然不能按中间代理压缩，但可以在客户端做 Brotli 压缩再喂给 TLS 层。我们优化过一个 Banner 图片请求，体积小了 40%。
- 连接预建：在 App 启动时预先创建 HTTPS 连接（连接池预热），等真正发请求时握好手。我习惯用一个后台线程提前做 DNS 和 TLS 握手。
🔧 实用工具：用
curl --tlsv1.3 --cert-status 可以测试 TLS 1.3 的握手耗时；用 Wireshark 抓包看 Client Hello 和 Server Hello 的时间差，就是实际的握手 RTT。
2.5 两者的核心流程对比图
下面这张图帮你一目了然地看清 HTTP 与 HTTPS 在请求生命周期上的差异。
2.6 总结与个人建议
我个人习惯把 HTTP 和 HTTPS 的差异总结成一句话：HTTP 快在连接建立，HTTPS 快在安全合规不可替代。对于 SDK 开发者来说，不建议为了节省流量全面抛弃 HTTPS。更好的做法是：
- 对非敏感数据（如公共配置、地区列表）用 HTTP + 短有效期的签名（比如 5 分钟过期）。
- 对用户数据、隐私、支付类请求，必用 HTTPS，且开启证书固定（Certificate Pinning）。
- 在客户端做连接池和 TLS 会话复用，实测可以减少 40%～60% 的握手总耗时。
🚀 行动清单
1. 把 TLS 版本升到 1.3（服务端和客户端双方支持才能生效）。
2. 开启会话复用，并设置合理的超时时间（我通常设 4 小时）。
3. 选择轻量级加密套件，比如 TLS_AES_128_GCM_SHA256。
4. 对非频繁的请求（如每天一次），可以用 HTTP 代替，但要做好安全兜底。
1. 把 TLS 版本升到 1.3（服务端和客户端双方支持才能生效）。
2. 开启会话复用，并设置合理的超时时间（我通常设 4 小时）。
3. 选择轻量级加密套件，比如 TLS_AES_128_GCM_SHA256。
4. 对非频繁的请求（如每天一次），可以用 HTTP 代替，但要做好安全兜底。