ASP.NET Core中aspnet:RequestQueueLimitPerSession的工作机制

aspnet:RequestQueueLimitPerSession 是.NET Framework下System.Web体系的专属配置，在ASP.NET Core中完全不生效，框架本身也没有内置对应的单会话请求队列限制逻辑。

• 该配置的作用对象是.NET Framework中System.Web自带的会话状态模块：旧版ASP.NET默认会对同一会话ID的请求做强制串行排队，同时设置单会话排队请求数上限，超出阈值就直接返回500错误，也就是旧版ASP.NET中常见的单会话队列超限报错。
• ASP.NET Core从底层重写了整套Web托管栈和会话中间件，完全移除了System.Web时代默认的「单会话请求强制串行+队列长度限制」逻辑，自然不会读取这个属于System.Web的配置项。

ASP.NET Core 没有内置按会话维度的请求队列限制，所有默认限流规则都是全局、连接级或者协议级的，和会话无关：

• 会话中间件本身的逻辑：Microsoft.AspNetCore.Session 中间件不会主动拦截同会话的并发请求，仅在执行会话状态读写操作时加异步锁保证数据一致性，不会因为同会话并发请求数过高主动抛出超限错误。
• Kestrel自托管场景限制：
  • 全局维度可通过KestrelServerLimits.MaxConcurrentConnections配置最大并发连接数、MaxConcurrentUpgradedConnections配置WebSocket等升级连接的最大并发数
  • HTTP/2协议维度默认限制单TCP连接最多开启100个并发流，对应配置项为Http2Limits.MaxStreamsPerConnection，如果单连接下并发请求数超过这个值，会触发协议层面的流拒绝，这也是HTTP/2场景下最容易遇到的并发请求报错原因。
• IIS托管场景限制：限流规则由ASP.NET Core Module和IIS应用程序池控制，仅存在应用池级别的全局请求队列，默认队列长度为1000，超出后返回503服务不可用错误，和会话维度无关。

如果需要在ASP.NET Core中实现类似旧版的单会话并发控制能力，可以通过自定义中间件实现，参考实现如下：

var builder = WebApplication.CreateBuilder(args);
// 注册会话信号量存储字典为单例
builder.Services.AddSingleton<ConcurrentDictionary<string, SemaphoreSlim>>();
// 注册会话服务
builder.Services.AddSession(); 

var app = builder.Build();
// 会话中间件必须放在自定义限流中间件之前
app.UseSession();

// 自定义单会话并发限流中间件
app.Use(async (context, next) =>
{
    var sessionSemaphores = context.RequestServices
        .GetRequiredService<ConcurrentDictionary<string, SemaphoreSlim>>();
    var currentSessionId = context.Session.Id;

    // 会话未创建时直接放行
    if (string.IsNullOrWhiteSpace(currentSessionId))
    {
        await next();
        return;
    }

    // 可根据业务场景自定义单会话最大并发数
    const int maxConcurrentPerSession = 30;
    var semaphore = sessionSemaphores.GetOrAdd(
        currentSessionId, 
        _ => new SemaphoreSlim(maxConcurrentPerSession)
    );

    // 可传入超时时间实现排队等待，这里设置2秒排队超时
    if (!semaphore.Wait(TimeSpan.FromSeconds(2)))
    {
        context.Response.StatusCode = StatusCodes.Status429TooManyRequests;
        await context.Response.WriteAsync("并发请求过多，请稍后重试");
        return;
    }

    try
    {
        await next();
    }
    finally
    {
        semaphore.Release();
        // 可增加定期清理逻辑，移除长时间无请求的会话对应的信号量，避免内存泄漏
    }
});

// 后续注册路由、授权、接口处理等中间件
app.Run();

如果在ASP.NET Core + HTTP/2场景下遇到大量并发请求触发500错误，优先排查两个方向：

• 检查是否触发了HTTP/2单连接最大流限制，可适当调大Http2Limits.MaxStreamsPerConnection配置，同时建议前端侧做请求节流，避免一次性发起过量并发请求
• 检查是否存在长耗时请求频繁读写会话状态，触发会话读写锁导致请求堆积超时，这类场景可考虑对不需要会话的接口关闭会话功能，减少锁冲突。

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