Web on 吾爱主机

TLS 1.3 握手与证书链校验：原理、流程与工程排查

Sat, 25 Jul 2026 00:00:00 +0800

线上偶发 “证书不受信任”“握手失败”“只能 HTTP 能开、HTTPS 间歇 525”，根因往往不在业务代码，而在 TLS 握手协商 与 X.509 证书路径校验。浏览器地址栏的小锁背后，是一次版本/密码套件协商、密钥交换、身份证明和密钥确认；服务端 PEM 链顺序错一环，客户端就会在完全不同的报错路径上失败。

本文基于 RFC 8446（TLS 1.3）、RFC 5280（PKIX 证书与路径校验），并对照 MDN 的 TLS/HTTPS 说明、OpenSSL s_client 与 Nginx ngx_http_ssl_module 官方文档，把机制、可复现排查命令与工程配置落到同一条链路上。

问题背景：TLS 到底在保护什么

MDN 对 Transport Layer Security（TLS）的定位很直接：让客户端在不可信网络上与服务器 安全通信。在 Web 上，用 TLS 保护 HTTP 的结果就是 HTTPS。TLS 从三方面加固连接：

目标	含义
机密性（Encryption）	传输中数据被加密，窃听者难以直接读内容
完整性（Integrity）	中间人无法在不被发现的情况下篡改数据
身份认证（Authentication）	一端能向另一端证明“我是谁”

在公开 Web 上，服务端向客户端认证 是常态；客户端向服务端出示证书 相对少见（多见于 mTLS / 专用 API）。HTTPS 也是对抗 中间人（MITM） 的关键防线：攻击者插在浏览器与站点之间时，若无法通过证书路径与握手完整性校验，就难以“静默”读写业务流量。

因此工程排错要分清两层：

握手层：版本、密码套件、密钥交换、Finished 校验是否完成。
信任层：证书链能否锚定到本地信任锚、名字是否匹配、是否在有效期内、是否被吊销策略拒绝。

核心原理：TLS 1.3 握手的三个阶段

RFC 8446 说明：安全通道的密码参数由 握手协议 产生。握手用于协商协议版本、选择密码算法、可选地互相认证，并建立共享密钥材料；完成后双方用该密钥保护应用层流量。握手失败或其它协议错误会终止连接（可选先发 alert）。

TLS 1.3 支持三种基本密钥交换模式：

(EC)DHE（有限域或椭圆曲线上的 Diffie-Hellman）
仅 PSK
PSK 与 (EC)DHE 组合

完整握手消息流（1-RTT）

规范 Figure 1 给出了基本完整握手（* 表示可选/场景相关；{} 表示用握手流量密钥保护；[] 表示用应用流量密钥保护）：

Client Server

Key ^ ClientHello
Exch | + key_share*
 | + signature_algorithms*
 | + psk_key_exchange_modes*
 v + pre_shared_key* -------->
 ServerHello ^ Key
 + key_share* | Exch
 + pre_shared_key* v
 {EncryptedExtensions} ^ Server
 {CertificateRequest*} v Params
 {Certificate*} ^
 {CertificateVerify*} | Auth
 {Finished} v
 <-------- [Application Data*]
 ^ {Certificate*}
Auth | {CertificateVerify*}
 v {Finished} -------->
 [Application Data] <-------> [Application Data]

可按三个阶段理解：

Key Exchange（密钥交换）
客户端发送 ClientHello（含随机数、可接受版本、对称密码/HKDF 哈希对列表，以及 key_share / pre_shared_key 等扩展）。服务端回 ServerHello 选定连接参数；若用 (EC)DHE，服务端 key_share 必须落在客户端给出的某一组上。ClientHello 与 ServerHello 共同决定共享密钥。此阶段之后的消息均加密。
Server Parameters（服务端参数）
- EncryptedExtensions：对那些不决定密码参数、也不绑定单张证书的 ClientHello 扩展作应答。
- CertificateRequest：若需要基于证书的客户端认证则出现；否则省略。
Authentication（认证）
证书类认证使用同一套消息：Certificate、CertificateVerify、Finished（PSK 认证则作为密钥交换的副作用发生）。
- Certificate：端点证书及链上支撑证书。约定使用证书认证时服务端必须发送；客户端仅当收到 CertificateRequest 时发送。
- CertificateVerify：证明持有与证书对应的私钥，并对握手到该点的完整性提供签名保护；服务器基于证书认证时必须发送，且紧挨在 Certificate 之后、Finished 之前。
- Finished：认证块的最后一条消息，用派生自 Base Key 的 MAC 对握手 transcript 做确认；收方必须校验，错误则 decrypt_error 终止。

双方都发送并成功校验对端 Finished 后，才可在连接上收发应用数据（0-RTT 与服务端首飞后抢发等例外见规范；后者在完成握手前无法确认对端身份与活性）。

相对 TLS 1.2 的关键变化（工程相关）

RFC 8446 §1.2 列出若干重大差异，与排障直接相关的包括：

