HTTP3

As a prerequisite to WebTransport (over HTTP3) we need to support HTTP3. This was not initially a plan but since we do want to support the benefits of QUIC we need this. Lsquic has been benchmarked with great results (just as good as uSockets with TLS) which is a great indication of quality.

As a first step, the most basic and simple HTTP3 req/res needs to be supported so that a full benchmark can be done. Minimal or no API changes should be needed

when do u think this will be implemented / done?

by the way, is this also going to be the fastest http3 in the world?

It doesn't have to be, it just needs to be "significantly" faster than Node.js. And that is what I'm waiting for, they rely on OpenSSL 3.1 which is not released or planned yet, so I cannot really benchmark a full solution yet. I do not want to build something that has no motivation for existing, so it has to be significantly faster than Node.js. Luckily it seems that is the case for QUIC at least, so should be true for HTTP3 also. But it relies on lsquic.

why not integrate with lsquic instead of developing your own?

Chrome 97 apparently has WebTransport..

The problem is there are no servers with QUIC/WebTransport or nothing easy to use, this library needs to get that going

Just waiting for it to be standardized https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3

Are you sure? Link?

Hi Alex. Just read in your Capitalism issue that you are hard at work on WebTransport over HTTP/3. Can you share what the client will be for testing? And whether you are considering adding your own client, for testing, if existing clients are lacking? Just curious.

I'm testing with all clients I can find - curl, quiche, lsquic, Firefox, Chrome

these benchmark may help: https://interop.seemann.io/

Here are some tentative perf. numbers:

• For reference, the following Node.js built-in non-SSL server does 16k req/sec on this machine:

const http = require('http');

const requestListener = function (req, res) {
  res.writeHead(200);
  res.end('Hello, World!');
}

const server = http.createServer(requestListener);
server.listen(8080);

• Same machine gets 200k SSL minimal req/seq with uSockets (nothing new here; faked http1 server without parser or formatter)
• For proper HTTP3 I currently get 84k req/sec if I use multiple QUIC connections but only one stream (this number is clearly better than anything Node.js but still way worse than the 200k)
• However, if we open two streams per connection we get 142k req/sec
• If we open 4 streams we get 250k req/sec (so at 4 streams we are above 200k)
• If we open 8 streams we get 345k req/sec
• If we open 16 streams per HTTP3 connection we get 475k req/sec (which is a bit ridiculous)

This is a bit apples-oranges comparison since HTTP3 streams are the equivalence to HTTP1 pipelining (which is considered broken and disabled in HTTP1 by all major browsers).

About 800k req/sec single-thread on M1 MacBook Air. That's with 16 streams and 10 connections.

HTTP/3 is now proposed as a standard by RFC. Congratulations to the web community :D

Hi Alex, any updates on the progress of supporting WebTransports? I feel like there's huge potential in exposing a WebSocket like interface through a QUIC server and using WebTransports to communicate with it (as an alternative to Websockets in supported browsers)

If you add support for quic, then does that mean this library would provide node devs a quic library even though node core disabled quic?

Yes uWS does not rely on anything nodejs, all it relies on is Google V8 for integration

That'd be cool, but I'd need access to quic directly, if you do add support, it would be good to also expose any quic functionality without using websockets or HTTP3.

Any plans on having websocket run over http3? https://datatracker.ietf.org/doc/rfc9220/

+1 for http3 support. While it isn't really as straightforward and easy to implement as http1.1, this would really improve performance and add a lot of new use cases for uwebsockets, where now http1.1 itself is performance/ bottleneck. Also, considering extensions, such as websockets over http3, it would make sense. Not really sure if this is already standard, but no doubt it will be really cool

Yeah we are here for the long run and will eventually come back to HTTP3 at some point. No updates to post right now.