HTTP/HTTPS 协议运维

• HPKP 通过 Public-Key-Pins 头钉扎公钥，防中间人
• 价值：防 CA 被黑/恶意证书，客户端验证公钥
• 废弃原因：误配置导致站点不可用（锁死）、需要备份密钥

HPKP（HTTP Public Key Pinning）让服务器通过 Public-Key-Pins 头声明信任的证书公钥（SPKI），客户端在后续访问时校验证书公钥是否与钉扎一致，从而防止中间人使用他人签发的证书。其工程价值是"防 CA 误签发/被攻破后的恶意证书"。但 HPKP 被废弃：一是误配置的后果极其严重——若钉扎了错误公钥而无备份，站点会永久不可用（客户端拒绝连接），几乎无法恢复；二是需维护备份密钥与多钉扎，运维复杂；三是与现代证书轮换/CI 冲突。因此被废弃，替代方案是 Expect-CT（强制证书透明度）与更安全的证书管理。

HPKP 的价值是"客户端钉扎公钥防中间人"，但"钉死则锁死"的致命风险导致废弃。运维教训是"公钥钉扎要谨慎、要有备份密钥"。

• 401 + WWW-Authenticate 触发认证，Authorization 携带凭据
• Basic 明文 base64，Digest 摘要哈希
• 与表单登录（Cookie/Session）的差异

HTTP 认证由服务器返回 401 与 WWW-Authenticate: Basic realm="..." 头，客户端弹出凭据框，再把凭据放入 Authorization 头重发。Basic 认证用 Authorization: Basic base64(user:pass)，明文 base64 可解码，仅 HTTPS 下安全。Digest 认证用 WWW-Authenticate: Digest ... 挑战值，客户端用 MD5 哈希响应，不传明文密码，但仍是弱密码学。与表单登录的差异：表单登录由应用层处理，用 POST + Cookie/Session 维持认证状态，认证在应用内；HTTP 认证是协议层，由浏览器/客户端承担，每次请求带 Authorization。Basic 常用于简单的设备/API 保护，表单登录用于真实用户系统。

核心差异是"协议层 vs 应用层"。Basic/Digest 是 HTTP 协议自带认证，表单登录是应用实现。Basic 必须配 HTTPS，Digest 防明文但弱。

• 重定向链（302/303）追踪与跳转次数
• Cookie 域/路径不匹配导致登录态丢失
• POST 重定向到 GET 丢失请求体（303/307 差异）

SSO 登录排障从 HTTP 层面看：① 重定向链——用 curl -L -v 追踪 302/303 跳转，看每一跳的 Location 与状态码，确认是否形成循环或跳转到错误域；② Cookie 域——检查 Set-Cookie 的 Domain/Path，若 SSO 与业务域 Cookie 域不一致，登录态无法跨域传递；③ POST 绑定丢失——SSO 用 POST 提交断言（SAML），若重定向把 POST 转成 GET（303），请求体丢失导致断言失败；307 保留请求方法。定位用 curl -L -i -c cookies.txt -b cookies.txt 逐步观察，辅以抓包看 Set-Cookie 与 Location。

SSO 排障三要素是"重定向链、Cookie 域、POST 保真"。curl 追踪跳转与 Cookie，抓包看 Set-Cookie 与 Location，能定位登录态丢失。

• cert pinning 在客户端硬编码/配置服务器证书或公钥
• 校验方式：按证书、按公钥（SPKI）、按哈希
• 与 TLS 标准校验的关系

cert pinning 是客户端在标准 TLS 校验之外，额外校验服务器证书/公钥是否与本地钉扎一致，防止中间人使用其他 CA 签发的证书。实现方式：钉扎完整证书、钉扎公钥（SPKI 哈希）、或钉扎证书指纹。轮换处理是关键难点：钉扎证书时，证书轮换会使钉扎失效，因此要"多钉扎"（同时钉扎新旧备份公钥）、预留备份密钥、或通过动态下发/更新策略。若只钉扎单一证书且未更新，轮换会导致客户端拒绝连接。因此现代做法常钉扎公钥并维护多把备份，配合监控与灰度更新。

