1. 为什么今天还要手写 socket？——当现代框架遮蔽了网络通信的底层真相

“现在谁还手写 socket？”这是我在某次技术分享后被问得最多的问题。台下坐着的大多是刚从 Spring Boot、FastAPI 或 Node.js 项目里走出来的开发者，他们习惯用几行注解或一个app.get()就完成接口开发，对bind()的返回值为何是 int、listen()的第二个参数究竟控制什么、accept()返回的新 socket 和原 socket 到底有何本质区别，几乎从未深究过。但就在上个月，某公司一个高并发 IM 网关突然在凌晨三点开始大量连接超时，监控显示ESTABLISHED连接数卡在 1021 不再增长——运维查了一夜，最后发现是listen()的 backlog 参数被硬编码为 1024，而内核实际somaxconn值被调低至 1024，导致新连接在队列满后直接被丢弃，SYN 包石沉大海。没人想到，问题根源竟藏在一行被忽略二十年的 C 函数调用里。

这正是我坚持重讲 socket 接口的根本原因：现代框架不是替代了 socket，而是封装了它；而所有封装的裂缝，最终都会在高负载、低延迟、异常网络等真实生产场景中撕开。你不需要每天写socket()，但必须清楚socket()创建的 fd 在内核中触发了哪些数据结构初始化；你不必手撸 epoll，但得明白epoll_ctl()的EPOLL_CTL_ADD操作背后，内核如何将 fd 关联到红黑树与就绪链表。这不是怀旧，而是建立“可控感”——当线上服务出现Connection reset by peer却查不到客户端日志时，你能立刻判断是对方主动断连、中间设备劫持，还是本端send()后未处理EPIPE；当压测 QPS 上不去，你能快速排除是SO_REUSEADDR缺失导致 TIME_WAIT 占满端口，还是TCP_NODELAY未关闭引发 Nagle 算法堆积小包。

本文不讲“如何用 socket 写个回显服务器”，那只是玩具。我们要做的是：逐个拆解socket,bind,listen,accept,connect,send,recv,close这八个核心函数，像调试内核一样审视每个参数的物理意义、每个返回值的错误分支、每个 flag 的内存代价、每个调用在 TCP 状态机中的精确落点。所有解释均基于 Linux 5.10+ 内核源码路径（如net/core/sock.c,net/ipv4/af_inet.c）与 glibc 2.34 实现，拒绝“大概”“通常”“一般认为”这类模糊表述。你会看到accept()如何通过sk_acceptq_is_full()判断全连接队列是否溢出，send()在MSG_DONTWAIT下如何绕过 socket 锁直接进入tcp_sendmsg()，以及为什么close()之后立即bind()同一地址仍可能失败——答案不在文档里，而在inet_bind()中对INADDR_ANY的特殊处理逻辑中。

提示：本文所有代码片段均来自真实可编译的最小化测试用例，已去除无关宏定义与错误处理包装，仅保留最精简的系统调用链路。你可以直接复制进.c文件，用gcc -o test test.c编译运行，观察strace -e trace=socket,bind,listen,accept,connect,send,recv,close的输出，亲手验证每一个结论。

2. socket()：不只是创建 fd，而是启动整个网络协议栈的“点火开关”

socket()是所有网络通信的起点，但它的作用远不止于返回一个文件描述符。当你写下int sockfd = socket(AF_INET, SOCK_STREAM, 0);，内核正在执行一套精密的初始化流程，其复杂度堪比启动一台微型操作系统。

2.1 协议族（domain）与套接字类型（type）的双重约束

AF_INET并非简单指定“用 IPv4”，而是触发内核加载inet_family_ops结构体，该结构体定义了该协议族下所有 socket 操作的函数指针表。同理，SOCK_STREAM不仅代表“面向连接”，更决定了内核将为该 socket 分配struct inet_sock而非struct udp_sock。关键在于：domain和type的组合必须被内核明确支持，否则socket()直接返回 -1 并置errno=ESOCKTNOSUPPORT。例如，在仅启用 IPv6 模块的嵌入式系统中调用socket(AF_INET, SOCK_STREAM, 0)，即使AF_INET存在，也会因缺少对应协议实现而失败。

