刚好碰到过类似的场景，我来帮你拆解清楚这个现象的来龙去脉：

一、这个特性的名称与归属 #

你遇到的是单一客户端并发请求限流的行为，核心控制逻辑属于ASP.NET框架，IIS会通过配套配置辅助实现这个限制。简单来说，就是服务器为了避免单一客户端占用过多资源，会对来自同一IP/客户端的并发请求做排队或节流处理。

二、为什么会出现这个现象？ #

1. ASP.NET的并发调度限制 #

在你用的IIS 8.5+ASP.NET Web API（集成模式）环境下，主要受这两个配置影响：

• maxConcurrentRequestsPerCPU：默认每个CPU核心允许处理5000个并发请求，但如果你的应用线程池调度跟不上，或者请求队列满了，来自同一客户端的请求就会被排队，导致响应时间拉长。
• requestQueueLimit：这是HTTP运行时的请求队列长度上限，当并发请求数超过这个值，后续请求就得等着前面的处理完才能进来，自然耗时就上去了。

如果是经典模式（不过Web API一般用集成模式，这里提一下以防万一），还会受maxWorkerThreads和maxIoThreads限制——这两个控制线程池里的工作线程和IO线程数量，默认每个CPU核心是20个，超过的话请求就得排队。

2. IIS的动态IP限流模块 #

IIS 8.5自带的**Dynamic IP Restrictions（动态IP限制）**模块，如果开启了"限制并发请求"的设置，就会直接对同一IP的并发请求数做限制。哪怕你的接口没有任何IO或CPU消耗，只要并发数超过阈值，就会被延迟处理。

3. 排除Session的锅 #

你的CheckOnline接口是匿名访问，没有启用Session，所以可以排除ASP.NET里Session导致的单客户端请求串行化问题（那个是用InProc Session时，同一客户端的请求会一个接一个处理，不过你的场景不沾边）。

三、怎么调整或禁用这个限制？ #

1. 修改ASP.NET配置 #

在应用的web.config里添加或修改以下配置，根据你的模式调整：

<!-- 经典模式下调整线程池线程数 -->
<system.web>
  <processModel maxWorkerThreads="100" maxIoThreads="100" />
</system.web>

<!-- 集成模式下调整并发请求数和队列限制 -->
<system.webServer>
  <httpRuntime maxConcurrentRequestsPerCPU="10000" requestQueueLimit="10000" />
</system.webServer>

注意：别把数值调得太夸张，比如8核服务器设个8000左右就够了，不然容易把CPU或内存跑满，反而影响稳定性。

2. 调整IIS动态IP限制 #

• 打开IIS管理器，找到你的网站，双击"Dynamic IP Restrictions"
• 点右侧的"Edit Feature Settings..."
• 要么取消勾选"Deny concurrent requests"，要么把"Maximum concurrent requests"的数值调高
• 最后点"Apply"保存就行

3. 检查线程池状态 #

可以在代码里加个日志，输出线程池的可用线程数：

ThreadPool.GetAvailableThreads(out int workerThreads, out int completionPortThreads);
// 把这两个数值打日志，看是不是线程池不够用

如果发现可用线程太少，可以在应用启动时调用ThreadPool.SetMinThreads()来设置最小线程数，避免线程池扩容慢导致的排队。

四、这个特性有啥用？ #

说白了就是保护服务器不被搞垮：

• 防止单一客户端（或者恶意爬虫/攻击者）发一堆请求把服务器的CPU、内存、线程池都占了，其他用户就用不了了
• 维持服务的稳定性，哪怕有突发的高并发请求，也能通过排队来逐步处理，不会直接崩溃
• 保证请求调度的公平性，让不同客户端的请求都能分到资源，不会出现一家独大的情况

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