Linux网络编程核心函数速查：从socket到epoll全流程解析

搞网络编程这些年，我最大的感受是：看似函数很多，真正天天摸的核心函数其实就那么二十来个。socket、bind、listen、accept、connect、send、recv、select、poll、epoll，这一串名字能覆盖掉九成以上的业务场景。这篇文章就是把 Linux 环境下这套网络编程核心函数按真实调用顺序整理一遍，每个函数讲清楚经典用法、返回值判断、参数选择和容易踩的坑。适合刚入门想搭起完整知识框架的同学，也适合工作一两年想快速拾回基础、准备面试复盘的人。整篇以 TCP/UDP 为主，代码示例是 C 语言，运行环境 Linux，macOS 也基本通用。

1. 网络编程核心函数的整体版图

1.1 为什么需要一张函数速查表

网络编程和普通文件读写有一个本质区别：文件操作基本上就是 open/read/write/close，流程固定；而网络编程是一个强顺序的多阶段过程，从创建套接字到绑定地址、监听、接受连接、收发数据、关闭连接，每个阶段对应不同的函数，而且每个函数都可能因为阻塞、信号、缓冲区、对端行为等因素返回特殊错误码。

我见过很多新手把函数原型背得滚瓜烂熟，但一写代码就露馅：bind 之前忘了填充地址结构，accept 之后不会处理新 fd，recv 返回 0 不知道是对端关闭。这些问题的根源，就是脑子里没有形成一条“调用链速查表”。所以这份速查的核心价值，不是帮你查参数类型，而是帮你在写代码时快速定位：我现在处于哪个阶段，该用哪个函数，函数返回值代表什么状态，下一步该做什么处理。

1.2 函数分类与学习路径

核心函数我习惯分成五类，每一类解决一个层面的问题。

学习路径上，我建议先走一遍 TCP 的“全链路闭环”：先用 socket → bind → listen → accept 起一个服务端，再用 socket → connect 建一个客户端，然后在两端之间 send/recv 互发消息，最后 close 收尾。这个闭环走通了，网络编程的骨架就立起来了。然后再补两块：一块是 UDP 的 sendto/recvfrom，另一块是多路复用的 select → poll → epoll。字节序和地址结构属于贯穿全程的基础，遇到不理解的地方随时回查。

1.3 我常用的记忆锚点

如果觉得函数太多记不住，我建议按调用顺序去记，而不是按字母表去记。

• 服务端链：socket() → bind() → listen() → accept() → recv()/send() → close()
• 客户端链：socket() → connect() → send()/recv() → close()
• UDP 链：socket() → sendto()/recvfrom() → close()

把这两条链路中每个函数的返回值和失败情况都默写一遍，比刷十遍函数原型都管用。TCP 三次握手和四次挥手的流程图也建议放在手边，把 accept、connect、close、shutdown 对应到状态上，你会突然发现自己通了。

2. 连接建立阶段：socket、bind、listen、accept、connect

2.1 socket()：先决定你要什么样的通道

socket() 是网络编程的第一个函数，它的核心是确定协议族和服务类型。

c复制#include <sys/socket.h>
int socket(int domain, int type, int protocol);

三个参数里，domain 选 AF_INET（IPv4）或 AF_INET6（IPv6），本地进程间通信用 AF_UNIX；type 选 SOCK_STREAM（TCP）或 SOCK_DGRAM（UDP）；protocol 一般直接填 0，表示由内核根据前两个参数自动选择默认协议。

值得多说一句的是，socket() 返回的 fd 和普通文件 fd 本质上是同一套文件描述符体系，所以它同样受到进程 fd 数量限制。我遇到过服务端运行一段时间后 socket() 返回 -1 而且 errno 是 EMFILE 的情况，最后定位是某个分支忘了 close，导致 fd 泄漏。生产环境一定要监控 fd 数量，这是非常经典的坑。

另外，如果希望 socket 一创建就带上非阻塞和 close-on-exec 标志，可以在 type 上或运算加 SOCK_NONBLOCK 和 SOCK_CLOEXEC，这样能省掉后续两个额外系统调用，也是多线程程序里避免 fd 意外被子进程继承的推荐姿势。

2.2 bind()：端口和地址的绑定

服务端拿到 socket 之后，需要绑定一个本地地址和端口，客户端才知道往哪里连。

c复制int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

这里的 addr 是通用结构体指针，实际我们需要填充的是 struct sockaddr_in。容易踩的第一个坑，就是忘记把整个结构体清零。正确姿势通常是：

