Support for HTTP/3

[plowin]

What is this feature-request about?

In 2021, http/2 support was integrated to CF (issue). Since June 2022, http/3 is a proposed standard in RFC 9114, is supported by the major browser and offered by ~25% percent of webpages out there.

Looking at the implementation of h/2, it will probably be a cross-cutting concern with h/3 as well. Proposing to use this issue to align on plan across WGs and companies.

Please share your thoughts!

Tag your pair, your PM, and/or team!

• WG lead for App Runtime Platform: @ameowlia
• Our team is responsible for haproxy-boshrelease and willing to investigate necessary changes there (in front of gorouter)

[ameowlia]

👋 Hi @plowin,

This is the first effort I have seen to make this happen. Hopefully after the h2 effort, this will be much easier. When h2 was designed, we kept in mind that h3 would come eventually.

Here is a link to all(?) of the changes we made across CF to get http2 working. I suspect the same places will need to be updated for http3.

By default http2 traffic has to be encrypted. Since CF puts an envoy sidecar in front of apps to do TLS, all apps that want to do HTTP2 have to do h2c, which is a special unencrypted HTTP/2 version. I believe h3c is a similar protocol for HTTP/3. With a quick google search I could not find a golang implementation of h3c.

❓ Do other languages support h3c yet?

[plowin]

For go, it does not seem to be in the standard library yet and we have no experience with the library. Also no experience with other languages.

I mainly opened this to see what the community thinks about it and if there is any demand (yet). Our stakeholder are just raising interest out of curiosity but I am not aware of any use-case requiring h/3 within CF. Maybe we learn about some use-cases via this issue soon!

[maxmoehl]

Looking at the standards RFC9000 and RFC9001, it seems like QUIC is tightly coupled to TLS and using QUIC without TLS is not officially supported. It could be that we will only be able to support HTTP/3 from client to gorouter and not from gorouter to an app (at least not without major changes). The QUIC-WG website also clearly states that QUIC version 1 is

a UDP-based, stream-multiplexing, encrypted transport protocol.

From RFC9114:

This document defines HTTP/3: a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2. HTTP/3 relies on QUIC to provide confidentiality and integrity protection of data; peer authentication; and reliable, in-order, per-stream delivery. While delegating stream lifetime and flow-control issues to QUIC, a binary framing similar to the HTTP/2 framing is used on each stream. Some HTTP/2 features are subsumed by QUIC, while other features are implemented atop QUIC.

To me this sounds like HTTP/2 and HTTP/3 are relatively close and we might just get away with using our h2 / h2c mix between gorouter and apps. The main benefits of QUIC are the native multiplexing, reduced TCP-head-of-line blocking and reduced latency through quicker handshakes. Since we are in a controlled environment with short roundtrip times, aggressive keepalive and (hopefully) no packet loss, the improvements might not be as drastic as they are in the public internet. I'd like to perform some performance tests that dis-/prove my theory.

Unless there are protocols that require HTTP/3 all the way (like gRPC does with HTTP/2) I don't see a compelling reason to support HTTP/3 between gorouter and apps, mainly due to the changes required to terminate TLS at the application (instead of envoy).