What problem do QUIC and http/3 solve?
LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
21–30 of 44 posts
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#22What problem do QUIC and http/3 solve?
By moving everything into the application, QUIC circumvents the extremely slow pace of innovation in operating systems' TCP stacks. Unlike userspace TCP, which requires elevated privileges such as CAP_NET_RAW on Linux, QUIC does not require any special privileges.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#23I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
I guess there is an audience for this stuff, among embedded systems developers or whatever, but after a brief look at the project it doesn't strike me as a project written with the care needed for C libraries. It is severely under-documented, for starters. For example, the word "thread" does not appear anywhere. Not sure why one would choose this over QUICHE.
I had an issue using quiche as a dependency via JNI and it was a blocker (I've moved on). The event would lose its reference and segfault; I was unable to track it to an actual cause in the debugger; lots of time wasted.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#24What problem do QUIC and http/3 solve?
It is a technology for adtech companies to circumvent operating system and network security features.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#25What problem do QUIC and http/3 solve?
Lots of resources are out there but essentially it expands http/2's multiplexed requests by building on top of UDP instead of TCP so it can ensure those requests don't block each other.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#26What problem do QUIC and http/3 solve?
Head of line blocking in http/2, and performance/reliability on dodgy mobile connections. It's definitely getting to the point of diminishing returns, but given how widely http is used it does seem to justify the effort.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#27Earlier quoted context omitted.
A good reason is that if you want interop with other languages, C is still the lingua franca of ABIs. All scripting languages have a way to interact with C through some form of FFI mechanism. I guess you could write it in Rust and maintain C bindings to it, but that would be painful.
Not really. We wrote a content-addressable-storage backup solution in rust[0], and one consumer is QEMU for doing backups of VMs, so we expose C bindings of our rust code[1] and use them in QEMU[2], effectively having rust async stuff handled by QEMU co-routine library. It wasn't exactly complicate or the like, required a bit of "plumbing code" but that's OK. Allowing to get (relatively) easy C bindings is a goal and…
Interesting, I stand corrected!
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#28What problem do QUIC and http/3 solve?
It is a technology for adtech companies to circumvent operating system and network security features.
If you've got enough cynicism to decide the only beneficiaries of QUIC are just "adtech companies" then I suggest saving a little of that cycnicism to put scare quotes around that word "security" in the second half of your sentence.
If you have effective security neither TLS 1.3 nor QUIC change anything in that regard. But they probably do change things for you. This means you did not have effective security.
Those making appliances or software to deliver "security" would very much like you to blame the designers of QUIC or TLS 1.3 for the fact that their products are ineffective. It is as if the Carbolic Smoke Ball Company had tried to blame doctors for diagnosing Carlill with Influenza rather than accepting that, in fact, Carbolic Smoke Balls don't work and so they owe her £100 per their advertisement.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#29What problem do QUIC and http/3 solve?
Head of line blocking in http/2, and performance/reliability on dodgy mobile connections. It's definitely getting to the point of diminishing returns, but given how widely http is used it does seem to justify the effort.
TCP HOLB is hardly diminishing returns; it’s the defining way in which HTTP/2 is not uniformly superior to HTTP/1.1—because of it, for a meaningful fraction of users, single-connection HTTP/2 behaves visibly worse than its primary competition, up-to-six-connection HTTP/1.1. (Lack of WebSockets support used to be another point, but that got fixed a year or two back.)
Some of the other benefits of HTTP/3 over HTTP/2, like the bypassing of TCP’s outmoded congestion control, are definitely more like diminishing returns.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#30What problem do QUIC and http/3 solve?
The way I look at the major improvements in the two recent HTTP versions is:
HTTP/2 was needed to better utilize the bandwidth by keeping the TCP connection busy without silence period. That means instead of "request - RTT delay - response - RTT delay - request - RTT delay- response ..." we have "request - request - request - response - response - response ..." without pauses between responses. These pauses in HTTP/1.1 cause the congestion windows drop to initial value and slow start after each response. For HTTP/1.1 the workaround was to establish multiple TCP connections to fetch resources in parallel. This + using multiple domains for assets was best practice with HTTP/1.1 and is not needed (or even discouraged) with HTTP/2.
The above change has a drawback: for links with high latency and lower reliability a single packet loss is causing this whole pipline to stall. The cause is how TCP retransmission + congestion control works. This is in contrast to multiple HTTP/1.1 connections where just single connection would stall and take time to recover to full speed. This has bigger impact on performance in wireless connections and content like live video streaming so something that the world move to.
To fix that HTTP/2 moves congestion control to upper layer that understand what is transmitted. Loss of single packet no longer causes the whole pipeline stall, it affects only the resource for which the loss occurred.
This all is needed especially in mobile networks. In older times the a good CDN was used to put content close to the user (or at least terminate the TCP connection close to the user) lowering the round trip time, TLS handshake time. With mobile connections becoming more popular this doesn't work because the big delay is in the "last mile" - in mobile link. You just can't move the CDN's server closer to cut this latency.
Of course there are also other improvements like faster connection establishment (with TLS).