HTTP/2 support in Knative Eventing

[slinkydeveloper]

Problem
Support HTTP/2

Persona:
Which persona is this feature for? Users/Developers

Exit Criteria

• All Knative Eventing components supports HTTP/2 transparently
• Users should be able to use HTTP/2 with possibly little/zero configuration
• Support HTTP/2 in the full event flow

Additional context (optional)
I propose to support HTTP/2 with:

• TLS ALPN (HTTP/2 Encrypted)
• H2C (HTTP/2 Cleartext) with H2C Upgrade

Both the http clients and http servers we use should support it transparently

[slinkydeveloper]

I'm doing some experiments here to enable eventing components to use http/2: master...slinkydeveloper:http_2_channel

My take up to this point is:

• H2C on ingress side is not hard, the h2c handler in std lib does the work for us master...slinkydeveloper:http_2_channel#diff-118f928fc3170f6eaeb7fdaa2d42d639R64
• H2C on egress side is a problem: As far as i know there is no way to configure the http Client to try to perform transparently the HTTP/2 upgrade using the Upgrade: h2c header. If you create a client, or you use TLS (that will try to upgrade to HTTP/2 using ALPN), or you can create an H2C only transport, like here: master...slinkydeveloper:http_2_channel#diff-a9445f4d489bf24dcc47599eb387cec4R53 and that's obviously a problem, because it cannot fallback to HTTP/1.1 if H2C is not supported. Not supporting this use case means that we cannot have an H2C connection from a trigger to a user application
• TLS ALPN on ingress side can be solved using the same mechanism we use now for webhooks to sign certificates. After the http server is configured with the certificates, the server should be able to accept http/2 connections
• TLS ALPN on egress side should just work without configuration

Also as @lionelvillard noted, serving supports TLS termination with HTTP/2, so, if I understood correctly, this means that a user application without any tls configured will behave like that:

Broker egress --[HTTP/2 TLS]-> queue-proxy --[HTTP/1.1 Plaintext]-> user-container

That doesn't sound correct to me, because the interaction between the queue-proxy and the user-container could end up being an important bottleneck, while i think it's preferable to support HTTP/2 from source to sinks

[slinkydeveloper]

I made a doc to explain better the proposal here: https://docs.google.com/document/d/1yVvNKNm9AbZbGg43uRRXOLBmjhGrC-Rhchje7_cWcu0/edit?usp=sharing

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[slinkydeveloper]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[slinkydeveloper]

/reopen

[slinkydeveloper]

/remove-lifecycle stale