Sure, you can reimplement multiplexing on the application level, but it just makes more sense to do it on the transport level, so that people don't have to do it in JavaScript.

▲

groundzeros2015 17 hours ago | parent [-]

But unfortunately QUIC is a user space implementation over kernel UDP.

▲

skissane 4 hours ago | parent | next [-]

QUIC is being added to the Linux kernel: https://lwn.net/Articles/1029851/

▲

MrDarcy 16 hours ago | parent | prev | next [-]

How is that relevant? The user agent (browser) handles the transport.

▲

groundzeros2015 13 hours ago | parent [-]

That’s the problem. Browsers are billion dollar ventures and are operating systems unto themselves. So they like QUIC.

But you have to include giant libraries and kernel can’t see the traffic to better manage timing etc.

▲

Veserv 8 hours ago | parent [-]

Those are non-issues.

It only takes a few thousand lines (easily less than 10k even with zero dependencies and no standard library) to implement QUIC.

Kernel management of transport protocols has zero actual benefit for latency or throughput given proper network stack design. Neither does hardware offload except for crypto offload. Claimed differences are just due to poor network stack design and poor protocol implementation.

▲

groundzeros2015 an hour ago | parent [-]

Which library is easily less than 10k? Chromium QUIC is 250k+ according to ChatGPT

	▲	Veserv 17 minutes ago \| parent [-]
		Mine. I implemented it myself. Not fully standards compliant since I skipped some irrelevant details like bidirectional streams when I can just make a pair of unidirectional streams, but handles all of the core connection setup and transport logic.

▲

adzm 10 hours ago | parent | prev [-]

There is no real reason QUIC couldn't be implemented in the kernel though.