在 system.net 中增加 "maxconnection" 设置有什么不利之处?

Any Downside to Increasing "maxconnection" Setting in system.net?

我们的系统存在 WCF 连接受限的问题,this answer 已解决该问题。我们将此设置添加到客户端的 web.config,并且两个并发连接的限制消失了:

除了明显的影响(例如服务器过载)之外,将此限制设置为高于默认“2”的数字(可能很多)是否有任何缺点?关于默认值如此之低的原因的任何来源?

一般来说,提高客户端连接限制是可以的,但有几点需要注意:

  • 如果您不拥有服务器,请小心,因为您的客户端应用程序可能会与 DoS 攻击相混淆,这可能会导致您的客户端 IP 地址被服务器阻止。即使您拥有服务器,这有时也是一种风险——例如,我们曾遇到过应用程序登录页面中的错误导致在用户按住 Enter 键时发出多个请求的情况。由于我们防火墙的 DoS 保护,这导致这些用户被阻止使用我们的应用程序!
  • 连接不是免费的。它们占用 RAM、CPU 和其他稀缺资源。拥有 5 或 10 个客户端连接不是问题,但是当您有数百个打开的客户端连接时,您将面临 运行 客户端资源不足的风险。
  • 客户端和服务器之间的代理或边缘服务器可能会施加自己的限制。因此,您可能会尝试同时打开 1,000 个连接,结果只有 #5,后来被代理拒绝了。
  • 有时,添加更多客户端连接是解决体系结构问题的一种方法。考虑解决架构问题。例如,如果您打开这么多连接是因为每个请求需要 10 分钟才能得到 return 结果,那么您真的应该查看更 loosely-coupled 的解决方案(例如 post 请求服务器排队并稍后回来获取结果),因为 long-lived 连接容易受到网络中断、客户端或服务器瞬时中断等的影响。
  • 能够同时打开多个连接可能会导致重新启动客户端或服务器应用程序存在风险,因为即使您的 "normal" 负载仅为 X requests/sec,如果客户端或服务器已被离线一段时间,然后客户端可能会尝试通过同时发出数百或数千个请求来处理待处理的请求。许多服务器对过载情况有 non-linear 响应,其中额外 10% 的负载可能会减少 100% 的响应时间,从而造成失控的过载情况。

所有这些风险的解决方案是小心 load-test 客户端和服务器都使用您想要支持的最大连接数...并且不要将连接限制设置为高于您已经设置的连接限制测试。不要仅仅因为可以就将连接限制提高到 1,000,000!

为了回答您问题的另一部分,2 个连接的默认限制可以追溯到非常旧版本的 HTTP 规范,该规范将客户端限制为每个域 2 个连接,这样网络浏览器就不会淹没服务器很多同时连接。有关详细信息,请参阅此答案: