What do HTTP/3 and QUIC mean? My phone switched from WiFi to data and web pages kept getting busy. I checked the response and saw that my own blog was already using it

Last week,

was browsing the web on my phone. When I reached the entrance of my residential complex, the WiFi disconnected, automatically switched to the data, the page showed no white screen, and the video continued playing. Two years ago, this one would have been a break, spinning for at least two or three seconds. When I got back, I used curl to flip through the headers of several sites and found the secret hidden in a single line of small text—even my own small blog with double-digit visits was already using it.

the evidence: the route change note in the response head

curl type your own blog and respond with this line at the top:

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

this line of alt-svc, in plain language, is a note the server sends you along with the response: "This time you still came by the old TCP route. Next time, you can come directly to me via UDP on port 443. That route is called h3, which is faster." The ma=86400 (some sites write ma=3600) is the expiration date for the note. Expired notes are invalid, so you can pick up another one again.

I casually tested four companies, and the difference was bigger than I imagined:

two details worth mentioning. First having notes doesn't mean you're already using them: The first visit still obediently uses TCP, the browser stores notes properly— the same temper as web file cache, so you reuse them locally—only on the second try switching to UDP. Second, the old h3-Q046 code name on their own blog—QUIC—was drafted for five or six years before it was officially finalized. RFC 9000 (QUIC itself) was only officially adopted in May 2021, RFC 9114 (HTTP/3) joined in June 2022, each version had a code starting with Q, and the server note listed all the old and new protocols, so any browser could match the code. It looks chaotic, but it's actually because compatibility is handled with great care.

TCP three things that have been disliked

HTTP/2 has already done the task of cramming dozens of streams into a single connection, so why do we have to start over? The root of the problem lies with TCP itself—three things.

first piece, the team leader blocked . Dozens of HTTP/2 streams are squeezed into a TCP pipe, which only recognizes byte order: if the 1000th byte is lost, even if the 1001st byte arrives early, it must wait in the buffer for resupply. A dozen video clips, images, and interface data were all queued in the tubes; losing one bag would result in collective punishment. Before loading the video segments, I wrote an article about a ten-minute cut into 64 . All 64 requests were squeezed into one tube, and a single packet could hold a string.

second item, handshake layered . When I went out to pick up a webpage, I did one round of TCP handshakes three times, then another round of TLS handshakes HTTPS the locked , and TLS 1.3 also required a round of back-and-forth. Before the first request can go on, run two or three RTTs in vain. RTT is just a round-trip latency : cross-province access takes 30 milliseconds one-way, and two or three round-trips mean nearly 200 milliseconds wasted in waste, not even counting packet loss and restarts.

the third thing is the most dangerous: the network changes, the breaks. TCP relies on quadruple connections: your IP, your port, the other IP, and the other port. The phone switches from WiFi to data, the IP starts with 192.168 to become a public address assigned by the carrier, the quadruple is voided, the connection is invalidated, and the webpage is white-screened and reconnected. The phrase "cutting the net and breaking the thread" mentioned at the beginning treats this disease.

QUIC play: Use UDP to build your own building

QUIC's full suite is simple: since TCP can't be used (all network intermediate devices recognize it and can't be changed), then don't use it—use UDP local foundations and rebuild reliability, encryption, and multiplexing upstairs. previously discussed the difference between TCP and UDP I mentioned UDP forgetting after sending and guaranteeing nothing. QUIC precisely valued this simplicity: UDP's port chimney is thin, so intermediate devices don't mess with it, and you can decide how you design it.

three cases of TCP and three doses of QUIC. Streams are not connected to each stream: each stream manages its own order. If the video segment is lost, only block the video stream. Images and interfaces are still removed, and the queue leader blockage is removed from the root. Handshake in One: Transport layer handshake and TLS handshake are combined into one. The first visit completes a full RTT, and the visited site can still be 0-RTT—the first request is to leave with the handshake and run as soon as it lands.

best of all, connection migration. QUIC doesn't use IP to identify people; each connection sends a Connection ID, recognizing IDs rather than addresses. The phone's WiFi data cut, the IP changed, but the Connection ID didn't change. The server saw it was still the same ID, so I continued using the connection. No page white, no video overload—that's how it works. Of course, don't idealize: the speed of wireless signals itself can't be controlled; when it comes to speed, you still have to bandwidth, negotiation, and actual testing.

have to do with the home network

pour cold water on this: in a home where fiber is as stable as an old dog, HTTP/3 and HTTP/2 feel similar, and their advantages only become apparent on the faulty line. The higher the packet loss rate, the more obvious the benefits of non-concurrent traffic — when the 2.4G band is overwhelmed by neighbors' routers, when the subway signal fluctuates, or when only one elevator bar remains, QUIC's packet loss resistance truly pays off. Scrolling through the web on my commute is more stable than before—it's not just my imagination.

sometimes the opposite happens. UDP of being treated differently is real: some company and campus networks limit UDP traffic or simply cut it off. If browsers fail to connect via QUIC, they quietly revert to TCP on their own, leaving users unaffected—they just don't get access to the new protocol. If your home has protocol-based QoS rules, UDP is prioritized very low, and HTTP/3 might actually be a bit slower than HTTP/2—new technologies aren't always fast, so you have to expect that.

clarify two easily confused matters. First, the router doesn't need to be configured at all: this is an application layer matter; the browser and server can negotiate among themselves, and the router's optical modem at home doesn't need to be changed at all. Second, don't confuse it with encryption DNS—the two have similar approaches: both "sneak in through the existing channel of port 443," but that article covers DNS queries using 443 encryption, while this article is about the entire web transmission route being changed—two different matters.

three minutes to see if you're using it

Chrome or Edge, press F12 to switch to the Network panel, refresh the page, right-click the header of the request list table, and check out the Protocol column. If the column shows h3, it is already running HTTP/3; if it shows h2, it is still HTTP/2 old road. If you want to see more details, type chrome://net-internals/#quic in the address bar to see the current status of all QUIC connections.

Command Party to handle it all in one go: curl -sI website | grep -i alt-svc shows that the server has sent a note; if there is no output, it means it hasn't been activated yet. To be honest, on my own computer, this curl 7.88 didn't have HTTP/3 support when compiled, so it couldn't send QUIC requests—but the notes are enough. Whether the connection is open is another matter, but whether it's announced or not is obvious.

don't see H3, don't rush to feel you're losing out. All three situations are normal: First, the site isn't even open (more than half of the domestic sites are still stuck at HTTP/2 or even 1.1, and Baidu's response speed makes me anxious); second, it's your first visit and the note hasn't warmed up yet; third, your network environment has blocked UDP, your browser automatically downgraded, and all features are missing, but the speed discount is gone.

what situations should you think of it

the sequence is just a few steps: if you know there's a new path, open the protocol column to take a look, and stay calm when you see h3, or when you don't. As for slow web page loading, check DNS, check cache when needed, and when large files get disconnected, the next step is the honest Range mechanism. the article about Breakpoint Resume mentioned it—no matter how new the transmission protocol is, it can't withstand a fast-breaking network cable.