cert pinning 增强安全但增加轮换复杂度。核心是"多钉扎 + 备份密钥 + 动态更新"，避免证书轮换导致断连。

• HttpOnly 标记使 Cookie 无法被 JS 读取
• 防止 XSS 窃取会话 Cookie
• 与 Secure、SameSite 的配合

HttpOnly 标记告诉浏览器该 Cookie 不能被 JavaScript（document.cookie）读取，只能通过 HTTP 请求自动携带。这样即使网站存在 XSS，攻击者脚本也无法读取会话 Cookie，从而无法窃取登录态。它是 XSS 防护的重要一环，但只防"Cookie 窃取"，不防 XSS 本身与其他攻击。配合 Secure（仅 HTTPS 传输）与 SameSite（防 CSRF）可加强 Cookie 安全。运维上设置会话 Cookie 时默认加 HttpOnly，敏感 Cookie 加快安全属性。

HttpOnly 的机制是"JS 不可读 Cookie"，阻断 XSS 的 Cookie 窃取路径。它防窃取不防 XSS，需配合其他安全措施。

• Expect-CT 头强制浏览器检查证书透明度
• 检测证书是否在 CT 日志
• 与 HPKP 的差异（不钉扎公钥，只要求 CT）

Expect-CT 是 HPKP 的替代方案，通过 Expect-CT: enforce; max-age=31536000 头要求浏览器检查证书是否在 CT 日志中，若证书未入 CT 日志则拒绝连接（enforce 时）。它不钉扎公钥，而是强制"证书透明度"检查，避免 HPKP 的"钉死锁死"风险。作用：防止恶意 CA 签发未记录的证书，因为未入 CT 日志的证书会被拒。运维上配置 Expect-CT 头并配合监控证书 CT 日志，但注意 Chrome 已移除 Expect-CT 支持（因 CT 强制已默认开启），故主要面向其他浏览器与内网。CT 强制对公网证书已是默认，Expect-CT 更多是补充。

Expect-CT 与 HPKP 的差异是"不钉扎公钥，只要求 CT 记录"，规避了 HPKP 的锁死风险。但已被 Chrome 移除，CT 默认强制取代。

• Authorization: Bearer 传递凭据
• 校验：中间件解析 token、验签、过期
• 泄漏风险：token 进入日志、反向代理/CDN 缓存、Referer

Bearer token 通过 Authorization: Bearer <token> 头传递，服务端校验 token 的签名、过期、scope。泄漏风险：token 若被反向代理/CDN 记录进 access log、或请求被缓存（代理缓存带 Authorization 的响应）、或通过 Referer 泄漏，都会被第三方拿到。规避：① 反向代理/CDN 不缓存带 Authorization 的请求（标准要求），配置 Vary: Authorization 或禁用缓存；② 日志脱敏，不记录 Authorization 头；③ 全程 HTTPS，防传输窃听；④ token 用短 TTL + 刷新机制，减少泄露窗口；⑤ 服务端校验 token 来源与 scope。运维上要确保代理层不落盘、不缓存、不转发到日志。

Bearer token 的泄漏风险在"缓存、日志、Referer"。规避核心是"不缓存、不落日志、HTTPS、短 TTL"。

• Negotiate 用 Kerberos，需要 SPN（服务主体名）
• 401 + WWW-Authenticate: Negotiate 触发，客户端回 Kerberos 票
• 401 循环原因：SPN 不匹配、票据缺失、时钟不同步、浏览器未配置

HTTP Negotiate/Kerberos 认证中，服务器返回 401 + WWW-Authenticate: Negotiate，客户端用 Kerberos 票据回 Authorization: Negotiate <token>。前提是服务器配置了正确的 SPN（如 HTTP/web.example.com），且客户端能获取该 SPN 的 Kerberos 票据。浏览器 401 循环的常见原因：SPN 不匹配或未配置、客户端无法访问 KDC、域账户无票据、客户端与服务器时钟不同步（Kerberos 严格依赖时间）、浏览器/站点未纳入信任。排障：setspn -L 检查 SPN、klist 看票据、kinit 获取票据、检查时钟同步，用 curl --negotiate 测试。