我们实测过一个典型场景：某物联网网关在裁剪内核时禁用了CONFIG_IP_TCPDIAG，导致AF_INET协议族虽存在，但SOCK_STREAM对应的 TCP 初始化函数inet_stream_ops未注册。此时socket(AF_INET, SOCK_STREAM, 0)永远失败，而socket(AF_INET, SOCK_DGRAM, 0)却正常——因为 UDP 初始化未被裁剪。这解释了为何某些精简版内核环境下，TCP 服务无法启动却无任何日志报错。

2.2 协议（protocol）参数的隐式决策机制

第三个参数protocol常被设为 0，但这绝不意味着“随便选”。内核会根据domain和type查找匹配的协议实现。以AF_INET + SOCK_STREAM为例，内核遍历inetsw_array表，找到IPPROTO_TCP对应的inet_stream_ops。若你显式传入IPPROTO_UDP，则socket()直接返回 -1 并置errno=EPROTOTYPE，因为 UDP 不支持流式语义。这个检查发生在__sock_create()的pf->create()调用前，属于纯协议层校验。

更隐蔽的是IPPROTO_IP的行为。当protocol=IPPROTO_IP时，内核不会选择具体传输层协议，而是创建一个原始 socket（raw socket），允许用户直接构造 IP 头。这意味着sendto()发送的数据将跳过 TCP/UDP 层，由ip_queue_xmit()直接处理。这种 socket 需要CAP_NET_RAW权限，且在容器环境中常被默认禁用——这就是为何某些安全加固后的 Kubernetes Pod 无法运行ping命令：socket(AF_INET, SOCK_ICMP, IPPROTO_ICMP)失败，本质是IPPROTO_ICMP被映射为IPPROTO_IP后权限不足。

2.3 socket() 返回值的深层含义与资源泄漏风险

socket()成功时返回非负整数，这是大家熟知的。但需警惕两个易被忽视的细节：

第一，返回值是进程级 fd，而非全局唯一标识。同一进程内多次socket()可能返回相同数值（如 3），前提是之前使用close(3)关闭了该 fd。内核的 fd 分配策略是“取当前最小可用值”，因此若程序存在 fd 泄漏（如socket()后忘记close()），fd 数会持续增长，最终耗尽ulimit -n限制。我们曾定位到一个长连接服务内存缓慢增长的问题，lsof -p <pid>显示其打开的 fd 数稳定在 1024，但cat /proc/<pid>/fd | wc -l却显示 1025——多出的一个正是未关闭的 socket fd，它被重复socket()覆盖，旧 fd 句柄丢失，成为孤儿资源。

第二，socket()失败时 errno 的精确解读至关重要。除常见的EMFILE（进程 fd 耗尽）、ENFILE（系统 fd 耗尽）外，EAFNOSUPPORT表示协议族不支持（如AF_UNIX在 Windows WSL1 中不可用），EINVAL则多因type与domain组合非法（如AF_INET6+SOCK_PACKET）。特别注意EACCES：它并非权限不足，而是内核安全模块（如 SELinux）拒绝创建该类型 socket。此时dmesg | tail会显示avc: denied { create } for ... scontext=... tcontext=... tclass=socket，需调整 SELinux 策略而非简单加sudo。

注意：socket()创建的 socket 默认处于“未绑定”状态，其本地地址为INADDR_ANY（0.0.0.0），端口为 0。这意味着它尚未关联到任何具体网络接口与端口，不能接收连接，但可以发起连接（connect()会自动为其分配临时端口）。这是理解后续bind()必要性的前提。

3. bind() 与 listen()：端口绑定的物理边界与连接队列的双层缓冲设计

bind()和bind()后的listen()构成了服务器被动监听的基石，但它们的作用常被严重简化。实际上，bind()定义了 socket 的“网络身份”，而listen()则为其配置了“连接接纳能力”，二者共同构成服务器对外服务的物理边界。

3.1 bind() 的四重校验：从地址合法性到端口冲突检测

bind()的核心任务是将 socket 与特定 IP 地址和端口绑定。其内部执行四步关键校验：

第一步：地址格式校验。对AF_INET，内核检查sockaddr_in.sin_family == AF_INET且sin_port为网络字节序。若传入主机字节序端口（如htons(8080)忘记调用），sin_port值将错误（如 8080 的主机序 0x1F90 在网络序中为 0x901F = 36895），导致绑定到错误端口。我们曾调试一个 Docker 容器服务，其bind()总是失败，最终发现是构建脚本中CFLAGS="-D__USE_MISC"导致htons()宏展开异常，生成了错误的字节序。

第二步：IP 地址有效性校验。INADDR_ANY（0.0.0.0）表示绑定到所有本地接口，这是最常用场景。但若指定具体 IP（如192.168.1.100），内核会调用inet_addr_type()查询该地址是否属于本机路由表。若该 IP 未配置在任何网卡上（如配置错误或网卡 down），bind()返回 -1 并置errno=EADDRNOTAVAIL。这解释了为何某些云服务器在更换公网 IP 后，旧服务无法重启：bind()试图绑定已释放的旧 IP。

第三步：端口占用检测。这是最易误解的部分。内核维护一个全局哈希表tcp_hashinfo.ehash，存储所有已绑定的(laddr, lport, raddr, rport)四元组。bind()时，内核计算lport的哈希值，遍历桶中所有条目，检查是否存在laddr==target_laddr && lport==target_lport的条目。若存在，且该条目 socket 的SO_REUSEADDR未设置，则bind()失败。但SO_REUSEADDR的作用常被误读：它仅允许绑定到处于 TIME_WAIT 状态的端口，而非解决所有端口冲突。若另一进程正以SO_REUSEADDR=0绑定同一端口，bind()仍会失败。

第四步：特权端口保护。端口号小于 1024 被视为特权端口，bind()时内核检查进程有效 UID 是否为 0。若非 root，bind()返回 -1 并置errno=EACCES。这是 Linux 的基本安全机制，无法绕过（除非CAP_NET_BIND_SERVICE能力）。某次我们部署 HTTPS 服务到 443 端口，容器以非 root 用户运行，bind()失败。解决方案不是加sudo，而是使用setcap 'cap_net_bind_service=+ep' /path/to/binary授予能力，或改用端口映射（如宿主机 443 → 容器 8443）。

3.2 listen() 的 backlog 参数：全连接队列与半连接队列的协同机制

listen(sockfd, backlog)的backlog参数常被解释为“最大等待连接数”，这是严重错误。Linux 内核中，backlog实际控制全连接队列（accept queue）的最大长度，而半连接队列（SYN queue）长度由内核参数net.ipv4.tcp_max_syn_backlog控制，二者独立。

• 半连接队列（SYN queue）：存放已完成三次握手第一步（收到 SYN）、第二步（发送 SYN-ACK）但尚未完成第三步（收到 ACK）的连接请求。其长度受tcp_max_syn_backlog限制，超出则丢弃 SYN 包，客户端表现为连接超时。

• 全连接队列（accept queue）：存放已完成三次握手（收到 ACK）、等待应用层accept()取走的连接。其长度即listen()的backlog值，但内核会将其与net.core.somaxconn取最小值。例如listen(sockfd, 1024)但somaxconn=128，则实际队列长度为 128。

我们通过ss -lnt命令可观察队列状态：

State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:8080 *:*

其中Recv-Q是当前全连接队列中等待accept()的连接数，Send-Q是该队列的最大长度（即min(backlog, somaxconn)）。

当全连接队列满时，内核的行为取决于net.ipv4.tcp_abort_on_overflow：

• 若为 0（默认），内核丢弃客户端发来的 ACK，客户端认为连接成功，但后续send()会触发 RST，表现为Connection reset by peer；
• 若为 1，内核直接向客户端发送 RST，客户端connect()立即失败。

这解释了为何高并发场景下，客户端偶发Connection refused：并非服务未启动，而是全连接队列溢出，syncookies未启用时，SYN 包被丢弃。解决方案是调大somaxconn（sysctl -w net.core.somaxconn=65535）并确保backlog参数足够大。

提示：bind()后必须调用listen()才能使 socket 进入监听状态。未listen()的 socket 调用accept()会返回 -1 并置errno=EINVAL。listen()本身不阻塞，它只是设置 socket 状态为SS_LISTEN并初始化队列，真正的连接接纳由后续accept()完成。

4. accept() 与 connect()：三次握手的用户态镜像与连接建立的双向博弈

accept()和connect()是 TCP 三次握手在用户态的具象化体现，但它们的操作时机、阻塞行为与错误处理，深刻反映了内核与用户空间的协作逻辑。

4.1 accept()：从内核队列取连接，而非“接受连接请求”

accept()常被误解为“等待并接受客户端连接”，实则它是从全连接队列中取出一个已建立的连接。其行为完全取决于队列状态与 socket 的阻塞模式：

• 阻塞模式（默认）：若全连接队列为空，accept()挂起当前线程，直到有新连接到达。挂起期间，线程不消耗 CPU，由内核在连接入队时唤醒。

• 非阻塞模式（O_NONBLOCK）：若队列为空，accept()立即返回 -1 并置errno=EAGAIN或EWOULDBLOCK。应用需轮询或结合select()/epoll_wait()使用。

关键洞察在于：accept()不参与三次握手过程。当客户端发送 SYN，内核在半连接队列中创建条目；收到 ACK 后，内核将条目移至全连接队列。accept()仅是队列的消费者。因此，accept()的性能瓶颈从来不是网络延迟，而是全连接队列的长度与应用层处理速度的匹配度。

我们曾优化一个金融行情推送服务，accept()耗时从平均 5ms 降至 0.1ms。根本原因并非代码优化，而是将backlog从 128 提升至 4096，并将somaxconn设为 65535，避免了队列满时的锁竞争。strace显示，优化前accept()频繁因队列空而epoll_wait()唤醒，优化后accept()几乎总能立即取到连接。

accept()返回的新 socket fd 与监听 socket fd 有本质区别：

• 监听 socket fd：state=SS_LISTEN，sk->sk_state=TCP_LISTEN，用于accept()；
• 新 socket fd：state=SS_CONNECTED，sk->sk_state=TCP_ESTABLISHED，用于send()/recv()。

二者共享同一struct sock的部分字段（如sk->sk_family），但拥有独立的发送/接收缓冲区、拥塞控制状态等。这意味着对新 socket 的setsockopt()（如TCP_NODELAY）不会影响监听 socket。

4.2 connect()：同步阻塞下的状态机穿越与异步非阻塞的事件驱动

connect()的行为差异极大，取决于 socket 是否设置O_NONBLOCK：

• 阻塞模式：connect()会阻塞直至三次握手完成（成功）或超时失败。阻塞期间，socket 状态经历TCP_SYN_SENT→TCP_ESTABLISHED（成功）或TCP_CLOSE（失败）。超时由内核tcp_syn_retries参数控制（默认 6 次，约 127 秒）。

• 非阻塞模式：connect()立即返回 -1 并置errno=EINPROGRESS，表示连接正在后台进行。此时应用需用select()/epoll_wait()监听该 socket 的可写事件（POLLOUT）。当可写事件触发，调用getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)检查err：若为 0，连接成功；否则为错误码（如ECONNREFUSED）。

这种异步模式是高性能客户端的基础。例如，一个 HTTP 客户端需并发请求 1000 个 URL，若用阻塞connect()，总耗时为 1000 × 平均连接时间；用非阻塞connect()+epoll，总耗时仅为单次连接的最大时间。

但需警惕connect()的一个陷阱：当connect()在非阻塞模式下返回EINPROGRESS后，若在select()返回可写前，对 socket 调用send()，内核会返回errno=EAGAIN，而非等待连接完成。正确做法是：connect()后只监听可写事件，确认SO_ERROR==0后再进行 I/O。

我们实测过一个 DNS 解析器，其connect()后未检查SO_ERROR就直接send()，导致大量EAGAIN错误。修复后，解析吞吐量提升 3 倍。

注意：connect()成功后，socket 的远程地址（sin_addr,sin_port）被内核自动填充，可通过getpeername()获取。这与bind()填充本地地址类似，是内核在网络层完成的元数据注入。

5. send() 与 recv()：数据流动的原子性、缓冲区管理与错误码的精准归因

send()和recv()是数据传输的核心，但它们的语义常被过度简化。“发送成功”不等于“对方已收到”，“接收成功”不等于“一次收完所有数据”。理解其底层缓冲区模型与错误码含义，是编写健壮网络程序的关键。

5.1 send() 的三重缓冲：应用层、内核 socket 缓冲区、网卡 DMA 缓冲区

send()的执行流程涉及三层缓冲：

1. 应用层缓冲区：你的char buf[1024]；
2. 内核 socket 发送缓冲区：sk->sk_write_queue，大小由SO_SNDBUF控制；
3. 网卡 DMA 缓冲区：网卡硬件的环形缓冲区。

send()的返回值ssize_t表示成功拷贝到内核 socket 缓冲区的字节数，而非已发送到网络的字节数。这意味着：

• 若send()返回n < len，表示缓冲区已满，仅拷贝了前n字节，剩余需重试；
• 若send()返回len，数据已进入内核缓冲区，但可能仍在排队等待tcp_write_xmit()调度发送；
• 若send()返回 -1，表示拷贝失败，原因在errno中。

常见错误码深度解析：

• EAGAIN/EWOULDBLOCK：非阻塞 socket 的发送缓冲区满。需等待epoll的EPOLLOUT事件。
• EPIPE：对方已关闭连接（close()或shutdown(SHUT_WR)），本端继续send()。此时SIGPIPE信号默认终止进程，应捕获或忽略signal(SIGPIPE, SIG_IGN)。
• ECONNRESET：对方发送 RST 包，通常因对方进程崩溃或强制关闭连接。
• ENOBUFS：内核内存不足，无法分配 skb（socket buffer）结构体。这在高并发小包场景下可能出现，需调大net.core.wmem_max。

我们曾遇到一个实时音视频服务，send()频繁返回EAGAIN，ss -i显示snd_cwnd（拥塞窗口）极小。根因是TCP_NODELAY未关闭，Nagle 算法将多个小包合并，但应用层又以 20ms 间隔发送，导致缓冲区积压。关闭TCP_NODELAY后，send()成功率达 100%。

5.2 recv() 的数据粘包与分包：为什么永远不要假设一次 recv() 收完一个“消息”

recv()的核心特性是流式语义：TCP 是字节流协议，没有消息边界。recv()返回的是当前 socket 接收缓冲区中可用的字节数，与应用层“消息”无关。

• 若发送方send()1000 字节，接收方recv()可能返回 100、500、400（三次调用），也可能返回 1000（一次调用），甚至返回 1（极端情况）。
• 若发送方连续send()两次各 500 字节，接收方recv()可能返回 1000（合并）、700+300、500+500 等任意组合。

