WCF连接在服务器端重置（RST立即发送给SYN，连接被拒绝）

有人能澄清一下服务器端和的功能是什么吗？我看过文件，我认为这可能与我们遇到的问题有关

我认为

MaxPendingAccepts

文档可能有问题

“此属性限制服务器可以等待侦听器的频道数。当

MaxPendingAccepts

过低时，将有一个小的时间间隔，在该时间间隔内，所有等待的频道都已开始为连接提供服务，但没有新的频道已开始侦听。在此时间间隔内，连接可以到达，并且将l失败，因为服务器上没有任何东西在等待它。可以通过将

MaxPendingConnections

属性设置为更大的数字来配置此属性。”

这是否真的意味着通过更改

MaxPendingConnections

来更改

MaxPendingAccepts

？我不清楚这两个属性之间的区别。我们目前没有将

MaxPendingConnections

设置为12*个内核（在我们的示例中为8个）

我们在一个大容量服务上使用net.tcp绑定。在过去几年中，我们的用户急剧增加，这是一个由4台服务器组成的NLB群集，但有时我们会遇到突发流量，其中（根据perfmon）每秒的呼叫数高达200+左右

在此期间，我们遇到了一些问题，网络流量监控显示我们获得了一个SYN，然后在0.2毫秒内我们发送回一个ACK，RST关闭连接

WCF跟踪在此期间没有显示任何错误，因此我认为这不是节流。我已经形成了一个假设，但到目前为止，我在netsh trace+网络监视器中找不到任何积极或消极的证据来证实这一点

Perfmon在max实例、调用和会话下向我们展示了良好的性能

现在，我们的服务器配置如下：

MaxConcurrentSessions = 1500;
MaxConcurrentInstances = 1500;
MaxConnections = 1600;
ListenBacklog = 800;
MaxPendingSessions = 300;
MaxPendingAccepts = 20;

// MaxPendingConnections = not set, as mentioned above,
// and docs seem to indicate this is 12 * cores (8).

我的新假设是，我们之所以可以发送RST来响应SYN，是因为可能没有实际的TCP侦听器？MaxPendingAccepts小于并发调用会导致这种行为吗

MaxPendingAccepts是否应该像挂起的会话一样设置为300？是否应该设置MaxPendingConnections？为什么文档说要设置MaxPendingConnections以影响MaxPendingAccepts

---

我试图验证MaxPendingAccepts为20是否会导致拒绝连接。

下面的链接显示了对此主题的良好理解，希望它对您有用。下面的链接显示了对此主题的良好理解，希望它对您有用。