Alt-Svc是HTTP协议中一个容易被忽视却非常关键的响应头，它的作用是告诉客户端：除了当前这个连接，我还在别的端口上提供基于其他协议的服务。对CDN厂商来说，这个头几乎是启用HTTP/3的标配，因为浏览器从HTTP/2切换到HTTP/3不可能靠服务端单方面推送，必须有一个广播机制让客户端知道升级入口在哪里，而Alt-Svc正是承担这个角色的信使。它与TLS握手阶段的ALPN扩展配合，构成了一套完整的协议协商闭环。
Alt-Svc头的语法结构与工作原理
Alt-Svc头的基本格式为Alt-Svc: clear或Alt-Svc: <protocol-id>=<host>:<port>; ma=<seconds>。其中protocol-id是ALPN协议标识符，常见的有h2（HTTP/2 over TLS）、h3（HTTP/3 over QUIC）等；host部分可以省略，省略时表示备选服务就在当前域名上；ma参数指定最大存活时间，单位是秒，客户端会在这个时间内缓存该信息。
一个典型的CDN响应头如下：
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=3600
这条头信息广播了两个备选服务：端口443上支持标准HTTP/3，缓存有效期为24小时；同时还支持HTTP/3的第29号草案版本，有效期1小时。客户端收到后会并行尝试当前连接与备选连接，并在验证备选服务可用后完成切换。切换成功后，后续请求就会走QUIC通道，而原始连接在空闲后自然关闭。
还有一种特殊写法Alt-Svc: clear，它用于显式清除客户端之前缓存的所有备选服务记录，常用于服务方主动下线某协议的场景。需要注意的是，Alt-Svc只能在安全上下文（HTTPS）中生效，HTTP明文响应中的Alt-Svc会被浏览器直接忽略，这是安全模型的硬性要求，因为明文环境下的广播内容可被中间人篡改，诱导客户端连接到攻击者控制的服务器。
ALPN：TLS握手中的协议识别机制
Alt-Svc只是广播了有哪些备选协议，真正完成协议选择的是ALPN（Application-Layer Protocol Negotiation）。它是一个TLS扩展，工作在握手阶段。客户端在ClientHello中携带自己支持的协议列表，按优先级排序；服务端从中挑选一个自己支持的，并在ServerHello中返回选中的协议。这样双方在TLS连接建立的同时就敲定了应用层协议，避免了握手完成后再用额外一轮往返去协商的开销。
以Nginx为例，启用ALPN需要OpenSSL 1.0.2以上版本，配置非常简单：
# Nginx中同时声明h2和http/1.1，按顺序表示优先级 listen 443 ssl http2; ssl_protocols TLSv1.2 TLSv1.3; # OpenSSL 1.1.1起原生支持ALPN，无需额外模块 # 可以用openssl命令验证ALPN是否生效 openssl s_client -connect ippipp.com:443 -alpn h2 < /dev/null 2>/dev/null | grep ALPN
QUIC的情况稍有不同。HTTP/3基于QUIC传输，QUIC将TLS 1.3握手直接内嵌在自己的加密层中，ALPN协商也随之内联。客户端发起QUIC连接时，初始包中的CRYPTO帧就携带了TLS ClientHello，其中包含alpn扩展值为h3。这就是为什么Alt-Svc广播h3后，客户端能够直接建立QUIC连接并立即使用HTTP/3语义，中间不存在传统TCP场景下的协议探测过程。
CDN场景下的完整升级流程
用户首次访问CDN域名时，DNS解析到边缘节点，客户端发起TCP加TLS连接，通过ALPN协商出h2，正常完成HTTP/2请求。边缘节点在响应中附带Alt-Svc头广播QUIC服务。浏览器将这条记录写入Alt-Svc缓存，与HSTS缓存类似，它独立于HTTP缓存存在。
下一次请求到来时，浏览器会发起竞速：一边在原TCP连接上发请求，一边尝试向广播的UDP端口发起QUIC连接。如果QUIC连接率先建立成功，后续流量就迁移到QUIC上。这个过程对页面渲染完全透明，即使QUIC握手失败，TCP通路也毫发无损，这正是Alt-Svc设计的精妙之处——升级失败没有任何代价。
在CDN配置层面，需要注意ma值的权衡。设置过长，比如30天，一旦服务端紧急下线QUIC端口，客户端会在很长时间内持续尝试失败连接；设置过短，比如60秒，又会造成频繁的重复验证。业界常见做法是86400秒起步，同时在服务变更窗口期主动下发Alt-Svc: clear来强制刷新客户端状态。另一个容易踩的坑是CDN回源配置：边缘节点到源站的链路是否启用HTTP/3与客户端侧无关，两者独立配置，不要因为客户端已升级就忽略回源优化。
验证与排障实战
验证Alt-Svc是否生效，最直接的方式是Chrome地址栏输入chrome://net-export/录制网络日志，或者使用curl的--alt-svc参数：
# curl会将Alt-Svc记录写入本地文件并在下次请求时尝试备选协议 curl -v --alt-svc altsvc.cache https://www.ipipp.com/ -o /dev/null cat altsvc.cache # 输出类似：h3 www.ipipp.com 443 # 再次请求，curl会自动尝试QUIC通道（需curl 7.66+且编译时启用HTTP/3）
排障时常见的问题有三种。一是Alt-Svc头存在但客户端始终不升级，首先检查响应是否走了HTTPS，其次确认UDP 443端口在客户端网络中未被防火墙拦截，企业内网封锁UDP是QUIC普及的最大障碍。二是备选服务返回证书不匹配，Alt-Svc指定的host必须持有覆盖原请求域名的证书，否则验证失败且该备选记录会被作废。三是配置了h3-29之类的草案版本但客户端只认正式版h3，各浏览器对草案支持参差不齐，生产环境建议同时广播正式标识与主流草案标识，并观察监控数据逐步收敛。
总体来看，Alt-Svc与ALPN的组合是HTTP协议族平滑演进的基石。它把协议升级的决定权交给了客户端，把升级通道的知情权交给了服务端，双方通过一次广播、一次协商就完成了从TCP到QUIC的无感迁移。理解这套机制，不仅有助于排查CDN性能问题，也为后续跟进HTTP/3的规模化落地打下了基础。