TCP的套接字与Linux的TCP套接字

Question

Linux API和TCP协议都具有称为“套接字”的概念。 它们是同一概念吗，Linux的TCP套接字是否实现TCP的套接字概念？

1. 连接和插座之间的关系：

   我听说两个连接不能共享Linux的TCP套接字 ，这是真的吗？

   Tenebaum的计算机网络（2011年5月5日，第6.5.2节“ TCP服务模型”，p553）说：

   一个套接字可以同时用于多个连接。 换句话说，两个或多个连接可以在同一套接字处终止。 连接由两端的套接字标识符标识。

   既然引言说两个连接可以共享一个“套接字”，那么本书是否使用与Linux的TCP套接字不同的“套接字”概念？ 本书是否使用TCP的套接字概念？

2. 进程与套接字之间的关系：

   我还听说， 两个进程可以共享Linux的TCP套接字 。 但是，如果两个进程可以共享一个套接字，那么这些进程是否不能在该套接字上随意创建自己的连接，因此在同一Linux的TCP套接字上有两个连接？ 与1（两个连接不能共享一个Linux TCP套接字）的矛盾吗？

两个进程可以共享一个TCP的套接字吗？

Answer 1

该书引用了套接字的一个更抽象的概念，它与特定的OS甚至网络/传输协议都不相关。 在书中，套接字只是一个唯一定义的连接端点。 因此，连接是一对插座（S1，S2），在某些未定义的上下文中，该对应该是唯一的。 现在使用我的连接特定于TCP的示例将具有一个抽象套接字，该套接字由接口IP地址和TCP端口号组成。 像我这样的stackoverflow用户和抽象套接字[443，151.101.193.69]之间有很多连接 ，但是从我的计算机[27165，192.168.1.231]到[443，151.101.193.69]只有一个连接，这是假的使用不可路由的IP地址的示例，以保护我的隐私。

如果我们更加具体并假设stackoverflow和我的计算机都在运行linux，那么我们可以讨论man 2 socket定义的man 2 socket以及使用它的linux API。 在这里，可以在侦听模式下创建套接字，通常将其称为服务器 。 该套接字可以在多个进程之间共享（在共享内存或状态的意义上共享）。 但是，当对等方连接到此侦听套接字时，会创建一个新的套接字（作为accept()调用的结果。原始侦听套接字可能会再次用于accept()另一个连接。我相信是否有多个进程被阻塞了）然后， accept()系统调用将完全被阻止，并返回新创建的连接套接字。

让我知道这里是否缺少什么。

Answer 2

与您正在阅读的文档一样，这很方便，但实际上并不准确。

套接字是一种通用的网络API。 它们与TCP的唯一关系是，您可以设置套接字以使用它。 您还可以设置套接字以与操作系统支持的任何其他网络协议进行通讯。 同样，您不必一定要使用套接字，许多操作系统仍提供其他网络API，有些具有相当大的利基优势。

这给您留下的问题是，非技术性语言使您对事物的组合方式有所了解，但它掩盖了实现细节，您无法从外行人的特性和类比中进行任何详细的推理。

因此，请忽略您由套接字形成的概念。 阅读实际的文档，而不是教程。 编写代码以查看其是否按您认为的那样工作。 您将了解到，现在所拥有的是外行对“套接字”的理解，掩盖了用socket()创建的socket()之间的差异，从accept()获得的socket() ，可以在Unix文件系统中找到的socket() ，等等。

即使是“连接”，即使对于TCP，也有些简化。

为了让您知道兔子洞有多深，“共享”也是如此-您可以在某些套接字上发送fd，而套接字是fd，则在fork() ，两个进程共享fd命名空间，您可以dup() fd的...

完全建立的TCP网络连接是{host1：port1，host2：port2}对，两端具有某些跟踪状态，并且在两端之间发送的数据包会根据TCP协议（即规则）更新状态。 您可以bind()套接字bind()到本地TCP地址，然后通过该套接字connect()依次connect()到远程（或本地）地址，因此从某种意义上说，连接可以共享一个套接字-但是，如果您正在运行服务器， accept()连接具有自己的专用套接字，这就是您确定read()的数据来自何处的方式。

常见的混淆之一是套接字可以绑定到的host：port对和套接字本身之间。 您将获得一个OS套接字来监听新连接，然后通过基于连接的协议（例如TCP）在每个连接上获得一个，但是它们都可以使用同一主机：端口，很容易掩盖现实并将其视为“套接字”。 ”，看起来您正在阅读的书就属于这种用法。