Why QUIC might kill TCP for good | Hacker News Reader

Why QUIC might kill TCP for good

3 pointsjosephbenedict6 comments

Cloudflare just announced the first media CDN built entirely on QUIC (moq.dev), and it feels like one of those quiet inflection points where the old guard (TCP) finally starts looking obsolete.

QUIC + HTTP/3 has been “the future” for a while, but until now most deployments were edge cases or just browsers quietly switching protocols under the hood. Media delivery is different, it stresses latency, congestion control, retransmissions, and real-time resilience in ways that show off QUIC’s strengths.

A few things that make me think TCP’s days are numbered (at least for large-scale internet workloads):

QUIC’s user-space implementation means iteration speed that TCP will never match.

Built-in multiplexing avoids the classic “TCP head-of-line blocking” problem.

Encryption as the baseline, not the addon.

Congestion control that works better for streaming and real-time traffic.

If the economics work out for Cloudflare and others, media over QUIC could be the wedge that normalizes QUIC everywhere — not just browsers, but infra, APIs, and even enterprise backends.

Curious if anyone here is already seeing QUIC make TCP irrelevant in production workloads (beyond web browsers)? Or is TCP going to stick around longer than we think, the way IPv4 has?

Regardless of the adoption rate of QUIC, TCP is going to stick around for many, many years. The existing installed base requiring it is just too enormous.

But I wonder... if QUIC does end up entirely supplanting TCP, that means it's an entirely different networking scheme. We'd no longer be using TCP/IP at all, but something else. QUIC/IP?

Regardless of the adoption rate of QUIC, TCP is going to stick around for many, many years.

I agree with this and would add that the HN crowd is very HTTP browser and API centric. There are hundreds of thousands of applications that will be using TCP and not be updated until the internet is shut off. This is especially true for B2B applications. Just getting them to update cipher protocols is like pulling teeth, each time. There are an amazing number of "business critical" applications that are running ancient libraries, protocols, etc...

TCP and UDP will never go away but browsers and some API libraries may stop using TCP. More likely additional Layer 7 protocols may get added to TCP and UDP and people will use what works best for their application needs.

>>There are an amazing number of "business critical" applications that are running ancient libraries, protocols, etc.

Do you know of any examples of these "walking wounded" applications? Can we bring some attention to reduce their foot print.

I would have to get former coworkers to dig through Jira. I would not bother. These are all proprietary applications supported by dead or dying companies. Most of the original developers are retired or no longer with us. The apps get picked up by acquiring companies rinse and repeat when they chapter 11.

More useful is finding newer, supported and open source applications that can replace their functionality but that's a whole other topic around prioritization and people paralyzed by fear of change due to the amounts of money flowing through their unsupported applications.

Isnt the main disadvatage of TCP over UDP, overhead, present only in unreliable connections? Afaik, when there is no loss or congestion, TCPs roundtrip or ordering does not cause significant delay.

So how relevant are the benefits you listed (faster development, multiplexing, congestion control) for residental end points? I am sceptical.

Bench wireguard (kernel not userland) against an ssh tunnel and you’ll know…

Reply on news.ycombinator.com