循环调用socket write时字符串缓冲区数据混杂问题

安全阿岳

2026-8-28

问题场景

我通过如下for循环多次调用目标函数：

for ( int con=0; con < this->controller_info.size(); con++ ) {
  try {
    this->pi.home_axis( this->controller_info.at(con).addr );
  }
  catch( std::out_of_range &e ) { ... }
}

其中home_axis()函数的定义如下：

long ServoInterface::home_axis( int addr ) {
  std::stringstream cmd;
  if ( addr > 0 ) cmd << addr << " ";
  cmd << "FRF";
  cmd << "\n";
  int bytes=this->controller.Write( cmd.str() );
  return NO_ERROR;
}

controller.Write()是标准write(2)系统调用的封装函数，作用是将字符串中的字符写入套接字文件描述符。

按照代码逻辑，每次调用home_axis()都会创建独立的全新std::stringstream cmd缓冲区，但实际运行时，首次执行for循环的过程中，接收写入数据的主机仅收到一条拼接后的字符串：

1 FRF2 FRF

但打印写入字节数时会输出两次6，说明写入端两次分别写入6字节的操作是正常执行的，只是接收端看似将两次数据作为单个缓冲区接收。

再次执行该for循环时，接收端可正常分两次收到如下内容：

1 FRF

以及

2 FRF

可在两个缓冲区到达时分别处理。

当前运行场景无多线程参与。进一步排查发现：若在for循环中插入1微秒的延迟，即调用usleep(1);，功能可正常运行；此外，若不使用for循环，以同样的快速连续调用方式手动执行两次home_axis()，代码如下：

this->pi.home_axis( this->controller_info.at(0).addr );
this->pi.home_axis( this->controller_info.at(1).addr );

功能同样可正常运行。

疑问：该问题是否由编译器优化导致？为何std::stringstream cmd缓冲区的数据会出现混杂？

解答

这个问题和编译器优化、std::stringstream缓冲区混杂没有任何关系，本质是TCP套接字的标准行为导致的，具体原因如下：

首先排除缓冲区/编译器问题
你观测到两次write都返回6字节，已经证明每次调用都成功把6字节数据提交给了内核套接字发送缓冲区。std::stringstream是home_axis()函数内的局部栈变量，每次函数调用都会新建实例，函数返回后就会销毁，根本不可能跨调用残留数据。同时write是系统调用，编译器没有权限跨过系统调用边界合并用户态的发送缓冲区，不可能出现优化导致的数据混杂。
核心原因1：TCP是面向字节流的协议，无应用层消息边界
TCP协议只保证字节按顺序、不丢失地递交给接收端，完全不维护应用层的消息分界。也就是说，发送端调用N次write每次写M字节，和接收端调用多少次recv、每次读到多少字节没有任何对应关系：内核既可能把多次write的内容合并成一次recv返回，也可能把单次write的内容拆成多次recv返回，这完全是TCP的标准合规行为，不是异常。
核心原因2：首次循环触发了Nagle算法
Nagle是TCP默认开启的拥塞控制算法，目的是减少网络中小数据包的数量，降低带宽浪费。规则很简单：如果当前连接上还有已发送但未收到对端ACK的数据包，后续提交的小尺寸数据（远小于MSS的包，你这里每次发6字节属于典型小包）会被内核缓存，直到凑够一个MSS、或者之前的包收到ACK，才会把缓存的数据一起发出去。
首次执行for循环时，循环逻辑非常紧凑，两次write的间隔极短：第一次提交的6字节小包刚发出去还没等收到对端ACK，第二次的6字节数据就已经提交到内核，直接被Nagle算法合并成一个TCP段发送，所以接收端一次就读到了12字节的拼接内容。
你观测到的其他现象完全符合这个逻辑

加usleep(1)就正常：1微秒的延迟足够让第一次发送的小包收到对端ACK，Nagle算法不会缓存第二次的数据，两个包分开发送，接收端大概率分两次读到。
手动连续调用两次home_axis()正常：不在循环里时，两次函数调用之间有额外的参数寻址、栈调整开销，间隔刚好够第一次的包收到ACK，没有触发Nagle合并。
第二次执行for循环正常：第一次循环跑完后，TCP连接的RTT估算、拥塞窗口状态已经稳定，两次write的间隔刚好没满足Nagle的合并条件，属于概率性的现象，本身就不是稳定复现的错误。

解决方案

最根本、最正确的处理方式：接收端必须实现应用层的消息拆包逻辑。你的协议里每条指令都是以\n结尾，接收端就应该持续读取套接字数据，把读到的内容存入本地缓冲区，遇到\n就切分出一条完整指令处理，完全不要依赖recv的返回边界做消息判断，这是TCP网络编程的基本要求。
如果需要降低小包合并的概率（注意：这个操作不能替代应用层拆包，就算关闭Nagle，网络链路中的路由器、接收端内核还是可能合并数据包），可以给套接字设置TCP_NODELAY选项关闭Nagle算法：

int flag = 1;
setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

设置后内核会尽快将你提交的数据发送出去，不会主动等待凑包。

内容的提问来源于stack exchange，提问作者astronomerdave

循环调用socket write时字符串缓冲区数据混杂问题

解决方案 #

解决方案