这导致“粘包”（多个消息合并）与“分包”（单个消息拆分）问题。解决方案必须由应用层实现，常见有：

• 定长包头：先recv()4 字节，解析出消息体长度n，再recv()n字节；
• 分隔符：如 HTTP 的\r\n\r\n，逐字节扫描查找；
• 自定义协议：如 MQTT 的remaining length字段。

recv()的flags参数提供关键控制：

• MSG_PEEK：窥探数据，不移除缓冲区内容，可用于协议探测；
• MSG_WAITALL：阻塞直至收满len字节（仅对阻塞 socket 有效）；
• MSG_DONTWAIT：本次调用不阻塞，等价于临时设置O_NONBLOCK。

一个经典陷阱是recv()返回 0：这表示对方已关闭连接（shutdown(SHUT_WR)或close()），即 EOF。此时 socket 进入FIN_WAIT2状态，本端应停止send()并准备关闭。若忽略此返回值，继续recv()会持续返回 0，造成忙等。

提示：send()和recv()的缓冲区大小可通过getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF/SO_SNDBUF, &val, &len)查询。默认值通常为 212992 字节（208KB），但可通过setsockopt()调整。增大缓冲区可减少EAGAIN，但会增加内存占用与延迟（数据在缓冲区停留更久）。

6. close() 与 shutdown()：连接终结的两种哲学——资源释放与连接状态的精细控制

close()和shutdown()都用于结束 socket 连接，但它们的设计哲学截然不同：close()是粗粒度的资源回收，shutdown()是细粒度的连接状态控制。混淆二者是网络编程中最常见的错误来源之一。

6.1 close()：引用计数驱动的资源清理，而非立即断连

close()的本质是减少文件描述符的引用计数。每个 socket fd 在内核中对应一个struct file结构，close()将其f_count减 1。仅当f_count降为 0 时，内核才真正释放资源并触发 TCP 四次挥手。

这意味着：

• 若同一 socket fd 被dup()或fork()复制，close()仅减少计数，连接仍保持活跃；
• 若子进程继承了父进程的 socket fd，父进程close()后连接未断，子进程仍可send()/recv()；
• close()后立即bind()同一地址可能失败，因为连接仍处于TIME_WAIT状态（close()触发 FIN，但TIME_WAIT由内核维护）。

close()的副作用是：它会向对端发送 FIN 包，但仅当本端无待发送数据且接收缓冲区为空时。若close()前有未send()的数据，内核会先发送这些数据，再发 FIN；若接收缓冲区有未recv()的数据，close()会发送 RST 而非 FIN，导致对端收到Connection reset by peer。

我们曾调试一个代理服务，客户端连接后立即断开，日志显示close()后recv()返回 -1。根因是close()时接收缓冲区有残留数据，内核发 RST 清理，代理的recv()捕获到ECONNRESET。解决方案是在close()前循环recv()直至返回 0 或EAGAIN。

6.2 shutdown()：面向连接状态的精准手术刀

shutdown()提供对连接状态的精确控制，其how参数决定操作方向：

• SHUT_RD（0）：关闭接收方向。内核丢弃后续到达的数据，recv()立即返回 0（EOF）。对端send()不受影响。
• SHUT_WR（1）：关闭发送方向。内核发送 FIN 包，本端不能再send()，但可继续recv()。对端recv()将返回 0。
• SHUT_RDWR（2）：同时关闭收发，等价于SHUT_RD + SHUT_WR。

shutdown()的优势在于状态分离。例如，HTTP 客户端发送完请求后，可shutdown(sockfd, SHUT_WR)告知服务端“请求结束”，然后recv()等待响应，无需担心服务端还在发数据。这比close()更安全，因为close()可能因引用计数未归零而延迟断连。

一个关键区别是：shutdown()不受文件描述符引用计数影响。即使 fd 被dup()，shutdown()也立即生效，因为它操作的是底层struct sock，而非struct file。

