Adding HTTP/3 support using aioquic

[Kludex]

Originally opened by @jlaine on 2019-08-25 14:48:30 in encode/httpx

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.

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/

[Kludex]

Originally posted by @florimondmanca on 2019-09-13T18:45:31Z

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 cut this work into multiple PRs to help with review and incremental improvements.

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

[Kludex]

Originally posted by @sethmlarson on 2019-09-13T19:51:10Z

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?

[Kludex]

Originally posted by @florimondmanca on 2019-09-13T20:12:48Z

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 build ConcurrencyBackend.connect_udp() 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.

[Kludex]

Originally posted by @jlaine on 2019-09-22T09:29:50Z

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

[Kludex]

Originally posted by @cdeler on 2020-09-02T14:27:32Z

I tried to follow the guide written by @tomchristie above.

The first step was

Rename BaseStream / Stream / ConcurrencyBackend.connect() to BaseTCPStream / TCPStream / ConcurrencyBackend.connect_tcp().

It has been implemented in encode/httpx#339
Having found the PR and the changes, I wanted to look around it and found that neither BaseTCPStream nor TCPStream nor ConcurrencyBackend are presented in httpx/httpcore repos. Moreover the file structure of he repo has significantly changed from the PR.

@florimondmanca , @tomchristie
Do you have a time to provide us with advice, where the process should start? Should it be some sort of new connection to httpcore._async/httpcore._sync with the aioquic backend?

[Kludex]

Originally posted by @tomchristie on 2020-09-03T10:39:11Z

@cdeler Well, it's about as complex as you could get for a contribution, but if you're up for it then I can certainly put in the guidance for a sensible way to approach it.

The keyword here, as with anything like this, will be incremental. 😀

• I'd start off with a pull request that just adds an http3 flag to the ConnectionPool configuration, in the same way as the existing http2 flag. It should also be passed through to the HTTPConnection instance. To begin with it shouldn't actually do anything, it should simply be there.
• The next step could be to "notice" if an HTTP/3 service is advertised. If an HTTP/1.1 or HTTP/2 connection gets a response with an Alt-Svc: h3 header, and if http3=True has been set, then a NotImplementedError exception should be raised.

At that point we've got a stub behaviour for detecting HTTP/3 support, which we can start to iterate on.

[Kludex]

Originally posted by @cdeler on 2020-09-03T11:42:10Z

The keyword here, as with anything like this, will be incremental. 😀
it's smart behaviour to make incremental changes, I'm happy to try doing that

[Kludex]

Originally posted by @tomchristie on 2020-09-03T13:14:12Z

Slight update - let's scratch the second part of that, actually I think we'll want to use the HTTP/2 frame-type ALTSVC to detect if we should upgrade or not.

We'll use that because we don't want to wait for response headers before we decide on if we should upgrade. The ALTSVC frame can be sent during the opening handshake, before the request itself is made. We'll probably need to end up doing some investigation into exactly when implementations choose to send this frame, before we're able to proceed from there.

[Kludex]

Originally posted by @cdeler on 2020-09-06T19:08:30Z

@tomchristie

Have you seen this example in the aioquic repo?

[Kludex]

Originally posted by @florimondmanca on 2020-09-06T19:45:57Z

@cdeler — Sure, it was posted by Jeremy (OP) in the issue description. :-) Obviously looks outdated by now since some bits of HTTPX API have changed, but I'm sure it's been discussed earlier in this thread?

[Kludex]

Originally posted by @chwba on 2021-06-16T14:23:49Z

Any way to make this work again? Currently getting NotImplementedError

[Kludex]

Originally posted by @jlaine on 2021-07-07T10:19:03Z

I've submitted aiortc/aioquic#203 to update the httpx demo for recent httpcore versions.

[Kludex]

Originally posted by @stale[bot] on 2022-02-20T15:13:42Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Kludex]

Originally posted by @unixfox on 2022-02-20T16:29:01Z

Bump still important.

[Kludex]

Originally posted by @stale[bot] on 2022-03-25T07:31:00Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.