sockets - NGINX : Exceeds 65535 connections limit

Question

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

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

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

NGINX release 1.9.1 introduces a new feature that enables use of the SO_REUSEPORT socket option, which is available in newer versions of many operating systems, including DragonFly BSD and Linux (kernel version 3.9 and later). This socket option allows multiple sockets to listen on the same IP address and port combination. The kernel then load balances incoming connections across the sockets.

因此，NGINX 调用 accept 接受入站连接。

The accept() system call is used with connection-based socket types (SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection request on the queue of pending connections for the listening socket, sockfd, creates a new connected socket, and returns a new file descriptor referring to that socket. The newly created socket is not in the listening state. The original socket sockfd is unaffected by this call.

新的socket会消耗端口吗？如果是，如何超过 65535 个连接限制？

Answer 1

您收到的评论是正确的:

TCP connections are defined by the 4-tuple (src_addr, src_port, dst_addr, dst_port). You can have a server connected to more than 65536 clients all on the same port if the clients are using different IP addresses and/or source ports. Example: server IP is 0.0.0.1 listening on port 80. All the 4-tuples could then be (*, *, 0.0.0.1, 80). So long as no 4-tuples are the same, the server can have as many connections on port 80 as its memory will allow. – Cornstalks Dec 4 '15 at 2:36

但是，在评估您是否会超过限制时，您还必须考虑 nginx 不仅仅是一个服务器(具有 ngx_connection.c#ngx_open_listening_sockets() call socket(2) 、 bind(2) 和 listen(2) 系统调用来接管端口像 80 ，然后在无限循环中调用 accept(2) )，但它也可能是上游服务器的客户端(根据需要调用 socket(2) 和 connect(2) 连接到上游端口，如 8080)。
请注意，虽然其服务器上下文不可能用完 TCP 端口(因为服务器在其所有连接中使用单个端口 - 例如，端口 80)，但在客户端用完 TCP 端口是真实的可能性，取决于配置。您还必须考虑在客户端执行 close(2) 之后在连接上， state goes to TIME_WAIT 大约 60 秒的时间(以确保如果任何迟到的数据包确实通过了，系统将知道如何处理它们)。
但是，话虽如此，请注意 the SO_REUSEPORT option至 getsockopt(2) ，至少在 the sharding context presented in the referenced release notes and reuseport announcement of nginx 1.9.1 , 与 65535 完全无关困境——它只是在内核和在内核下运行的应用程序之间具有可扩展的多处理器支持的构建块:

I ran a wrk benchmark with 4 NGINX workers on a 36-core AWS instance. To eliminate network effects, I ran both client and NGINX on localhost, and also had NGINX return the string OK instead of a file. I compared three NGINX configurations: the default (equivalent to accept_mutex on), with accept_mutex off, and with reuseport. As shown in the figure, reuseport increases requests per second by 2 to 3 times, and reduces both latency and the standard deviation for latency.

至于你的基本问题， uint16_t 的解决方案外发问题 TCP ports考虑到这一点时，可能不会通过 TCP 使用后端，和/或通过 proxy_bind 使用额外的本地地址。 et al 指令(和/或限制可以与后端建立的 TCP 连接的数量)。