变化	工程含义
对称算法只保留 AEAD	旧 CBC/非 AEAD 套件不再进入 1.3 协商
去掉静态 RSA / 静态 DH 套件	基于公钥的密钥交换提供前向保密（forward secrecy）
ServerHello 之后握手消息加密	证书等不再明文暴露在握手中后期
密钥派生改用 HKDF	密钥分离与分析模型更清晰
版本协商改为扩展中的版本列表	兼容历史上错误实现版本协商的服务端
会话恢复 / 旧 PSK 套件统一为新 PSK 交换	恢复与 0-RTT 都围绕 PSK 建模
可选 0-RTT early data	省一轮 RTT，但牺牲部分安全属性

0-RTT：快，但默认不适合“写操作”

当客户端与服务端已共享 PSK（外部配置或先前握手得到）时，客户端可在首飞发送 early data。规范强调：0-RTT 在连接建立时节省往返，代价是某些安全属性。Nginx 文档进一步写明：early data 内的请求 可能遭受重放（replay）；应用层可用 $ssl_early_data 识别，例如：

proxy_set_header Early-Data $ssl_early_data;

工程默认建议：

保持 ssl_early_data off;（Nginx 默认即为 off），除非上层明确幂等且能处理重放。
切勿把“首次提交订单/支付/改密”暴露给 0-RTT 路径。

证书链校验：从信任锚走到叶子

握手里的 Certificate 消息只是把 证书序列 交给对端；真正“信不信”取决于客户端的 认证路径校验。

RFC 5280 §6 指出：Internet PKI 的路径处理验证 主体可分辨名和/或主体备用名（SAN） 与主体公钥之间的绑定；该绑定还受路径上证书约束与依赖方输入限制。基本路径校验中：

有效路径从信任锚（trust anchor）签发的证书开始。
信任锚选择是策略问题（层级 PKI 顶端 CA、组织自建根、系统信任库中的根等），但路径校验过程本身与“选了哪颗根”无关。
校验相对于 当前日期时间（实现也可支持对过去某时刻的验证，但不能对有效期之外的时间做校验）。
客户端 必须拒绝 含有不支持 critical 扩展的证书。

叶子身份：SAN 才是名字的主战场

subjectAltName（SAN）把身份绑定到证书主体：可含邮箱、DNS 名、IP、URI 等。规范要求：只要要把这类身份绑进证书，就必须使用 SAN（或 issuer 对应扩展）；DNS 名也可额外用 subject 的 domainComponent 表示，但现代浏览器与库几乎都以 SAN DNS 做主机名匹配。

线上“证书有效但浏览器仍报警”的常见原因：

证书只写在 CN、未正确填 SAN。
SAN 有 example.com 却没有 www.example.com（或反过来）。
多站点共用 IP，TLS 客户端未发 SNI，服务端回了默认虚拟主机证书。

CA 与路径长度：basicConstraints

basicConstraints 标明主体是否为 CA，以及可包含该证书的路径最大深度。若 v3 证书无此扩展，或存在但 cA 未断言，则该公钥不得用于验证证书签名——这也是“把服务器叶子证书误当成中间 CA 拼进链”会立刻失败的原因之一。

服务端交付的链 vs 客户端验证出的链

OpenSSL s_client -showcerts 显示的是 服务端发送的证书列表（发送顺序），文档明确：它不是已验证链。测试工具默认在证书校验错误后仍可能继续握手；生产客户端不应如此。需要“校验失败就中止”时使用 -verify_return_error。

实践：用 OpenSSL 复现握手与链问题

1）看协议版本、套件与服务端发送的证书

# 强制 TLS 1.3，展示服务端 certificate_list，SNI 指定主机名
openssl s_client -connect example.com:443 \
 -servername example.com \
 -tls1_3 \
 -showcerts </dev/null

关注输出中的：

Protocol / Cipher（是否真是 TLSv1.3 与 AEAD 套件）
Certificate chain 段：叶子是否在前、中间证书是否齐全
Verify return code（在默认“测试继续”模式下仍会打印校验结果）

OpenSSL 说明：若未提供 -servername，会尽量用 -connect 里的 DNS 名填充 SNI；从 1.1.1 起默认行为如此。排查“默认证书错了”时，刻意省略 SNI 与 显式指定 SNI 对比往往立刻见分晓：

# 对比：不发 SNI（排查默认 vhost 证书）
openssl s_client -connect 203.0.113.10:443 -noservername -showcerts </dev/null

2）让校验错误真正失败（贴近生产客户端）

openssl s_client -connect example.com:443 \
 -servername example.com \
 -verify_return_error \
 -CAfile /etc/ssl/certs/ca-certificates.crt </dev/null

-verify_return_error 会在服务端证书校验失败时返回错误并通常中止握手，而不是“打印 warning 仍连上”。

3）从 PEM 文件本地拆解链

