HTTP/3 support.

It would be nice to start planning support for HTTP/3. aioquic provides a sans-I/O API for HTTP/3 similar to h2 which would make such an integration possible.

The main hurdle is that the connection model is very different to HTTP/1.1 and HTTP/2 : we cannot simply establish a (reader, writer) pair over a TCP connection and pass this to the protocol layer. Between the HTTP/3 layer and the UDP transport, we have a QUIC layer which returns (datagram, addr) tuples indicating where datagrams need to be sent:

https://aioquic.readthedocs.io/en/latest/quic.html#aioquic.quic.connection.QuicConnection.datagrams_to_send

Note that the destination address may change during the connection’s lifetime, for example in response to receiving a PreferredAddress from the server during the TLS handshake.

In order to provide a first demonstration, @tomchristie suggested I write a dispatcher which makes use of aioquic’s HTTP/3 support. The code is still a bit rough, but it works:

https://github.com/aiortc/aioquic/blob/master/examples/httpx_client.py

This can be run as:

python examples/httpx_client.py https://cloudflare-quic.com/

See also https://github.com/encode/httpcore/issues/173

[unixfox]

Bump, still relevant.

[jlaine]

were your servers local or on the cloud handling hundreds, possibly thousands of requests per second sir? the post requests made is to a solana rpc.

perhaps I am doing something wrong.

The servers were distant, the results I mention are runs of aioquic’s interop suite against a variety of servers, and the acceptance criterion is that the time to download 5MB and 10MB files over HTTP/3 must no more than 10% over HTTP/1.1 or HTTP/2 (using httpx). I’m not sure the server’s load is relevant here as we are talking about client performance.

I don’t think you’re doing anything wrong, there are definitely some reports of initial connection time outliers using aioquic, which can kill the measured performance. I haven’t managed to debug these cases yet but I do believe they are fixable.