jrudolph commented on issue #484:
URL: https://github.com/apache/pekko-http/issues/484#issuecomment-2056372271
A few thoughts here:
* One main point of HTTP/2 is that you only need a single TCP connection
open and multiplex multiple requests on top of it. The benefit is to amortize
the cost of setting up a connection (TLS and CWND setup). One drawback is that
having a single connection is a potential clump risk, i.e. it may stay open
longer than intended (load balancing changes), any TCP connection state
problems will affect all ongoing (and potentially future) requests.
* The main point of the HTTP/1.1 `singleRequest` / pool API is to relieve
the user of the HTTP connection handling. With HTTP/2 this is less of a concern
as a single connection can already support multiple ongoing HTTP requests at
the same time.
What we already have for HTTP/2:
* create a single connection and multiplex requests over it using
`OutgoingConnection.http2` (returns a `Flow`)
* create a "managed connection" which automatically reconnects an HTTP2
connection when the connection fails using
`OutgoingConnection.managedPersistentHttp2` (returns a `Flow`)
What is missing:
* "pool" for HTTP/2 that keeps a single managed persistent HTTP/2
connection per host and automatically dispatches requests based on the host to
that connection (that relieves code using the client from keeping state)
* `singleRequest`-like APIs using that pool (or on top of one of the
existing `Flow` returning solutions)
* any kind of automatic negotiation of whether to use HTTP/1.1 or HTTP/2
In terms of essential functionality, it seems that not much is missing. Many
backend usages that need an HTTP/2 client are already supported if you can do
the "dispatch to the right host connection" (which only requires that you can
keep the single managed connection as a state in your client shim).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
