HTTP / HTTPS / TLS 与 RPC

HTTP/1.1 队头阻塞 · HTTP/2 多路复用与 HPACK · HTTP/3 QUIC · HTTPS/TLS 握手（RSA vs ECDHE 前向安全）· 证书链 · gRPC/Protobuf · REST vs RPC 选型 · 长连接与 keep-alive

加密原语（对称/非对称/哈希、AEAD、HMAC、数字签名、RSA 加密 vs 签名的钥匙方向、ECDHE 的 E 到底是什么）现在收拢在 crypto-fundamentals 作为单一事实源；本篇只保留"HTTP 协议演进 + TLS 握手骨架 + gRPC/REST 选型"三条协议层主线，需要原理细节请跳过去。

场景问题

打个比方（TLS 握手）：非对称加密好比一把"只能锁、不能开"的公开挂锁（公钥人人可取）配一把"只有我有"的钥匙（私钥）。客户端把自己生成的对称密钥锁进保险箱寄过去，只有握着私钥的服务器能打开；之后双方都拿到对称密钥，就改用又快又省的对称加密畅聊——非对称慢，全程用会卡死。类比失效边界：这套死穴是"那把公开挂锁是不是服务器本人的"——中间人可以拿自己的挂锁冒充，靠 CA 证书链担保。而 ECDHE 更进一步：每次会话临时造一把新钥匙、用完即弃，服务器私钥日后泄露也解不开旧流量（前向安全）。原语细节详见 crypto-fundamentals。

后台与网络面试高频题，本质考"协议演进解决了什么问题、代价是什么"：

实现方案

HTTP 版本演进：一部消灭队头阻塞的历史

• HTTP/1.0：一个请求一个 TCP 连接，用完即关，握手开销大
• HTTP/1.1：Connection: keep-alive 复用连接；引入管线化（pipelining）但因队头阻塞（HOL）——同一连接上响应必须按请求顺序返回，前一个慢后面全等——基本没启用。浏览器改用"每域名开 6 个并发连接"绕过
• HTTP/2：一个 TCP 连接上引入流（stream）+ 帧（frame），多个请求响应多路复用并发交织，彻底解决 HTTP 层 HOL；HPACK 头部压缩（静态表+动态表+Huffman）省掉重复的大头部；Server Push（已渐被弃用）
• HTTP/3：跑在 QUIC（基于 UDP） 上

HTTP/3 与 QUIC

QUIC 在 UDP 上自己实现可靠传输、拥塞控制、多路复用和加密：

• 消灭 TCP 队头阻塞：QUIC 的每个 stream 独立，一个流丢包只阻塞该流，其他流照常 → 传输层不再互相拖累
• 握手更快：把 TLS 1.3 握手和传输握手合并，1-RTT 建连，恢复连接可 0-RTT（TCP+TLS1.2 要 2-3 RTT）
• 连接迁移：用 Connection ID 而非四元组标识连接，手机从 WiFi 切 4G IP 变了连接不断
• 代价：UDP 常被中间设备限速/拦截；用户态实现更耗 CPU

HPACK 头部压缩与 HTTP/2 流控（深挖）

HTTP/1 每个请求都重复发一坨几乎不变的大头部（Cookie、User-Agent、Accept…），HTTP/2 用 HPACK 消掉这份冗余：

• 静态表：预定义 61 个高频头部（:method: GET、:status: 200…），命中直接用 1 字节索引替代整个头部。
• 动态表：连接级、双方各维护一份的滑动表，把本连接出现过的头部追加进去，后续请求同名同值只发一个索引；表满按 FIFO 淘汰，大小可由 SETTINGS_HEADER_TABLE_SIZE 协商。
• Huffman 编码：对没进表、必须传字面量的字符串再做静态 Huffman 压缩。
• 增量编码：请求头按"相对上一次的增量"表达，这也是为什么 HTTP/2 头部是有状态的——编解码器必须严格按帧顺序处理。

安全坑：对"密文长度随明文压缩率变化"的压缩（如 HTTP/1 时代的 SPDY/TLS 压缩）做注入可推断秘密，即 CRIME/BREACH。HPACK 通过"不跨用户输入与敏感头共表 + 可对敏感头标记 never-indexed（不进动态表）"来缓解；面试问"HTTP/2 头压缩有什么风险"答这条。

HTTP/2 流控：连接级 + 流级两级 WINDOW_UPDATE 信用窗口（类似 TCP 滑动窗口但在应用层），防止快发送方压垮慢接收方；还有流优先级/依赖树（weight + dependency）指导服务端调度先发哪个流——但实现复杂、收益有限，HTTP/3 已简化。传输层滑动窗口对比见 TCP/HTTP 滑动窗口。

HTTPS / TLS 握手

HTTPS = HTTP over TLS。核心是混合加密：用非对称加密安全地协商出对称密钥，之后用对称加密传数据（对称快得多）。

TLS 1.2 握手（简化）：

1. Client Hello：支持的密码套件、随机数
2. Server Hello + 证书 + 服务器随机数
3. 客户端验证证书链，用 ECDHE 交换参数算出 pre-master → 双方各自导出对称会话密钥
4. 双方 Finished，之后对称加密通信

密钥交换选型（RSA vs ECDHE、前向安全的实现细节、AEAD 是什么、CA 证书链如何逐级验签、CRL/OCSP/Stapling）以及 TLS 1.3 相对 1.2 的四条大改动，详见 crypto-fundamentals——本篇只保留协议层视角的握手骨架，加密原理不在此复述。

