本文探讨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语言免费学习笔记（深入）”；