操作系统内功 · 第 42 篇｜Socket 选项：SO_REUSEADDR、TCP_NODELAY 与陷阱清单

socket 选项（setsockopt）是最容易被「抄配置」的领域：网上抄一段 setsockopt(SO_REUSEADDR)、再加一行 TCP_NODELAY，程序似乎跑得更好了——但抄来的人多半说不清这两行到底改变了内核里的哪个判断，也解释不了为什么有时加了 REUSEADDR 照样 bind 失败。本篇挑出应用工程师最常接触、也最容易用错的五个选项：SO_REUSEADDR（重启服务的「救命稻草」与它的边界）、TCP_NODELAY（与延迟确认联手的 40ms 之约）、SO_KEEPALIVE（默认两小时才探一次的死连接漏洞）、SO_SNDBUF/SO_RCVBUF（设置了反而关闭自动调优的反直觉行为）、SO_LINGER（RST 关闭的得与失）。每个选项都从内核语义讲到线上故障形态——目标是下次遇到「Address already in use」或「偶发 40ms 延迟」时，你能直接说出机制层面的因果，而不是再抄一遍配置。

一、SO_REUSEADDR：它到底放行了什么

bind: Address already in use 的机理要先摆清楚：bind 失败的条件不是「端口被占用」这么笼统，而是「与某个现有 socket（不论状态）的四元组冲突且没有选项豁免」。TIME_WAIT 是最常见的元凶——主动关闭方（通常是服务端，因为服务端先发 FIN+ACK 完成四次挥手）的连接在关闭后停留 60 秒（tcp_fin_timeout 默认 60），这个状态下的 socket 仍占用着 local_ip:port，新进程 bind 同一个地址端口就会 EADDRINUSE。SO_REUSEADDR 的豁免规则在 Linux 上可以精确表述：允许 bind 一个「当前处于 TIME_WAIT 状态」的本机地址端口（严格说是：只要冲突方不处于 LISTEN 状态且不重叠到无法区分，就放行；对 LISTEN 中的 socket 仍然拒绝——它不能让你两个进程同时 listen 同一个端口，那是 SO_REUSEPORT 的事，本系列此前已有专文讲惊群与 REUSEPORT，此处不展开）。使用方式很简单：

flowchart LR
    A["服务运行中<br/>LISTEN 0.0.0.0:8080"] --> B["客户端断开<br/>服务端主动 close"]
    B --> C["旧 socket 进入 TIME_WAIT<br/>占用 8080 端口 60 秒"]
    C --> D{"新进程 bind 8080"}
    D -- "无选项" --> E["EADDRINUSE<br/>bind: Address already in use"]
    D -- "bind 前 setsockopt SO_REUSEADDR" --> F["放行，新服务正常 LISTEN"]
    F --> G["注：另一个活跃 LISTEN 仍被拒绝<br/>那是 SO_REUSEPORT 的领域"]

int on = 1;
setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
bind(listen_fd, ...);        /* 在 bind 之前设置，顺序不能反 */

两个工程细节。第一，必须在 bind 之前设置——setsockopt 只影响之后的行为，bind 完再设为时已晚，这是新手第一坑。第二，TIME_WAIT 挂在谁身上取决于谁主动关闭：服务端做「半关闭后等待客户端 FIN」是常见模式（先 shutdown 写端、read 到 EOF 再 close），这时 TIME_WAIT 挂在服务端进程已退出的 socket 上，新进程要 bind 就需要 REUSEADDR；如果把「主动关闭」让给客户端（协议上让客户端先发 FIN），服务端关闭后立即进入 CLOSED，bind 就不需要豁免——这是长连接网关设计中「谁主动断」的一个真实考量。另外 SO_REUSEADDR 对 UDP 与组播还有额外语义（允许不同端口复用同地址做组播接收），语义随协议变化，用之前查清当前平台的 man 7 socket——它也是少数「Windows 与 Linux 语义差异显著」的选项（Windows 上 SO_REUSEADDR 接近 Linux 的 REUSEPORT，能引发端口劫持），跨平台代码要小心。

二、TCP_NODELAY：与延迟确认联手的 40ms 之约