c复制struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);  // 监听所有本地网卡
addr.sin_port = htons(8080);
if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
    perror("bind");
    exit(1);
}

两点经验：第一，监听地址用 INADDR_ANY，避免写死具体 IP，这样服务器不管配了哪个网卡都能接受连接；第二，如果端口被占用，bind 会返回 EADDRINUSE。这通常是上一个进程刚退出，端口还在 TIME_WAIT 状态，解决方式是 listen 之前调用 setsockopt 设置 SO_REUSEADDR，让端口可以快速复用。

2.3 listen() 和 accept()：让内核帮你排队

bind 完成之后，套接字还是一块“空地”，需要调用 listen() 进入监听模式，然后不断 accept() 取出已经完成的连接。

c复制int listen(int sockfd, int backlog);
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

backlog 这个参数经常被误解成“最大连接数”，实际上它表示内核为这个监听 socket 维护的连接队列长度。Linux 上这个值不建议随便写几千几万，还要看系统参数 /proc/sys/net/core/somaxconn 的限制。超过限制后，内核会静默截断，极端情况下客户端连接会卡住。我自己习惯将 backlog 设成 128 ~ 512，同时确认 somaxconn 至少不低于这个值。

accept() 默认是阻塞的，没有新连接就挂在那里。accept 返回的是一个全新的 fd，这个 fd 才真正承载了与客户端的 TCP 连接。同时，通过 accept 的第二个参数可以拿到客户端的地址信息，用来打印日志或者做来源限制。注意 accept 每次只能取出一个连接，要处理多个连接，就得配合多线程或前面说的多路复用。

2.4 connect()：客户端发起连接

客户端这边的 connect() 本质上就是向服务端发送 SYN，触发三次握手过程。

c复制int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

阻塞模式下，connect 要等到握手完成或者失败才返回。常见的失败包括：服务端没监听（ECONNREFUSED）、网络不可达（ENETUNREACH）、握手超时（ETIMEDOUT）。如果是对非阻塞 socket 调用 connect，函数会立刻返回 -1，并设置 errno 为 EINPROGRESS，表示握手还在进行中，后续要通过 select/poll/epoll 监听 socket 的可写事件来判断连接是否成功。

这里有一个很实用的小技巧：连接成功后可调用 getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &errlen) 检查 err 是否为 0，如果为 0 说明连接建立成功，否则就是握手失败的具体错误码。这个模式在写非阻塞客户端时非常常见。

为了方便理解，我再给一个最小可运行的 TCP 服务端骨架：

c复制#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

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

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(8080);
    bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr));

    listen(listen_fd, 128);
    printf("listening on 8080...\n");

    struct sockaddr_in client_addr;
    socklen_t len = sizeof(client_addr);
    int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &len);
    char *msg = "hello from server\n";
    send(conn_fd, msg, strlen(msg), 0);
    close(conn_fd);
    close(listen_fd);
    return 0;
}

这段代码省略了错误处理，实际项目里面每个系统调用都要检查返回值。先把链路跑通，再逐步加强健性。

3. 数据收发与边界处理：send、recv、sendto、recvfrom、shutdown、close

3.1 send() / recv()：返回值不是用来嫌少的

连接建立之后，核心操作就是读写。send/recv 是“已经连接”的 socket 上最经典的收发函数。

c复制ssize_t send(int sockfd, const void *buf, size_t len, int flags);
ssize_t recv(int sockfd, void *buf, size_t len, int flags);

两个函数返回的都是实际发送/接收的字节数。我反复和新同事强调一个概念：send 返回 n，不代表对端收到了 n 个字节，只代表内核缓冲区成功接收了 n 个字节；recv 返回 n，也不代表消息结束了，只是这次调用最多读到 n。TCP 是字节流协议，它不保存消息边界，这是新手最容易搞混的地方。

recv 返回 0 只有一个含义：对端已经关闭了连接。这时候服务端如果继续从这个 fd 上 recv，就一直返回 0，所以必须把这个 fd 关掉并从自己的连接管理列表里移除。send 还可能触发 SIGPIPE 信号，当对端已经关闭连接而我们还继续写数据时，默认行为是杀死整个进程。生产服务端一定记得屏蔽或处理 SIGPIPE，否则一个客户端异常退出可能拖垮整个服务进程。

阻塞模式下，send 发送的字节数可能少于 len，recv 收到的字节数也可能少于 len。所以代码里必须做“发送/接收循环”，把未完成的字节数在循环里继续发送或接收，直到全部完成。

