问并发请求的真正含义是什么？

EN

我认为对web应用程序的“并发请求”不会深入到链接层。这更多的是一个由应用程序处理请求的问题，以及在处理过程中有多少请求到达。

例如，如果一个请求平均需要2秒才能完成(从web服务器接收到它，到通过应用程序处理它，再到发回响应)，那么如果它每秒收到许多请求，那么它可能需要处理大量并发请求。

请求需要重叠并并发处理，否则请求队列将无限期地被填满。这可能看起来像是常识，但对于许多web应用程序来说，这是一个真正的问题，因为大量的请求可能会使应用程序的资源陷入困境，例如数据库。因此，如果应用程序的数据库交互性差(过于复杂的过程、糟糕的索引/优化、与许多其他应用程序共享的数据库的缓慢链接，等等)这就造成了一个瓶颈，它限制了应用程序可以处理的并发请求的数量，即使应用程序本身应该能够处理这些请求。

.Imagining在端口80监听的http服务器，发生的情况是：

• 客户端连接到服务器以请求某个页面；它使用某个原始本地端口从某个原始IP地址进行连接。
• 操作系统(实际上是网络堆栈)查看传入请求的目标IP (因为服务器可能有多个NIC)和目标端口(80)，并验证某个应用程序是否已注册为在该端口( http服务器)上处理数据。4个数字(源IP、源端口、目的IP、端口80)的组合唯一标识连接。如果这样的连接尚不存在，则会将一个新的连接添加到网络堆栈的内部表中，并将连接请求传递给http服务器的侦听套接字。从现在开始，网络堆栈只传递用于连接到application.
• Multiple客户端的数据就可以发送请求，对于每个请求都会发生上述情况。所以从网络的角度来看，所有的事情都是连续发生的，因为数据一次只到达一个数据包。
• 从软件的角度来看，http服务器正在侦听传入的请求。在客户端开始出现错误之前，它可以排队的请求数由程序员根据硬件容量确定(这是并发性的第一步:可能有多个请求等待处理)。对于每个请求，它将创建一个新套接字(尽可能快，以便继续清空请求队列)，并让应用程序的另一部分(不同的线程)完成请求的实际处理。这些处理例程将(理想情况下)花费大部分时间等待数据到达，并(理想情况下)对其做出快速反应。
• 由于数据处理通常比网络I/O快许多倍，因此服务器在处理网络流量时可以处理许多请求，即使硬件只有一个处理器也是如此。多个处理器增加了这一能力。因此，从软件的角度来看，所有的事情都发生在concurrently.
• How上，实现数据的实际处理是性能的关键所在(您希望它尽可能高效)。有几种可能性(由socket类提供的异步套接字操作、线程池、唯一线程、.NET 4的新并行特性)。

确实，没有两个包可以同时到达(除非根据Gabe的评论正在使用多个网卡)。然而，web请求通常需要多个数据包。当多个请求几乎同时传入(无论是使用有线还是无线访问)时，这些包的到达是分散的。此外，这些请求的处理可能会重叠。

添加多线程(或多个处理器/核心)，您可以看到从数据库读取(这需要大量等待响应)等冗长的操作很容易重叠，即使单个数据包以串行方式到达也是如此。

编辑：在上面添加了注释，以纳入加布的反馈。