Nagle 算法的目标是减少小包：当连接上有「未确认的小段数据」时，后续小写入先攒在发送缓冲里，直到收到 ACK 或攒满一个 MSS 才发出。延迟确认（delayed ACK）是接收方的节俭策略：收到数据不立即回 ACK，等最多约 40ms，盼着捎带在响应数据里一起发。两个各自正确的优化相遇，会合演出一个经典的 40ms 卡顿：客户端 write-write（先发请求头、再发请求体，两次小写）→ Nagle 把第二段扣住等 ACK → 服务端收完第一段后按延迟确认等 40ms 才回 ACK → 客户端的第二段卡满 40ms 才出门。链路上的每一方都在「等对方」，这个互相等待就是 req/resp 协议（Redis 客户端、RPC 框架、数据库驱动）偶发 40ms 尖刺的标准成因——40ms 这个数字正是延迟确认定时器的典型时长，在抓包里看到「请求发出后 40.0ms 才有响应」基本可以直接怀疑这里。解法就是 TCP_NODELAY：

int on = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on));  /* 关闭 Nagle */

现代服务端框架（Redis、gRPC、Nginx 的上游连接）几乎默认开启它。但有两个更准确的姿势值得知道：其一，比「全局关 Nagle」更好的是消灭小写入本身——把两次 write 合并成一次（或用 writev 聚合），应用层攒够再发，Nagle 就没有触发的机会；高性能序列化框架的 buffer 复用本质上都在做这件事。其二，TCP_NODELAY 关的是 Nagle，不影响延迟确认——接收端的 40ms 由 TCP_QUICKACK（另一个选项，且内核随时可能按自己的判断退回延迟确认，它不是持久承诺）与 tcp_delack_min 等机制控制，单纯关 Nagle 解决不了「服务端响应被延迟确认拖住」的方向。所以遇到 40ms 尖刺，先抓包定位是哪个方向的等待（发送方 Nagle 还是接收方 delayed ACK），再对症选药。还有个新选项值得一提：Linux 4.13 引入的 TCP_NODELAY 之外的 TCP_CORK（「塞住」发送直到凑满或显式拔塞）适合「明确要成批发送」的场景——CORK 与 NODELAY 语义相反（一个憋大包、一个放小包），同一条连接不该同时开两个。

三、SO_KEEPALIVE：默认 7200 秒的空洞

TCP 自带的保活机制默认参数保守到近乎失效：tcp_keepalive_time 默认 7200 秒（2 小时）才开始探测，之后每 tcp_keepalive_intvl（75 秒）发一个探测包，连续 tcp_keepalive_probes（9 次）无响应才判死——从对端拔网线到本机感知，默认要等约 2 小时 11 分钟。代价是灾难性的：长连接网关上的死连接占着 fd、占着连接池与内存，负载均衡器后面的服务「连接数虚高」，真正的请求却被哈希到死连接上排队直到超时。开启与调参的完整四步：

int on = 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on));
/* 内核级全局参数（sysctl）：tcp_keepalive_time=7200, intvl=75, probes=9
   逐连接覆盖（Linux 2.4+）： */
int idle = 60, intvl = 10, cnt = 6;
setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE,  &idle, sizeof(idle));  /* 60s 空闲后开始探测 */
setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &intvl, sizeof(intvl)); /* 每 10s 一次 */
setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT,   &cnt,  sizeof(cnt));    /* 6 次失败判死 */

这套参数下，探测从 60 秒开始、共 6 次、间隔 10 秒——死连接在约 2 分钟内被识别（60 + 10×6 = 120s），代价只是每条空闲连接每分钟 1 个 66 字节的探测包，几乎可忽略。注意 keepalive 探测包是纯 TCP 层的 ACK（无载荷），不能替代应用层心跳：它只能证明「TCP 路径活着」，不能证明「对端应用还能干活」（对端进程 hang 死、内核活着的情况，keepalive 照样通过）；LB/NAT 中间设备也可能只按应用层流量清理映射表。所以成熟的连接治理是三层并用：TCP keepalive（网络层探活，约 2 分钟）+ 应用层心跳（应用可用性，秒级或十秒级）+ 空闲超时主动回收（连接池层的资源上限）。另外 keepalive 的计数器在 socket 关闭后无意义，对「半开连接」（对端突然掉电）它是最便宜的第一道探测器——这是它比应用心跳更底层、也更难被业务代码漏配的原因。

四、SO_SNDBUF/SO_RCVBUF：手动设置与自动调优的互斥