# 分拆 fullchain.pem 中的每张证书主题/颁发者/SAN/有效期
openssl crl2pkcs7 -nocrl -certfile /etc/nginx/ssl/fullchain.pem \
 | openssl pkcs7 -print_certs -noout -text \
 | egrep 'Subject:|Issuer:|DNS:|Not Before|Not After|CA:'

核对顺序：叶子 → 中间 →（一般不要把公共根塞进服务端发送链，根应由客户端信任库提供）。

4）Nginx 侧：链顺序与协议底线

官方 ssl_certificate：同一 PEM 内先主证书（叶子），再中间证书；密钥用 ssl_certificate_key。
ssl_protocols 默认已是 TLSv1.2 TLSv1.3——新站点通常不必再打开 TLS 1.0/1.1。

server {
 listen 443 ssl http2;
 server_name api.example.com;

 # 叶子在前，中间在后（官方顺序）
 ssl_certificate /etc/nginx/ssl/api.fullchain.pem;
 ssl_certificate_key /etc/nginx/ssl/api.key;

 # 与当前默认一致；显式写出便于审计
 ssl_protocols TLSv1.2 TLSv1.3;
 # TLS 1.3 套件由库侧管理；此指令主要影响 ≤1.2
 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers off;

 # 多 worker 共享会话参数，降低重复握手成本
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 1d;

 # OCSP stapling：需让 Nginx 知道签发者证书
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate /etc/nginx/ssl/api.chain-only.pem;
 resolver 1.1.1.1 8.8.8.8 valid=300s;

 # 默认关闭 0-RTT；开启前先确认业务幂等
 ssl_early_data off;

 # 仅在 mTLS 场景打开
 # ssl_verify_client on;
 # ssl_client_certificate /etc/nginx/ssl/client-ca.pem;
 # ssl_verify_depth 2;
}

说明（均来自 Nginx 官方指令文档）：

ssl_session_cache 默认 none；生产建议 shared:... 并配合合适超时。
ssl_stapling 默认 off；开启时签发者证书须可知（可在 fullchain 或 ssl_trusted_certificate 中提供）。
ssl_verify_client 默认 off；ssl_verify_depth 默认 1。
ssl_early_data 默认 off；开启后请求可能被重放。

常见坑与排查清单

现象	更可能的原因	建议动作
浏览器报 NET::ERR_CERT_COMMON_NAME_INVALID	SAN 不匹配访问主机名	`openssl x509 -in leaf.pem -noout -ext subjectAltName`
手机信任、某台服务器不信任	服务端少发中间证书 / 系统信任库过旧	`-showcerts` 数链长；补全 intermediate
同 IP 多站，偶发证书串站	SNI 未传到正确 vhost	对比 `-servername` 有无
仅部分客户端握手失败	仍协商到 TLS 1.0/1.1 或过旧套件	收紧 `ssl_protocols`；抓包看 ClientHello
`s_client` 显示 Verify error 但仍连上	工具默认不因校验失败中止	加 `-verify_return_error`
开启 early data 后偶发重复写	0-RTT 可重放	关闭 early data，或业务读 `$ssl_early_data` 拒绝非幂等
stapling 无效 / 日志 OCSP error	缺签发者证书或 resolver	配 `ssl_trusted_certificate` + `resolver`
mTLS 客户端被拒	深度/信任锚/optional 语义不符	查 `ssl_verify_client` / `ssl_verify_depth` / 客户端链

补充运维习惯：

证书轮换演练：新 fullchain 应用后，立刻用外网 VPS 跑一遍 s_client -verify_return_error，不要只在本机 curl -k。
HTTP→HTTPS：MDN 建议对明文入口 301 到 HTTPS，并配合 HSTS（Strict-Transport-Security）降低 SSL stripping 窗口；同时杜绝 mixed content（HTTPS 页加载 HTTP 子资源）。
密钥权限与进程身份：私钥仅 Nginx worker 可读；配置重载失败时注意旧进程仍握旧 fd。

总结

TLS 1.3 握手可粗分为 密钥交换 → 服务端参数 → 认证；ServerHello 之后的握手消息受握手流量密钥保护，CertificateVerify 证明私钥持有，Finished 做握手完整性确认。
1.3 强制 AEAD、去掉静态 RSA 密钥交换、引入统一 PSK/0-RTT 模型——配置与排障要以 前向保密 + 加密握手 + 谨慎 early data 为默认心智。
证书信任是 从信任锚出发的路径校验（RFC 5280），不是“PEM 里有几段文字”；SAN、basicConstraints、中间证书顺序与 SNI 是线上最高频的失败点。
用 openssl s_client 区分“服务端发送了什么”和“客户端验证是否通过”，用 Nginx 官方顺序拼 fullchain，并按业务风险决定是否打开会话缓存、stapling 与 0-RTT。

把“能连上”升级为“能证明连对了人、用对了算法、链完整且可复现验证”，HTTPS 才真正从开关变成可运维的安全能力。

