HTTP3

[ghost]

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

[superdolt]

when do u think this will be implemented / done?

[superdolt]

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

[ghost]

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.

[superdolt]

why not integrate with lsquic instead of developing your own?

[ghost]

Chrome 97 apparently has WebTransport..

[e3dio]

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

[ghost]

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

[ghost]

Are you sure? Link?

[ddevienne]

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.

[ghost]

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

[hiqsociety]

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

[ghost]

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).

[ghost]

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

[AmirHmZz]

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

[theseyan]

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)

[CMCDragonkai]

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?

[ghost]

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

[CMCDragonkai]

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.

[Zubnix]

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

[Bolderaysky]

+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

[uNetworkingAB]

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

[sjmueller]

With WebTransport coming to Safari iOS 18 and macOS this fall, accessibility could approach 85% of all users by end of 2024. Any update on if/when uWebSockets will add support?

[uNetworkingAB]

I cannot give you an exact update due to NDAs and other legal reasons, but I can say that the commercial interest in WebTransport in the fields I care about has been entirely missing. This is why development has stopped.

I don't want to be first to market just for the sake of being first to market - in fact, for WebSockets this library came 5 years after all the other implementations already had established their market shares.

If there is no proven commercial need for a feature to exist, it won't exist. As it would break the rules of free market capitalism.

If WebTransport becomes widespread and poorly implemented in common libraries, and where there is a significant commercial return on investment for implementing it better - I will do so.

Otherwise, I will not do so.

[sjmueller]

WebTransport already has a proven need in the game industry, as evidenced by most native mobile games which use udp. The web doesn’t have this option, except for WebRTC — which is a hacky solution for server authoritative games. WebTransport is the answer.

Makes sense that you’re driven by your sponsorships + areas of interest, but “no proven commercial need” is confusing. Unless gaming isn’t considered commercial?

[uNetworkingAB]

but “no proven commercial need” is confusing. Unless gaming isn’t considered commercial?

This is not what I said. You have illogically inverted what I said:

No commercial need => Won't exist is not the same as Does not exist => No commercial need

[uNetworkingAB]

Gaming can have a need for this, but the most important section still stands:

If WebTransport becomes widespread and poorly implemented in common libraries, and where there is a significant commercial return on investment for implementing it better - I will do so.

So to speak clearly: give me a significant chunk of money and I will do it. Else, I will not do it.

[sjmueller]

So to speak clearly: give me a significant chunk of money and I will do it. Else, I will not do it.

This makes sense to me, everyone should get a return on their time investment. Might be worthwhile to setup sponsorships in a way that allows the contributions to lean towards the features needed. Not sure if this is possible, but it would open up smaller contributors instead of relying on whales.