Negotiate 的 401 循环核心是"SPN 与票据"。SPN 不匹配、时钟偏移、票据缺失都会导致无法完成，排障从 SPN/Kerberos/时钟入手。

• HTTP/2 多路复用，同一连接可承载多请求
• connection coalescing 合并多个域名到同一连接
• 前提：同 IP、证书覆盖所有域名（SAN）、ALPN 一致

HTTP/2 的连接合并（connection coalescing）让浏览器把多个域名（如 a.example.com、b.example.com）的请求合并到同一个 TCP/TLS 连接上，减少连接数。前提条件：① 域名解析到同一 IP（相同服务器）；② 服务器证书（SAN）覆盖所有域名（或使用通配符证书）；③ 协商的协议版本（ALPN）一致。若满足，浏览器可复用连接。这要求证书 SAN 覆盖多个域名、DNS 指向同一源。运维上若想让多域名合并连接，需保证证书覆盖与同源；否则浏览器会断开合并。connection coalescing 降低连接与握手开销，但多域名需共享证书与 IP。

coalescing 的价值是"多域名复用一个连接"，前提是"同 IP + 证书覆盖 + 同协议"。它依赖证书 SAN 与 DNS 一致性。

• server push 主动推送资源，减少请求
• 取舍：可能推送不需要的资源、浪费带宽、缓存问题
• 反向代理支持与缓存关联

HTTP/2 server push 允许服务器在客户端请求时主动推送相关资源（如 CSS/JS），减少往返。但取舍明显：服务器可能推送客户端已缓存或不需要的资源，浪费带宽；推送与缓存命中控制复杂；反向代理（如 Nginx）对 server push 的支持有限且需与缓存协调。因此 server push 在现代已不再推荐，被 103 Early Hints 与 <link rel=preload> 取代——后者只发提示，客户端按需请求，更可控。反向代理取舍：若开启 server push 需精确控制推送内容与缓存，否则反而劣化。多数运维选择禁用 server push。

server push 的取舍是"主动推送 vs 浪费带宽/缓存难控"。现代倾向 Early Hints/preload，更精准且不浪费。生产多禁用 server push。

• QUIC 用 UDP 443 与非 443 端口，复用 443 减少防火墙改动
• 连接迁移、0-RTT 对负载均衡/NAT 会话保持的挑战
• Alt-Svc 头协商启用 HTTP/3

HTTP/3（QUIC）基于 UDP，复用 443 端口（也可用其他端口），避免大范围防火墙改动。但运维影响显著：① 连接迁移——QUIC 连接可跨 IP/端口迁移（连接 ID），会话保持不依赖 IP，这使负载均衡的哈希（按 IP/五元组）与 NAT 会话保持失效，需要基于 connection ID 的会话保持；② 0-RTT——重放风险与负载均衡的分布式状态问题；③ 防火墙/NAT——需放行 UDP 443，且 NAT 的 UDP 会话超时需足够长，否则长连接被切断。服务端启用：先服务 HTTP/2，再通过 Alt-Svc: h3=":443" 头告知客户端可用 HTTP/3，客户端后续升级。Nginx 需编译 HTTP/3 模块并配置 listen 443 quic。

QUIC 的运维挑战是"连接迁移 + 0-RTT + UDP NAT/防火墙"。Alt-Svc 是渐进协商启用 HTTP/3 的机制，先 h2 后 h3。

• Permissions-Policy 头控制浏览器 API（摄像头、地理位置等）可用性
• 语法：feature=allowlist
• 与 Feature-Policy 的演进

Permissions-Policy 头（原 Feature-Policy）控制浏览器敏感 API（如摄像头、麦克风、地理位置、支付、USB）在页面或 iframe 中的可用性。语法 Permissions-Policy: camera=(), geolocation=(self), payment=(self "https://trusted.example.com")：() 表示禁用，self 允许同源，可指定可信来源。它限制页面能否调用这些 API，减少恶意/滥用（如页面偷偷调用摄像头）。用于安全加固：默认禁用不必要的 API，只放行需要的来源。注意与 CSP 的 Permissions-Policy 指令（Meta 标签）配合，是浏览器权限控制的两层。