socket 缓冲区有一个反直觉的机制：手动 setsockopt 一次，内核的自动调优就永久退出。Linux 的 TCP 自动调优（tcp_rmem/tcp_wmem 三元组：min/default/max）会按带宽时延积（BDP）动态伸缩缓冲区，长肥管道（高带宽、高延迟，比如跨国链路）能自动把接收缓冲撑到几十 MB 以填满管道；一旦应用手动 setsockopt(SO_SNDBUF, ...)，该连接的发送缓冲就被钉死在你给的值上，自动调优对发送方向永久失效（接收方向同理，且内核实际分配的缓冲是你设置值的约 2 倍，因为要留协议头/元数据余量）。手动设小了——比如抄了某篇老文章的 SO_SNDBUF=65536——在 100ms RTT × 1Gbps 的链路上，吞吐被钳制在 64KB/0.1s ≈ 5Mbps，管道容量明明可以到 Gbps 级。这解释了「为什么设置了缓冲区反而更慢」的经典困惑。正确的姿势分场景：绝大多数服务不要碰这两个选项，让 tcp_wmem/tcp_rmem 的默认 max（现代内核通常 4MB～16MB）与自动调优工作；确实要限上限（防止慢客户端占内存）时，优先调全局 sysctl（tcp_rmem max、tcp_mem），让自动调优在新的天花板内继续工作；只在「必须硬限制单连接内存」的场景（如海量连接网关按连接数核算内存预算）才手动设置，且要按 BDP 计算而不是拍脑袋。查询当前生效值用 getsockopt 而不是想当然：

int sz; socklen_t len = sizeof(sz);
getsockopt(fd, SOL_SOCKET, SO_SNDBUF, &sz, &len);
printf("sndbuf=%d\n", sz);   /* 内核返回实际值（已含翻倍），可能远大于你设置的值 */

五、SO_LINGER 与剩余选项速查

SO_LINGER 控制 close 的行为模式：默认关闭时 close 走「优雅关闭」——内核把发送缓冲里未发完的数据继续发完，然后走四次挥手，进程不等（close 立即返回，挥手在内核后台完成）。打开并设 l_onoff=1, l_linger=0 则是硬关闭：close 直接发 RST，跳过挥手、丢弃未发数据、不进 TIME_WAIT。它的正面用途很窄：UDP 场景用 {1,0} 关闭以避免后续 ICMP 报错堆积；HTTP 客户端确认响应已完整接收后用 RST 快速释放避免 TIME_WAIT 堆积（激进但有效）；调试时强制复现「对端收到 RST」的场景。负面代价要记牢：RST 会丢掉发送缓冲里未发出的数据（对端可能已发送的窗口内数据也被丢弃），且对端收到 RST 时读到的是 ECONNRESET 而非 EOF——依赖「读到 EOF 才收尾」的协议逻辑会被打断。生产代码里 SO_LINGER 的默认建议是不开，除非你能明确说清为什么需要 RST。其余高频选项一张表带过：SO_RCVTIMEO/SO_SNDTIMEO（阻塞 read/write 的超时，注意对非阻塞 socket 与信号中断的行为差异，现代做法是整体 nonblocking + epoll + 自管超时）；SO_BROADCAST（UDP 广播许可）；SO_BINDTODEVICE（绑定网卡，抓包/旁路工具常用，需 CAP_NET_RAW）；IP_PKTINFO（让服务端知道请求到达的本机 IP，多地址服务器必须开，否则 reply 的源地址可能选错）；TCP_DEFER_ACCEPT（连接只到「有数据到达」才唤醒 accept 队列，抗 SYN-only 扫描）；SO_INCOMING_CPU/SO_ATTACH_REUSEPORT_CBPF（配合多队列网卡做 CPU 亲和分流，高性能网关进阶）。

小结

socket 选项的价值不在「抄配置」，而在理解它改变的是内核里哪个判断。SO_REUSEADDR 放行的是 TIME_WAIT 上的 bind（LISTEN 冲突依旧拒绝，同端口多进程是 SO_REUSEPORT 的领域），必须在 bind 前设置，主动关闭方的归属决定了谁需要它。TCP_NODELAY 关闭 Nagle，治的是「小写入 × 延迟确认」合谋的 40ms 尖刺，但更根本的解法是消灭小写入本身；它管不了接收端的 delayed ACK，方向要靠抓包定位。SO_KEEPALIVE 默认 7200 秒的探测起点近乎无用，TCP_KEEPIDLE/INTVL/CNT 三件套把它调成 2 分钟级死连接探测器，但它只探网络路径，应用可用性还得靠应用层心跳。SO_SNDBUF/SO_RCVBUF 的手动设置会永久退出 TCP 自动调优，绝大多数服务不该碰，限内存优先动 sysctl 天花板。SO_LINGER 的 RST 模式丢数据、破 EOF 语义，默认不开。这些选项的共同纪律是：先弄清故障形态（bind 失败？40ms？死连接堆积？带宽上不去？），再按机制选药——选项清单只是药方，机制理解才是医生。