2、SO_REUSEADDR 详解：SO_REUSEADDR 的作用、解决 TIME_WAIT 问题、多进程绑定同一端口

SO_REUSEADDR 这个选项，说白了就是告诉内核：「这个端口我还能再用一次」。很多刚入行的朋友觉得它很神秘，其实没那么复杂。我最早接触它是在做一个高并发网关的时候，服务重启后老是报端口被占用，折腾了半天才发现是 TIME_WAIT 在搞鬼。

2.1 SO_REUSEADDR 到底干了什么？

先看它的官方定义：允许重用本地地址和端口。但这句话太抽象了。我换个说法——它允许你在端口还处于 TIME_WAIT 状态时，强行把它绑回来。

正常情况下，一个端口被释放后，内核会留一个 TIME_WAIT 的冷却期。这个期间你要是想重新 bind 这个端口，系统会直接拒绝。但如果你设置了 SO_REUSEADDR，内核就会放行。

嗯，这里要注意：不是所有场景都能随便用。我见过有人把它当成万能药，结果出了不少诡异的问题。

2.2 解决 TIME_WAIT 问题

TIME_WAIT 是 TCP 主动关闭连接的一方会进入的状态，持续 2MSL（大约 1-4 分钟）。为什么要有这个状态？说白了就是为了防止最后一个 ACK 丢失，导致对端重发 FIN。

但问题来了——如果你的服务需要频繁重启，或者短连接特别多，TIME_WAIT 的端口就会堆积。端口资源是有限的，一旦耗尽，新连接就建立不了。

我曾经在一个压测环境里遇到过：每秒几千个短连接，跑几分钟后服务就报 bind: Address already in use。查了一下，TIME_WAIT 的 socket 占了上千个。

解决方案很简单：

int opt = 1;
if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
    perror("setsockopt");
    exit(1);
}

这段代码放在 bind() 之前。加了之后，即使端口还处于 TIME_WAIT，也能直接绑定成功。

2.3 多进程绑定同一端口

这个功能很多人不知道。SO_REUSEADDR 配合 fork，可以让多个进程监听同一个端口。内核会自动把进来的连接分发给其中一个进程。

典型的应用场景：

• Apache 的 prefork 模式
• Nginx 的多 worker 进程
• 自己写的简单并发服务器

实现方式：

int sockfd = socket(AF_INET, SOCK_STREAM, 0);
int opt = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(8080);
addr.sin_addr.s_addr = INADDR_ANY;

bind(sockfd, (struct sockaddr*)&addr, sizeof(addr));
listen(sockfd, 128);

for (int i = 0; i < 4; i++) {
    if (fork() == 0) {
        // 子进程直接 accept
        while (1) {
            int client = accept(sockfd, NULL, NULL);
            // 处理客户端请求
            close(client);
        }
    }
}
// 父进程等待
wait(NULL);

注意看：所有子进程共享同一个 listen socket。谁先抢到 accept 谁就处理。这种模型在 Linux 上跑得很稳。

2.4 SO_REUSEADDR 与 SO_REUSEPORT 的区别

很多人把这两个搞混。我直接给个表格，一目了然：

特性	SO_REUSEADDR	SO_REUSEPORT
主要用途	跳过 TIME_WAIT，快速重启	多进程/多线程负载均衡
多进程绑定	需要先启动一个进程 bind，再 fork	每个进程独立 bind 同一个端口
内核分发策略	谁先 accept 谁处理	内核做负载均衡（4.5+ 内核支持）
安全性	低，其他用户也能绑定	高，只有相同 uid 的进程能绑定
跨平台	几乎所有平台都支持	Linux 3.9+，其他平台支持有限

简单总结：

• 想解决 TIME_WAIT 问题 → 用 SO_REUSEADDR
• 想做多进程负载均衡 → 优先考虑 SO_REUSEPORT（Linux 上）
• 老系统或跨平台 → 用 SO_REUSEADDR + fork

2.5 知识体系图

下面这张图把 SO_REUSEADDR 的核心逻辑串起来了：

2.6 避坑指南

最后分享几个我踩过的坑：

1. 不要对客户端 socket 设置 SO_REUSEADDR——客户端用随机端口，没必要重用。我见过有人对 connect 的 socket 也设了这个，结果端口冲突了。
2. UDP 也能用 SO_REUSEADDR——多播场景下特别有用。多个进程可以同时接收同一个多播地址的数据。
3. Windows 上的行为不一样——Windows 的 SO_REUSEADDR 允许完全相同的地址和端口重复绑定，这可能导致数据混乱。跨平台代码要小心。
4. 安全风险——恶意程序可以绑定你的端口，劫持流量。关键服务建议加上 SO_EXCLUSIVEADDRUSE（Windows）或使用 SO_REUSEPORT 的 uid 检查机制。