HTTP/3 and QUIC protocols, status of for Julia web clients or servers

HTTP/3 seems to be around the corner, already implemented in most web browsers (may be off by default), makes web browsing much faster. It’s based on QUIC protocal (which IS DONE), then UDP, not TCP of TCP/IP (so it’s going to be much less used overall soon).

For some code, e.g. clients (even Julia’s own Pkg [manager] in Base?), HTTP/3 and QUIC might be very important, as in if Julia doesn’t catch up to it will be slower. On the server side, you can e.g. use @essenciary’s Genie.jl (and/or Stipple.jl) to implement websites. Since Genie builds on already existing web servers, it seems only them need to/already do(?) support HTTP/3, so I’m not too worried. I believe Genie (and some other Julia software) may work as a full web server, if configured that way (non-default?) then not needing any non-Julia web server [code]. Then it would be slower, using HTTP/1.1, not even HTTP/2 (which Julia seemingly can skip implementing).

Franklin.jl (e.g. used for julialang.org) makes static web sites, so it’s immune, i.e. also defers to web servers software, that can/does implement HTTP/3.

(For clients), it’s unclear Julia needs Julia-only implementations of HTTP/3 or QUIC. It seems like a lot of work, and not worth it to do more than wrap already existing implementations. Not sure such a wrapper should be in Base (e.g. for Pkg, or the download function). I believe Julia already uses curl, and it has those protocols.

I thought already enabled in Chrome (and thus Brave, I used the instructions to enable there): https://developers.cloudflare.com/http3/tutorials/chrome/

https://curl.se/docs/http3.html

1 Like

Pkg uses Downloads which uses libcurl, so once curl supports HTTP/3 we will automatically be able to use it as well. Pkg servers will have to be upgraded to support HTTP/3 as well before it matters, but they use an nginx frontend, so that will also be doable. HTTP.jl is a separate, pure Julia implementation of the HTTP protocol, so that’s an entirely different story. Someone will have to implement HTTP/3 in the package if they want it to work.

Oh, I’ll note that it’s pretty unusual on the server side not to have something like nginx in front of the actual application server, so it may not matter if Genie or whatever else supports HTTP/3: it can just serve HTTP/1 or HTTP/2 and let nginx (or whatever other caching proxy goes in front of it) handle serving HTTP/3.

4 Likes

curl apparently has “experimental” support for HTTP/3 now, but only if you enable it at build time.

Note that one of the big selling points of HTTP/3 is to support multiplexed downloads of multiple files over a single UDP connection. To exploit this we will need to use the curl multi API, but it looks like we are already doing this?

(CURLPIPE_MULTIPLEX is enabled by default in curl ≥ 7.62 for use with HTTP/2, and presumably this will use HTTP/3 once it is available.)

See also the nginx HTTP/3 roadmap — looks like they have things well in hand.

2 Likes

Yes, we very much use the multi API. God do we use the multi API.

2 Likes

On Wikipedia: “On 6 June 2022, IETF standardized HTTP/3 as RFC 9114.”

Note it’s been used for much longer, by now 81% of desktop web browsers support it, so it’s really a good time to have full support in Julia.

https://curl.se/docs/http3.html

HTTP/3 and QUIC support in curl is considered EXPERIMENTAL until further notice. It needs to be enabled at build-time.

The docs may simply be outdated(?), would you know if it’s enabled at build-time?

It is not enabled at build time currently. I’d be ok with enabling it in the libcurl build but disabling it by default unless explicitly turned on for a request by passing the relevant options to libcurl. I really don’t feel like feel like being guinea pigs for experimental http/3 support. The benefits do not outweigh the potentially issues at this point.

1 Like