NGINX：超过65535个连接限制

Question

与HTTP不同，websocket在从HTTP升级后保持长时间连接。

即使操作系统被调优为使用所有端口，总共仍然只有65536个端口。NGINX有可能超过这个限制吗？

一个潜在的解决方案是so_reuseport，但是它缺少文档--至少我没有找到除了下面这段

Answer 1

您收到的评论是正确的：

TCP连接由4元组(src_addr、src_port、dst_addr、dst_port)定义。如果客户端使用不同的IP地址和/或源端口，则可以将服务器连接到超过65536个客户端，所有客户端都位于同一端口。示例：服务器IP为0.0.0.1侦听端口80。然后所有的4元组都可以是(*，*，0.0.0.1，80)。只要4元组不是相同的，服务器就可以在端口80上有尽可能多的连接，因为它的内存允许。-玉米秆，12月4'15日2:36

但是，在评估是否会超出限制时，还必须考虑nginx不仅仅是一个服务器（有ngx_connection.c#ngx_open_listening_sockets()调用socket(2)、bind(2)和list(2)系统调用来接管80等端口，然后在无限循环中调用accept(2)等接受端口），它还可能是上游服务器的客户机（根据需要html" target="_blank">调用socket(2)和

请注意，尽管在其服务器上下文中不可能用完TCP端口（因为服务器在其所有连接中使用单个端口--例如，端口80)，但根据配置，在客户端上用完TCP端口是真正可能的。您还必须考虑，在客户机对连接执行clos(2)之后，状态将转到time_wait约60秒（以确保如果有任何迟到的数据包通过，系统将知道如何处理它们）。

但是，话虽如此，请注意getsockopt(2)的so_reuseport选项，至少在引用的发行说明和nginx 1.9.1的reuseport公告中提供的sharding上下文中，与65535困境完全无关--它只是在内核和内核下运行的应用程序之间提供可伸缩的多处理器支持的一个构建块：

我在一个36核的AWS实例上运行了一个wrk基准测试，有4个NGINX工作人员。为了消除网络影响，我在localhost上同时运行了client和NGINX，并让NGINX返回字符串OK而不是文件。我比较了三种NGINX配置：默认配置（相当于accept_mutex打开）、使用accept_mutex关闭和使用Reuseport。如图所示，reuseport将每秒的请求增加了2到3倍，并减少了延迟和延迟的标准偏差。

至于您的潜在问题，对于传出TCP端口的UINT16_T问题的解决方案可能是，当需要关注时，不通过TCP使用后端，和/或通过Proxy_Bind等指令使用额外的本地地址（和/或限制可以与后端建立的TCP连接的数量）。