对 nginx 的第 513 个并发请求会发生什么？

Question

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

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

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

Answer 1

根据docs

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

和the source of ngx_get_connection() 它只会发出警告并且不会打开新连接：

“%ui worker_connections 不够”

所以似乎没有任何排队。

如果返回值是NULL（适用于这种情况），那么它将只是close the socket（如果有的话），所以不会处理连接，而是会杀死它。同样的行为似乎也是consistent between UDP and other types。

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

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

出于测试目的，只需对 Nginx 使用可能的最低值 worker_connections，直到它启动并继续运行，对于 Kestrel 类似，并查看它在以下情况下的行为：

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

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