3.2 UDP 场景：sendto() / recvfrom()

UDP 是数据报协议，收发函数带上了目标地址参数。

c复制ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
               const struct sockaddr *dest_addr, socklen_t addrlen);
ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,
                 struct sockaddr *src_addr, socklen_t *addrlen);

sendto 每次都要填目标地址，recvfrom 可以返回发送方的地址，这样服务端才知道给谁回包。UDP 没有“连接”的概念，但 Linux 允许对 UDP socket 调用 connect()，这个 connect 不是建立连接，而是给 socket 指定一个默认对端，之后就可以直接用 send/recv 收发，在内核层面会有一定的过滤效果。

UDP 有个核心特征：不保证不丢包、不保证顺序。我做实时转码转发项目的时候，经常看到有人把 TCP 的思路带进 UDP，发了包就等 recv，结果疯狂超时。UDP 场景更合理的做法是配合应用层重传、序号校验和超时判断。recvfrom 如果 buffer 太小，多出的数据会被内核直接丢弃，这是 UDP 丢包里最常见但最容易被忽略的原因。

3.3 shutdown() 与 close()：半关闭边界

close() 和 shutdown() 的差别，很多人到了工作两三年才真正体会。

close(fd) 的作用是减少文件描述符的引用计数，只有当引用计数归零时才真正关闭 socket。在多进程或多线程共享同一个 fd 的场景下，一个线程调 close 并不会立刻断开连接，另一个持有 fd 的线程还能继续收发数据。shutdown() 则不同，它是直接操作 socket 本身的连接状态。

c复制int shutdown(int sockfd, int how);

how 有三个选项：SHUT_RD 关闭读方向，SHUT_WR 关闭写方向，SHUT_RDWR 同时关闭。最典型的场景是半关闭：客户端发送完请求后调用 shutdown(fd, SHUT_WR)，告诉服务端“我说完了，不再发送数据，但我仍然想接收你这边后续的响应”。服务端在看到 recv 返回 0 之后，依然可以向这个连接写数据，写完再 close。这个模式在 HTTP 协议里就有实际应用。

一句话总结：close 管的是 fd 引用计数，shutdown 管的是连接本身的读写方向。如果你需要确保连接立刻断开，或者实现半关闭语义，用 shutdown。

3.4 收发循环的代码骨架

我直接给一个稳定的收发循环，很多项目里都能直接改造复用。

c复制ssize_t send_all(int fd, const void *buf, size_t len, int flags) {
    const char *p = buf;
    size_t left = len;
    while (left > 0) {
        ssize_t n = send(fd, p, left, flags);
        if (n == -1) {
            if (errno == EINTR) continue;
            return -1;
        }
        p += n;
        left -= n;
    }
    return len;
}

ssize_t recv_all(int fd, void *buf, size_t len, int flags) {
    // 注意：这个函数只适用于你能准确预知消息长度的协议
    char *p = buf;
    size_t left = len;
    while (left > 0) {
        ssize_t n = recv(fd, p, left, flags);
        if (n == -1) {
            if (errno == EINTR) continue;
            return -1;
        }
        if (n == 0) break; // 对端关闭
        p += n;
        left -= n;
    }
    return len - left;
}

recv_all 这种写法要配合“消息长度明确”的协议使用，否则会遇到 TCP 粘包问题。业务上通常有两种解法：一种是固定长度消息，一种是 "头部长度 + 可变内容" 的协议结构。头部长度字段建议用网络字节序存，读取时先 recv 头部并 ntohl 解出内容长度，再 recv 对应长度的内容。这一步是所有基于 TCP 自定义协议的基础。

4. 地址结构与字节序：sockaddr_in、htons、inet_pton、inet_ntop

4.1 sockaddr_in 的内存结构

刚开始看网络编程的人，多半会被 struct sockaddr 和 struct sockaddr_in 绕晕。内核接口为了兼容 IPv4、IPv6、本地套接字等，统一接收 struct sockaddr 这个“通用地址”指针，长度参数单独传。而具体填充时，IPv4 用的是 sockaddr_in。

c复制struct sockaddr_in {
    short            sin_family;   // AF_INET
    unsigned short   sin_port;     // 网络字节序的端口号
    struct in_addr   sin_addr;     // IPv4 地址
    char             sin_zero[8];  // 填充对齐
};

