WCF中netTcpBinding达maxConnections上限的行为及内存占用问题

一、100个客户端同时交互时的服务行为 #

netTcpBinding的maxConnections参数默认值为10，它控制服务同时接受的活跃连接数，配套的ListenBacklog（监听队列长度）默认也是10。当100个客户端同时发起连接请求时：

• 服务会立即接受前10个连接，剩下的90个请求中，仅有10个能进入监听队列等待，其余80个客户端会直接遭遇连接失败（可能是TCP层面的超时，或是WCF抛出的连接拒绝异常）。
• 已建立的10个连接上的请求，会通过WCF的线程池处理。如果这些连接的请求并发量较高，后续请求会进入服务端的请求队列排队，客户端会出现明显的响应延迟。
• 当某个活跃连接断开后，服务会从监听队列中取出下一个等待的连接完成建立，逐步处理剩余客户端，但这个过程是串行的，大部分客户端会经历较长等待，甚至因为超时无法完成连接。

二、内存占用对比 #

当maxConnections=10时，服务最多同时维护10个活跃连接，对应的内存开销（Socket实例、会话对象、请求缓冲区等）会显著低于maxConnections设置为大于100的情况：

• 若maxConnections设为大于客户端数量（比如200），服务会同时接受所有100个客户端的连接，此时需要为每个连接分配对应的资源，内存占用会大幅上升。
• 请求排队的内存开销远低于维护活跃连接的开销，因此maxConnections越小，服务宿主的内存占用反而越低。

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