[HN Gopher] LiteSpeed QUIC (LSQUIC) is an open-source implementa...
___________________________________________________________________
LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC
and HTTP/3
Author : ZnZirconium
Score : 57 points
Date : 2021-02-15 13:54 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| garblegarble wrote:
| I 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?
| Nokinside wrote:
| I don't know about open source developer case.
|
| If you develop commercial embedded software and need to be able
| to develop safety critical software there is no contest: C and
| Ada are the two best tools. Obviously you limit the coding to
| subset of C. MISRA C for example.
|
| You can buy commercial tools for C and Ada that do static
| analysis only your source-code way past anything that you get
| from other languages. You can prove the absence of run time
| errors. No divisions by zero, no sudden application termination
| etc.
|
| If you write safety critical code, you don't do dynamic memory
| allocation or unrestricted recursion anyway. The strengths that
| Rust has in memory allocation are irrelevant. Running out of
| memory or unlimited recursion are errors.
| rapsey wrote:
| There is zero reason for this to exist.
| [deleted]
| gostsamo wrote:
| Rust so far does not cover all architectures that C can reach.
| When the GCC implementation is ready, it might change, but not
| yet.
| jarym wrote:
| Well if you're an experienced C developer then yes it does.
| mhh__ wrote:
| Of course _my_ code has no bugs in it!
| garblegarble wrote:
| But lots of the vulnerable C code we have in the world today
| was written by very experienced C developers, so I don't know
| that's a particularly strong argument
| jarym wrote:
| You must remember, a LOT of C code was written back in a
| time when the Internet was a more trusting environment.
| Lots of developers didn't even comprehend that there'd be
| malicious actors.
|
| The point stands, if you're an experienced developer in one
| particular language then of course you will write in that
| language.
| tlamponi wrote:
| > You must remember, a LOT of C code was written back in
| a time when the Internet was a more trusting environment.
| Lots of developers didn't even comprehend that there'd be
| malicious actors.
|
| Hackers were a well established thing in the 80s, with
| its origin "phreaking" being even older than that, so no
| it wasn't a naive time when everybody though all just had
| the best interest possible in mind. Note also that not
| all crashes and breakages are intended and result of a
| malicious actor, or do you now argue that human entry
| errors just did not happen back then?
|
| Further, most code today does not come from that era but
| rather _originated_ from 90s to 2000s, with not even much
| of that being still around in that form.
|
| > The point stands, if you're an experienced developer in
| one particular language then of course you will write in
| that language.
|
| 1. That's the first time you make that point, the
| original reply of yours has no argument whatsoever, so
| nothing "still stands".
|
| 2. If you're really an experienced developer in one
| particular language then you are aware of its
| shortcomings and will also look closely for languages
| addressing them without adding other disadvantages.
| Everything else would be just short-sighted, which isn't
| really a good virtue to have as experienced developer.
|
| 3. How comes that new code written by highly experienced
| developers, e.g., working on OS kernels, with a massive
| testing effort still let slip through buffer overflows,
| use after free, integer underflows, etc. etc.?
| jeffbee wrote:
| It is essentially the same as arguing that after huffing
| paint for 30 years, one is qualified to huff more paint.
| [deleted]
| antoinealb wrote:
| 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.
| tlamponi wrote:
| 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
| feature of rust, at least the project itself provides and
| maintains the rust-bindgen crate[3][4].
|
| Having a bit bigger and slightly complex project like a
| backup server done in rust is such a relief compared to C or
| similar languages. Good speed, fast start up times like C but
| refactoring is really a breeze lots of safety is guaranteed
| and more time can be spent on fixing the semantic bugs.
|
| [0]:
| https://pbs.proxmox.com/docs/introduction.html#introduction
|
| [1]: https://git.proxmox.com/?p=proxmox-backup-
| qemu.git;a=summary
|
| [2]: https://git.proxmox.com/?p=pve-
| qemu.git;a=blob;f=debian/patc...
|
| [3]: https://github.com/rust-lang/rust-bindgen
|
| [4]: https://rust-lang.github.io/rust-bindgen/
| antoinealb wrote:
| Interesting, I stand corrected!
| rapsey wrote:
| The rust based cloudflare implementation has C APIs. Also C
| bindings to rust libs are not that painful at all to
| maintain.
| vlmutolo wrote:
| There are some good rust implementations of QUIC, too.
|
| Cloudflare: https://lib.rs/crates/quiche
|
| Mozilla: https://lib.rs/gh/mozilla/neqo/neqo-interop
| rapsey wrote:
| Also quinn: https://crates.io/crates/quinn
| jeffbee wrote:
| 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.
| mondainx wrote:
| 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.
| justin66 wrote:
| I bet almost all of the implementations of QUIC right now are
| open source.
| tyingq wrote:
| I believe they are calling it out as open source because their
| LiteSpeed web server has non open source editions.
| emteycz wrote:
| For sure, but why does it matter here?
| turminal wrote:
| What problem do QUIC and http/3 solve?
| ocdtrekkie wrote:
| It is a technology for adtech companies to circumvent operating
| system and network security features.
| tialaramex wrote:
| 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 PS100 per their advertisement.
| jeffbee wrote:
| 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.
| jayd16 wrote:
| 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.
| nicoburns wrote:
| 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.
| chrismorgan wrote:
| 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.
| daper wrote:
| 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).
___________________________________________________________________
(page generated 2021-02-15 23:01 UTC)