第 513 个并发请求 nginx 会发生什么情况？

Question

Nginx 是基于事件的，默认情况下作为 1 个进程运行，支持最多 512 个并发连接。另一个进程将允许另外 512 个并发连接。

我使用 nginx 作为 kestrel 服务器的反向代理。Kestrel 支持无限连接。

假设同时处理 512 个请求，当第 513 个请求到来时，nginx 会拒绝它还是将其添加到队列中？

Answer 1

根据文档

设置工作进程可以打开的最大同时连接数。

它的来源ngx_get_connection()只会发出警告并且不会打开新连接：

“%ui worker_connections 不够”

所以看起来没有任何排队现象。

如果返回值是NULL（对于这种情况），那么它将简单地关闭套接字（如果有的话），因此不会处理连接，而是会终止它。同样的行为在 UDP 和其他类型之间似乎也是一致的。

关于“无限”，我对任何提到它的东西都持高度怀疑的态度。一种类型的资源最终会不够，无论是 CPU 利用率、内存、文件系统资源还是其他资源，因此，如果库/应用程序提到“无限”，请检查它的真正含义是什么，以及当这种“无限”的东西可以时会发生什么不再无限了。然后，您将找到可以调整 Nginx 配置以匹配（或更高一点，以便它可以处理所有传入）连接的指标。

我进行了快速搜索并发现microsoft.aspnetcore.server.kestrel.core.kestrelserverlimits.maxconcurrentconnections其相关内容ConnectionLimitMiddleware，如果启用，似乎会进行某种连接排队，如果禁用，我猜它将受到操作系统底层套接字限制的限制，但是我只发现了对Windows的非常简短的引用' 套接字缓冲区大小 (TCP)，因此您需要更深入地挖掘。

出于测试目的，只需对 Nginx 使用尽可能低的值，worker_connections直到它启动并保持运行，与 Kestrel 类似，看看它在以下情况下的行为如何：

• 红隼 > Nginx
• 红隼==Nginx
• Kestrel < Nginx

打开针对服务器的套接字并偶尔发送一两个字节，因此套接字很忙。