这可能是一个非常基本的问题，但它让我感到困惑。
两个不同的连接套接字可以共享一个端口吗？我正在编写一个应该能够处理超过 100k 并发连接的应用程序服务器，并且我们知道系统上可用的端口数约为 60k（16 位）。一个已连接的套接字被分配给一个新的（专用）端口，因此这意味着并发连接数受到端口数的限制，除非多个套接字可以共享同一个端口。那么问题来了。
【问题讨论】：
标签： sockets tcp network-programming port
我想没有一个答案能说明过程的每一个细节，所以就这样吧：
考虑一个 HTTP 服务器：
它要求操作系统将端口 80 绑定到一个或多个 IP 地址（如果选择 127.0.0.1，则只接受本地连接。您可以选择 0.0.0.0 绑定到所有 IP 地址（本地主机、本地网络、广域网，两个 IP 版本））。
当客户端连接到该端口时，它将锁定一段时间（这就是套接字有积压的原因：它将许多连接尝试排队，因为它们不是即时的）。
然后操作系统会选择一个随机端口并将该连接传输到该端口（将其视为一个临时端口，从现在开始处理所有流量）。
然后释放 80 端口用于下一个连接（首先，它将接受积压中的第一个）。
当客户端或服务器断开连接时，随机端口会保持打开一段时间（远程端为 CLOSE_WAIT，本地端为 TIME_WAIT）。这允许沿路径刷新一些丢失的数据包。该状态的默认时间是 2 * MSL 秒（它会在等待时消耗内存）。
在等待之后，该随机端口再次空闲以接收其他连接。
所以，TCP 甚至不能在两个 IP 之间共享一个端口！
【讨论】：
没有。不可能在特定时刻共享同一个端口。但是你可以让你的应用程序在不同的时刻进行端口访问。
【讨论】：
那么，当服务器侦听 TCP 端口上的传入连接时会发生什么？例如，假设您在端口 80 上有一个 Web 服务器。假设您的计算机的公共 IP 地址为 24.14.181.229，而尝试连接到您的人的 IP 地址为 10.1.2.3。此人可以通过打开到 24.14.181.229:80 的 TCP 套接字来连接到您。很简单。
直觉上（并且错误地），大多数人认为它看起来像这样：
Local Computer | Remote Computer
--------------------------------
<local_ip>:80 | <foreign_ip>:80
^^ not actually what happens, but this is the conceptual model a lot of people have in mind.
这很直观，因为从客户端的角度来看，他有一个 IP 地址，并通过 IP:PORT 连接到服务器。既然客户端连接到80端口，那么他的端口也必须是80？这是一个明智的想法，但实际上并非如此。如果这是正确的，我们只能为每个外国 IP 地址服务一个用户。一旦远程计算机连接，那么他将占用端口 80 到端口 80 的连接，其他人无法连接。
必须明白三件事：
1.) 在服务器上，进程正在侦听端口。一旦它得到一个连接，它就会把它交给另一个线程。通信永远不会占用监听端口。
2.) 连接由操作系统通过以下 5 元组唯一标识：（本地 IP、本地端口、远程 IP、远程端口、协议）。如果元组中的任何元素不同，那么这是一个完全独立的连接。
3.) 当客户端连接到服务器时，它会选择一个随机的、未使用的高阶源端口。这样一来，单个客户端最多可以有约 64k 到服务器的相同目标端口的连接。
所以，这实际上是客户端连接到服务器时创建的内容：
Local Computer | Remote Computer | Role
-----------------------------------------------------------
0.0.0.0:80 | <none> | LISTENING
127.0.0.1:80 | 10.1.2.3:<random_port> | ESTABLISHED
首先，让我们使用 netstat 查看这台计算机上发生了什么。我们将使用端口 500 而不是 80（因为端口 80 上发生了很多事情，因为它是一个通用端口，但在功能上它并没有什么区别）。
netstat -atnp | grep -i ":500 "
正如预期的那样，输出为空白。现在让我们启动一个 Web 服务器：
sudo python3 -m http.server 500
现在，再次运行 netstat 的输出如下：
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
所以现在有一个进程在端口 500 上主动监听（状态：LISTEN）。本地地址是 0.0.0.0，这是“监听所有 ip 地址”的代码。一个容易犯的错误是只监听端口 127.0.0.1，它只接受来自当前计算机的连接。所以这不是一个连接，这只是意味着一个进程请求绑定（）到端口 IP，并且该进程负责处理与该端口的所有连接。这暗示了每台计算机只能有一个进程监听端口的限制（有一些方法可以使用多路复用来解决这个问题，但这是一个更复杂的话题）。如果网络服务器正在侦听端口 80，则它无法与其他网络服务器共享该端口。
现在，让我们将用户连接到我们的机器：
quicknet -m tcp -t localhost:500 -p Test payload.
这是一个简单的脚本 (https://github.com/grokit/quickweb)，它打开一个 TCP 套接字，发送有效负载（在本例中为“测试有效负载”），等待几秒钟并断开连接。发生这种情况时再次执行 netstat 会显示以下内容：
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:54240 ESTABLISHED -
如果您连接另一个客户端并再次执行 netstat，您将看到以下内容：
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:26813 ESTABLISHED -
...也就是说，客户端使用另一个随机端口进行连接。因此，IP 地址之间永远不会混淆。
【讨论】：
理论上，是的。练习，不是。大多数内核（包括 linux）不允许您第二个 bind() 到已分配的端口。允许这样做并不是一个非常大的补丁。
从概念上讲，我们应该区分 socket 和 port。套接字是双向通信端点，即我们可以发送和接收字节的“事物”。这是一个概念性的东西，一个名为“socket”的包头中没有这样的字段。
端口是能够识别套接字的标识符。在 TCP 的情况下，端口是一个 16 位整数，但也有其他协议（例如，在 unix 套接字上，“端口”本质上是一个字符串）。
主要问题如下：如果传入的数据包到达，内核可以通过其目标端口号识别其套接字。这是一种最常见的方式，但不是唯一的可能性：
因为您正在使用应用程序服务器，所以它可以做到这一点。
【讨论】：
bind()。
bind() 设置监听套接字的操作系统吗？我可以想象，是的，这很有可能，但事实是 WinSock 和 Posix API 都为此使用了 bind() 调用，即使它们的参数化实际上是相同的。即使 API 没有此调用，您需要以某种方式说出来，您想从哪里读取传入的字节。
listen()/accept() API 调用可以创建套接字，内核将通过它们的传入来区分它们港口。 OP的问题可以按照他本质上要求的方式来解释。我认为，这很现实，但他的问题并不是这个意思。
服务器 套接字侦听单个端口。该服务器上所有已建立的客户端连接都与连接的服务器端相同的侦听端口相关联。已建立的连接由客户端和服务器端 IP/端口对的组合唯一标识。同一服务器上的多个连接可以共享相同的服务器端 IP/端口对，只要它们与不同的客户端 IP/端口对相关联，并且服务器将能够处理可用系统资源允许的尽可能多的客户端。
在客户端上，新的出站连接通常使用随机的客户端端口，在这种情况下可能会用完如果您在短时间内建立大量连接，则可用端口。
【讨论】：
已连接的套接字分配给新的（专用）端口
这是一种常见的直觉，但它是不正确的。连接的套接字未分配给新的/专用端口。 TCP 堆栈必须满足的唯一实际约束是 (local_address, local_port, remote_address, remote_port) 的元组对于每个套接字连接必须是唯一的。因此，服务器可以有许多 TCP 套接字使用相同的本地端口，只要端口上的每个套接字都连接到不同的远程位置。
【讨论】：
bind() 操作在 connect() 操作之前，甚至是隐式的。
bind() 仅在服务器端使用accept()? 之前所以客户端也会绑定特定端口？
bind()可以在connect()之前在客户端使用。
accept() 在侦听套接字上返回的套接字）