You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, we have two implementations for IConnection. HttpConnection is used for .NET Core while for .NET Fx, we use HttpWebRequestConnection. This requirement maintenance of two similar, but distinct code paths.
We also have an implementation of HttpClientFactory used internally to pool the underlying HttpMessageHandlers. This is designed to re-use sockets where possible, while also ensuring stale handlers are removed such that connections refresh periodically.
Proposals
HttpClient Unification
Review whether we can safely unify these to use HttpClient in the case of all target frameworks. This simplifies the design and testing of future features implemented at the lowest level of the transport.
Removal of HttpClientFactory behaviours
There is overhead involved in maintaining the HttpMessageHandler pool and the machinery required for the pool to function. This includes allocations and additional dispatch time. Since .NET Core introduced the SocketsHttpHandler, it includes built-in pooling support with configuration options to control the lifetime of sockets in that pool. We could leverage this, rather than maintaining our own pool. On .NET Fx, we could use ServicePointManager to achieve the same goal (once unified on HttpClient APIs).
Things to consider
While this proposal seems simple in principle, there is a gotcha. SocketsHttpHandler until .NET 6.0 does not utilise the internal DiagnosticsHandler which emits diagnostic events and ensure trace headers are forwarded. This presents a problem since we need to use the SocketsHttpHandler in order to configure the pooling timeouts, but in doing so, we lose the diagnostics capabilities. This PR for .NET 6.0 partially addresses the problem for the trace parent header propagation at least but perhaps not all diagnostic capabilities.
We need to test what is/isn't supported and decide if we have conditional code to remove HttpMessageHandler requirements only for .NET 6.0. Alternatively, we may be able to roll our own version of the DiagnosticsHandler in such a way as to allow the removal of HttpMessageHandler for all target frameworks.
While it would diverge the code-base to handle .NET 6.0 differently, if the diagnostics support is sufficient there when using SocketsHttpHandler, we could offer an initial benefit to consumers on this runtime.
Next steps
Remove HttpWebRequestConnection usage for .NET Fx targets and test in .NET 4.61 upwards.
Investigate the impact of the loss of DiagnosticHandler capabilities when using SocketsHttpHandler on .NET Core 3.1, .NET 5.0 and .NET 6.0. An outcome of this investigation will drive subsequent planning of the best design.
The text was updated successfully, but these errors were encountered:
stevejgordon
changed the title
[WIP] HttpConnection Unification and Optimisation
[Proposal] HttpConnection Unification and Optimisation
Aug 20, 2021
Current situation
Today, we have two implementations for
IConnection
.HttpConnection
is used for .NET Core while for .NET Fx, we useHttpWebRequestConnection
. This requirement maintenance of two similar, but distinct code paths.We also have an implementation of
HttpClientFactory
used internally to pool the underlyingHttpMessageHandlers
. This is designed to re-use sockets where possible, while also ensuring stale handlers are removed such that connections refresh periodically.Proposals
HttpClient
UnificationReview whether we can safely unify these to use
HttpClient
in the case of all target frameworks. This simplifies the design and testing of future features implemented at the lowest level of the transport.Removal of
HttpClientFactory
behavioursThere is overhead involved in maintaining the
HttpMessageHandler
pool and the machinery required for the pool to function. This includes allocations and additional dispatch time. Since .NET Core introduced the SocketsHttpHandler, it includes built-in pooling support with configuration options to control the lifetime of sockets in that pool. We could leverage this, rather than maintaining our own pool. On .NET Fx, we could useServicePointManager
to achieve the same goal (once unified onHttpClient
APIs).Things to consider
While this proposal seems simple in principle, there is a gotcha.
SocketsHttpHandler
until .NET 6.0 does not utilise the internalDiagnosticsHandler
which emits diagnostic events and ensure trace headers are forwarded. This presents a problem since we need to use theSocketsHttpHandler
in order to configure the pooling timeouts, but in doing so, we lose the diagnostics capabilities. This PR for .NET 6.0 partially addresses the problem for the trace parent header propagation at least but perhaps not all diagnostic capabilities.We need to test what is/isn't supported and decide if we have conditional code to remove
HttpMessageHandler
requirements only for .NET 6.0. Alternatively, we may be able to roll our own version of theDiagnosticsHandler
in such a way as to allow the removal ofHttpMessageHandler
for all target frameworks.While it would diverge the code-base to handle .NET 6.0 differently, if the diagnostics support is sufficient there when using
SocketsHttpHandler
, we could offer an initial benefit to consumers on this runtime.Next steps
HttpWebRequestConnection
usage for .NET Fx targets and test in .NET 4.61 upwards.DiagnosticHandler
capabilities when usingSocketsHttpHandler
on .NET Core 3.1, .NET 5.0 and .NET 6.0. An outcome of this investigation will drive subsequent planning of the best design.The text was updated successfully, but these errors were encountered: