服务器端Socket通信：新创建的客户端套接字是否占用端口？

你的观察是对的——服务器为客户端创建的连接套接字不会占用新端口，依然复用监听的1234端口，下面给你拆解清楚：

核心逻辑：TCP连接的四元组标识 #

TCP连接是由「源IP+源端口+目的IP+目的端口」这四个元素唯一确定的。对于你的场景：

• 客户端1的连接四元组是：客户端IP:2000 <-> 服务器IP:1234
• 客户端2的连接四元组是：客户端IP:3000 <-> 服务器IP:1234

服务器的监听套接字负责接受新连接请求，一旦握手完成，就会生成对应连接的套接字——这个套接字直接复用监听的1234端口即可，因为四元组已经足够区分两个不同的客户端连接，完全不需要新端口。

对你观察结果的解释 #

1. Wireshark抓包看到数据包指向1234：这是正常的，客户端发起通信时，目的端口本来就是服务器的监听端口1234，所有和这两个客户端的通信数据包，目的端口都会是1234。
2. netstat没看到新端口：不是没有对应套接字，而是你要关注ESTABLISHED状态的条目。执行对应的netstat命令后，你会看到两条（或更多）状态为ESTABLISHED的记录，它们的本地端口都是1234，远程端口分别是2000和3000——这些就是对应两个客户端的连接套接字。

关于“内部多路复用”的纠正 #

你的描述有点偏差：不是靠“内部多路复用”跳过端口占用，而是TCP协议本身就允许同一个端口被多个连接套接字复用，只要它们的四元组不同。服务器的多路复用（比如select/poll/epoll）是用来高效管理这些连接套接字的，和端口占用无关。

验证方法 #

Linux系统 #

执行命令：

netstat -anp | grep 1234

查看输出里ESTABLISHED状态的行，你会看到类似：

tcp        0      0 服务器IP:1234       客户端IP:2000       ESTABLISHED 进程ID/进程名
tcp        0      0 服务器IP:1234       客户端IP:3000       ESTABLISHED 进程ID/进程名

这两条就是对应两个客户端的连接套接字，它们的本地端口都是1234。

Windows系统 #

执行命令：

netstat -ano | findstr 1234

同样找ESTABLISHED状态的条目，本地地址列会显示服务器IP:1234，远程地址列分别是客户端IP:2000和客户端IP:3000。

内容的提问来源于stack exchange，提问作者DoyoHntr