参考资料

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3（.txt：https://www.rfc-editor.org/rfc/rfc8446.txt）
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile（.txt：https://www.rfc-editor.org/rfc/rfc5280.txt）
MDN: Transport Layer Security (TLS)
MDN: HTTPS
OpenSSL: openssl-s_client
Nginx: Module ngx_http_ssl_module

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

Wed, 15 Jul 2026 00:00:00 +0800

很多系统的“慢”并不在业务逻辑，而在重复传输不变的响应体。浏览器、CDN、反向代理都可能持有一份旧副本；真正关键的是：这份副本还能不能直接用？如果不能直接用，能否只问服务器“变了没有”？

HTTP 把这件事拆成两层：

新鲜度（freshness）：缓存还在不在有效期内，决定要不要立刻回源；
验证（validation）：过期或必须再确认时，用条件请求做协商，成功则返回 304 Not Modified，避免再次传输实体。

本文基于 HTTP 语义规范（RFC 9110）与 HTTP 缓存规范（RFC 9111），结合 Nginx 能力，讲清楚 Cache-Control、ETag / Last-Modified、If-None-Match / If-Modified-Since 的协作关系，以及可落地的配置与排错方法。

一、先分清：存下来 ≠ 可以直接用

RFC 9111 把缓存决策大致分成：

阶段	问题	关键概念
存储（store）	响应能不能进缓存	方法、状态码、`no-store`、`private`、`Authorization` 等
新鲜度（fresh）	已存副本是否仍 fresh	`max-age` / `s-maxage` / `Expires` / Age
验证（validate）	stale 后能否复用	条件请求 + 校验器（validator）
复用（reuse）	最终回什么	200 全量、304 无 body、或回源新响应

常见误解：

no-cache 不是“禁止缓存”。它表示：可以用存储副本，但必须先成功验证后才能拿去满足其他请求。
no-store 才是“不要存”。缓存不得存储该请求/响应的任何部分，也不能拿它去满足别的请求。
private 不是“浏览器也不能缓存”。它限制的是共享缓存（CDN、公司代理）：响应面向单个用户；私有缓存（浏览器）仍可在规则允许下存储。

把语义说清楚，后面的工程配置才不会互相打架。

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

指令	含义（工程视角）
`max-age=N`	响应在 age > N 秒后视为 stale
`s-maxage=N`	只对共享缓存覆盖 `max-age`/`Expires`；并带有必须再验证后才能复用 stale 的语义
`public`	明确允许缓存（例如带 `Authorization` 的响应在共享缓存中的场景）
`private`	禁止共享缓存存储（或限定字段）
`no-cache`	使用前必须验证
`no-store`	不要存储
`must-revalidate`	一旦 stale，不得在未验证成功前复用；断连时更应报错而不是偷偷给 stale

一个可记的分层：

# 静态资源：可公开、长期缓存（内容指纹化后）
Cache-Control: public, max-age=31536000, immutable

# HTML 入口：可缓存但每次用前确认
Cache-Control: no-cache

# 登录态 API：不要被中间层存
Cache-Control: private, no-store

# 对一致性要求高的共享缓存内容
Cache-Control: public, max-age=60, must-revalidate

2. Age 与“看起来刚生成”

响应里的 Age 表示估计已在缓存中停留的秒数。共享缓存命中时，客户端看到的“年龄”往往不是 0。排查“为什么我设了 max-age=60，却总在提前回源”时，要同时看：

源站给出的 Cache-Control / Expires
中间层是否改写了头
响应是否已有较大 Age

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

没有显式过期信息时，部分缓存会用启发式算法估算 fresh 时间。这在不同实现间差异大，生产环境应显式给出 freshness，不要赌默认行为。

三、校验器：ETag 与 Last-Modified

验证阶段依赖表示元数据（representation metadata），最常见两类：

1. `Last-Modified`

源站认为所选表示最后修改的时间（HTTP-date）。例如：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

优点：实现简单，文件系统/对象存储天然具备 mtime。
局限：

秒级精度，一秒内多次变更可能撞车；
时钟回拨、多副本 mtime 不一致会误判；
内容没变但元数据变了时，语义可能不够准。

2. `ETag`（实体标签）

ETag 是源站为某个表示分配的不透明标签：

ETag: "xyzzy"
ETag: W/"xyzzy"

强校验器（strong）：表示数据（以及会影响 200 内容的关键元数据）变化时标签应变化。适合字节级精确比较。
弱校验器（weak，W/ 前缀）：语义等价即可，即使字节不完全相同。生成成本更低，但比较能力更弱。

RFC 9110 明确：在不便存修改时间、一秒精度不够、或修改时间维护不一致时，ETag 通常比 Last-Modified 更可靠。

工程上常见生成策略：

策略	适用	注意
内容哈希（SHA-256 截断）	静态文件、构建产物	强 ETag，成本随体积上升
版本号 / 修订号	业务资源、CMS	发布流程必须保证“内容变则版本变”
inode + size + mtime	传统文件服务器	迁移/复制后可能变，跨机一致性差
弱 ETag（模板渲染摘要）	HTML 片段语义不变	不要拿去当字节级一致性保证

