base-drafts
neqo
base-drafts | neqo | |
---|---|---|
9 | 12 | |
1,610 | 1,762 | |
0.2% | 0.5% | |
0.0 | 9.7 | |
15 days ago | 5 days ago | |
Shell | Rust | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
base-drafts
-
Multipath TCP for Linux
QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/
Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.
Server connection migration is explicitly forbidden by QUIC:
https://github.com/quicwg/base-drafts/pull/2031
- What does TCP/IP, OSI model even in means in job requirements
-
RFC 9114 – HTTP/3
https://github.com/quicwg/base-drafts/issues/253
TL;DR just like HTTP/2, we wanted to avoid friction in deploying these protocols. Having to rewrite URLs because of new schemes is pretty unpalatable, it has major impact. Instead, HTTP/3 can rely on other IETF-defined mechanisms like Alt-Svc (RFC 7838) and the more recent SVCB / HTTPS RR [1] DNS-based methods. The latter has been deployed on Cloudflare a while [2] and supported in Firefox. Other user agents have also expressed interest or intent to support it.
The net outcome is that developers can by and large focus on HTTP semantics, and let something a little further down the stack worry more about versions. Sometime devs will need to peek into that area, but not the majority.
[1] - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...
-
Announcing s2n-quic 1.0
After lots of hard work, we're excited to open-source [s2n-quic](https://github.com/aws/s2n-quic), a Rust implementation of the [IETF QUIC protocol](https://quicwg.org/). Feel free to ask any questions here in the comments or by [opening an issue](https://github.com/aws/s2n-quic/issues/new/choose). Thanks!
- The IETF QUIC Working Group
-
Crate to build network packets over UDP
Maybe check out laminar and quinn, which implement custom protocols on top of UDP (quinn implements QUIC), to get an idea on how to do things.
-
QUIC is now RFC 9000
IETF work is conducted mostly on email lists, hence the "many thousands of emails".
For some newer work like QUIC, GitHub is used to maintain a more to-the-minute shared view of the documents, and then again as mentioned in the text you quoted, GitHub Issues and PRs are used to manage the document, particularly by the most active participants.
https://github.com/quicwg/base-drafts - of course raising issues or PRs for them now won't do anything useful for you, because these RFCs were published. But you can see there were thousands of commits, one of the last being Martin Thompson's minor typographical tweaks summarised as "DOES IT NEVER END?!?".
- QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
neqo
- What's the status of Servo right now?
-
Any rust implementations of WebTransport ?
Neqo (Mozilla) and Quiche (Cloudflare) both implement QUIC and HTTP/3. I believe they are both developing an implementation of WebTransport.
- S2n-QUIC (Rust implementation of QUIC)
-
Announcing s2n-quic 1.0
neqo
-
Firefox – Fix parsing of content-length http3 header
Mozilla has a Rust QUIC implementation (one of three good ones in Rust) https://github.com/mozilla/neqo
I'm not sure why it's not used here.
-
Which QUIC crate should I use
As an code hobbyist I'm working on an opensource project where I would be happy to use QUIC. I did a little research and found Quinn and Quiche but also the Mozilla's implementation for which I couldn't find crate Neqo.
-
QUIC is now RFC 9000
Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully but I got illegal instruction segfault when executing cli.
https://github.com/h2o/quicly
There are a few Rust alternatives for QUIC. Anyone tried them and have comments.
https://github.com/cloudflare/quiche
https://github.com/quinn-rs/quinn
https://github.com/mozilla/neqo
-
QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
The reason is the need to have total flexibility (control). [0]
I reckon to make it as painless as possible to integrate it into Firefox. Also probably a tiny bit of not-invented-here syndrome too :)
[0] https://github.com/mozilla/neqo/issues/81
-
Experiments with h3 clients + Envoy
mozilla/neqo
What are some alternatives?
s2n-quic - An implementation of the IETF QUIC protocol
quiche - 🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
shadowsocks-rust - A Rust port of shadowsocks
udp2raw - A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment)
quinn - Async-friendly QUIC implementation in Rust
aiortc - WebRTC and ORTC implementation for Python using asyncio
openmptcprouter - OpenMPTCProuter is an open source solution to aggregate multiple internet connections using Multipath TCP (MPTCP) on OpenWrt
quicly - A modular QUIC stack designed primarily for H2O
hysteria - Hysteria is a powerful, lightning fast and censorship resistant proxy.