HTTP/3 使用 QUIC 作为传输层，通过 UDP 提供多路复用、连接迁移和内置 TLS 1.3。与 HTTP/2 基于 TCP 不同，代理缓存不能再简单地终止 TCP 连接后读取 HTTP 头部，而必须处理 UDP 数据报并解析 QUIC 帧。这意味着传统的 Apache 反向代理配置如果不做调整，即使后端已经支持 HTTP/3，客户端也无法通过代理建立 QUIC 连接。本文会从代理缓存的视角拆解 HTTP/3 落地步骤，并通过 kubeadm 部署的后端服务验证整套链路。
一、QUIC 如何改变代理缓存的连接模型
HTTP/3 的传输层不再是 TCP，而是基于 UDP 的 QUIC。QUIC 把 TLS 握手、流控、多路复用都整合进自身协议，一个 QUIC 连接内部可以承载多个 HTTP 请求，且各个流之间不会像 HTTP/2 over TCP 那样因为单个丢包导致整体队头阻塞。对代理缓存来说，最大的影响在于：转发前必须能够从 UDP 数据报中正确还原出 HTTP 头部，才能计算缓存键、判断是否命中缓存、存储响应体。
在实际部署中，代理还需要处理 HTTPS 证书终止。HTTP/3 强制使用 TLS 1.3，而 QUIC 使用 TLS 的早期数据机制来实现 0-RTT 握手。客户端首次连接后端时，后端会通过 Alt-Svc 响应头告知自己支持 HTTP/3。例如一个简单的响应头可能如下：
HTTP/1.1 200 OK Content-Type: text/html Alt-Svc: h3=":443"; ma=86400
代理缓存如果只监听 TCP 443，就只能处理 HTTP/2 和 HTTP/1.1，客户端无法通过 UDP 443 发起 QUIC 握手。因此代理节点必须同时打开 UDP 443 端口，并配置与 TCP 443 相同的证书。缓存命中逻辑也需要针对 QUIC 连接进行调整：同一个源站的不同连接可能来自不同的客户端 IP 或不同的 UDP 会话，缓存键应尽量基于 URL 和 Host 头，而不是底层连接五元组。
二、Apache Traffic Server 的 HTTP/3 代理缓存配置
Apache HTTP Server 本身对 HTTP/3 的支持仍比较有限，生产环境更常用 Apache Traffic Server（ATS）作为代理缓存节点，它原生支持 HTTP/3 和 QUIC。ATS 的核心配置文件包括 records.config、remap.config 以及证书配置目录。下面是一个简化示例，让 ATS 监听 UDP 443 并开启磁盘缓存：
# records.config 关键项 CONFIG proxy.config.http.server_ports STRING 8080 8080:ipv6 CONFIG proxy.config.http.cache.http INT 1 CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl CONFIG proxy.config.ssl.server.private_key.path STRING /etc/trafficserver/ssl CONFIG proxy.config.http.insert_response_via_str INT 0
remap.config 负责把外部请求映射到后端。这里假设 kubeadm 集群中的 Caddy 服务通过 DNS 名称 caddy-quic.default.svc.cluster.local 暴露 UDP 8443，并且 ATS 与 Kubernetes 集群使用相同的内部 DNS。缓存键插件可以避免无关查询参数干扰命中：
map https://ippipp.com https://caddy-quic.default.svc.cluster.local:8443 \ @plugin=cachekey.so @pparam=--include-headers=host
证书方面，ATS 需要读取 PEM 格式的完整证书链和私钥。证书路径必须可被 ATS 进程读取，否则 QUIC 握手会在 TLS 阶段失败。另外要注意，HTTP/3 的 UDP 监听与 TCP 监听使用同一证书时，客户端会优先尝试 QUIC，失败后回退到 TCP，因此 Alt-Svc 头只在 TCP 响应中下发即可。
三、kubeadm 部署 HTTP/3 后端并接入代理
使用 kubeadm 初始化集群后，可以先部署一个简单的 HTTP/3 后端。Caddy 是一个不错的选择，因为它默认启用 HTTP/3，并且配置非常简洁。为了减少 kube-proxy 对 UDP 会话的干扰，演示环境采用 hostNetwork 模式，让 Pod 直接使用宿主机网络监听 UDP 8443。实际生产环境如果必须使用 Service，建议设置 externalTrafficPolicy: Local 并配合支持 UDP 的负载均衡器。
apiVersion: apps/v1
kind: Deployment
metadata:
name: caddy
spec:
replicas: 1
selector:
matchLabels:
app: caddy
template:
metadata:
labels:
app: caddy
spec:
hostNetwork: true
containers:
- name: caddy
image: caddy:latest
ports:
- containerPort: 8443
protocol: UDP
args: ["caddy", "reverse-proxy", "--from", "https://ippipp.com:8443", "--to", "http://127.0.0.1:8080"]
上述 YAML 中，Caddy 监听宿主机的 UDP 8443，并把请求反向代理到本机 8080 端口。与 ATS 配置对应，ATS 将外部 443 流量映射到 caddy-quic.default.svc.cluster.local:8443。由于使用了 hostNetwork，Pod 的网络命名空间与宿主机相同，DNS 解析和 UDP 端口绑定都更直观。如果 ATS 与 Caddy 不在同一台机器，可以通过 NodePort 或负载均衡器暴露 8443。
同时可以创建一个标准 Service 对象，方便集群内部通过 DNS 访问 Caddy，而无需关心 Pod IP 变化：
apiVersion: v1
kind: Service
metadata:
name: caddy-quic
namespace: default
spec:
selector:
app: caddy
ports:
- name: quic
port: 8443
targetPort: 8443
protocol: UDP
这样 ATS 的 remap 规则中的后端地址 caddy-quic.default.svc.cluster.local 就能被集群 DNS 正确解析。对于 HTTPS 证书，需要确保证书覆盖 ippipp.com 以及可能使用的内部域名，避免客户端或 ATS 校验证书失败。
四、验证与故障排查
配置完成后，首先确认 ATS 的 UDP 443 端口处于监听状态。可以使用 ss -lunp | grep 443 查看，也可以直接抓包观察 QUIC 握手。如果客户端支持 HTTP/3，可以使用 curl 的 --http3 参数发起测试：
curl --http3 -I https://ippipp.com tcpdump -i eth0 udp port 443 -n
如果返回的响应头中包含 Alt-Svc: h3=":443" 且请求状态正常，说明代理已经成功终结 HTTP/3。缓存命中可以通过 ATS 的 stats 接口或访问日志确认。若连接超时，常见原因是防火墙屏蔽了 UDP 443，或者 ATS 的证书路径不正确。QUIC 握手对时间戳和 TLS 配置比较敏感，可以打开 ATS 的 debug 日志查看 QUIC handshake failed 相关提示。
另一个容易被忽略的问题是 UDP 缓冲区。默认的 Linux 内核缓冲区可能不足以承载大流量 QUIC 连接，导致高并发时出现丢包。可以临时调大缓冲区进行测试：
sysctl -w net.core.rmem_max=7500000 sysctl -w net.core.wmem_max=7500000
调大缓冲区后，QUIC 的吞吐量和握手成功率通常会有明显改善。如果使用 kube-proxy 的 Service 暴露 UDP，还需要关注 conntrack 对 UDP 流的超时设置，因为 QUIC 连接可能长时间空闲，过短的 conntrack 超时会导致连接被提前清理。
五、优化缓存命中与 UDP 稳定性
HTTP/3 代理缓存不能沿用 HTTP/1.1 时代基于连接复用的缓存判断方式。QUIC 连接可以在客户端 IP 变化后继续使用，因此缓存键应当尽量规范化，只保留 Host、路径、查询参数等与资源内容直接相关的字段。忽略无意义的跟踪参数可以显著提升缓存命中率。ATS 的 cachekey 插件支持多种规范化规则，例如去除特定查询参数、统一大小写等。
在 kubeadm 集群中，如果后端 Pod 数量较多，建议使用支持 UDP 的 Ingress Controller 或自定义负载均衡器，而不是单纯依赖 kube-proxy 的 NodePort。kube-proxy 对 UDP 的负载均衡粒度较粗，长连接情况下同一客户端可能始终被转发到同一个后端 Pod，无法充分利用多副本。对于需要连接迁移能力的场景，可以在代理层启用 QUIC 连接 ID 路由，但这需要额外中间件支持。
证书轮换和 0-RTT 安全也需要纳入规划。0-RTT 请求可能被重放，因此代理缓存对非幂等请求不应直接接受 0-RTT 数据。可以在 ATS 上配置只对 GET、HEAD 等安全方法启用早期数据，对 POST、PUT 等请求强制完整握手。这样既保留了 HTTP/3 的低延迟优势，又避免了缓存污染和重复提交问题。整体来看，Apache 代理缓存落地 HTTP/3 并不是简单改一个监听端口，而是需要从传输层、缓存策略、证书体系到 Kubernetes 网络模型做协同调整，才能在生产环境中稳定运行。
Apache代理缓存HTTP/3QUIC修改时间：2026-08-26 07:56:07