我想我知道这里发生了什么，但是会感谢确认和/或阅读材料可以将“思考”变成“知道”，在Tl，DR部分的帖子结尾处的实际问题：
情景：
我正在测试我的MVC应用程序，因为其中一个内部组件正在停止（与数据库连接的超时）。
在我的一个网页上有一个Jquery数据表，它每半秒通过ajax查询一次更新 - 我当前的任务是在数据请求超时时显示正确的错误。所以为了测试，我做了一个存储过程，要求DB服务器在响应之前等待3秒，这比配置的超时设置要长 - 这样就可以保证超时异常让我陷阱。
我正在Chrome浏览器中测试一个客户端。正在VS2013 IIS Express中调试应用程序
问题： 当我的目的性减速被激活时，没想到会出现以下症状：
1）在启动带有装配数据的页面之后，应用程序在处理来自客户端浏览器的所有请求时变慢了 - 还有3个其他组件发送ajax更新请求，与我故意破坏的请求并行，这同样减慢了也适用于我在Web应用程序中生成请求的任何操作（如导航到其他页面）。浏览器的调试器显示请求是按时发送的，但是服务器端的相应断点很晚才被发现（延迟超过10秒甚至几分钟）
2）即使我使用应用程序关闭选项卡，我的服务器也会继续处理请求。我关闭了浏览器，我确保chrome.exe进程被终止，但是各种Controller操作的断点在之后的20分钟仍然被击中 - 主要是通过自动循环来自多个页面的ajax请求而“触发”的操作我试图在我的测试中访问。我试图导航到的主要页面上也出现了断点。在第二次测试时，我使用RawCap监视环回接口，以确保实际上没有任何请求仍然在后台运行。
理论我想用另一种解释来证实或否认：
所以上面的场景是以服务器无法处理的频率发出循环请求 - 客户端数据表循环每隔0.5秒发送一次，每个都需要至少3秒才能生成超时。显然，IIS中的某个地方必须限制它能够处理的并发请求数量......
令我感到意外的是，我有点假设如果达到了那个限制（我也假设存在），那么请求就会被拒绝 - 相反，看起来他们排队等待绝对无用的时间。稍后处理 - 我的意思是，在什么情况下半小时后处理排队的Web请求会有用？
所以到目前为止我的问题是：
Tl，DR问题：
IIS Express（Visual Studio 2013附带）是否具有并发连接限制？
如果是： { 这个限制是否可以在某处配置，如果是，那么在哪里？
IIS表达如何处理达到该限制的情况 - 处理是否也可以在某处进行配置？ （我的意思是像服务器一样繁忙的排队与即时错误） }
如果不是： { 当请求的速度超过可处理速度时，服务器如何处理这些情况？是否可以在任何地方配置处理？ }
此处 - http://www.iis.net/learn/install/installing-iis-7/iis-features-and-vista-editions
我发现IIS7至少允许无限数量的silmulatneous连接，但如果服务器的速度不足以处理所有请求，那么它实际上是如何工作的呢？是否可以在任何地方配置限制，以及是否达到该限制的处理？
感谢您对上述在线阅读材料的任何链接。
答案 0 :(得分：1)
首先，这是一个简短的Web服务器101.生产级Web服务器是多线程的，大约一个线程=一个请求。您通常会在Web服务器上看到某种类型的设置，称为＆＃34; max requests＆＃34;，这再次大致对应于它可以产生多少个线程。每个线程在CPU和RAM方面都有开销，因此，根据运行的机器所拥有的资源，Web服务器可以产生多少真正的上限。
当Web服务器达到此限制时，它不会开始拒绝请求，而是在线程释放后将请求排队。例如，如果Web服务器的最大请求数为1000（典型值），则会突然受到1500个请求的轰炸。前1000个将立即处理，另外500个将排队，直到一些初始请求被响应，释放线程并允许处理一些排队的请求。
此处的相关主题区域是async，它在Web应用程序的上下文中允许将线程返回到＆＃34;池＆＃34;当他们处于等待状态时。例如，如果您正在与API通信，那么在发送请求和从API获取响应之间，通常会由于网络延迟而等待一段时间。如果您异步处理此问题，那么在此期间，可以将线程返回到池以处理其他请求（例如前一个示例中的500个排队请求）。当API最终响应时，将返回一个线程以完成处理请求。 Async允许服务器通过使用空闲来处理新请求的线程来更有效地处理资源。
然后，有客户端 - 服务器的概念。在HTTP等协议中，客户端发出请求，服务器响应该请求。但是，两者之间没有持久的联系。 （这在HTTP 1.1中有点不真实。客户端和服务器之间的连接有时会持续存在，但这只是为了允许更快的未来请求/响应，因为启动连接所需的时间不是一个因素。但是，有＆＃ 39;在这种情况下仍然没有关于客户端/服务器状态的真正持久通信）。这里的要点是，如果客户端（如Web浏览器）向服务器发送请求，然后客户端关闭（例如关闭浏览器中的选项卡），则该事实不会传达给服务器。所有服务器都知道它收到了一个请求并且必须响应，并且会响应它，即使在另一端技术上没有任何东西可以接收它。换句话说，仅仅因为浏览器标签已经关闭，并不意味着服务器将停止处理请求并继续前进。
然后有超时。客户端和服务器都将具有一些他们遵守的超时值。 Internet的分布式特性（由TCP / IP和HTTP等协议实现）意味着网络中的节点被假定为瞬态的。没有持久连接（除了上面的相同注释）并且在发出请求的客户端和服务器响应请求之间可能发生网络中断。如果客户端/服务器没有为此计划，他们可以简单地坐在那里等待。但是，这些超时可能会有很大差异。服务器通常会在30秒内超时响应请求（尽管可能无限期地设置）。像网络浏览器这样的客户端往往有点宽容，在某些情况下超时时间为2分钟或更长。当服务器达到超时时，请求将被中止。根据为什么发生超时，客户端可能会收到各种错误响应。但是，当客户端超时时，通常不会向服务器发出通知。这意味着如果服务器的超时时间高于客户端，则服务器将继续尝试响应，即使客户端已经继续运行。关闭浏览器选项卡可能被视为立即客户端超时，但同样，服务器并不是更明智的，并且一直在努力完成其工作。
所以，所有这一切都归结为这一点。首先，在进行长轮询时（这是您每隔一段时间重复提交一次AJAX请求所做的事情），您需要建立一个取消方案。例如，如果最后5个请求超时，则应至少停止轮询一段时间。更好的方法是让一个AJAX请求的响应启动下一个。因此，您可以使用setInterval而不是使用setTimeout之类的东西，并让AJAX回调启动它。这样，只有在连锁完整的情况下，请求才会继续。如果一个AJAX请求失败，则轮询立即停止。但是，在这种情况下，您可能需要一些后备才能在一段时间后重新启动请求链。这可以防止使用新请求无休止地轰炸已经失败的服务器。此外，轮询应该继续存在一些上限。如果用户将标签打开几天而不是使用它，您是否真的应该继续轮询服务器？
在服务器端，您可以使用带取消令牌的异步。这样做有两件事：1）它为你的服务器提供了更多的喘息空间来处理更多的请求; 2）它提供了一种方法来解除请求，如果它的某些部分应该超时。有关这方面的更多信息，请访问：http://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4#CancelToken