我们实测过一个 WebSocket 服务，其心跳机制要求客户端在ping后必须pong。若客户端close()连接，服务端可能因close()延迟而错过pong，触发超时断连。改用shutdown(sockfd, SHUT_WR)后，服务端立即收到 FIN，可准确判断客户端已退出。

注意：close()和shutdown()都会触发内核的连接状态机迁移，但close()的时机由引用计数决定，shutdown()的时机由调用者精确控制。在多线程或多进程环境中，优先使用shutdown()进行连接管理，close()仅用于最终资源释放。

7. 实战避坑指南：从 10 个真实故障案例看 socket 接口的隐藏雷区

理论终需落地。以下是我们从十年 C/C++ 服务器开发中提炼的 10 个高频故障案例，每个都对应一个 socket 接口的典型误用，附带复现方法与根治方案。

7.1 案例 1：bind()失败于EADDRINUSE，但netstat显示端口空闲

现象：bind()返回errno=EADDRINUSE，netstat -tuln | grep :8080无输出。

根因：端口被TIME_WAIT状态的 socket 占用。netstat默认不显示TIME_WAIT，需加-a参数：netstat -tulna | grep :8080。

复现：启动服务 A 绑定 8080，客户端连接后断开，A 立即close()；立即启动服务 B 绑定 8080，失败。

根治：bind()前设置SO_REUSEADDR：

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

注意：SO_REUSEADDR允许绑定TIME_WAIT端口，但不允许多个进程同时绑定同一端口（除非SO_REUSEPORT）。

7.2 案例 2：accept()返回的 socket 无法send()，errno=EAGAIN

现象：accept()成功，但首次send()返回 -1 且errno=EAGAIN。

根因：accept()返回的 socket 继承了监听 socket 的O_NONBLOCK标志。若监听 socket 设为非阻塞，新 socket 也是非阻塞。

复现：fcntl(listen_fd, F_SETFL, O_NONBLOCK)后accept()，对新 fdsend()。

根治：accept()后显式清除O_NONBLOCK：

int flags = fcntl(new_fd, F_GETFL, 0); fcntl(new_fd, F_SETFL, flags & ~O_NONBLOCK);

或统一使用epoll管理所有 socket，避免混合阻塞/非阻塞模式。

7.3 案例 3：recv()返回 0，但连接未断，服务僵死

现象：recv()返回 0，程序未处理 EOF，循环recv()陷入忙等。

根因：recv()返回 0 表示对端shutdown(SHUT_WR)或close()，连接已半关闭，本端应停止recv()并准备关闭。

复现：客户端shutdown(sockfd, SHUT_WR)后退出，服务端recv()返回 0。

根治：recv()后严格检查返回值：

ssize_t n = recv(sockfd, buf, sizeof(buf), 0); if (n > 0) { // 处理数据 } else if (n == 0) { // 对端关闭，清理资源 close(sockfd); return; } else { // 错误处理 }

7.4 案例 4：send()大量返回EAGAIN，CPU 占用 100%

现象：高并发下send()频繁返回EAGAIN，top显示 CPU 100%。

根因：非阻塞 socket 的send()失败后，应用未等待epoll事件，而是立即重试，形成忙等。

复现：send()返回EAGAIN后，while (send() == -1 && errno == EAGAIN);。

根治：send()失败且errno==EAGAIN时，将 socket 加入epoll监听EPOLLOUT，在事件触发后再重试。

7.5 案例 5：connect()超时长达 127 秒，远超预期

现象：非阻塞connect()后select()等待 5 秒，但实际连接耗时 127 秒。

根因：select()超时后，connect()仍在后台进行。select()返回可写，但getsockopt(... SO_ERROR)返回 0 前，连接未完成。

复现：connect()后select()等待 5 秒，select()返回可写，但SO_ERROR仍为EINPROGRESS。

根治：select()返回可写后，必须调用getsockopt()检查SO_ERROR，