关于 java 中的服务器套接字，我见过许多与此类似的答案：“假设您有一台服务器，其端口 5000 上有服务器套接字。客户端 A 和客户端 B 将连接到我们的服务器。
客户端 A 在端口 5000 上向服务器发送请求。客户端 A 端的端口由操作系统选择。通常，操作系统会选择下一个可用的端口。此搜索的起点是以前使用的端口号 + 1（因此，例如，如果操作系统最近发生在我们的端口 45546 上，则操作系统将尝试 45547）。
假设不存在连接问题，服务器会收到客户端 A 在端口 5000 上进行连接的请求。然后服务器会打开自己的下一个可用端口，并将其发送给客户端。在这里，客户端 A 连接到新端口，服务器现在再次拥有可用的端口 5000。”
我在 stackoverflow 上的多个问题中看到了类似的答案，这些问题涉及如何在accept()返回的套接字中使用与 ServerSocket 正在侦听的端口不同的端口。我一直认为 TCP 是由四组信息来识别的：
客户端 IP ：客户端端口和服务器 IP ：服务器端口 -> 协议（以区分 TCP 和 UDP）
那么为什么accept()需要返回绑定到不同端口的套接字呢？每个标头中发送的四重信息是否足以区分来自不同计算机的同一服务器端口的多个连接，而无需使用服务器计算机上的不同端口进行通信？
然后，服务器打开自己的下一个可用端口，并将其发送给客户端。
不。它创建一个新的套接字same本地端口号。没有第二端口号被分配或发送给客户端。服务器对连接请求的响应的 SYN/ACK 段不包含第二个端口号。
在这里，客户端 A 连接到新端口，
否。客户端确认 SYN/ACK 数据包，并且客户端连接到original确认 SYN/ACK 后，从那时起端口。没有第二个连接。
现在服务器的端口 5000 再次可用。”
一直都是这样。
我在 stackoverflow 上的多个问题中看到了类似的答案，这些问题涉及如何在accept()返回的套接字中使用与 ServerSocket 正在侦听的端口不同的端口。
任何这样的答案都是不正确的，应该“以极大的偏见”否决并进行负面评论。 TCP 握手定义在RFC 793 http://www.ietf.org/rfc/rfc793.txt并且没有指定第二端口和第二连接消息的分配和交换。只有三条消息，这甚至不足以发生这种情况。
那么为什么accept()需要返回绑定到不同端口的套接字呢？
事实并非如此。
每个标头中发送的四重信息是否足以区分来自不同计算机的同一服务器端口的多个连接，而无需使用服务器计算机上的不同端口进行通信？
Yes.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
