套接字 API accept() 函数是如何工作的? [英] How does the socket API accept() function work?

问题描述

套接字 API 是 TCP/IP 和 UDP/IP 通信(即我们所知的网络代码)的事实上的标准.然而，它的核心函数之一，accept() 有点神奇.

借用一个半正式的定义:

<块引用>

accept() 用于服务器端.它接受收到的传入尝试从创建一个新的 TCP 连接远程客户端，并创建一个新的与套接字关联的套接字此连接的地址对.

换句话说，accept 返回一个新的套接字，服务器可以通过它与新连接的客户端进行通信.旧套接字(在其上调用 accept)保持打开状态，在同一端口上，侦听新连接.

accept 是如何工作的?它是如何实施的?关于这个话题有很多困惑.许多人声称接受会打开一个新端口，您可以通过它与客户端进行通信.但这显然不是真的，因为没有打开新的端口.您实际上可以通过同一个端口与不同的客户端进行通信，但是如何进行呢?当多个线程在同一个端口上调用recv时，数据怎么知道去哪里了?

我猜这类似于客户端地址与套接字描述符相关联的内容，每当数据通过 recv 传入时，它都会被路由到正确的套接字，但我不确定.

对这种机制的内部运作有一个全面的解释会很棒.

解决方案

您的困惑在于认为套接字由服务器 IP : 服务器端口标识.实际上，套接字由四组信息唯一标识:

Client IP : Client Port 和 Server IP : Server Port

因此，虽然服务器 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:8010.0.0.2:5678 - 192.168.1.1:80

The socket API is the de-facto standard for TCP/IP and UDP/IP communications (that is, networking code as we know it). However, one of its core functions, accept() is a bit magical.

To borrow a semi-formal definition:

accept() is used on the server side. It accepts a received incoming attempt to create a new TCP connection from the remote client, and creates a new socket associated with the socket address pair of this connection.

In other words, accept returns a new socket through which the server can communicate with the newly connected client. The old socket (on which accept was called) stays open, on the same port, listening for new connections.

How does accept work? How is it implemented? There's a lot of confusion on this topic. Many people claim accept opens a new port and you communicate with the client through it. But this obviously isn't true, as no new port is opened. You actually can communicate through the same port with different clients, but how? When several threads call recv on the same port, how does the data know where to go?

I guess it's something along the lines of the client's address being associated with a socket descriptor, and whenever data comes through recv it's routed to the correct socket, but I'm not sure.

It'd be great to get a thorough explanation of the inner-workings of this mechanism.

解决方案

Your confusion lies in thinking that a socket is identified by Server IP : Server Port. When in actuality, sockets are uniquely identified by a quartet of information:

Client IP : Client Port and Server IP : Server Port

So while the Server IP and Server Port are constant in all accepted connections, the client side information is what allows it to keep track of where everything is going.

Example to clarify things:

Say we have a server at 192.168.1.1:80 and two clients, 10.0.0.1 and 10.0.0.2.

10.0.0.1 opens a connection on local port 1234 and connects to the server. Now the server has one socket identified as follows:

10.0.0.1:1234 - 192.168.1.1:80  

Now 10.0.0.2 opens a connection on local port 5678 and connects to the server. Now the server has two sockets identified as follows:

10.0.0.1:1234 - 192.168.1.1:80  
10.0.0.2:5678 - 192.168.1.1:80

这篇关于套接字 API accept() 函数是如何工作的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！