this post was submitted on 16 Apr 2026
31 points (100.0% liked)

Technology

42783 readers
435 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 4 years ago
MODERATORS
remington@beehaw.org
alyaza@beehaw.org
TheRtRevKaiser@beehaw.org
gyrfalcon@beehaw.org
rs5th@beehaw.org
coldredlight@beehaw.org
SemioticStandard@beehaw.org
31
QUIC will soon be as important as TCP (www.theregister.com)
submitted 1 week ago by Powderhorn@beehaw.org to c/technology@beehaw.org
6 comments fedilink hide all child comments
 

While Larry was producing most of the content for the "Request/Reponse" chapter for the next edition of our book, I took the lead on writing a section on QUIC, since I have closely followed its development.

Our expectation is that the role of QUIC will be about as important as that of TCP in the coming years, which means it warrants more substantial coverage than we provided in the last edition. So I dug a bit deeper into the bits and bytes of QUIC than I have previously, with a goal of bringing the coverage up to par with our TCP coverage. In addition to reading through the RFCs, I found lots of good information in the original QUIC design spec as well as some conference publications on the design and evaluation of SPDY (predecessor of HTTP/2) and QUIC.

One rather trivial thing that makes it harder for me to get to grips with QUIC is the fact that its RFCs (four of them, spanning hundreds of pages) lack pictures of the packet headers. The rationale for this, I believe, is that QUIC makes extensive use of fields that are variable in length and frequently not aligned on 32-bit boundaries, which makes packet header pictures a bit complicated and less tidy.

you are viewing a single comment's thread
view the rest of the comments
[–] NigelFrobisher@aussie.zone 3 points 1 week ago* (last edited 1 week ago) (2 children)

We’ll get this going shortly after the IPv6 rollout is complete. Also I skim read the article and still don’t know what QUIC is - I guess a new transport protocol?

[–] MaskedNybbles@piefed.social 4 points 1 week ago* (last edited 1 week ago) (1 children)

My fuzzy memory wants to say it uses/is based atop UDP, and makes it more reliable.

Just checked before posting, and that seems to be the case on a cursory glance of its wiki article: https://en.wikipedia.org/wiki/QUIC

[EDIT] Should have read the article first—and it does mention UDP by the end.

[–] HubertManne@piefed.social 3 points 1 week ago

yeah tcp has a lot of overhead. A lab I worked in made a thing they called reliable udp because they did a lot of collaborative vr type of things which came out of telephony I think. Kinda cool its been more advanced being rudp was really just retranmission of failed packets.