问题背景 #

我正在研究一段UDP客户端示例代码，核心片段如下：

/* UDP client in the internet domain */
struct sockaddr_in server, from;
//...省略部分代码
sock= socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) error("socket");
server.sin_family = AF_INET;
hp = gethostbyname(argv[1]);
if (hp==0) error("Unknown host");
bcopy((char *)hp->h_addr, (char *)&server.sin_addr, hp->h_length);
server.sin_port = htons(atoi(argv[2]));
length=sizeof(struct sockaddr_in);
//...省略部分代码
n=sendto(sock,buffer, strlen(buffer),0,(const struct sockaddr *)&server,length);
if (n < 0) error("Sendto");
n = recvfrom(sock,buffer,256,0,(struct sockaddr *)&from, &length);
if (n < 0) error("recvfrom");
//...省略部分代码

我一直有个疑问：客户端是怎么知道从哪个端口接收服务器的回复消息的？我知道调用sendto时系统会选一个可用端口嵌入UDP消息，服务器能读到这个端口并回复，但客户端代码里并没有显式绑定端口的逻辑，它是怎么确定要在这个端口上监听回复的？

之前看到相关技术讨论提到，sendto调用时会发生隐式绑定，我想搞清楚这个机制的工作原理：它是不是和显式调用bind绑定一个随机可用端口的效果完全一样？看起来这种隐式绑定是持久的，希望能了解更多细节。

隐式绑定的工作原理 #

其实当你创建一个UDP套接字（socket(AF_INET, SOCK_DGRAM, 0)）后，如果没有显式调用bind指定端口，第一次调用sendto（或者UDP的connect，只是记录目标地址而非建立连接）的时候，操作系统会自动帮你完成以下操作：

• 选择一个当前未被占用的临时端口（通常是系统预留的临时端口范围，比如Linux上默认是32768-60999）
• 将这个套接字绑定到该临时端口，同时关联上你的本地IP地址（如果是多网卡，会根据路由选择合适的出口IP）

这种隐式绑定和你手动调用bind绑定随机端口的效果几乎完全一致，比如你可以手动写这样的代码：

struct sockaddr_in my_addr;
memset(&my_addr, 0, sizeof(my_addr));
my_addr.sin_family = AF_INET;
my_addr.sin_addr.s_addr = htonl(INADDR_ANY); // 绑定所有本地IP
my_addr.sin_port = 0; // 让系统选端口
bind(sock, (struct sockaddr *)&my_addr, sizeof(my_addr));

这段代码的作用和sendto触发的隐式绑定是等价的——都是让系统分配一个随机可用端口，并且把套接字和这个端口绑定。

关于持久性 #

这种隐式绑定是持久的，一旦完成，这个套接字就会一直和该端口关联，直到套接字被关闭。也就是说，后续你再调用recvfrom或者sendto，都会使用这个已经绑定好的端口，不会每次调用都重新分配端口。这也是为什么客户端能收到服务器回复的原因：服务器从收到的UDP包中获取到客户端的源端口，然后把回复发送到这个端口，而客户端的套接字已经和这个端口绑定，recvfrom就能从这个端口读取到消息。

为什么不需要显式绑定？ #

UDP客户端通常不需要显式绑定端口，因为客户端的端口对服务器来说只是一个回复的目标，不需要固定。操作系统自动分配临时端口的机制已经足够可靠，而且能避免手动指定端口时可能遇到的端口冲突问题。

内容的提问来源于stack exchange，提问作者schrödinbug