65536 +1 系统上的连接

65536 +1 系统上的连接

65536 个端口对于网络中的每个系统,每个连接或发送/接收都将使用其中之一。

我的问题是:如果我们有 65536+1 会发生什么連接?!

我知道这不会以正常方式发生,但我很好奇操作系统如何处理它。

答案1

请注意,系统可以处理超过 65536 个并发连接,因为它们不是必然每个都使用单独的端口。

TCP 连接或 UDP 流由 4 元组定义:

(source IP address, source port, destination IP address, destination port)

因此,即使你的 Web 服务器只有一个 IP 地址,并且只有一个只监听 80 端口的 HTTP 服务器软件包,理论上它也可以处理 65536 个连接每个连接到它的客户端 IP 地址。因此来自客户端 IP 地址 1 的 64Ki 连接加上来自客户端 IP 地址 2 的 64Ki 连接,等等。

因此,协议支持(初步估计)2 48 个连接/流到单个 IPv4 地址上的单个 TCP 或 UDP 端口。考虑 TCP 和 UDP,以及 IPv4 的地址空间和 IPv6 的宇宙/可笑的庞大地址空间,您会发现协议本身不太可能成为主机可以处理的并发连接数限制的来源。

同样,TCP 或 UDP 协议中没有任何内容可以阻止客户端计算机使用单个 IP 地址上的单个源端口与各种服务器地址和端口建立多个传出连接。有时,给定操作系统的网络 API 可能使此操作变得困难,但重要的是要记住,古老的“[BSD] 套接字”API 只是 TCP 和 UDP 的一个 API。TCP 和 UDP 可能具有传统套接字 API 未公开的功能。

因此,给定主机可以处理的并发 TCP 连接或 UDP 流的数量不仅受端口号限制,还受系统资源(例如跟踪所有这些连接并为它们提供服务所需的 RAM 空间和 CPU 时间)限制。此外,操作系统的实现特定细节可能会施加人为限制。例如,在 Unix“一切都是文件”的理念中,每个 TCP 连接或 UDP 流可能都有一个文件描述符。如果您的 Unix 内核对它可以跟踪的文件描述符数量有限制,那么该文件描述符限制就是您的内核可以处理的并发 TCP 连接或 UDP 流数量的人为限制。

相关内容