本文探讨Node.js socket.write()与C语言 recv()通信时常见的阻塞问题。核心在于TCP是字节流协议而非消息协议，recv()不会自动识别消息边界。文章将详细解释为何recv()会持续阻塞等待数据或连接关闭，并提供多种应用层消息协议设计方案，如定长消息、长度前缀消息和分隔符消息，以实现可靠且非阻塞的数据传输。
1. 理解TCP的字节流特性
tcp（传输控制协议）提供的是一个可靠的、有序的、全双工的字节流服务。这意味着它保证数据按发送顺序到达，但不提供任何关于“消息”或“数据包”边界的信息。
当你从Node.js服务器使用 socket.write(Buffer.from(“123”)) 发送数据时，这些字节被简单地放入TCP缓冲区并传输。TCP本身并不知道“123”是一个完整的消息，它只是一个字节序列。
C语言客户端的 recv() 函数的作用是从套接字缓冲区读取可用的字节。它会阻塞直到有数据可读，或者直到连接被对端关闭（此时 recv() 返回0），或者发生错误（返回-1）。
当Node.js服务器调用 socket.end() 时，它会发送一个FIN（结束）包，信号通知连接的写入端已关闭。此时，C客户端的 recv() 最终会返回0，表示对端已关闭连接，从而退出阻塞状态。然而，如果Node.js服务器只调用 socket.write() 而不调用 socket.end()，TCP连接仍然是开放的。C客户端的 recv() 会持续阻塞，因为它在等待更多数据，而不会知道当前已接收的字节是否构成一个“完整”的消息。
2. 原始C客户端 GetData 函数的问题分析
原始的 GetData 函数设计存在根本性缺陷：
char *GetData(int socket_fd){ char init[] = {0x17, 0x22}; int bytes_read, n_reads = 0; char *buffer = (char *)malloc(BUFFER_SIZE); if (buffer == NULL) { /* ... */ } send(socket_fd, init, 2, 0); // 发送初始化数据 int offset = 0; // 问题所在：循环会一直执行，直到recv返回0或-1 while ((bytes_read = recv(socket_fd, buffer + offset, BUFFER_SIZE, 0)) > 0) { if (bytes_read == -1) { /* ... */ } offset += bytes_read; char *tmp = realloc(buffer, offset + BUFFER_SIZE); // 动态扩容 if (tmp == NULL) { /* ... */ } buffer = tmp; } return buffer;}
这个 while 循环会一直执行，直到 recv 返回0（表示对端关闭连接）或-1
立即学习“C语言免费学习笔记（深入）”；
以上就是Node.js与C语言Socket通信：深入理解TCP流与应用层消息边界处理的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1511643.html
微信扫一扫 
支付宝扫一扫 
