QUIC Is Not Quick Enough over Fast Internet

1. tailscale

   1 1,026 20,264 9.9 Go

   The easiest, most secure way to use WireGuard and 2FA.

   

   https://github.com/tailscale/tailscale/pull/2370 was a practical drive toward this, will not proceed on this path.

   much more approachable, boats has written about challenges integrating in rust: https://without.boats/tags/io-uring/

   in the most general form: you need a fairly "loose" memory model to integrate the "best" (performance wise) parts, and the "best" (ease of use/forward looking safety) way to integrate requires C library linkage. This is troublesome in most GC languages, and many managed runtimes. There's also the issue that uring being non-portable means that the things it suggests you must do (such as say pinning a buffer pool and making APIs like read not immediate caller allocates) requires a substantially separate API for this platform than for others, or at least substantial reworks over all the existing POSIX modeled APIs - thus back to what I said originally, we need a replacement for POSIX & BSD here, broadly applied.

2. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

3. monoio

   2 26 4,136 7.9 Rust

   Rust async runtime based on io-uring.

   

4. tokio-uring

   3 32 1,178 4.4 Rust

   An io_uring backed runtime for Rust

   

5. quic

   4 3 167 9.5 C

   In-kernel QUIC implementation with Userspace handshake (by lxin)

   

6. neqo

   5 13 1,883 9.7 Rust

   Neqo, the Mozilla Firefox implementation of QUIC in Rust

   

   Looks like Mozilla is currently working on implementing `sendmmsg` and `recvmmsg` use in neqo (Mozilla's QUIC implementation) [1].

   [1] https://github.com/mozilla/neqo/issues/1693

7. pcurl

   6 1 12 0.0 Shell

   

   > but as a user living very far from major datacenters on an unstable and frequently slow network, HTTP[23] have been the best thing since sliced bread. How it looks in practice is getting hundreds of megabits/s when network is under low load ...

   The surprise is that some users aren't able to access your site if you enable HTTP[23], and those that can will have worse latency on average.

   There's a trick that I use to download large "files" -- I use content-range and multiple parallel fetch() calls. Because of the fast (lower latency) start of HTTP1.1 this outperforms H2 when you can get away with it. People who don't want to use JavaScript can use https://github.com/brunoborges/pcurl or something like it.

   > https://man7.org/linux/man-pages/man2/recvmmsg.2.html

   Cool. I don't think it helps H3 because the other end will just block anyway (because it's Linux only and the other side probably isn't Linux), and it seems to be a little slower than recvmsg() when there's only a small amount of traffic so I'm pretty sure it's not going to help me, but I'll keep poking around at it...

Suggest a related project