证书压缩是什么
证书压缩（RFC 8879）在握手过程中对证书链做无损压缩，减少大证书链带来的握手字节数与延迟。客户端在 ClientHello 里用 compress_certificate 扩展声明自己支持的压缩算法及优先级，服务端从交集里选一个，把 Certificate 消息压缩后发送；两侧没有共同算法时不启用，握手照常进行。收益主要出现在证书链较大、跨地域链路延迟高或移动网络首包敏感的场景。
基本信息
| 标准 | RFC 8879 |
|---|---|
| 协商方式 | 客户端 compress_certificate 扩展列出算法偏好，服务端择一 |
| 算法编号 | zlib(1)、brotli(2)、zstd(3)，见 IANA TLS Certificate Compression 注册表 |
| 生效条件 | 客户端与服务端同时支持同一算法 |
| 收益场景 | 大证书链、跨地域握手、移动网络首连 |
| 额外开销 | 压缩解压消耗 CPU，高并发时需评估占比 |
典型使用场景
- 移动端首连优化：证书链大的站点在弱网下握手字节数是首屏延迟的重要构成。
- 多域名网关：一台网关承载大量证书时，压缩能显著降低握手流量。
- 跨境访问：延迟高、丢包多的链路上，减少往返字节比压缩静态资源见效更直接。
- CDN 能力核对：确认边缘节点是否已与客户端协商启用证书压缩。
- 成本评估：在带宽账单与 CPU 占用之间做实测权衡，而不是默认全开。
确认是否协商成功
确认是否协商成功
openssl s_client -connect example.com:443 -servername example.com -msg </dev/null 2>&1 | grep -i 'compress_certificate' | head -3
# 对比启用前后的握手字节数（可用 tcpdump 抓包后按字节统计）
# tshark -r handshake.pcap -Y 'tls.handshake.type == 11' -T fields -e frame.len | awk '{s+=$1} END {print s}'
# 服务端侧看实现支持的算法与优先级配置算法与收益对照
| 编码 | 编号 | 特点 |
|---|---|---|
| zlib | 1 | 兼容性最好，压缩率一般 |
| brotli | 2 | 压缩率较好，编解码开销中等 |
| zstd | 3 | 压缩率与速度均衡，较新实现支持 |
| 不压缩 | 不协商 | 两侧无交集时的默认行为 |
小证书链的收益有限，评估时以实际握手字节数与首字节时间变化为准；只看扩展是否出现，并不能说明压缩真的省了流量。