.NET Framework下Parallel调用HttpClient并行请求因异步问题超时如何解决

问题根因 #

你遇到的408超时90%概率是.NET Framework的默认连接限制导致的：ServicePointManager.DefaultConnectionLimit 针对同一域名的默认并发连接数仅为2，也就是说你哪怕同时发起数千个请求，最多也只能同时建立2个TCP连接发请求，剩下的请求都会在本地排队，等待空闲连接。排队时间过长时，服务端已经完成TCP握手但迟迟等不到客户端发送HTTP请求内容，就会返回408 Request Timeout错误。

另外如果你的getResultsFor方法中存在CPU密集型同步逻辑，会卡死AsyncContext的单工作线程，也会导致请求无法及时发出，产生排队超时。

最优解决方案（按实施成本从低到高排序） #

1. 调高同域名并发连接限制（成本几乎为0，优先尝试） #

在程序启动入口处添加以下配置，不需要修改现有业务逻辑：

// 方式一：全局调整默认连接限制，数值根据服务端可承载的并发能力调整，通常设为50~200即可
ServicePointManager.DefaultConnectionLimit = 100;

// 方式二：仅针对目标请求域名调整，避免影响其他外部接口调用
var targetServicePoint = ServicePointManager.FindServicePoint(new Uri("https://你的目标接口根域名"));
targetServicePoint.ConnectionLimit = 100;
// 可选优化：关闭不必要的握手逻辑降低请求延迟
targetServicePoint.UseNagleAlgorithm = false;
targetServicePoint.Expect100Continue = false;

2. 限制请求并发数（改动极小，无需上层改造） #

不需要限制到1个并发，只需要把同时发起的请求数控制在合理范围，避免瞬间请求太多导致本地/服务端队列过长，用SemaphoreSlim实现：

// 并发阈值根据压测结果调整，通常20~100即可
private static readonly SemaphoreSlim _requestConcurrencyLimiter = new SemaphoreSlim(50);

public static void MakeMultipleRequests(IEnumerable<MyClass> enumerable)
{
    AsyncContext.Run(async () => 
    {
        var requestTasks = enumerable.Select(async c => 
        {
            await _requestConcurrencyLimiter.WaitAsync();
            try
            {
                await getResultsFor(c).ConfigureAwait(false);
            }
            finally
            {
                _requestConcurrencyLimiter.Release();
            }
        });
        await Task.WhenAll(requestTasks);
    });
}

3. 检查HttpClient复用逻辑 #

确保你的HttpClient是全局单例复用的，不要每次调用getResultsFor都新建实例，频繁销毁HttpClient会导致端口耗尽、大量TCP握手排队，进一步加剧超时问题。

4. 兜底调整超时时间 #

如果确实存在合法的长排队场景，可以在单例初始化HttpClient时拉长超时阈值：

// 超时时间按需调整，默认值为100秒
httpClient.Timeout = TimeSpan.FromMinutes(3);

你之前设想的限制仅1个请求同时调用SendAsync完全没必要，会直接把并发能力砍到最低，性能暴跌，完全不需要采用。

内容的提问来源于stack exchange，提问作者Simon W