Permissions-Policy 是"浏览器 API 权限的声明式控制"，按功能限制来源。它是减少敏感 API 暴露面的安全头。

• Referrer-Policy 控制 Referer 头携带的信息
• 策略：no-referrer、origin、same-origin、strict-origin 等
• 防止 URL 中敏感信息通过 Referer 泄漏

Referrer-Policy 头控制浏览器在请求时携带多少引荐来源信息（Referer 头）。策略分级：no-referrer（不带）、origin（只带来源域）、same-origin（仅同源带完整）、strict-origin-when-cross-origin（跨源只带域，降级时安全）、no-referrer-when-downgrade（HTTPS→HTTP 时不带）。它防止 URL 中查询参数（如 token、订单号）通过 Referer 泄漏给第三方跳转站点。安全运维上建议用 strict-origin-when-cross-origin（现代浏览器默认），对敏感页面可设 no-referrer。它是防止 Referer 泄漏的关键。

Referrer-Policy 控制"Referer 携带多少信息"，核心是防 URL 敏感信息跨源泄漏。strict-origin 系列是推荐默认。

• X-Content-Type-Options: nosniff 禁止 MIME 嗅探
• 防浏览器猜测内容类型执行脚本
• 与 Content-Type 的配合

X-Content-Type-Options: nosniff 告诉浏览器禁止 MIME 嗅探（MIME sniffing），即浏览器必须严格执行服务器声明的 Content-Type，不能因为内容看起来像 HTML/脚本就猜测处理。这防止"把实际是 HTML 的内容用 text/plain 或 image 类型返回，却被浏览器当作脚本执行"的 XSS/恶意文件攻击。例如防止上传的图片被当作 HTML 执行。运维上为所有响应加 X-Content-Type-Options: nosniff，并确保服务端正确设置 Content-Type。它是基础安全头之一。

nosniff 的机制是"关闭 MIME 嗅探"，强制按 Content-Type 处理，防范"内容类型被误判为可执行"的攻击。

• 4xx 客户端错误：400/401/403/404/429
• 5xx 服务端错误：500/502/503/504
• 结合语义定位：参数、认证、权限、限流、网关

4xx 是客户端错误，5xx 是服务端错误。常见 4xx：400 请求错误（参数/语法）、401 未认证、403 无权限、404 资源不存在、429 限流/请求过多。5xx：500 服务端内部错误、502 网关/上游无效响应、503 服务不可用（过载/维护）、504 网关超时。定位：400 查请求参数与编码，401/403 查认证与权限，404 查路由，429 查限流配置；500 查应用日志，502 查上游与网关，503 查过载与部署，504 查上游超时与慢响应。结合 Nginx access log 的 $status 与 error log 的 $upstream_status 定位是代理层还是上游。

4xx/5xx 的定位核心是"区分客户端与服务端、区分代理与上游"。状态码 + 日志（access/error/upstream）结合定位。

• 缓存键、TTL、Cache-Control/ETag
• 命中率、回源、缓存过期
• 排查命中 vs 未命中（X-Cache）、回源

HTTP 缓存与 CDN 排障关注：缓存键（URL+参数+Vary）、TTL（Cache-Control max-age）、校验（ETag/Last-Modified）。排查时看响应头 X-Cache: HIT/MISS（CDN 命中）、Age（缓存时长）、Cache-Control与 ETag。命中率低时查：缓存键是否含不必要参数（导致缓存碎片）、TTL 是否过短、是否被 Vary: Authorization 或 Cache-Control: no-store 禁用。回源量高时查预热、缓存碎片、URL 不规范。一致性：CDN 与源站对同一资源缓存策略不一致导致新旧混杂，需统一 Cache-Control/ETag。用 curl 带 -H "Accept-Encoding: gzip" 与访问不同 CDN 节点对比。

缓存排障核心是"看 X-Cache/Age/Cache-Control，查命中率与回源量"。缓存键与 TTL 是影响命中率的两大因素。

