1. 从两个函数说起为什么send和recv值得单独拎出来讲做网络编程的人每天都在跟send和recv打交道。但说实话我见过太多写了几年服务端代码的人对这两个函数的理解还停留在“一个发一个收”的层面。真到了线上出现吞吐上不去、延迟抖动、连接莫名其妙断掉的时候往往就是这些基础认知的盲区在作祟。send和recv是 TCP 套接字编程里最核心的两个数据出入口。它们看起来简单——一个把数据写进内核发送缓冲区一个从内核接收缓冲区把数据读出来。但魔鬼藏在细节里返回值到底代表什么什么时候会阻塞发送缓冲区满了怎么办接收端读得慢会不会影响发送端这些问题如果没搞清楚写出来的代码在实验室跑得挺好一上生产环境就各种问题。这篇文章适合谁看如果你写过 socket 编程能跑通一个简单的客户端-服务端通信但对send/recv的行为边界不够确定那这篇内容就是给你准备的。我会从内核缓冲区的角度把这两个函数的行为拆开讲清楚然后给出可直接参考的代码模板最后把我自己踩过的坑和排查经验整理出来。全篇基于 Linux 环境下的阻塞式套接字展开非阻塞和 IO 多路复用的场景会顺带提到但主线是阻塞模式下的行为分析。2. 理解send和recv的前提内核缓冲区到底在干什么2.1 发送缓冲区和接收缓冲区的本质TCP 通信在应用层和网络层之间隔着一个内核。应用层调用send数据并不是直接飞到对端去的而是先被拷贝进内核的发送缓冲区send buffer。内核协议栈再根据拥塞窗口、对端接收窗口、MSS 等因素决定什么时候把数据真正发出去。同理recv也不是直接从网线上拿数据而是从内核的接收缓冲区receive buffer里把已经排好序的数据拷贝到应用层。你可以把发送缓冲区想象成一个快递站的暂存区。你把包裹交给快递站调用send快递站不一定马上发车它要凑够一车、或者等到发车时间点才走。你的send调用返回成功只代表包裹已经被快递站收下了不代表收件人已经拿到了。这个类比的关键在于send返回成功 ≠ 数据已到达对端。这是很多人最容易误解的地方。TCP 提供的是可靠传输但这个可靠性是内核协议栈帮你保证的不是send这个调用本身保证的。send只负责把数据从应用层交给内核后面的事它管不了。2.2 缓冲区大小对send/recv行为的决定性影响每个 TCP 套接字都有发送缓冲区和接收缓冲区大小可以通过SO_SNDBUF和SO_RCVBUF这两个套接字选项来查看和设置。在 Linux 上你可以用getsockopt获取当前值也可以用setsockopt尝试修改。但要注意内核会对你的设置值进行加倍处理而且有上下限约束。查看缓冲区大小的代码大概长这样int sndbuf_size; socklen_t optlen sizeof(sndbuf_size); getsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, sndbuf_size, optlen); printf(Send buffer size: %d bytes\n, sndbuf_size); int rcvbuf_size; optlen sizeof(rcvbuf_size); getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, rcvbuf_size, optlen); printf(Receive buffer size: %d bytes\n, rcvbuf_size);实测下来在默认配置的 Linux 机器上发送缓冲区通常是 16KB 到 4MB 之间的某个值具体取决于系统参数。接收缓冲区类似。这两个缓冲区的大小直接决定了send什么时候会阻塞、recv一次能读到多少数据。发送缓冲区满了会怎样如果套接字是阻塞模式send就会卡住直到缓冲区有空间容纳你要发送的数据。注意这里的措辞——“容纳你要发送的数据”。如果你要发 100KB但缓冲区只剩 50KB 空间send不会只发 50KB 就返回它会一直等到能放下完整的 100KB 才返回。这个行为很关键后面讲返回值的时候还会展开。接收缓冲区空了会怎样阻塞模式下recv会卡住直到有数据可读。如果对端关闭了连接recv会返回 0。如果发生错误返回 -1 并设置errno。2.3 阻塞与非阻塞模式下行为的根本差异阻塞模式下send和recv的语义比较直观发不出去就等没数据就等。但等待的代价是线程被挂起什么都干不了。非阻塞模式下这两个函数的行为就变成了“能发多少发多少能收多少收多少干不了就立刻返回”。非阻塞send的返回值需要特别小心处理。它可能返回一个小于请求长度的值表示只发送了一部分。比如你请求发 1000 字节它返回 300意思是只有 300 字节被拷贝进了发送缓冲区剩下的 700 字节需要你再次调用send来发送。这就是所谓的“短写”short write。非阻塞recv类似可能只读到部分数据就返回了。我个人的建议是除非你有明确的理由使用非阻塞模式比如配合 epoll 做高并发否则先用阻塞模式把逻辑跑通。阻塞模式的代码更简单不容易出错。等你确实需要处理大量并发连接了再考虑切换到非阻塞 IO 多路复用的方案。3. send函数深度拆解返回值、阻塞条件和常见误判3.1 send的返回值到底代表什么send函数的原型是ssize_t send(int sockfd, const void *buf, size_t len, int flags);返回值是一个ssize_t类型。在阻塞模式下如果一切正常返回值应该等于你传入的len。如果返回 -1说明出错了需要检查errno。如果返回值小于len但大于 0说明只发送了部分数据——这种情况在阻塞模式下比较少见但并非不可能特别是在信号中断或者缓冲区边界的情况下。这里有一个非常重要的认知send返回的值表示有多少字节被拷贝进了内核发送缓冲区而不是有多少字节被对端接收了。这两者之间可能隔着几毫秒到几秒的时间差取决于网络状况和对端处理速度。我见过有同学在代码里这样写int ret send(sockfd, buf, len, 0); if (ret len) { printf(Data sent successfully\n); }然后他以为对端已经收到数据了。实际上如果对端应用层还没有调用recv数据可能还躺在对端的内核接收缓冲区里。如果对端机器突然断电这些数据就丢了。TCP 的可靠性保证的是“如果连接正常数据最终会按序到达”但它不保证“send返回时数据已经到达”。3.2 发送缓冲区满时的阻塞行为与超时设置阻塞模式下当发送缓冲区没有足够空间时send会一直等待。这个等待时间可能很长取决于对端什么时候开始读取数据。如果对端应用层一直不调用recv接收缓冲区满了之后TCP 的滑动窗口会收缩到 0发送端的内核就会停止发送数据发送缓冲区很快也会满然后你的send调用就会一直卡在那里。这种场景在实际中并不罕见。比如对端服务因为某个 bug 卡住了不再读取数据你的发送线程就会永久阻塞。为了避免这种情况可以给套接字设置发送超时struct timeval tv; tv.tv_sec 5; // 5秒超时 tv.tv_usec 0; setsockopt(sockfd, SOL_SOCKET, SO_SNDTIMEO, tv, sizeof(tv));设置之后如果send在 5 秒内无法完成会返回 -1 并设置errno为EAGAIN或EWOULDBLOCK。这样你的程序就有机会从阻塞中恢复做一些错误处理或者重试逻辑。注意SO_SNDTIMEO对非阻塞套接字无效。非阻塞套接字本身就不会阻塞所以不需要超时设置。3.3 部分发送的处理模板虽然阻塞模式下send通常会发送完整的数据但严谨的代码应该处理部分发送的情况。下面这个模板可以直接拿去用ssize_t send_all(int sockfd, const void *buf, size_t len) { size_t total_sent 0; const char *ptr (const char *)buf; while (total_sent len) { ssize_t n send(sockfd, ptr total_sent, len - total_sent, 0); if (n 0) { if (errno EINTR) { continue; // 被信号中断重试 } return -1; // 真正的错误 } if (n 0) { break; // 不应该发生但防御性处理 } total_sent n; } return total_sent; }这个函数会一直循环发送直到所有数据都交给内核或者发生错误。EINTR的处理很重要——当进程收到信号时阻塞的send可能被中断并返回 -1此时errno会被设置为EINTR正确的做法是重新调用send而不是当作错误处理。3.4 一个容易被忽略的细节send的长度上限send的len参数是size_t类型理论上可以很大。但实际上内核能接受的单次发送数据量是有限制的。如果你尝试一次发送几 MB 的数据send可能会返回 -1 并设置errno为EMSGSIZE。具体的上限取决于协议和内核配置对于 TCP 来说通常受限于发送缓冲区的大小。我的经验是单次send的数据量不要超过发送缓冲区的大小。如果你要发送大量数据拆分成多次发送更稳妥。比如你要发 1MB 的数据可以每次发 64KB循环发送。这样既能避免EMSGSIZE错误也能让内核更平滑地处理数据。4. recv函数深度拆解数据读取的边界与流式语义4.1 recv的返回值语义与连接关闭检测recv的原型是ssize_t recv(int sockfd, void *buf, size_t len, int flags);返回值的含义需要分情况讨论。返回值大于 0表示实际读取到的字节数这个值可能小于你请求的len。返回值等于 0表示对端已经关闭了连接收到了 FIN 包这是检测连接关闭的标准方式。返回值等于 -1表示出错需要检查errno。这里有一个 TCP 编程的核心概念需要强调TCP 是字节流协议没有消息边界。你发送端调用了三次send每次发 100 字节接收端调用一次recv可能读到 300 字节也可能读到 50 字节甚至可能读到 1 字节。接收端无法从recv的返回值判断发送端是怎么发的。这个特性导致了很多新手常犯的错误。比如发送端发了一条“Hello”消息接收端recv之后打印出来发现是“Hel”就以为数据丢了。实际上数据没丢只是还没读完需要再次调用recv。4.2 如何正确处理流式数据长度前缀与分隔符方案既然 TCP 没有消息边界应用层就必须自己定义边界。常见的方案有两种长度前缀法和分隔符法。长度前缀法的做法是在每条消息前面加上固定字节数的长度字段。比如用 4 字节的uint32_t表示消息体的长度接收端先读 4 字节解析出长度 N然后再读 N 字节的消息体。这个方案适合二进制协议效率高没有歧义。// 发送端 uint32_t msg_len htonl(strlen(message)); send_all(sockfd, msg_len, 4); send_all(sockfd, message, strlen(message)); // 接收端 uint32_t msg_len; recv_all(sockfd, msg_len, 4); msg_len ntohl(msg_len); char *buffer malloc(msg_len 1); recv_all(sockfd, buffer, msg_len); buffer[msg_len] \0;分隔符法适合文本协议比如用换行符\n作为消息结束标志。接收端不断读取数据直到遇到分隔符为止。这个方案实现简单但如果消息体本身包含分隔符就需要转义处理。// 接收端按行读取 char buffer[1024]; int pos 0; while (1) { char c; ssize_t n recv(sockfd, c, 1, 0); if (n 0) break; if (c \n) { buffer[pos] \0; process_line(buffer); pos 0; } else { buffer[pos] c; } }逐字节读取的效率很低实际项目中通常会配合缓冲区来批量读取然后在缓冲区里查找分隔符。4.3 recv返回0的各种场景与误判recv返回 0 通常意味着对端关闭了连接。但有一种情况容易被误判如果recv的len参数是 0它会立即返回 0但这并不表示连接关闭。所以永远不要传 0 给len。另外如果对端调用了shutdown只关闭了写方向SHUT_WR你的recv会返回 0但连接并没有完全断开你仍然可以向对端发送数据。这种情况下返回 0 表示“对端不会再发数据了”而不是“连接彻底断了”。还有一种边界情况如果接收缓冲区里有数据但对端已经发送了 FINrecv会先把缓冲区里的数据读完然后才返回 0。所以你不能因为recv返回了数据就认为连接一定还活着下一次recv可能就返回 0 了。4.4 recv的阻塞与超时控制和send类似阻塞模式下recv会在没有数据可读时一直等待。如果对端既不发送数据也不关闭连接recv就会永久阻塞。设置接收超时的方法struct timeval tv; tv.tv_sec 10; tv.tv_usec 0; setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, tv, sizeof(tv));超时后recv返回 -1errno为EAGAIN或EWOULDBLOCK。注意区分超时和真正的错误超时可以重试真正的错误如ECONNRESET需要关闭连接。实操心得如果你的服务需要同时处理多个连接不要在每个连接上单独阻塞recv。用select、poll或epoll来管理多个套接字在有数据可读时才调用recv这样可以用少量线程处理大量连接。5. 完整实操一个可复现的TCP收发程序5.1 服务端实现要点下面是一个完整的服务端代码框架包含了错误处理、超时设置和消息边界处理#include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include arpa/inet.h #include sys/socket.h #include netinet/in.h #define PORT 9000 #define BUF_SIZE 4096 ssize_t recv_all(int sockfd, void *buf, size_t len) { size_t total_recv 0; char *ptr (char *)buf; while (total_recv len) { ssize_t n recv(sockfd, ptr total_recv, len - total_recv, 0); if (n 0) { if (errno EINTR) continue; return -1; } if (n 0) break; total_recv n; } return total_recv; } int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd 0) { perror(socket); exit(1); } 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 INADDR_ANY; addr.sin_port htons(PORT); if (bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); exit(1); } if (listen(listen_fd, 5) 0) { perror(listen); exit(1); } printf(Server listening on port %d\n, PORT); while (1) { struct sockaddr_in client_addr; socklen_t client_len sizeof(client_addr); int conn_fd accept(listen_fd, (struct sockaddr *)client_addr, client_len); if (conn_fd 0) { perror(accept); continue; } printf(Client connected: %s:%d\n, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); // 设置接收超时 struct timeval tv; tv.tv_sec 30; tv.tv_usec 0; setsockopt(conn_fd, SOL_SOCKET, SO_RCVTIMEO, tv, sizeof(tv)); char buffer[BUF_SIZE]; while (1) { // 先读4字节长度 uint32_t msg_len; ssize_t n recv_all(conn_fd, msg_len, 4); if (n 0) { printf(Client disconnected or error\n); break; } msg_len ntohl(msg_len); if (msg_len BUF_SIZE - 1) { printf(Message too large: %u\n, msg_len); break; } // 再读消息体 n recv_all(conn_fd, buffer, msg_len); if (n 0) break; buffer[msg_len] \0; printf(Received: %s\n, buffer); // 回显 uint32_t resp_len htonl(msg_len); send(conn_fd, resp_len, 4, 0); send(conn_fd, buffer, msg_len, 0); } close(conn_fd); } close(listen_fd); return 0; }这个服务端的关键点在于先读长度字段再读消息体确保每次处理的是完整的一条消息。recv_all函数保证了即使数据分多次到达也能正确拼装。5.2 客户端实现要点客户端代码和服务端对称核心逻辑是发送时先发长度再发内容#include stdio.h #include stdlib.h #include string.h #include unistd.h #include arpa/inet.h #include sys/socket.h #include netinet/in.h #define SERVER_IP 127.0.0.1 #define PORT 9000 ssize_t send_all(int sockfd, const void *buf, size_t len) { size_t total_sent 0; const char *ptr (const char *)buf; while (total_sent len) { ssize_t n send(sockfd, ptr total_sent, len - total_sent, 0); if (n 0) { if (errno EINTR) continue; return -1; } total_sent n; } return total_sent; } int main() { int sockfd socket(AF_INET, SOCK_STREAM, 0); if (sockfd 0) { perror(socket); exit(1); } struct sockaddr_in server_addr; memset(server_addr, 0, sizeof(server_addr)); server_addr.sin_family AF_INET; server_addr.sin_port htons(PORT); inet_pton(AF_INET, SERVER_IP, server_addr.sin_addr); if (connect(sockfd, (struct sockaddr *)server_addr, sizeof(server_addr)) 0) { perror(connect); exit(1); } printf(Connected to server\n); const char *messages[] {Hello, TCP send recv test, Goodbye}; for (int i 0; i 3; i) { uint32_t msg_len htonl(strlen(messages[i])); send_all(sockfd, msg_len, 4); send_all(sockfd, messages[i], strlen(messages[i])); // 读回显 uint32_t resp_len; recv(sockfd, resp_len, 4, MSG_WAITALL); resp_len ntohl(resp_len); char buffer[4096]; recv(sockfd, buffer, resp_len, MSG_WAITALL); buffer[resp_len] \0; printf(Echo: %s\n, buffer); } close(sockfd); return 0; }客户端这里用了MSG_WAITALL标志它告诉内核“尽量读满请求的字节数再返回”。这个标志在读取固定长度数据时很有用但要注意它仍然可能被信号中断而返回部分数据所以严谨的代码还是应该配合循环。5.3 编译运行与验证方法把上面的代码分别保存为server.c和client.c编译命令gcc -o server server.c -Wall gcc -o client client.c -Wall先运行服务端再运行客户端。你应该能看到客户端发送三条消息并收到回显服务端打印出接收到的每条消息。验证send/recv行为的一个好方法是在客户端发送大量数据比如 10MB同时在服务端recv之前加上sleep(5)。你会观察到客户端的send在发送了一定数据后阻塞住直到服务端开始读取。这个实验能直观地展示发送缓冲区和接收缓冲区的作用。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方法send返回-1errno为EPIPE对端已关闭连接仍尝试发送检查对端是否已关闭忽略SIGPIPE信号send返回-1errno为EAGAIN非阻塞套接字发送缓冲区满等待可写事件后重试recv返回0对端关闭连接正常关闭流程清理资源recv返回-1errno为ECONNRESET对端异常断开RST关闭连接记录日志数据读不全TCP流式语义未处理消息边界使用长度前缀或分隔符send阻塞很久对端接收缓冲区满窗口收缩设置SO_SNDTIMEO检查对端读取逻辑吞吐量低单次send数据量太小合并小包增大单次发送量6.2 踩坑记录SIGPIPE信号的坑这个坑我踩过不止一次。当对端已经关闭连接你仍然调用send时内核会向进程发送SIGPIPE信号。这个信号的默认行为是终止进程。也就是说你的服务端可能因为一个客户端异常断开就整个挂掉了。解决办法有两种一是忽略SIGPIPE信号二是在send时使用MSG_NOSIGNAL标志。我通常两个都做signal(SIGPIPE, SIG_IGN); // 或者 send(sockfd, buf, len, MSG_NOSIGNAL);忽略SIGPIPE之后send会返回 -1 并设置errno为EPIPE你就可以正常处理这个错误了。6.3 踩坑记录recv返回0不等于出错很多新手看到recv返回 0 就慌了以为出错了。实际上返回 0 是 TCP 连接正常关闭的标志。正确的处理方式是关闭套接字清理资源如果是服务端就继续accept下一个连接。但要注意一种情况如果recv返回 0但你还有数据要发送给对端这时候发送会失败因为对端已经关闭了接收方向。TCP 是全双工的但对端关闭连接通常意味着它不再接收数据了。6.4 踩坑记录缓冲区大小设置的陷阱setsockopt设置SO_SNDBUF和SO_RCVBUF时内核会将你设置的值加倍并且有最小值和最大值的限制。比如你设置 1024 字节内核实际可能会给你 4608 字节取决于系统配置。如果你设置的值超过了系统上限内核会静默地截断到上限值。更重要的一个坑是接收缓冲区的大小会影响 TCP 窗口大小从而影响吞吐量。在高延迟网络环境下如果接收缓冲区太小TCP 窗口就小发送端一次能发的数据就少吞吐量上不去。这就是所谓的带宽时延积问题。计算公式是所需缓冲区大小 带宽 × 往返时延比如带宽 100Mbps往返时延 50ms那么所需缓冲区至少是 100Mbps × 50ms / 8 625KB。如果接收缓冲区小于这个值吞吐量就会受限于窗口大小而不是带宽。6.5 独家技巧用tcpdump验证send/recv的实际行为当你怀疑send返回了但数据没发出去或者recv读到的数据和预期不符时tcpdump是最直接的验证工具tcpdump -i any -nn port 9000 -X这个命令会抓取 9000 端口的所有流量并以十六进制和 ASCII 形式显示。你可以清楚地看到每个 TCP 报文的内容、序列号、ACK 号。对比send的返回值和tcpdump的抓包结果就能确认数据到底有没有离开本机。我个人的习惯是在开发和调试阶段始终开着一个tcpdump窗口。很多问题不用猜看一眼抓包就清楚了。比如你以为是send没发出去抓包一看发现早就发出去了是对端没读或者你以为是网络问题抓包一看发现是应用层逻辑错误。7. 性能相关的几个关键考量7.1 小包合并与Nagle算法TCP 默认启用了 Nagle 算法它会尽量把小包合并成一个大包再发送以减少网络上的小报文数量。这个算法在大多数场景下是有益的但在某些延迟敏感的场景下会造成问题。比如你发送一个很小的请求Nagle 算法可能会等一会儿看有没有更多数据要发这就增加了延迟。禁用 Nagle 算法的方法int flag 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));但不要盲目禁用。如果你的应用本身就是批量发送数据Nagle 算法帮你合并小包反而能提高效率。只有在交互式、请求-响应模式的场景下禁用 Nagle 才有明显收益。7.2 单次send数据量的选择前面提到过单次send的数据量不要超过发送缓冲区大小。但具体多少合适我的经验是对于大块数据传输单次send的大小设置在 16KB 到 64KB 之间比较合适。太小了系统调用开销大太大了容易阻塞且内存占用高。如果你要发送的数据超过这个范围拆分成多次发送。但要注意拆分之后接收端需要自己处理消息边界所以长度前缀方案在这种情况下是必须的。7.3 接收端的读取策略接收端每次recv读多少这取决于你的应用层协议。如果是长度前缀协议你可以先读 4 字节长度然后根据长度分配缓冲区再读消息体。如果是流式处理可以用一个固定大小的缓冲区循环读取边读边处理。一个常见的优化是使用较大的接收缓冲区比如 64KB每次recv尽量多读一些数据减少系统调用次数。但缓冲区太大也会浪费内存特别是在高并发场景下每个连接都分配大缓冲区会迅速耗尽内存。实操心得在高并发服务中我通常把接收缓冲区设置为 16KB 到 32KB。这个大小足以容纳大多数请求同时不会占用太多内存。如果单个请求可能很大就在应用层做分片处理。8. 写在最后send和recv这两个函数我用了很多年每次深入看它们的实现和行为都会有新的收获。它们不仅仅是两个 API而是应用层和内核协议栈之间的桥梁。理解这座桥梁的承载能力和行为边界是写出稳定可靠的网络程序的基础。如果你只能记住一件事那就是send成功不代表数据到达recv返回 0 不代表出错TCP 是流不是包。这三句话涵盖了最常见的认知误区。后续如果你想继续深入可以沿着两个方向扩展一是研究非阻塞模式下配合 epoll 的事件驱动编程模型二是深入 TCP 协议栈的拥塞控制和流量控制机制。这两个方向都能帮你写出更高性能、更可靠的网络服务。