四、条件请求：如何问“变了没有”

1. `If-None-Match`（优先，基于 ETag）

客户端/缓存带上已存表示的 ETag：

GET /app.js HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

源站比较当前 ETag：

匹配（表示未变）→ 304 Not Modified，通常无 body；
不匹配 → 200 OK + 新表示（含新的 ETag）。

对 If-None-Match，规范要求使用弱比较函数：即使只有弱 ETag，也可用于缓存验证。

2. `If-Modified-Since`（基于时间）

GET /style.css HTTP/1.1
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

若所选表示的修改时间不比该日期更新，则不必再传实体。

3. 两者同时出现时谁说了算？

RFC 9110 规定：若请求里带了 If-None-Match，接收方必须忽略 If-Modified-Since——因为实体标签被认为是更准确的替代条件。两者同时出现多是兼容历史客户端；服务端实现应按规范优先级处理。

4. `304 Not Modified` 到底省了什么

304 表示：若没有条件约束，这次本应是 200；但条件为假（未修改），客户端应继续使用本地已存表示。

源站仍应带上在同等 200 中会发送的关键头（如 ETag、Date、Content-Location 等），以便缓存刷新元数据（freshen），而不只是“空响应”。

流量层面：

首次：200 + 完整 body（例如 800KB）
之后未变更：304 + 几乎无 body（通常几百字节头）

对静态资源、移动端弱网、跨境回源，收益非常明显。

五、一张图串起完整路径

Client/CDN 本地有副本？
 |
 | 无 -----> 普通 GET -----> 200 + body + Cache-Control + ETag/LM
 |
 | 有且 fresh -----> 直接复用（不回源）
 |
 | 有但 stale / 或 no-cache
 v
 条件请求：If-None-Match / If-Modified-Since
 |
 +--> 未变：304（刷新头，复用旧 body）
 |
 +--> 已变：200（新 body + 新校验器）

记住两句话：

fresh 解决“要不要问”；
validator 解决“问了以后要不要传 body”。

只有 max-age 没有校验器，过期后往往只能全量回源；只有 ETag 没有合理 freshness，会变成“每次都协商”，仍然浪费 RTT。

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

构建后文件名含 hash，例如 app.3f2a1c.js：

location /static/ {
 # 文件名已指纹化，可大胆长缓存
 expires 365d;
 add_header Cache-Control "public, max-age=31536000, immutable";
}

要点：

URL 变 = 内容变，可用超长 max-age；
immutable 提示浏览器在 freshness 内不必做启发式再验证（支持情况因客户端而异，但不妨碍给出）；
旧 URL 自然失效，无需纠结主动 purge 每一个文件。

2. HTML / 入口文档

入口常引用带 hash 的静态资源，自身却要尽快看到新版本：

Cache-Control: no-cache
ETag: "html-rev-42"

或短 max-age + 强制再验证：

Cache-Control: max-age=0, must-revalidate
ETag: "html-rev-42"

这样浏览器/边缘仍可存副本，但使用前会走条件请求；HTML 未变则 304，变了才下新文档。

3. 个性化或含凭证的 API

Cache-Control: private, no-store

原因：

private 避免 CDN 把用户 A 的响应给用户 B；
no-store 进一步降低敏感信息落盘风险。

注意：no-store 不是完备隐私方案（恶意或失控缓存可能不遵守），敏感数据仍要靠鉴权、最小化返回字段和传输安全。

4. 可被 CDN 缓存的公共 API / 配置

Cache-Control: public, s-maxage=30, max-age=10
ETag: "cfg-20260715-1"

浏览器短缓存（max-age）；
CDN 稍长（s-maxage）；
过期后用 ETag 协商，降低源站带宽。

Nginx 反代缓存可配合：

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:50m inactive=10m;

location /api/public/ {
 proxy_cache api_cache;
 proxy_cache_valid 200 30s;
 # 过期后用条件请求回源校验
 proxy_cache_revalidate on;
 # 更新期间允许短暂提供 stale，降低源站抖动影响
 proxy_cache_use_stale updating error timeout http_500 http_502 http_503;
 proxy_pass http://upstream;
}

proxy_cache_revalidate on 的作用，正是在缓存过期后启用 If-Modified-Since / If-None-Match 条件回源——这与 RFC 里的 validation 模型一致。

七、服务端如何正确实现条件 GET

以伪代码说明最小正确逻辑：

def handle_get(request, resource):
 etag = resource.strong_etag() # 例如 '"%s"' % sha256(body)[:16]
 last_mod = resource.last_modified_http_date()

 # 1) 优先处理 If-None-Match
 inm = request.headers.get("If-None-Match")
 if inm:
 if etag_matches(inm, etag): # 按弱比较规则实现
 return response_304(etag=etag, last_modified=last_mod)
 return response_200(resource, etag=etag, last_modified=last_mod)

 # 2) 否则再看 If-Modified-Since
 ims = request.headers.get("If-Modified-Since")
 if ims and not resource.modified_after(ims):
 return response_304(etag=etag, last_modified=last_mod)

 return response_200(resource, etag=etag, last_modified=last_mod)

