Cloudflare: https://lib.rs/crates/quiche
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...
Once you get a microcontroller fast enough to handle Http3, you are talking about well known platforms (such as ARM, MIPS, x86). All of which are supported by Rust and LLVM.
https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
Not sure why one would choose this over QUICHE.
because it doesn't use threads? The library is intended to be used inside an eventloop. I think the same also applies for other typical transport libraries - e.g. HTTP/2 or TLS ones.
> Not sure why one would choose this over QUICHE.
I think there are certainly reasons. lsquic seems a lot more optimized than quiche and most other libraries out there. It makes use of some pretty clever datastructures (e.g. https://github.com/litespeedtech/lsquic/blob/master/src/libl...), and likely has a drastically lower rate of heap allocations than other implementations. Some of those things - like the use of intrusive linked lists - are unfortunately not that easy to apply in Rust.
I wouldn't be suprised if lsquic outperforms various other implementations - and if that's important to users it might be a reason to choose it (but as always: measure for your use-case).
I personally also think Rust is the way to go for system level code. But I wouldn't dismiss a project for not using Rust. And this one at least has a fair set of unit-tests, so it looks to me a lot more sane than a lot of other C based projects.
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.
And I love C.
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).
a) multiplexed tcp of http/2 is tcp-in-tcp with its well known problems. tcp over udp is not so problematic
b) as a udp protocol, congestion control is user space controlled. There's been some work on congestion control lately, but it's difficult to explore that for client to server transfers with tcp
c) path mtu detection in the presence of icmp blackholes is still a mess, in 2021; a udp based protocol puts control of packtization into userland.
I think that's fairly factual, so here's the opinion part.
a) tcp-in-tcp problems could have been solved by just using tcp. http/2 without multiplexing still gives some benefits (explicit server shutdown indications are a big one for me; binary vs text and compression may help with data length, but framing may not)
b) plugable congestion control would make more sense here to me. A certain company behind quic also controls a widely deployed operating system, and could make it happen; although adoption is slow, so it would take longer than switching to quic for their sites.
c) turning on path mtu blackhole detection by default on that same company's mobile operating system would help here as well. A certain other mobile OS without a diverse hardware marketplace quickly discovers and responds to lost big packets by sending smaller packets.
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.
QUIC requires one less RTT for connection establishment than TCP+TLS, which reduces the time to first byte on new connections.
Besides this QUIC allows the client to migrate between different IP addresses and networks. This means that e.g. a download on a phone doesn't get interrupted if the user moves from cellular to WiFi.
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.
