HTTP/3 support.

[jlaine]

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 encode/httpcore#173

[jlaine]

I'm not too sure how to move this forward. Ideally I'd like to have a WIP pull request which we can rebase / amend until we're happy with the result. However I haven't really got a feel for how the code should integrate with httpx's connection management. Any hints on how to approach this problem?

[sethmlarson]

We'll need to add UDP support to our backend interface, that's definitely step 1.

After that we need to see how we want to implement client storage so we can remember things like Alt-Svc headers between requests.

Next would be landing an HTTP/3 specifier along with the H3Connection dispatcher. I'm not sure how compatible aioquic is with an SSLContext object (probably not at all?) so that will take some tweaking. And because HTTP/3 is known to not work in some routes we'll have to implement "fallback to TCP and forget the H3 alt svc" on the HTTPConnection object somehow.

Anything I'm missing @encode/httpx-maintainers?

[florimondmanca]

I don't know enough about HTTP/3 to tell (for example, I'm not sure what the differences between QUIC and HTTP/3 and the associated aioquic APIs are?), but the approach highlighted by @sethmlarson sounds sensible to me.

One thing I'm sure of is that we'll need to chunk this into multiple PRs, otherwise we risk ending up with a 1000 LOC+ PR that's a pain for everyone to look at. That way we can more easily track progress too.

We'll need to add UDP support to our backend interface, that's definitely step 1.

Yup, and UDP support is definitely going to be a big chunk.

HTTPX is currently very much coupled to TCP. In particular, right now a given HTTPConnection doesn't know about other connections, but from what you've said it seems like a QUIC "connection" needs to know about the surrounding connections to do packet routing (though it might be a defining property of UDP?), correct? Anyway, there'll be some refactoring needed before supporting UDP to clarify what is TCP-specific and what is not.

After that we need to see how we want to implement client storage so we can remember things like Alt-Svc headers between requests.

I think this should be an improvement over a basic design, right? (Under the hypothesis that remembering Alt-Svc headers will only allow us to skip the protocol switching phase of establishing an HTTP/3 connection.)

So, in terms of planning, I tried to think about the various steps in a bit more detail. I could see something like:

1. Rename BaseStream / Stream / ConcurrencyBackend.connect() to BaseTCPStream / TCPStream / ConcurrencyBackend.connect_tcp().
2. Add UDP support. This will most likely include building an UDP version of TCPStream and the associated methods on ConcurrencyBackend. At this point, the resulting updated ConcurrencyBackend (with an asyncio implementation) can be unit-tested against a very basic asyncio UDP server.
3. Add httpx.dispatch.http3.HTTP3Connection, an HTTP/3 implementation via aioquic. To reduce the scope of this step, we can set some constraints:
   • HTTPConnection.connect() should try to connect via HTTP/3 and create a UDPStream / H3Connection if and only if HTTP/3 is one of the given http_versions (e.g. Client(http_versions=["HTTP/3"]). This way, we don't need to think about Alt-Svc and the switch between TCP and UDP yet.
   • All QUIC connections can be stored on H3Connection directly (similar to how we have one h11.H1Connection on our H1Connection class), without thinking about sharing those connections yet (provided we need to share those at all?).
4. Add Alt-Svc support: always connect via TCP first, and only if Alt-Svc is received then establish a newH3Connection. (Will this require to modify HTTP11Connection and HTTP2Connection so that they are able to process Alt-Svc header in the response? Is raising an exception in HTTP11Connection.send() and HTTP2Connection.send() and catching it in Connection.send() a sensible enough way of signalling we should reconnect via UDP-HTTP/3?)
5. Optimize connection making by remembering Alt-Svc headers.
6. Implement sharing of QUIC connections between HTTPConnections — if relevant?

---

Some resources I've come across:

• HTTP/3 Explained: https://http3-explained.haxx.se/en/
• asyncio UDP client example: UDP Echo Client
• Trio UDP discussion w/ usage hints: What about UDP ? python-trio/trio#537
• Hypercorn initial implementation: https://gitlab.com/pgjones/hypercorn/commit/7c1f519fe117f3fbcc6a62fcccdae2e8dfe0b61a

[sethmlarson]

Lots of great info @florimondmanca!! 🎉

I'm going to chime in here again at the idea of using AnyIO and adding our stream interface to that?

[florimondmanca]

I'm going to chime in here again at the idea of using AnyIO and adding our stream interface to that?

As in, using AnyIO (see #296) to provide an ConcurrencyBackend.connect_udp() implementation for all backends on top of their UDP sockets API? I'm not against the idea but it might be a bit too much for this particular issue. It could be a preliminary step but we haven't decided yet on whether we should switch over to AnyIO.

Edit: also, since AnyIO mandates the same "strict context management everywhere" approach than Trio, it's highly probable we'd need to refactor some internals to comply with that requirement. One item in particular is the Stream interface, which trio/AnyIO primarily expose as a context manager, although it's possible to .aclose() manually.

[jlaine]

HTTPX is currently very much coupled to TCP. In particular, right now a given HTTPConnection doesn't know about other connections, but from what you've said it seems like a QUIC "connection" needs to know about the surrounding connections to do packet routing (though it might be a defining property of UDP?), correct? Anyway, there'll be some refactoring needed before supporting UDP to clarify what is TCP-specific and what is not.

I don't see why the different connections should have any kind of coupling. The most straightforward approach is going to be opening a distinct UDP socket for every QUIC/HTTP3 connection so there will be a one-to-one mapping between socket and QUIC/HTTP3 connection.

At a high level, an HTTP3 connection is going to be very similar to an HTTP2 connection: you can run any number of requests on top of your connection.

I think this should be an improvement over a basic design, right? (Under the hypothesis that remembering Alt-Svc headers will only allow us to skip the protocol switching phase of establishing an HTTP/3 connection.)

HTTP3 support has landed in cURL and more recently in Chrome/canary so I'd suggest looking into how they handle Alt-Svc.

Some resources I've come across:

You might want to add aioquic's demo HTTP client:

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