quic: complete the QUIC/HTTP3 implementation

[jasnell]

This PR is necessarily quite large, and I apologize for that.

This gets the QUIC and HTTP/3 implementations to a functional state with a complete suite of tests and docs.

The PR contains the necessary fixes and improvements in both the C++ and JavaScript layers, along with 214 individual test files.

What's working:

• QUIC Server and Client
• HTTP/3 Server and Client (confirmed interop with Chrome's QUIC client)
• Diagnostics Channels and Performance API integration

The implementation is still gated behind the --experimental-quic compile flag.

$ ./configure --ninja --experimental-quic
$ make
$ ./node --experimental-quic

Which means this can safely land in without impacting CI.

I will need to thoroughly test on all of the Node.js supported platforms so I will be asking the @nodejs/build team if we can get a CI job set up to support an experimental build that sets the --experimental-quic compilation flag.

How to review:

The PR is divided in to four distinct commits. The first focuses entirely on the C++ layer. If you're familiar with Node.js C++ code, this is where I would start. The bulk of the implementation is here. The organization of the code is straightforward and there are tons of code comments to act as sign posts. The second commits focuses entirely on the JS layer. This essentially acts as a thin layer on top of the C++ bits. The third commit are the doc updates. If you need a high level overview of the module before digging into details, start with this commit. The fourth is all the tests.

In this PR, the tests alone account for 15,831 LOC in 214 files.

The total actual implementation is around 15,831 LOC across C++ and JS (including code comments).

The docs are around 3,179 LOC.

I fully understand that reviewing this is a giant task. Understand that writing it has been a giant task. Had I split this up into a bunch of individual PRs the review process would not have been any easier and would have taken 10 times longer. There's no easy way to get a substystem like this correctly implemented.

I'm happy to jump on calls to walk people through this. I'm happy to explain every part of it as necessary. I'm happy to review potential design changes to the API.

As a side note: the updated implementation makes use of the new experimental stream/iter API as the stream interface.

And yes, given the sheer size of this, I used Opencode/Opus to help get things finished. I read and reviewed every LOC modified.

Signed-off-by: James M Snell jasnell@gmail.com
Assisted-by: Opencode:Opus 4.6

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/net
• @nodejs/quic
• @nodejs/security-wg

[Qard]

Got through a bit of it, but still lots more to review. Seems generally reasonable so far, though I haven't got through all the implementation code yet.

[Qard]

Is this a return of head-of-line blocking? Is that a requirement of http/3 somewhere? Do we have any mechanisms of mitigating the blocking problems or at least containing them as much as possible?

[jasnell]

https://datatracker.ietf.org/doc/html/rfc9218

The idea is that HOL blocking is actually correct when the client is unable to incrementally process resources of the same priority. This provides flexibility to mark priorities stream-by-stream rather than imposing HOL on everything regardless of priority.

[jasnell]

For http3, the implementation currently relies on nghttp3's default internal prioritization to determine which stream's data to send at any given time. It will require experimentation to determine how well it performs when interacting with node.js applications using streaming data sources.

[Qard]

What nesting is there to limit? Promises would flatten themselves automatically, so is there something else those interact with that could allow more than one level of nesting here? 🤔