Repository navigation
Update on QUIC #57281
Description
Just wanted to give an update on the situation with the QUIC implementation.
At this point I'm quite glad that I didn't move forward on the implementation that ... um... quickly.
Some history:
QUIC depends directly on TLS 1.3 as a core part of the protocol. Years ago BoringSSL defined and implemented a set of additional APIs that exposed the functionality runtimes need to correctly implement TLS 1.3 for QUIC. Engineers at Akamai and Microsoft ported those APIs -- again, years ago -- to OpenSSL and had a PR that sat there ready to go for years that the OpenSSL project refused to land. Because of the indecision, Akamai and Microsoft decided to lightly fork OpenSSL with the BoringSSL QUIC APIs which, because it was backwards compatible with OpenSSL and because they were able to keep it up to date with OpenSSL, we decided to adopt. So for a while now we have been shipping Node.js with this alternative OpenSSL+quic.
However, a while back the OpenSSL project decided, for reasons that are still completely mysterious to me, that they wanted to have their entirely own implementation of the full QUIC protocol. So instead of just landing the APIs that already existed and that folks were already using, they decided to come up with an entirely new implementation from scratch. Unfortunate, up to now this implementation has not exposed any of the APIs we would actually need to be able to implement QUIC ourselves.
What this decision by the OpenSSL OMC has done is forced Akamai and Microsoft to fully fork OpenSSL into a new project called quictls which is no longer tracking OpenSSL development. They will attempt to remain as API compatible as possible for most things but the QUIC stuff is completely separate. What's worse is that quictls is currently not able to commit to the kinds of Long Term Support guarantees that we need for Node.js.
This means that we are being forced off of quictls and will need to move back to the mainline OpenSSL.
Within the past few weeks, OpenSSL has added a handful of APIs to OpenSSL 3.5 that allow other implementations to make use of the TLS 1.3 implementation .... openssl/openssl#26683 ... The problem, of course, is that OpenSSL 3.5 has not yet been released and it is not actually clear if what APIs they have exposed will actually work with the ngtcp2 library that we use to handle most of the QUIC semantics. My next task will be to try to verify that ngtcp2 can use these new, different, as yet unreleased APIs.
This puts the entire QUIC-in-Node.js project at risk. If we cannot make these APIs work then I'm not quite sure where to go from here beyond adandoning all of the work that has already been done. I will be investigating further over the next few weeks and hopefully will be able to make something work but we shall see.
One additional downside of this approach taken by OpenSSL is that it will make it impossible to backport the QUIC implementation to any Node.js versions that does not have at least OpenSSL version 3.5.
Side note: I'd actually like us to consider the possibility of switching entirely to BoringSSL and away from OpenSSL. While BoringSSL does not carry the same Long Term Support guarantees that OpenSSL does, and has a much more constrained set of algorithms/options -- meaning it would absolutely be a breaking change -- the model they follow echoes that approach that v8 takes and we've been able to deal with that just fine.
/cc @nodejs/quic @nodejs/tsc @nodejs/net @nodejs/crypto
Activity
splitice commentedon May 14, 2025
We also have a currently in development application using QUIC (using a publicly forked version of @jasnell's previous implementation). We primarily use the streaming APIs, only occasionally have we ever responded with Buffer / ArrayBuffer's (usually for error responses).
If implementing a nodejs compatible stream is too much, perhaps a
.writemethod to write but not end (respondTo without the end)? It would be nice to be able to stream to a QUIC stream without needing to write a C++ module.Honestly after all the defects we fixed the previous implementation works pretty damn well (at-least the APIs we use).
martenrichter commentedon May 17, 2025
In the meantime, I have looked at the source code. There you find TODOs of jasnell for a stream implementation, so I assume it is planned. (You pass a stream for the body. It is a bit interesting that it then would only use readablestreams)
bergmorten commentedon Jun 27, 2025
Any update when this will be available?
jasnell commentedon Jun 27, 2025
Unfortunately, no. We're stalled waiting on Openssl 3.5 to be landed, which is taking a bit of time since openssl decided to change their build sufficiently that much of it needs to be updated. There are a few folks working on that actively and I will continue this work once they've been successful.
trivikr commentedon Jun 27, 2025
The update to OpenSSL 3.5 is being done in PR #58100
DemiMarie commentedon Jun 27, 2025
What is the reason for using a bundled OpenSSL instead of the version provided by the OS package manager?
jasnell commentedon Jun 27, 2025
Bundling a vendored-in openssl means that we are better able to respond to vulnerabilities, updates, etc independently of the OS package managers, which often end up lagging behind or use support cycles that are on very different schedules than Node.js. We do support distributions that want to use their versions of openssl, but the vendored model allows much greater control, much greater stability, and reliability at the cost of a higher maintenance burden.
kapouer commentedon Jun 28, 2025
Also I cannot stress enough how nice is the ability for distributions to choose between bundled and shared library.
bergmorten commentedon Jun 29, 2025
I believe it's critical that Node.js still lacks support for QUIC and HTTP/3. Node.js is a framework designed for web communication, yet it does not support these well-established protocols—despite other languages having done so for quite some time.
While it’s possible to implement QUIC using C or Rust via N-API, those solutions come with their own challenges, especially when working within the Electron environment.
Given how widely Electron and Node.js are used together, it's also important that once QUIC support is added to Node.js, it is backported to earlier versions. This would allow Electron—which typically lags a few versions behind—to adopt it more easily.
I would consider this a high-priority task.
kibertoad commentedon Jun 29, 2025
@bergmorten Would you like to sponsor the effort or contribute some work to that end?
jasnell commentedon Jun 29, 2025
Well, I certainly would love to see it land sooner than later 😁 ... One step at a time.
richardlau commentedon Jun 30, 2025
I'm still planning on working on this, but have been distracted by my imminent move from Red Hat to IBM.
FTR we are already testing every PR to Node.js against a shared library OpenSSL 3.5 so that configuration works. The remaining work is to update the bundled version of OpenSSL in
deps/openssl-- that is taking a bit more time because we need to translate OpenSSL's configure/build into Node.js' gyp based build.targos commentedon Jun 30, 2025
Now that I think a bit more about this, given:
Does it mean that technically the work for QUIC can already be started independently of #58100 ?
jasnell commentedon Jun 30, 2025
Oh! I think I missed the fact that we were testing against shared 3.5. That might be enough to get me started again, tho I'm a bit reluctant to do so until it's for sure that we're not going to have a problem with the vendored in version -- I don't want to do a ton of work only to hit yet another unexpected roadblock.
trivikr commentedon Jul 28, 2025
PR to start re-enabling and working on quic with openssl 3.5 is up at #59249
trivikr commentedon Aug 5, 2025
As per comment in related PR #59249 (comment), the goal is to have QUIC ready to go in time for the 25.0.0 release in October 2025.
trivikr commentedon Aug 5, 2025
Should this issue be closed as there has been decision to implement QUIC on top of OpenSSL 3.5, and the work is in progress?
jasnell commentedon Aug 5, 2025
Yep, makes sense.
colocohen commentedon Sep 4, 2025
Hi everyone,
I’ve been experimenting with a Node.js implementation of QUIC as part of an independent project. It’s still a work in progress (not production-ready yet), but it already includes a self-contained TLS 1.3 implementation (no OpenSSL dependency), packet parsing, and stream management.
Here’s the repo if anyone is interested in following or providing feedback:
https://github.com/colocohen/quico
I thought it might be relevant to share here, since it shows that QUIC support in pure Node.js is feasible, and can evolve with community interest. Any thoughts or feedback are very welcome.
DemiMarie commentedon Sep 4, 2025
@colocohen I was not expecting TLS1.3 in ~2000 lines of JS!
Arka-98 commentedon Oct 19, 2025
Hey jasnell / trivikr, was QUIC released as part of the Nodejs 25 release?
trivikr commentedon Oct 19, 2025
Hi @Arka-98, QUIC is available with option
--experimental-quicin Node.js 25.xExample code for handshake can be viewed in https://github.com/nodejs/node/blob/main/test/parallel/test-quic-handshake.mjs
Some features are yet to be implemented. And it's going to take more time for QUIC to be tested by the community before it can get stable.
Node.js is volunteer driven project. Lead developer James and others are working on their free time.
If the support for QUIC in Node.js important for you, do help us get it to completion!
An easiest way to help is to use QUIC with option
--experimental-quicin Node.js 25.x+ and either submit or upvote feature requests!An example of a feature request from last week is to support for streaming posted at https://github.com/proxy/www.github.com/nodejs/node/issues/60234
You can also dive deep into the implementation, and post PRs yourself to add support!
For example, @martenrichter who submitted the above feature request to support streaming has opened a PR at https://github.com/proxy/www.github.com/nodejs/node/pull/60237
Other ways to contribute:
Arka-98 commentedon Oct 19, 2025
sure thanks trivikr
khteh commentedon Oct 21, 2025
How to test this without a proper http/3 server?
splitice commentedon Oct 22, 2025
@khteh the committed code can host a server and function as a client. Its transport layer.
I'll be running the same test suite on it that we previously built to experiment with the previous QUIC implementation once clienthello and streams (PR https://github.com/proxy/www.github.com/nodejs/node/issues/60234) merge.
I've been looking into committing clienthello (inc dynamic key/certificate) support, havent figured out the specifics of doing it yet though. Seems not particularly beginner friendly so I might focus elsewhere for now.
TyIsI commentedon Nov 16, 2025
Just asking out loud:
As far as the NodeJS implementation goes, is there a feature/implementation matrix of which spec features have been implemented and what hasn't, and what needs tests or testing?
Or is there a reference implementation test suite?
almaceleste commentedon Nov 21, 2025
@TyIsI, https://node.green/
TyIsI commentedon Nov 22, 2025
@almaceleste That doesn't include QUIC though?
almaceleste commentedon Nov 24, 2025
@TyIsI, apparently, this is because this feature is not included in the EcmaScript.
TyIsI commentedon Nov 24, 2025
@almaceleste that was my understanding as well.
That's why I figured I would ask if there is an implementation matrix specifically for QUIC.
I'll assume that there isn't one and see if I can get around to making one this week!
nbbeeken commentedon Nov 24, 2025
@TyIsI I think this testing matrix has what you may be looking for: #60122
mealeyst commentedon Nov 24, 2025
@jasnell & @martenrichter I'm not sure if it would be helpful, but I'd be happy to try and take a swing at some of those tests. Not sure if there is any in particular that might be helpful to grab.
TyIsI commentedon Nov 25, 2025
@nbbeeken yes, thank you!
I'll get read up and redirect any questions I have to there.