从上面的评论来看，你似乎不明白如何recv工作原理，或者应该如何使用它。
You really想打电话recv循环中，直到您知道已收到预期的数据量或直到您得到“零字节读取”结果，这意味着另一端已关闭连接。总是如此，无一例外。
如果您需要同时执行其他操作（可能是使用服务器进程！），那么您可能需要检查描述符准备情况poll or epoll第一的。这使您可以在套接字准备就绪时对其进行复用。
您想要这样做的原因是您不知道数据将如何打包以及数据包如何（或何时）到达。加，recv不保证一次读取的数据量。它将提供您调用它时缓冲区中的内容，不多也不少（如果什么都没有，它可能会阻塞，但随后您still不保证恢复时会返回任何特定数量的数据，它仍然可能返回，例如50 字节！）。
即使您总共只发送 5,000 字节，TCP 将其分成 5 个（或 10 个或 20 个）数据包也是完全有效的行为，并且对于recv每次调用它时一次返回 500（或 100、或 20、或 1）个字节。这就是它的工作原理。
TCP 保证您发送的任何内容最终都会到达另一端或产生错误。而且，它保证您发送的任何内容都会按顺序到达。它并不能保证其他太多。最重要的是，它不保证在任何给定时间准备好任何特定数量的数据。
您必须为此做好准备，唯一的方法就是致电recv反复。否则在某些情况下你总是会丢失数据。
MSG_WAITALL原则上应该让它按照你期望的方式工作，但那就是bad行为，并且不保证其有效。如果套接字（或网络堆栈中的某些其他结构）运行违反软限制或硬限制，则可能不会，可能不会满足您的要求。有些限制也很模糊。例如，数字为SO_RCVBUF必须是两倍大由于实现细节，与您期望在 Linux 下收到的内容一样。
服务器应用程序的正确行为应该never取决于诸如“它适合接收缓冲区”之类的假设。原则上，您的应用程序需要准备好使用 1 KB 接收缓冲区接收 TB 级的数据，并且如果需要的话，一次接收 1 个字节的数据块。更大的接收缓冲区将使其更加高效，但仅此而已......它仍然必须以任何方式工作。
事实上，你只会看到超过某个“巨大”限制的失败，这只是运气（或者更确切地说，运气不好）。事实上，在该限制下它显然“工作正常”，这表明您所做的事情是正确的，但事实并非如此。它起作用是一个不幸的巧合。
EDIT:
根据下面评论中的要求，这可能是这样的（代码显然未经测试，买者自负。)
std::vector<char> result;
int size;
char recv_buf[250];
for(;;)
{
if((size = recv(fd, recv_buf, sizeof(recv_buf), 0)) > 0)
{
for(unsigned int i = 0; i < size; ++i)
result.push_back(recv_buf[i]);
}
else if(size == 0)
{
if(result.size() < expected_size)
{
printf("premature close, expected %u, only got %u\n", expected_size, result.size());
}
else
{
do_something_with(result);
}
break;
}
else
{
perror("recv");
exit(1);
}
}
这将收到您想要的任何数量的数据（或直到operator new throws bad_alloc在分配了几百 MiB 大小的向量之后，但这是一个不同的故事......）。
如果要处理多个连接，则需要添加poll or epoll or kqueue或类似的功能（或...fork），我将把这个作为练习留给读者。
