跨机器TCP通信：C++发送uint32_t至Python接收字节异常

问题背景 #

C客户端通过TCP Socket发送uint32_t类型调试数据（值为255，经htonl转换为网络字节序后字节序列为00 00 00 FF），Python端通过recv(4)获取数据并使用struct.unpack('!I')解析。本地测试完全正常，但跨机器部署后，Python端固定收到b'\x14\x01\x02\x00'（解析结果为335610368），C端发送日志显示字节序列正常。

具体排查方向 #

1. 排查数据流是否被残留数据污染 #

• 检查C++端：调用send_int前，确认Socket发送缓冲区无残留未发送数据。可通过getsockopt查询缓冲区状态，或改为短连接模式（每次发送新建Socket）避免旧数据干扰。
• 检查Python端：调用receive_int前，先读取并丢弃Socket接收缓冲区中所有残留数据，确保本次接收的是最新发送的内容。

2. 精准验证抓包数据 #

• 在Python端所在机器的网卡上抓取目标TCP连接的流量，确认：
  • 若抓包显示C发送的就是14 01 02 00，说明问题出在C端（比如日志打印的是转换后的值，但实际发送了其他内存数据）；
  • 若抓包显示发送的是正确的00 00 00 FF，但Python端收到错误数据，需排查Python接收逻辑或极端情况（如中间网络设备篡改数据）。

3. 核查C++发送逻辑的准确性 #

• 确认发送字节数完整：务必检查send函数的返回值，确保实际发送了4字节：

  uint32_t num = 255;
  uint32_t net_num = htonl(num);
  ssize_t sent_bytes = send(sock_fd, &net_num, sizeof(net_num), 0);
  if (sent_bytes != sizeof(net_num)) {
      fprintf(stderr, "发送不完整：仅发送了%zd字节\n", sent_bytes);
  }
  

• 检查内存是否被篡改：确认net_num变量在send调用前未被其他代码意外修改，可在send前再次打印其内存中的字节值，和日志做对比。

4. 修复Python端的接收逻辑 #

• 确保接收完整4字节：recv(4)可能因网络分段只返回部分字节，需改为循环接收直到凑够4字节：

  import struct
  
  def receive_int(sock):
      received_data = b''
      while len(received_data) < 4:
          chunk = sock.recv(4 - len(received_data))
          if not chunk:
              raise ConnectionError("连接已关闭")
          received_data += chunk
      return struct.unpack('!I', received_data)[0]
  

• 验证接收数据长度：每次接收后打印数据长度，避免因短数据导致解析错误。

5. 排除中间网络设备干扰 #

• 尝试在两台机器间直连网线测试，避开路由器、防火墙等设备；或改用UDP协议发送相同数据，验证是否能收到正确内容，排除网络设备篡改的可能性。

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