knative
HTTP/2 support in Knative Eventing
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
I'm doing some experiments here to enable eventing components to use http/2: https://github.com/knative/eventing/compare/master...slinkydeveloper:http_2_channel
My take up to this point is:
- H2C on ingress side is not hard, the
h2chandler in std lib does the work for us https://github.com/knative/eventing/compare/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: h2cheader. 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: https://github.com/knative/eventing/compare/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
I made a doc to explain better the proposal here: https://docs.google.com/document/d/1yVvNKNm9AbZbGg43uRRXOLBmjhGrC-Rhchje7_cWcu0/edit?usp=sharing
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
@devguyio: Reopened this issue.
In response to this:
/remove-lifecycle stale /triage accepted /reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