实现清单：

同一表示的 ETag 必须稳定：相同内容不要每次随机；
内容变更必须换 ETag：漏更新会造成“改了却一直 304”；
Vary 要配对：若响应随 Accept-Encoding / Authorization / 自定义头变化，必须正确 Vary，否则缓存会串内容；
压缩前后一致性：对 gzip/br 内容，ETag 策略要与表示选择一致，避免“协商错表示”；
不要手动拼错弱标记：W/ 大小写敏感，格式为 W/"tag"。

八、常见坑与排查清单

坑 1：`no-cache` 和 `no-store` 用反

想“每次确认后再用本地副本” → no-cache（或 max-age=0, must-revalidate）+ ETag；
想“别存敏感响应” → no-store（通常再加 private）。

坑 2：只配了长缓存，没有内容指纹

Cache-Control: max-age=31536000 配在固定 URL 的 app.js 上，发版后用户会长时间用旧脚本。正确做法是 hash 文件名 或主动缩短 freshness 并保证能 purge。

坑 3：ETag 在多实例间不一致

滚动发布时实例 A/B 对同一文件算出不同 ETag（例如混入了进程启动时间），客户端会在 200/304 间抖动，缓存命中率暴跌。校验器生成必须内容决定论。

坑 4：中间层剥掉了校验器或改写了 Cache-Control

排查命令：

# 看源站
curl -sI https://origin.example.com/static/app.js | sed -n '1,20p'

# 看经 CDN/Nginx 后
curl -sI https://www.example.com/static/app.js | sed -n '1,20p'

# 模拟条件请求
ETAG='"abc123"'
curl -sI -H "If-None-Match: $ETAG" https://www.example.com/static/app.js | sed -n '1,15p'

对比：ETag、Cache-Control、Age、CF-Cache-Status/X-Cache 等是否符合预期。第二次应看到 304（在 ETag 仍匹配时）。

坑 5：API 被共享缓存误缓存

带 cookie/authorization 的响应若缺少 private/no-store，再叠加错误的 public，可能把用户数据缓存到边缘。对用户相关响应默认保守，对真正公共的 GET 再显式放开。

坑 6：304 后客户端仍像“没更新样式”

常见是 HTML 长缓存，或 Service Worker / 应用内二次缓存。协议层 304 只保证这一跳 HTTP 缓存协商；还要检查：

HTML 的 Cache-Control；
SW 的 cache.addAll 策略；
应用本地 localStorage 里的资源清单。

九、选型小结

目标	推荐组合
最大化静态资源性能	内容哈希 URL + 长 `max-age` + `public`
入口文档尽快更新	`no-cache` 或短 max-age + ETag + 304
公共只读 API 降源站负载	`s-maxage` + ETag + CDN `proxy_cache_revalidate`
用户私有数据	`private, no-store`，默认不进共享缓存
过期后仍要强一致	`must-revalidate` / `proxy-revalidate` / `s-maxage` 语义

原则：

用 freshness 控制回源频率；
用 validator 控制回源体积；
用 private/no-store 控制安全边界；
用 URL 指纹解决“长缓存与发布”的矛盾。

总结

HTTP 缓存不是“加一个 Redis”或“在 Nginx 里 proxy_cache on”这么简单，它是一套有严格语义的协议机制：

Cache-Control 回答能不能存、能存多久、过期后能不能直接用；
ETag / Last-Modified 回答如何证明表示是否变化；
If-None-Match / If-Modified-Since 与 304 回答如何在确认未变时省略 body。

把这三层设计对齐后，静态站点、前后端分离入口、CDN 边缘缓存和公共 API 都能在带宽、延迟、一致性之间取得可解释的平衡。下次再看到“用户一直是旧页面”或“源站带宽无故升高”，先把响应头和一次条件请求抓出来——答案通常就在 Cache-Control 与校验器的协作里。

参考资料

IETF RFC 9111：HTTP Caching（新鲜度、验证、Cache-Control 指令语义）
IETF RFC 9110：HTTP Semantics（ETag、Last-Modified、If-None-Match、If-Modified-Since、304 Not Modified）
MDN：HTTP caching
MDN：ETag
MDN：If-None-Match
MDN：Cache-Control
Nginx 文档：ngx_http_headers_module（expires / add_header）
Nginx 文档：ngx_http_proxy_module（proxy_cache_revalidate、proxy_cache_use_stale、proxy_cache_valid）

Node.js 26.5.0 Current 发布：Web Streams、TLS 可观测性与权限模型修复实践指南

Fri, 10 Jul 2026 09:02:00 +0800