这里有个实际经验：sockaddr_in 和 sockaddr 虽然类型不同，但它们在内存布局上的起始部分兼容，所以代码里常见 (struct sockaddr *)&addr 这种强转。很多人纠结为什么不能直接把 sockaddr_in 传给 bind，原因就是 bind 的接口为了兼容多地址族，只能定义成通用类型。

IPv6 对应的是 sockaddr_in6，结构更复杂，里面有一个 16 字节的地址数组。如果写 IPv6 功能，记住不要直接强转成 sockaddr_in，长度也不一样，容易踩内存越界的坑。

4.2 字节序转换：htons / ntohs / htonl / ntohl

字节序是网络编程里绕不开的基础。x86 等机器是“小端”存储，而网络协议规定数据必须按“大端”传输，所以主机字节序和网络字节序之间需要显式转换。

四个函数各司其职：

• htons：host to network short，一般用来转端口号
• htonl：host to network long，一般用来转 IP 地址
• ntohs：network to host short，恢复端口号
• ntohl：network to host long，恢复 IP 地址

填端口时一定带上 htons，比如 htons(8080)；recvfrom 拿到客户端地址后，要输出端口就得用 ntohs(client_addr.sin_port)。我见过很多线上日志端口号变成了一大串奇怪数字，就是漏了 ntohs。

另外一个容易踩的坑：如果你把字符串形式的端口用 atoi 转成整数之后，直接塞给 sin_port，忘了 htons，连接一定失败。类似这种细节，排查起来很费时间，所以我把字节序转换放在速查里重点标注。

4.3 inet_pton / inet_ntop：字符串与二进制地址互转

现代代码中，字符串 IP 和二进制 IP 之间的转换，推荐用 inet_pton 和 inet_ntop，这组函数同时支持 IPv4 和 IPv6。

c复制#include <arpa/inet.h>
int inet_pton(int af, const char *src, void *dst);
const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);

inet_pton 返回 1 表示转换成功，0 表示 src 不是合法的 IP 地址，-1 表示 af 不支持。经典用法：

c复制struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
inet_pton(AF_INET, "192.168.1.10", &addr.sin_addr);
addr.sin_port = htons(8080);

打印客户端 IP 时：

c复制char ip[INET_ADDRSTRLEN];
inet_ntop(AF_INET, &client_addr.sin_addr, ip, sizeof(ip));

这里提醒一下：老接口 inet_addr 和 inet_ntoa 虽然还在，但前者不能处理 255.255.255.255 这种特殊地址，返回值有歧义，而且不支持 IPv6，新的代码不建议再用。INET_ADDRSTRLEN 和 INET6_ADDRSTRLEN 是专门为这两个函数准备的缓冲区大小宏，直接用它定数组长度，别自己拍脑袋写一个 16。

4.4 一个常见的地址填充完整流程

综合上面内容，客户端连接一个目标地址的完整流程大概是：