证书信任链一句话：服务器证书由中间 CA 签发、中间 CA 由根 CA 签发，客户端用内置根证书逐级验签。信任链结构与吊销机制见 crypto-fundamentals。

RPC 与 gRPC / Protobuf

RPC（远程过程调用）让调用远程服务像调本地函数：客户端 stub 把参数序列化 → 网络传输 → 服务端反序列化并执行 → 回传结果。关键组件：序列化协议 + 传输协议 + 服务发现/治理。

gRPC = HTTP/2（传输，多路复用+流式）+ Protobuf（序列化）+ IDL 定义服务：

• Protobuf：二进制编码，用字段编号（tag）而非字段名，varint 变长编码整数，比 JSON 小几倍、快几倍；.proto 是强 schema，跨语言生成代码，向后兼容靠"字段编号不复用、新字段设可选"
• 支持 4 种模式：一元、服务端流、客户端流、双向流（靠 HTTP/2 stream）

REST vs RPC 选型

一句话：对外/浏览器/调试友好 → REST；内部服务间高性能、强契约、流式 → gRPC。

为什么这么做

• 为什么 HTTP/2 用单连接多路复用：多连接（HTTP/1.1 绕法）浪费握手和拥塞窗口、服务端连接数爆炸。单连接多路复用省资源、共享拥塞控制、头部压缩收益大——代价是把队头阻塞下压到 TCP 层，于是有了 HTTP/3。
• 为什么 HTTPS 混合加密：非对称加密（RSA/ECC）能在不安全信道安全协商密钥，但慢；对称加密（AES）快但要先有共享密钥。混合方案取两者之长：非对称只用于握手协商一次，海量数据走对称。
• 为什么 Protobuf 用字段编号而非字段名：编号比字段名短（省字节），且"编号不变、名字可改"让协议演进更稳；新增字段用新编号且设为可选，老客户端忽略未知编号 → 天然向前/向后兼容。

为什么别的选择不行

• 为什么不干脆全上 HTTP/3：UDP 常被防火墙/NAT/运营商限速或封锁，落地需回退到 HTTP/2；用户态实现 CPU 开销更高。它是对高丢包移动网络的优化，不是无条件更优，需并存降级。
• 为什么不继续用 RSA 密钥交换：无前向安全，一次私钥泄露 = 所有历史流量裸奔。ECDHE 用临时密钥把"历史流量安全"和"长期私钥"解耦，这是现代 TLS 的底线，TLS 1.3 直接移除了 RSA 交换。
• 为什么内部服务不用 REST/JSON 图省事：JSON 文本编码体积大、解析慢、无强 schema（字段拼错运行时才炸）。高频内部调用累积起来，gRPC 的二进制 + 多路复用 + 编译期契约收益显著。对外 API 才更看重 JSON 的通用与可读。

沉淀结论

面试速答清单：

• HTTP 演进主线 = 消灭队头阻塞：1.1 连接级串行 → 2 应用层多路复用（TCP 层仍 HOL）→ 3 QUIC(UDP) 传输层消灭 HOL
• HTTP/2：流+帧多路复用、HPACK 头压缩；但单 TCP 连接丢包阻塞所有流
• HTTP/3/QUIC：流独立(丢包不互相阻塞)、1-RTT 建连、0-RTT 恢复、连接迁移；代价是 UDP 被限 + CPU 高
• HTTPS 混合加密：非对称握手协商对称密钥，数据走对称；ECDHE 提供前向安全，RSA 交换不安全
• TLS 1.3：1-RTT 握手、只留前向安全+AEAD 套件；证书靠 CA 签名 + 内置根证书验签
• gRPC = HTTP/2 + Protobuf(二进制/字段编号/强 schema/向后兼容) + 双向流
• 选型：对外/浏览器/可读 → REST；内部高频/强契约/流式 → gRPC

记忆口诀

• HTTP 演进：1.1 连接级串行 / 2 应用层多路复用 / 3 QUIC 传输层灭 HOL
• HTTP/2 vs 3：单 TCP 丢包阻塞全流 / QUIC 流独立 + 1-RTT + 连接迁移
• HTTPS 握手：非对称协商 / 对称传输 / ECDHE 前向安全（RSA 交换不安全）
• gRPC：HTTP/2 多路复用 / Protobuf 二进制强 schema / 双向流

内容来源

关键点整理自 RFC 7540（HTTP/2）、RFC 9000/9114（QUIC/HTTP3）、RFC 8446（TLS 1.3）、gRPC 官方文档、Protocol Buffers 文档 与《High Performance Browser Networking》（Ilya Grigorik）重写为五段式。传输层与流控细节可参见本站 TCP/HTTP 滑动窗口。请以各 RFC 与官方文档为准。

自测：合上资料能说清楚吗？

1. HTTP/2 号称"解决了队头阻塞"，为什么在丢包网络下反而可能不如 HTTP/1.1？

2. HTTPS 既然要加密，为什么不全程用非对称加密，而要"非对称 + 对称"混合？

3. 什么是前向安全（PFS）？对比 RSA 密钥交换与 ECDHE，谁能提供、靠什么实现？

4. gRPC 比 REST/JSON 快在哪几处？为什么内部微服务偏爱它？

5. HTTP/3 用 UDP，既然更快为什么不无条件全上？