Node.js 26.5.0 已于 2026-07-08 发布，属于 Current 版本线的一次常规功能与维护更新。它不是安全发布，但包含了几类对后端服务、网关、边缘函数和内部平台都值得关注的变化：Blob 新增面向流式读取的能力，TLS 协商信息更容易被观测，权限模型在 NODE_OPTIONS 传播场景下修复了行为一致性问题，同时依赖组件继续更新到较新的版本。

如果你的生产环境仍以 LTS 为主，不需要因为 Current 版本线的每次发布立即升级线上服务；但如果团队正在验证 Node.js 26、维护基础镜像、做运行时平台适配，26.5.0 很适合作为一次“小步升级 + 回归验证”的窗口。

这次发布的定位

从官方 release index 可以看到，Node.js 26.5.0 的发布日期为 2026-07-08，随附组件版本包括：

npm：11.17.0
V8：14.6.202.34
libuv：1.52.1
zlib：1.3.2.1-motley
OpenSSL：3.5.7
ABI modules：147
security: false，即这不是一次安全专版发布

这意味着它更适合被理解为 Current 线的功能增强和维护版本，而不是“必须立刻全量升级”的安全补丁。不过，Current 线通常会提前暴露未来 LTS 可能影响应用的运行时变化，平台团队应该尽早把它纳入 CI 验证。

关键变化一：`Blob.textStream()` 让文本读取更贴近流式处理

官方发布说明将 blob.textStream() 列为 notable change。过去我们处理 Blob 文本内容时，常见方式是一次性调用 blob.text()：

const text = await blob.text();

这种写法简单，但它会把文本内容整体读入内存。对于普通接口请求体、配置片段或小文件来说问题不大；但在日志分析、对象存储网关、上传文件预处理等场景中，一次性读取会放大内存峰值，也不利于和 Web Streams 管线组合。

Blob.textStream() 的价值在于：它把“文本内容”暴露为可流式消费的接口，应用可以更自然地接入 ReadableStream、TextDecoderStream、分块处理、背压控制等模式。实践中建议关注三类用法：

// 伪代码：面向流式消费的处理方式
const stream = blob.textStream();

for await (const chunk of stream) {
 // 分块统计、过滤、写入下游，而不是一次性放进内存
 processChunk(chunk);
}

升级验证时不要只跑“能否启动”的 smoke test，应补充大文件和高并发场景，观察 RSS、GC 暂停、吞吐量是否更稳定。

关键变化二：TLS 协商组信息更容易排查

26.5.0 还提到 “report negotiated TLS groups”。这类变化不一定会改变业务逻辑，但对运维和安全排障很有价值。

在实际生产中，TLS 问题经常表现为“某些客户端能连、某些客户端失败”：

客户端运行时、OpenSSL、系统证书库版本不同；
负载均衡、反向代理、服务端 Node.js 的 TLS 配置不一致；
安全基线升级后，曲线/密钥交换组被禁用或协商失败；
FIPS、国密或企业代理环境引入额外限制。

如果运行时能报告协商到的 TLS groups，平台团队就能把“握手失败/降级/兼容性差”的问题从黑盒日志变成可观测事实。建议在升级验证阶段做一次完整 TLS 回归：

node -p "process.versions"
openssl s_client -connect example.com:443 -tls1_3 </dev/null

同时检查服务端访问日志、网关日志和 APM 标签，确认 TLS 版本、加密套件、协商组等信息是否能被统一记录。对于金融、企业内网、老旧 Android/WebView 客户端，这一步尤其重要。

关键变化三：权限模型与 `NODE_OPTIONS` 的一致性修复

Node.js 的 Permission Model 仍处于演进阶段，但已经是很多团队评估“最小权限运行 JavaScript 服务”的重要方向。26.5.0 的提交列表包含 “fix permission model propagation via NODE_OPTIONS”。

这类修复值得平台团队认真看待，因为 NODE_OPTIONS 在容器镜像、PaaS 平台、CI/CD、serverless 运行时里非常常见。例如：

export NODE_OPTIONS="--experimental-permission --allow-fs-read=/app/config"
node server.js

如果权限相关选项在子进程、worker、工具链包装脚本中传播不一致，可能会出现两种风险：

开发/测试环境以为权限限制已生效，但生产包装脚本绕过了限制；
本该允许的读取、网络或子进程行为被误拦截，导致线上难以复现的故障。

因此，升级到 26.5.0 后建议新增一组“权限模型回归用例”，覆盖：主进程、child_process、worker、测试框架、构建脚本以及容器入口脚本。不要只验证应用入口文件。

关键变化四：依赖组件更新带来的隐性影响

本次版本还包含若干依赖更新，例如 release notes 中列出的 Undici、nghttp3、SQLite 等更新；release index 也显示 OpenSSL、libuv、zlib 等底层组件处在较新的版本组合上。对大多数业务而言，这些更新不会直接要求改代码，但它们可能影响：