c复制struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(8080);
if (inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr) <= 0) {
    // 处理无效 IP
}
if (connect(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) {
    perror("connect");
}

这几行代码是客户端网络模块最常见的样子，没有任何花哨，但每一步都是必须的。memset 清空避免栈上残留脏数据，inet_pton 保证 IP 合法，htons 保证端口字节序正确。凡是 connect 连接不上又查不出原因的，先回头看这三步。

5. 多路复用：select、poll、epoll

5.1 select()：老牌函数，理解事件集合的起点

单线程要同时处理多个 socket，多路复用就是最核心的方案。select 是这组方案里最古老、最“容易理解”的一个。

c复制int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

使用 select 有几个固定的搭配动作：FD_ZERO 清空集合、FD_SET 把 fd 加入集合、select 返回后 FD_ISSET 判断某个 fd 是否有事件。默认情况下，fd_set 能管理的 fd 数量上限是 FD_SETSIZE，通常是 1024。也就是说，select 在默认编译参数下无法处理上万连接。

还有两个细节值得注意：第一，timeout 参数在 Linux 上会被内核修改，如果要在循环里反复用同一个超时时间，每次 select 之前都需要重新赋值；第二，select 返回之后，没有就绪事件的 fd 会从集合中移出，所以循环里要重新构造 fd_set，不能复用上一次的结果。

select 最大的优点是简单，连接数几百以内完全够用。最大的缺点是可扩展性差，每次调用都要把整个 fd_set 从用户态拷贝到内核态，内核还要线性扫描全部 fd。连接量上来之后，这个开销会非常明显。

5.2 poll()：摆脱限制，但本质未变

poll 可以理解成 select 的结构化升级版，它用 pollfd 数组替代了 fd_set 位图，不再受 1024 限制。

c复制struct pollfd {
    int fd;
    short events;   // 关注的事件：POLLIN / POLLOUT / POLLERR
    short revents;  // 返回时就绪的事件
};
int poll(struct pollfd *fds, nfds_t nfds, int timeout);

调用前填充 events，调用后检查 revents。判断读事件用 revents & POLLIN，判断写事件用 revents & POLLOUT，同时还要检查 POLLERR 和 POLLHUP，不然对端断开时你可能拿不到预期的事件。

poll 相比 select 的改进主要体现在数量上限上，但底层仍然是“全量集合传给内核、内核全量扫描”的模式。当 fd 数量到几千并且活跃比例很低时，poll 依然会在每次调用中遍历全部 fd。所以我通常把 poll 当作 select 的替代品，但它仍然不是高并发服务端的终极答案。

5.3 epoll 三件套：Linux 高并发的标配

Linux 下真正适合大规模高并发的方案是 epoll，核心函数有三个。

c复制int epoll_create1(int flags);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_create1 创建一个 epoll 实例，参数传 0 或 EPOLL_CLOEXEC；epoll_ctl 负责把关心的 fd 添加、修改、删除到事件表；epoll_wait 阻塞等待就绪事件，返回值是就绪事件的数量，就绪事件列表通过 events 数组返回。

epoll 和 select/poll 最大的不同，是它通过内核事件表 + 回调机制避免了全量扫描。只有真正发生事件的 fd 才会被放到就绪列表里，所以处理大量空闲连接时，它的时间复杂度接近 O(事件数) 而不是 O(连接数)。这也是为什么 Redis、Nginx 这些高性能服务在 Linux 上都基于 epoll。

epoll 有两种触发模式：

• 水平触发（LT）：只要 fd 有数据可读，每次 epoll_wait 都会返回。这是默认模式，逻辑简单。
• 边缘触发（ET）：只有 fd 从“无数据”变为“有数据”时，才会通知一次。之后如果没有把数据读完，内核不会再通知，必须自己循环 recv 读到返回 EAGAIN 为止。

ET 模式效率更高，因为减少了重复通知，但处理逻辑必须严谨。我建议新手先用 LT，熟悉之后再切 ET。ET 模式下最常见的 bug，是 recv 还没读完就等下一次 epoll_wait，结果一直等不到通知，连接就像死掉一样。

5.4 如何根据并发规模选型

结合我自己的使用经验，给一个简单的选型逻辑：

• 连接数在几十到几百，业务逻辑简单，用 select 完全够，代码量最少。
• 连接数到几百上千，并且要跨平台，用 poll 更稳妥。
• Linux 服务端、连接数成千上万，或者大量连接不活跃，直接用 epoll，别犹豫。
• 边缘触发不是必须的，LT 模式在绝大多数业务下已经够高效。

选型的前提是理解每个模型的代价。select/poll 的瓶颈是每次调用都要遍历全部 fd；epoll 的瓶颈则在于用内核事件表换来了高扩展性，但代码复杂度更高，对 fd 的管理也更精细。不要盲目“为了 epoll 而 epoll”，量级不够的时候，简单方案反而更稳。

6. 高频报错与排查技巧速查

6.1 EINTR、EAGAIN、ECONNRESET：错误码是程序语言

网络编程里，错误码比函数原型更需要背。我按出现频率排了几个必懂的：

• EINTR：系统调用被信号中断。很多阻塞调用在收到信号后返回 -1，errno 为 EINTR。经典处理是循环重试，或者注册信号处理器时设置 SA_RESTART 让内核自动重启被中断的调用。
• EAGAIN / EWOULDBLOCK：非阻塞模式下，当前没有数据可读，或者发送缓冲区已满。这不是错误，而是“现在没有可用数据/空间”，应该等下一次事件通知。很多人把 EAGAIN 当错误处理，导致非阻塞逻辑直接崩。
• ECONNREFUSED：对端端口根本没进程监听，连接直接被拒绝。
• ECONNRESET：对端已经把连接重置了。常见于对端进程崩溃、或双方对连接状态理解不一致。
• EPIPE：往一个对端已经关闭的 socket 上写数据。不处理 SIGPIPE 时，进程可能直接退出。
• ETIMEDOUT：连接超时。可能是网络不通，也可能是服务端长时间没有响应。
• EADDRINUSE：端口被占用。最常见原因是服务刚退出，端口处于 TIME_WAIT。

错误码排查时，先打印 errno 对应的字符串，strerror(errno) 是这个阶段最常用的调试函数。不要只记数字，不同平台上错误码数字可能不一样，按宏名判断是标准做法。

6.2 服务端 TIME_WAIT 与端口复用

主动关闭连接的一方，会进入 TIME_WAIT 状态，并且默认要等待 2MSL（Linux 上通常约 60 秒）。压测场景或短连接服务里，可能出现大量 TIME_WAIT。

如果你遇到“上次跑完服务立刻重启，bind 报地址已被占用”，这就是 TIME_WAIT 在作怪。解决方案就是我在 bind 小节提到的 SO_REUSEADDR：它允许新 socket 绑定到 TIME_WAIT 状态的端口。注意，SO_REUSEADDR 解决的是 bind 的问题，对 connect 主动连接别的服务的行为没有影响。

还有一个相关选项 SO_REUSEPORT，它允许多个进程/线程各自 bind 同一个端口，内核做负载均衡。这个特性适合多 worker 进程的模型，但使用前要确认你的内核版本支持，并认真阅读语义，否则可能出现意料之外的包分发行为。

查看当前连接状态，我常用 ss -lnt 或者 netstat -antp。如果发现大量 TIME_WAIT，优先检查是不是业务代码里服务端主动关闭了连接，以及是否可以用连接复用或者长连接替代短连接。

6.3 用 strace 和 tcpdump 定位问题

代码层面的报错相对好查，真正麻烦的是“连接看起来建立成功但数据就是不通”“客户端超时服务端没日志”。这种时候靠猜效率太低，直接用两个工具往下挖。

strace 能跟踪系统调用和信号，最常见用法是：

bash复制strace -ff -e trace=network -p <pid>

能看到进程实际调用了哪些网络函数、参数是什么、每次调用的返回值是多少。如果 send 一直返回 EAGAIN，说明发送缓冲区被占满；如果 connect 一直 ETIMEDOUT，说明网络层就有问题。strace 能帮你把“代码逻辑”？和“内核实际行为”对齐。

tcpdump 则是抓网络包，在 Linux 上看数据包是否真实到达：

bash复制tcpdump -i any port 8080 -nn

当服务端日志显示没收到数据时，先用 tcpdump 确认数据包是否到达网卡。如果包到了但应用层没反应，问题在应用代码；如果包根本没到，问题在网络链路、防火墙或者路由。这个分层排查思路非常有效。

6.4 我在这块踩过的三个坑

最后分享三个亲自踩过的坑，希望能帮你省掉排查时间。

第一个坑是 SIGPIPE 导致进程莫名其妙退出。有一次压测服务端，晚上收到告警说进程挂了，可日志里没有任何错误。后来用 strace 才发现进程是被 SIGPIPE 信号打死的，原因是客户端断开后服务端继续向这个 fd 写数据。从那以后，我的服务代码都会先 signal(SIGPIPE, SIG_IGN) 或者用 MSG_NOSIGNAL 标志位，再统一处理写入返回的错误码。

第二个坑是 accept 之后没有及时把新 fd 设置为非阻塞。在高并发场景下，如果某个连接的输入缓冲区长时间没数据，所有依赖这个连接的 recv 可能会把进程阻塞住，影响其他连接的服务。服务端的固定姿势是 accept 拿到新 fd 后立刻设置 O_NONBLOCK，然后用多路复用管理所有连接。

第三个坑是非阻塞 connect 只靠 epoll 可写事件判断成功。早期写非阻塞客户端，我以为只要是 POLLOUT 就说明连接成功，结果对方端口不通，select 照样返回可写。后来检查 SO_ERROR 才发现实际错误是 ECONNREFUSED。非阻塞 connect 的正确处理一定显式检查 SO_ERROR，不能只看可写事件。

这份速查写到这里，其实核心函数就这么多，背后要记住三件事：第一个是理解每个函数返回值和错误码的业务含义，第二个是严格按照调用顺序组织代码流程，第三个是无论阻塞还是非阻塞，都要把“部分成功”和“资源释放”处理干净。我自己的习惯是，每次带新同事入门，都会让他们先默写一遍服务端和客户端的调用链，再针对每个错误码说出触发场景。能把这一步做好，网络编程的基础就基本过关了。最后再分享一个小技巧：把 send_all、recv_full、set_nonblock、print_addr 这类通用能力封装成公共函数，放到每个项目的基础库里，你会在后续所有网络业务里受益。