HTTP tunnel: add support for h2

[kyessenov]

This is a follow up to @alyssawilk 's work on adding HTTP tunnel info for automatic CONNECT conversion within the upstream cluster, thus, removing the need to internal listener with HCM in some cases. Removing HCM from the trusted base is a big advantage for a very narrow use case of CONNECT initiation.

The request is to extend it to h2/h3 CONNECT as well. At the first glance, the main difficulty appears to be tunnel sharing for multiplexed streams.

/assign @kyessenov

[kyessenov]

I think the design has to involve a two-phase stream selection mechanism:

1. The upstream cluster selects a host opting into the "tunnel" transport.
2. The host creates a new transport socket stream over the tunnel.

The important factor is that (2) is dis-associated from (1). That means that hosts from multiple clusters should be able to share the tunnel connection, since they are handed a stream from the transport factory without any assumption about the backing of the stream. The difficulty is managing the lifecycle of the tunnel. In the current design, the tunnel is established and torn down on-demand. If we go with the on-demand approach, the way it would work for (2) is:

2a. There is a per-worker "tunnel" manager that owns all the tunnels. The manager is part of the tunnel upstream transport socket factory. 2b. Each host propagates TunnelInfo to the transport socket to initiate a tunnel connection creation. The manager then allocates a connection and hands over streams over the connection to the requesting hosts. 2c. We can omit tunnel drainage I think if the hosts are drained. However, we'd probably need some way to trigger a host drain in the same place where TunnelInfo is decided and changed.

Does this sound like it makes sense @alyssawilk?

[alyssawilk]

The HTTP/1.1 direct path is really simple because it's just prepending and stripping super simple bytes. I think it'd be doable to take an L7 envoy stream and have a fast path which encapped the L7 stream as HTTP/1.1 on an upstream HTTP/2 connection. I don't think there's a simple solution to encap HTTP/2 over HTTP/2 without doing the 2 passes. Want to just snag some time on my calendar to chat about this?

[kyessenov]

Thanks, scheduled. I want to scope it to just TCP encapsulation after cluster host resolution. Internal listeners work well for HTTP in HTTP CONNECT.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.