• HTTP/2 多路复用减少连接、头部压缩
• HTTP/3 QUIC 连接迁移、0-RTT
• 对负载均衡/防火墙/NAT 的影响

HTTP/2 多路复用使单一连接承载多个并发流，减少连接数与 TLS 握手，头部压缩（HPACK）降低开销；但队头阻塞（TCP 层）仍存在。HTTP/3（QUIC）基于 UDP，支持连接迁移（连接 ID 不变，IP 变化连接不断）与 0-RTT，消除 TCP 队头阻塞。运维影响：HTTP/2 的多路复用需注意连接数监控与流控；HTTP/3 的连接迁移使负载均衡的 IP 哈希会话保持失效，需基于连接 ID；NAT/防火墙需放行 UDP 443 且会话超时足够。监控上要分别统计 h2/h3 连接、流、0-RTT 命中。兼容性：h3 通过 Alt-Svc 渐进启用，保留 h2 兜底。

HTTP/2 主打多路复用，HTTP/3 主打连接迁移与 0-RTT。运维重点是会话保持方式改变与 UDP 放行。

• TLS 握手 1-2 RTT 开销
• 会话复用（session ticket/resumption）减少 RTT
• OCSP stapling、TLS 1.3、0-RTT

TLS 握手开销是 HTTPS 的主要延迟来源（1.2 为 2 RTT，1.3 为 1 RTT）。优化手段：① 会话复用（session ticket/resumption）——客户端复用会话，省去完整握手，TLS 1.3 可 0-RTT；② 升级 TLS 1.3——单 RTT 且握手更精简；③ OCSP stapling——服务器带 OCSP 响应，免客户端回源；④ 硬件加速——AES-NI 指令集加速 AEAD 加密，降低 CPU 开销；⑤ 长连接复用（HTTP keepalive）减少握手次数。综合优化后在 HTTP/2 多路复用下，TLS 握手低频化，延迟显著下降。

HTTPS 性能优化核心是"减少握手次数与 RTT、降低 CPU 开销"。会话复用 + TLS 1.3 + OCSP stapling + AES-NI 是组合拳。

• ID token 是 JWT，含用户身份声明
• 传递：Authorization 头（Bearer）或 Cookie
• 签名校验（JWKS）、过期验证（exp）

OIDC ID token 是 JWT，携带用户身份声明（sub、email、exp 等）。传递方式：API 场景用 Authorization: Bearer <id_token> 头，Web 场景可放 Cookie（配合 HttpOnly/Secure）。校验：用 IDP 的 JWKS 公钥验签（验证签名与 issuer、audience），检查 exp 过期、iat 签发时间、nbf 生效时间。与 TLS 协同：TLS 保证传输加密（防窃听/中间人），JWT 签名保证内容完整性（防篡改），两者互补——TLS 管"在途"，JWT 管"内容"。ID token 不能通过明文传输，Bearer 头需配 HTTPS；Cookie 传递需 HttpOnly/Secure 防窃取。

ID token 的"传递"用 Authorization 头或 Cookie，"校验"用 JWKS 验签 + exp 过期。TLS 与 JWT 签名分别防窃听与篡改。

• 请求转发路径、Host 头、X-Forwarded-For
• 上游状态、超时、重试
• 日志关联（access/error/upstream）

反向代理/负载均衡 HTTP 排障关注：① 转发路径——确认请求经代理到达哪个上游，Host 头是否正确透传（影响虚拟主机），X-Forwarded-For/X-Real-IP 是否传递真实 IP；② 上游状态——用 $upstream_status、$upstream_addr 看上游响应与地址，502/504 对应上游故障/超时；③ 超时与重试——proxy_connect/read/send_timeout、proxy_next_upstream 重试；④ 日志关联——同时看 access log（$status、$upstream_status、$request_time）与 error log。用 curl -v 带自定义 Host 头与 -x 代理测试，抓包看转发后的请求头。排障核心是"确认请求是否转发、转发到哪、上游返回什么"。

代理排障核心是"转发路径 + 上游状态 + 日志关联"。Host 头与 X-Forwarded 决定转发正确性，$upstream_status 定位上游。