HTTP 客户端行为：连接复用、代理、重定向、超时和 header 处理；
HTTP/2 / HTTP/3 相关边界行为；
内置 SQLite 场景的兼容性和性能；
原生插件编译、ABI 兼容和镜像体积；
TLS/加密能力与企业安全基线的匹配。

如果项目依赖 node-gyp、原生 addon、Electron、Playwright、Puppeteer 或自定义 OpenSSL 行为，建议在升级前后分别输出环境信息：

node -p "process.version"
node -p "process.versions"
npm ls --depth=0

并在 CI 中保留构建日志，方便定位 ABI 或编译链变化。

注意事项

26.5.0 是 Current，不等同于 LTS；生产环境是否采用要看团队的运行时策略。
这不是安全发布，不应把它包装成“紧急安全升级”。
权限模型仍要关注实验性接口和未来变更，不建议仅凭一次修复就假设所有沙箱场景都已稳定。
原生 addon 和构建链要在目标架构上验证，尤其是 Alpine、ARM64、CI runner 与生产镜像不一致时。
如果线上仍在 Node.js 22/24 LTS，优先处理对应 LTS 安全更新，再安排 Node.js 26 的兼容性验证。

总结

Node.js 26.5.0 的重点不在“惊天动地的新功能”，而在几个对工程实践很实用的方向：更流式的 Blob 文本读取、更好的 TLS 可观测性、权限模型传播修复，以及底层依赖维护更新。对平台团队来说，最合理的姿势是：把它纳入 CI 和预发环境，围绕 Web Streams、TLS、权限模型、原生 addon 建立回归清单；对业务团队来说，则应继续遵循 LTS 优先策略，等验证充分后再决定是否升级运行时基线。

参考资料

官方发布说明：https://nodejs.org/en/blog/release/v26.5.0
官方 release index：https://nodejs.org/download/release/index.json
GitHub Release：https://github.com/nodejs/node/releases/tag/v26.5.0
Node.js Permission Model 文档：https://nodejs.org/api/permissions.html
Node.js Web Streams 文档：https://nodejs.org/api/webstreams.html

Web on 吾爱主机

TLS 1.3 握手与证书链校验：原理、流程与工程排查

问题背景：TLS 到底在保护什么

核心原理：TLS 1.3 握手的三个阶段

完整握手消息流（1-RTT）

相对 TLS 1.2 的关键变化（工程相关）

0-RTT：快，但默认不适合“写操作”

证书链校验：从信任锚走到叶子

叶子身份：SAN 才是名字的主战场

CA 与路径长度：basicConstraints

服务端交付的链 vs 客户端验证出的链

实践：用 OpenSSL 复现握手与链问题

1）看协议版本、套件与服务端发送的证书

2）让校验错误真正失败（贴近生产客户端）

3）从 PEM 文件本地拆解链

4）Nginx 侧：链顺序与协议底线

常见坑与排查清单

总结

参考资料

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

一、先分清：存下来 ≠ 可以直接用

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

2. Age 与“看起来刚生成”

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

三、校验器：ETag 与 Last-Modified

1. Last-Modified

2. ETag（实体标签）

四、条件请求：如何问“变了没有”

1. If-None-Match（优先，基于 ETag）

2. If-Modified-Since（基于时间）

3. 两者同时出现时谁说了算？

4. 304 Not Modified 到底省了什么

五、一张图串起完整路径

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

2. HTML / 入口文档

3. 个性化或含凭证的 API

4. 可被 CDN 缓存的公共 API / 配置

七、服务端如何正确实现条件 GET

八、常见坑与排查清单

坑 1：no-cache 和 no-store 用反

坑 2：只配了长缓存，没有内容指纹

坑 3：ETag 在多实例间不一致

坑 4：中间层剥掉了校验器或改写了 Cache-Control

坑 5：API 被共享缓存误缓存

坑 6：304 后客户端仍像“没更新样式”

九、选型小结

总结

参考资料

Node.js 26.5.0 Current 发布：Web Streams、TLS 可观测性与权限模型修复实践指南

这次发布的定位

关键变化一：Blob.textStream() 让文本读取更贴近流式处理

关键变化二：TLS 协商组信息更容易排查

关键变化三：权限模型与 NODE_OPTIONS 的一致性修复

关键变化四：依赖组件更新带来的隐性影响

推荐升级流程

1. 先确认版本线策略

2. 建立最小回归清单

3. 对 Web Streams 和 Blob 场景做专项验证

4. 对权限模型做“入口链路”测试

5. 保留快速回滚方案

注意事项

总结

参考资料

1. `Last-Modified`

2. `ETag`（实体标签）

1. `If-None-Match`（优先，基于 ETag）

2. `If-Modified-Since`（基于时间）

4. `304 Not Modified` 到底省了什么

坑 1：`no-cache` 和 `no-store` 用反

关键变化一：`Blob.textStream()` 让文本读取更贴近流式处理

关键变化三：权限模型与 `NODE_OPTIONS` 的一致性修复