HTTP/3和QUIC是什么意思？手机从WiFi切到流量网页不断线，我翻响应头看到自家博客都用上了

上周拿着手机看网页，走到小区门口WiFi断了，自动切到流量，页面没白屏，视频接着播。搁两年前这一下必断，起码转圈两三秒。回来我用curl翻了翻几个站的响应头，发现秘密就藏在一行小字里——连我自己那个访问量两位数的小博客，都已经在用它了。

证据先看：响应头里那张换路条

curl敲自家博客，响应头里有这么一行：

alt-svc: quic=":443"; h3=":443"; h3-Q046=":443"; h3-Q043=":443"

这行alt-svc，人话就是服务器随响应塞给你的一张便条：「这趟还是走老路（TCP）来的，下回你可以直接走443端口的UDP来找我，那条路叫h3，更快」。后面的ma=86400（有的站写ma=3600）是便条保质期，过期的便条作废，重新走老路再领一张。

我顺手测了四家，差距比想象的大：

两个细节值得说。一是有便条不等于已经在用：第一次访问还是老老实实走TCP，浏览器把便条收好——跟网页文件缓存一个脾气，记在本地下回用——第二次才试着改走UDP。二是自家博客那串h3-Q046带代号的老名字——QUIC这协议在正式定稿前当了五六年草案，RFC 9000（QUIC本体）2021年5月才转正，RFC 9114（HTTP/3）2022年6月跟上，草案期各版本各有一个Q打头的代号，服务器便条上把新老全列一遍，谁家的浏览器都能对上暗号。看着乱，其实是兼容性做得厚道。

TCP被嫌弃的三件事

HTTP/2已经把一个连接里塞几十条流这事做完了，为什么还要推倒重来？病根在TCP自己身上，三件事。

第一件，队头阻塞。HTTP/2的几十条流挤在一根TCP管子里，TCP只认字节顺序：第1000字节丢了，第1001字节哪怕早到了也得在缓冲区里蹲着等补货。视频的十几片、图片、接口数据全在管子里排队，一个包丢了全员连坐。看视频的分片加载之前我写过一篇十分钟的片子被切成64片，那64个请求全挤一根管子，丢一个包能拖住一串。

第二件，握手层层叠。出门取个网页，TCP三次握手先来一轮，HTTPS那把锁的TLS握手再来一轮，TLS 1.3也要一个来回。第一个请求能上路之前，先空跑两三个RTT。RTT就是一个来回的时延，跨省访问单程30毫秒，两三个来回就是小两百毫秒白白烧掉，还没算丢包重来的。

第三件最要命，换网就断。TCP靠四元组认连接：你的IP、你的端口、对方IP、对方端口。手机从WiFi切到流量，IP从192.168开头变成运营商分的公网地址，四元组作废，连接跟着作废，网页白屏重连。开头说的「切网不断线」，治的就是这个病。

QUIC的玩法：拿UDP当地基自己盖楼

QUIC的全家桶思路很简单：既然TCP动不了（全网中间设备都认它，改不动），那就不动它——拿UDP当地基，自己在楼上把可靠性、加密、多路复用全重造一遍。之前讲TCP和UDP的区别时说过UDP发完就忘、什么也不保证，QUIC恰恰看中这份轻省：UDP的端口烟囱细，中间设备不折腾它，想怎么设计自己说了算。

对着TCP的三宗病，QUIC三副药。流与流之间不连坐：每条流自己管自己的顺序，视频那片丢了，只堵视频那条流，图片和接口照走不误，队头阻塞从根上拆掉。握手合一：传输层握手和TLS握手并成一次做，第一次访问一个RTT全办完，访问过的站还能0-RTT——第一个请求跟着握手一起出门，落地就跑。

最妙的是连接迁移。QUIC不拿IP认人，每个连接发一个Connection ID，认ID不认地址。手机WiFi切流量，IP变了，Connection ID没变，服务器一看还是这个ID，连接继续用。页面不白屏、视频不重载，就是这么来的。当然也别神化：无线信号本身的快慢它是管不了的，网速的账该算还是得按带宽、协商、实测那三本来。

跟家里的网络有什么关系

先泼盆冷水：家里光纤稳如老狗的场景，HTTP/3和HTTP/2体感差不多，它的优势要在差线路才放大。线路丢包率越高，流不连坐的好处越明显——2.4G频段被邻居家路由挤爆的时候、地铁上信号忽好忽坏的时候、电梯口只剩一格的时候，QUIC的抗丢包才真金白银地兑现。通勤路上刷网页比以前稳，不是错觉。

也有反着来的情况。UDP被区别对待是真实存在的：一些公司网、校园网对UDP流量限速或者直接掐掉，浏览器试QUIC连不上，会自己悄悄退回TCP，用户全程无感，只是享受不到新协议而已。家里如果有按协议分流的QoS规则，UDP的优先级被压得很低，HTTP/3反而可能比HTTP/2还慢一点——新技术不是处处快，这个心理预期得有。

两个容易搞混的事顺带掰清。一是路由器完全不用设置：这是应用层的事，浏览器和服务器自己商量，家里的路由器光猫一个字都不用改。二是别把它跟加密DNS搞混——俩货思路像，都是「借443端口的既有通道混进去」，但那篇讲的是DNS查询这个小事走443加密，本文讲的是整个网页传输换了条路，两码事。

三分钟看看自己在不在用

Chrome或Edge按F12，切到Network（网络）面板，刷新页面，在请求列表的表头上右键，把Protocol（协议）这一列勾出来。列里显示h3的就是已经跑在HTTP/3上，显示h2的还是HTTP/2老路。想看得更细，地址栏敲chrome://net-internals/#quic，能看到当前所有QUIC连接的状态。

命令行党一行搞定：curl -sI 网址 | grep -i alt-svc，有输出说明服务器发了便条，没输出就是还没开。说个诚实话，我自己电脑上这个curl 7.88编译时没带HTTP/3支持，发不了QUIC请求——但看便条足够了，路通不通另说，告不告示一目了然。

看不到h3别急着觉得吃亏，三种情况都正常：一是站压根没开（国内一大半站还停在HTTP/2甚至1.1，百度的响应头我看着都替它着急）；二是第一次访问，便条还没捂热；三是你的网络环境把UDP掐了，浏览器自动降级，功能一个不少，就是速度优惠没了。

什么情况该想起它

顺序上就这么几步：知道有这么条新路，会开Protocol列看一眼，看到h3不慌、看不到不恼。至于网页打开慢的账，该查DNS查DNS、该看缓存看缓存，大文件下载断了接着下靠的还是老实的Range机制，断点续传那篇讲过它——传输协议换得再新，也替你扛不住一根快断的网线。