Linux多客户端-服务端子进程stdin高效传输问题咨询

一、如何增大传输数据块提升通信效率 #

针对你的场景，可以从以下几个方向入手优化：

• 增大服务端read调用的缓冲区大小
  当前每次读取的块固定为65536字节，大概率是read调用时指定的缓冲区大小就是这个值。直接把read的参数改大（比如设为4*1024*1024即4MB），内核会尽可能把当前接收缓冲区里的所有数据一次性返回给应用层，减少读取和解析的次数。

• 异步分离数据读取与解析操作
  现在解析单块数据要0.01秒，这个耗时会阻塞服务端继续读取新数据。把解析逻辑放到单独的线程池/进程池处理，主线程只负责用select监听并快速读取数据到内存队列，这样服务端能及时腾出TCP接收缓冲区，让客户端可以发送更大的数据块。

• 调整TCP缓冲区大小
  在客户端和服务端的socket上设置更大的收发缓冲区：

  • 代码层面用setsockopt设置：

    # 服务端设置接收缓冲区（示例为2MB）
    server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 2 * 1024 * 1024)
    # 客户端设置发送缓冲区
    client_sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 2 * 1024 * 1024)
    

  • 同时调整Linux系统参数，确保内核允许这么大的缓冲区：

    sysctl -w net.core.rmem_max=2097152  # 最大接收缓冲区
    sysctl -w net.core.wmem_max=2097152  # 最大发送缓冲区
    

  更大的缓冲区能让内核缓存更多数据，服务端一次read可以拿到更大的数据块。

• 客户端一次性发送完整序列化数据
  确保客户端把pickle序列化后的整个大bytes对象用sendall一次性发送，让内核负责TCP分段，而不是手动拆分发送。这样只要服务端接收窗口足够大，内核会攒够更多数据再发送，减少小数据包的数量。

二、为什么time.sleep(0.1)会减小数据块大小 #

核心原因是TCP滑动窗口机制和应用层接收节奏的影响：

• 当服务端调用time.sleep(0.1)时，会暂停0.1秒才会再次读取数据。这段时间里，客户端发送的数据会堆积在服务端的TCP接收缓冲区中，缓冲区可用空间持续减少。服务端的TCP栈会通过TCP窗口通告告诉客户端“当前只能接收少量数据”，客户端因此只能发送小数据块，直到服务端恢复读取、腾出缓冲区空间。
• 同时，默认开启的Nagle算法会让客户端TCP栈等待前一个数据包的ACK或攒够足够数据再发送。服务端sleep导致ACK延迟返回，Nagle算法会因为超时提前发送小数据块，进一步加剧数据块过小的问题。
• 而CPU满载或去掉sleep时，服务端read调用频率极高，能快速清空接收缓冲区，TCP窗口始终保持较大状态，客户端可以一次性发送更大的数据块，Nagle算法也能攒够足够数据再发送，因此数据块显著增大，传输效率大幅提升。

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