摘要：在开发者便利度角度，我们很轻松地使用HttpClient对象发出HTTP请求，只需要关注应用层协议的BaseAddr、Url、ReqHeader、timeout。
在开发者便利度角度，我们很轻松地使用HttpClient对象发出HTTP请求，只需要关注应用层协议的BaseAddr、Url、ReqHeader、timeout。
实际在HttpClient请求在源码级别是 HttpMessagehandler在躬身前行。
1. 早期.NET HttpClient遇到的Socket滥用/DNS解析问题
早期.NET的HttpClient使用HttpClientHandler[1], 该Handler具备完整的async、proxy、dns、Connection pool 请求一条龙能力。底层Handler又会构建tcp连接池 ，开发者不注意使用场景和底层原理容易造成Socket滥用、主机端口耗尽（参考资料是：tcp4次挥手，主动端开方不会立即释放端口，存在2min的time_wait状态）。
一般实践会采用单例模式，重用HttpClient对象（也即重用HttpClientHandler）， 但此时又会遇到DNS解析问题的尴尬（HttpClient仅在创建时为连接解析DNS，不跟踪DNS服务器指令的TTL）。
意识到重用httpClient带上的dns解析副作用之后， .NET团队和.ASP.NETCore团队分别给出了技术路线来尝试解决这个问题，
前者在.NETCore 2.1 引入了具备对连接池中连接做生命周期管理能力的 SocketsHttpHandler；
后者基于ASP.NETCore框架随处可见的DI能力，实现了针对HttpClientHandler实例的缓存工厂。
2. .NET Core2.1+ HttpClient 改造HttpClientHandler证明自己
新版本的思路是哪里有问题， 我就改造哪里。
.NET Core 2.1改造了HttpClient原始的HttpClientHandler源码, 让其underlyingHandler=SocketsHttpHandler，也就是说在.NETCore2.1起HttpClient的核心Handler实质就是SocketsHttpHandler[2]， HttpClientHandler只是一个套壳。SocketsHttpHandler中与连接生命周期相关的三个关键属性：
var handler = new SocketsHttpHandler{
PooledConnectionLifetime = TimeSpan.FromMinutes(15), // 限制连接的生命周期,默认无限 Recreate every 15 minutes， 这个配置可用于缓解DNS解析问题
PooledConnectionIdleTimeout = TimeSpan.FromMinutes(2), // 空闲连接在连接池中的存活时间， NET6 1min
MaxConnectionsPerServer = 100, // 定义到每个目标服务节点能建立的最大连接数 未设置 = int.MaxValue
};
var sharedClient = new HttpClient(handler);
都聊到此了，在打算重用HttpClient实例时，插入SocketsHttpHandler并调整PooledConnectionLifetime，可缓解DNS解析问题。
3. ASP.NETCore IHttpClientFactory缓存工厂 曲线救国
IHttpClientFactory 充分体现了“计算机领域的任何问题都可以通过增加一个间接的中间层来解决” 这一方法论。
为解决重用HttpClient引起的DNS解析副作用，IHttpClientFactory对实际使用的核心HttpClienthandler开启了缓存工厂模式，在外侧尝试跟踪并控制Handler的存活周期。
① 通过IHttpClientFactory注入的命名的/类型化的HttpClient实例，底层核心的Handler来自缓存字典；
② 缓存字典中的缓存项默认2min，意味着2min时间内产生的命名HttpClient实例都是引用同一个核心HttpMessageHandler实例（LifeTimeTrackingHttpMessageHandler）；public HttpClient CreateClient(string name){
ThrowHelper.ThrowIf(name);
HttpMessageHandler handler = CreateHandler(name);
var client = new HttpClient(handler, disposeHandler: false);
HttpClientFactoryOptions options = _optionsMonitor.Get(name);
for (int i = 0; i < options.HttpClientActions.Count; i++)
{
options.HttpClientActions[i](client "i");
}
return client;
}
public HttpMessageHandler CreateHandler(string name)
{
ActiveHandlerTrackingEntry entry = _activeHandlers.GetOrAdd(name, _entryFactory).Value; // 工厂模式，惰性取值
StartHandlerEntryTimer(entry); // 跟踪缓存项的过期时间
return entry.Handler;
}
缓存是用线程安全的字典以惰性生成的方式实现：_activeHandlers = new ConcurrentDictionary>(StringComparer.Ordinal);
_entryFactory = (name) => {
return new Lazy( =>
{
return CreateHandlerEntry(name);
}, LazyThreadSafetyMode.ExecutionAndPublication);
};
缓存的是LifeTimeTrackingHttpMessageHandler[3]对象，这是一个托管资源。
③ 每个活跃的核心handler上外挂了存活时间， 一旦到期便从活跃字典中移出， 并移动到过期handler队列[4]；
internal sealed class ExpiredHandlerTrackingEntry{
private readonly WeakReference _livenessTracker;
// IMPORTANT: don't cache a reference to `other` or `other.Handler` here.
// We need to allow it to be GC'ed.
public ExpiredHandlerTrackingEntry(ActiveHandlerTrackingEntry other)
{
Name = other.Name;
Scope = other.Scope;
_livenessTracker = new WeakReference(other.Handler); // 跟踪LifeTimeTrackingHttpMessageHandler 托管资源
InnerHandler = other.Handler.InnerHandler!; // InnerHandler 是托管资源底层引用的非托管资源
}
public bool CanDispose => !_livenessTracker.IsAlive;
public HttpMessageHandler InnerHandler { get; }
public string Name { get; }
public IServiceScope? Scope { get; }
}
托管资源LifeTimeTrackingHttpMessageHandler 不接受dispose(httpclient)的指引，而是由gc跟踪再无HttpClient引用而被清理。
Q：此时就出现了一个问题， 托管资源已经被gc清理， 那依赖的底层非托管资源什么时候清理的？这个不清理可是有大问题。
A ：这里使用了一个C#高级的用法：弱引用WeakReference[5]：能够在不影响gc的情况下，获得对象的“弱引用”， 并据此知道该实例是不是已经被gc清理了；本文是弱引用_livenessTracker跟踪了托管资源LifeTimeTrackingHttpMessageHandler， 该托管资源被gc清理后_livenessTracker会得到感知。btw，关于弱引用，我会开一新篇章来讲述。
④ 最后由程序内置的定时清理程序来清理底层非托管资源。
if (entry.CanDispose) //跟踪到托管对象已经被gc{
try
{
entry.InnerHandler.Dispose;
entry.Scope?.Dispose;
disposedCount++;
}
catch (Exception ex)
{
Log.CleanupItemFailed(_logger, entry.Name, ex);
}
}
//注意：InnerHandler并不是托管对象LifeTimeTrackingHttpMessageHandler
具体是通过弱引用得知引用被gc之后，再去清理底层的非托管资源:
在使用层面， IHttpClientFactory并非直接管控连接池连接，而是在外层对Handler做存活缓存，故工厂对外只提供了SetHandlerLifetime(TimeSpan.FromMinutes(5)) 这一个配置函数。
IHttpCLientFactory 工厂除了具备 “通过管理HttpClientHandler实例的缓存生存期，避免手动管理HttpClient生存期时出现的DNS问题”， 还具有HttpClient实例的产生更符合.NET 框架的调性：DI、 以委托方式配置HttpClient中间件的惯例
中心化配置、 命名或者类型化客户端
提供基于 Polly 的中间件的扩展方法，以利用 HttpClient中的委托处理程序。
（通过 ILogger）添加可配置的记录体验，以处理工厂创建的客户端发送的所有请求。
本文从早期的HttpClient带来的尴尬（重用HttpClient带来的DNS解析问题）， 扩展到.NET团队尝试解决该问题的两个思路。
.NET Core 2.1的思路是增强HttpClient库底层的连接池能力，提供了SocketsHttpHandler来控制连接的生命周期，
IHttpClientFactory的思路是绕过HttpClient本身的问题，在上层用存活缓存的思路来使用HttpClientHandler实例， 充分贯彻了“计算机领域的任何问题都可以通过增加一个间接的中间层来解决”的思想。
本篇文字和图片均为原创，读者可结合图片探索源码， 欢迎反馈 ~。。~。
[1]
早期.NET的HttpClient使用HttpClientHandler: https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System/net/System/Net/Http/HttpClientHandler.cs#L917
[2]
SocketsHttpHandler:
[3]
LifeTimeTrackingHttpMessageHandler:
[4]
过期handler队列:
[5]
弱引用WeakReference: https://learn.microsoft.com/en-us/dotnet/api/system.weakreference?view=net-9.0
来源：opendotnet