套接字API是TCP/IP和UDP/IP通信（也就是我们所知道的网络编程）的事实标准。然而，它的核心函数之一accept()有点神奇。
借用一个半正式的定义：
accept()用于服务器端。 它接受了一个收到的进入尝试， 从远程客户端创建一个新的TCP连接， 并创建与该连接的套接字地址对关联的新套接字。
换句话说，accept通过一个新的套接字返回给服务器，服务器可以通过该套接字与新连接的客户端进行通信。旧的套接字（在其上调用accept）保持打开状态，在同一端口上监听新的连接。
accept如何工作？如何实现？这个问题存在很多混淆。许多人声称accept会打开一个新的端口并通过它与客户端进行通信。但这显然不是真的，因为没有打开新的端口。你实际上可以通过同一个端口与不同的客户端进行通信，但是怎样做呢？当几个线程在同一个端口上调用recv时，数据如何知道去哪里？
我猜这是客户端的地址与套接字描述符相关联，每当数据通过recv传输时，它就会被路由到正确的套接字，但我不确定。
深入了解这个机制的内部工作原理将是很好的。
客户端IP:客户端端口和服务器IP：服务器端口。因此，虽然服务器的IP和端口在所有已接受的连接中都是恒定的，但客户端的信息才是用于跟踪所有数据传输的重要依据。192.168.1.1:80的服务器和两个客户端10.0.0.1和10.0.0.2。
10.0.0.1打开本地端口1234并连接到服务器，现在服务器有一个套接字，其标识如下：10.0.0.1:1234 - 192.168.1.1:80
现在10.0.0.2在本地端口5678上打开一个连接并连接到服务器。现在服务器有两个如下所示的套接字：
10.0.0.1:1234 - 192.168.1.1:80
10.0.0.2:5678 - 192.168.1.1:80
补充一下用户“17 of 26”所提供的答案：
Socket 实际上由 5 元组组成 - (源IP、源端口、目标IP、目标端口、协议)。其中协议可以是 TCP 或 UDP 或任何传输层协议。该协议在 IP 数据报的“协议”字段中被识别。
因此，在服务器上有两个不同的应用程序与完全相同的 4 元组上的同一个客户端通信，但协议字段不同，例如：
Apache 在服务器端使用 (server1.com:880-client1:1234，采用TCP)，
魔兽世界在服务器端使用 (server1.com:880-client1:1234，采用UDP)
无论哪种情况，客户端和服务器都将处理此问题，因为 IP 数据包中的协议字段不同，即使所有其他 4 个字段都相同。
在我学习这个的时候，令我困惑的是术语socket和port给人的印象是它们是物理实体，而实际上它们只是内核用来抽象网络细节的数据结构。
因此，这些数据结构被实现为能够区分来自不同客户端的连接。至于它们是如何实现的，答案要么是a.) 它并不重要，套接字API的目的恰恰是让实现不重要; 或者b.)看一下。除了强烈推荐的Stevens系列书籍提供了一个详细的描述，可以查看Linux、Solaris或其中一个BSD的源代码。
正如其他人所说，套接字由4元组（客户端IP、客户端端口、服务器IP、服务器端口）唯一标识。
运行在服务器IP上的服务器进程维护一个活动套接字数据库（这意味着我不关心它使用什么样的表/列表/树/数组/魔术数据结构），并监听服务器端口。当它通过服务器的TCP/IP堆栈接收到消息时，它会检查客户端IP和端口是否与数据库匹配。如果在数据库条目中找到了客户端IP和客户端端口，则将消息移交给现有处理程序；否则，创建一个新的数据库条目，并生成一个新的处理程序来处理该套接字。
在ARPAnet的早期，某些协议（例如FTP）会监听指定的端口以获取连接请求，并回复一个移交端口。该连接的进一步通信将通过移交端口进行。这是为了提高每个数据包的性能：在那些日子里，计算机速度慢了几个数量级。