sockets - 当服务器套接字接受客户端套接字时到底发生了什么？

Question

我正在学习套接字编程，服务器套接字accept()让我很困惑。我写了两个server socket accept()的场景，大家看看:

1. 当服务器套接字执行 accept() 时，它会创建一个新的(客户端)套接字，该套接字绑定(bind)到与服务器套接字所在端口不同的端口边界。因此套接字通信是通过新绑定(bind)的端口完成的，服务器套接字(仅用于 accept())正在等待原始绑定(bind)端口上的另一个客户端连接。

我认为这不太正确，因为 (1) 端口与单个进程匹配，以及 (2) 套接字接受是进程内部的事情，单个进程可以有多个套接字。所以想到了第二种情况，基于一些 stackoverflow 的答案:

1. 当服务器套接字执行accept() 时，它会创建一个未绑定(bind)到任何特定端口的新(客户端)套接字。当客户端与服务器通信时，它使用绑定(bind)到服务器套接字的端口(谁接受()的连接)和哪个客户端套接字 实际通信由 (sourceIP, sourcePort, destIP, destPort) 元组从 TCP header(?) 在传输级别解决(这也很可疑，因为我认为套接字有点像应用程序级别对象)

这种情况也引发了一些问题。如果套接字通信仍然使用服务器套接字的端口，即客户端向服务器套接字端口发送一些消息，它是否使用服务器套接字的积压队列？我的意思是，如何区分来自客户端的消息是 connect() 还是 read() 或 write()？以及如何将它们解析为服务器中的每个客户端套接字，没有任何端口绑定(bind)？

如果我的某个场景是正确的，那么它是否可以回答以下问题？或许，我的两种情况都是错误的。如果您能指导我正确答案，或者至少指导我学习一些相关文本，我将不胜感激。

Answer 1

当您创建一个套接字并在该套接字上进行绑定(bind)，然后进行监听时，您所拥有的就是所谓的监听套接字。当一个连接建立时，这个套接字基本上被克隆到一个新的套接字，这个套接字被称为服务套接字，它绑定(bind)的端口仍然与原始端口相同。

但是这个套接字和之前的监听套接字有一个重要的区别。也就是说，它是 socket pair 的一部分。唯一标识连接的是套接字对。因此图中有 2 个套接字对，TCP 通信 channel 的两端有 2 个 IP 地址和 2 个端口。在服务套接字的克隆过程中，TCP 内核将分配所谓的 TCB 并将在其中存储这 2 个 IP@ 和 2 个端口。 TCB 还包含属于 TCB 的套接字号。

每次进入一个 TCP 段时，都会检查 TCP header 以及它是否是一个 SYN，对于一个 SYN，你会建立连接，这样你就已经通过了，但是内核正在检查它的监听列表 socket 。如果它是一个普通的 TCP 数据包，而不是 SYN，两个端口号都在 TCP header 中并且 IP@ 是 IP header 的一部分，因此内核可以使用此信息找到属于此 TCP 连接的 TCP。 (对于 SYN，此信息也在那里，但正如我所说，对于 SYN，您只需处理监听套接字)

简而言之，它是如何工作的。

此信息可以在 UNIX 网络编程:套接字网络 API 中找到。在那里描述了到套接字的链接，而在其他引用资料中通常没有详细描述，而是通常突出显示 TCP 的细节。