第十四章：套接字选项——掌控连接的“隐形开关”

套接字选项，说白了就是操作系统给咱们程序员留的一堆“小旋钮”。你可以拧一拧，调一调，让 TCP 连接按照你想要的方式工作。我刚开始学网络编程时，总觉得这些选项可有可无，直到线上服务出了几次诡异的问题……嗯，从那以后，我再也不敢小看它们了。

14.1 为什么需要套接字选项？

你想想看，一个 socket 创建出来，默认的行为是操作系统定的。但实际场景千奇百怪：

• 服务器崩溃重启后，端口还被占用着，怎么办？
• 发送小数据包时，Nagle 算法非要攒一堆再发，延迟受不了怎么办？
• 接收缓冲区太小，大流量一来就丢包，怎么办？

这些问题的答案，就藏在 getsockopt() 和 setsockopt() 这两个函数里。它们就是操作套接字选项的“钥匙”。

14.2 两个核心函数：getsockopt() 和 setsockopt()

先看原型，其实很简单：

#include <sys/socket.h>

int getsockopt(int sockfd, int level, int optname,
               void *optval, socklen_t *optlen);

int setsockopt(int sockfd, int level, int optname,
               const void *optval, socklen_t optlen);

参数解释一下：

• sockfd：你创建的套接字描述符
• level：选项所在的协议层，比如 SOL_SOCKET（通用层）、IPPROTO_TCP（TCP 层）
• optname：选项的名字，比如 SO_REUSEADDR
• optval：选项值的缓冲区指针
• optlen：值的长度（getsockopt 是传入传出参数）

我个人习惯把 setsockopt 放在 bind() 之前调用，尤其是 SO_REUSEADDR。为什么？下面马上说。

14.3 SO_REUSEADDR——端口复用的“后悔药”

这个选项是我在项目中遇到最多坑的地方。先看一个典型场景：

你写了一个 HTTP 服务器，监听 8080 端口。某次你 Ctrl+C 停掉它，然后立刻重启。结果——bind: Address already in use！

为什么会这样？因为 TCP 的 TIME_WAIT 状态。主动关闭连接的一方，会进入 TIME_WAIT 状态，持续 2MSL（大约 1-4 分钟）。在这段时间里，端口被系统“锁住”了。

解决办法？在 bind() 之前加上这行：

int optval = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));

14.4 TCP_NODELAY——告别 Nagle 算法的“拖延症”

Nagle 算法是 TCP 的一个优化：它会把多个小数据包攒起来，等到确认收到前一个包后再一起发。目的是减少小包数量，提高网络利用率。

但有些场景下，这个“攒包”行为是灾难性的：

• 实时游戏：每个操作都要立刻发出去，不能等
• SSH 终端：你敲一个字符，希望立刻看到回显
• WebSocket 推送：延迟越低越好

这时候就需要禁用 Nagle 算法：

int optval = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(optval));

14.5 SO_RCVBUF 和 SO_SNDBUF——缓冲区大小的“调音台”

每个 TCP 连接都有两个缓冲区：接收缓冲区和发送缓冲区。默认大小通常是 64KB 或 128KB，但具体看系统。

什么时候需要调大？

• 高带宽延迟乘积（BDP）场景：比如跨洲传输，带宽 100Mbps，延迟 200ms，默认缓冲区根本不够用
• 大流量下载服务器：缓冲区大一点，吞吐量能上去

什么时候需要调小？

• 嵌入式设备：内存紧张，能省则省
• 实时性要求高的场景：缓冲区太大反而增加延迟

int rcvbuf = 256 * 1024;  // 256KB
setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));

int sndbuf = 256 * 1024;  // 256KB
setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &sndbuf, sizeof(sndbuf));

14.6 SO_KEEPALIVE——检测死连接的“心跳线”

TCP 本身是“无感知”的。如果一端突然断电、网线被拔，另一端可能永远不知道，直到下次尝试发送数据。

SO_KEEPALIVE 就是用来解决这个问题的。它会让内核定期发送探测包，检查对端是否还活着。

int optval = 1;
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof(optval));

默认的探测间隔是 2 小时，太长了。你可以通过 /proc/sys/net/ipv4/tcp_keepalive_time 等系统参数调整。不过更灵活的做法是自己在应用层实现心跳——我一般这么干，因为可控性更强。

14.7 其他常用选项一览

选项名	层级	作用	典型场景
SO_LINGER	SOL_SOCKET	控制 close() 的行为：是否等待未发送数据发完	需要确保数据全部发送后再关闭连接
SO_BROADCAST	SOL_SOCKET	允许发送广播数据包	UDP 广播场景
TCP_CORK	IPPROTO_TCP	类似 Nagle 但更激进：攒够一定量再发	HTTP 响应头+体的合并发送
SO_TIMESTAMP	SOL_SOCKET	在接收的数据包上附加时间戳	网络延迟测量、PTP 时间同步

14.8 知识体系总览

下面这张图，是我自己梳理的套接字选项知识结构。你可以把它当作一个“速查地图”：

14.9 实战建议：什么时候该用哪个？

我根据多年经验，整理了一个“决策速查”：

• 写服务器：SO_REUSEADDR 是标配，TCP_NODELAY 看业务需求
• 写客户端：一般不需要改选项，除非有特殊延迟要求
• 写实时应用：TCP_NODELAY + 调小缓冲区
• 写下载工具：调大 SO_RCVBUF，让吞吐量跑满
• 写心跳检测：要么用 SO_KEEPALIVE，要么自己实现应用层心跳（我推荐后者）