Unix domain socket传输达特定字节后停止工作如何解决

DevOps 小满

2026-8-29

问题根因

截断和Unix domain socket本身的系统级缓冲区限制无关，核心原因是客户端实现没有遵循go-ethereum IPC接口的JSON-RPC协议规范，触发了服务端的僵死连接保护机制，被主动断开了连接。你观察到的219264字节、36544字节两个随机截断阈值，只是不同场景下服务端发送缓冲区/未处理消息队列被打满的临界值，不是固定的传输上限。

你看到的断连流程完全符合Unix SOCK_STREAM流套接字的标准断连表现：

服务端判定连接异常，主动发送FIN包关闭写端，此时客户端的recv会把内核接收缓冲区里剩余的存量数据读完，之后就会永久阻塞
客户端此时继续调用send往已经被对端关闭的套接字写数据，第一次写入会收到对端返回的RST包，第二次写入就会直接抛出OSError: [Errno 32] Broken pipe错误
连接完全释放后，recv会直接返回空字节b''，代表对端已经彻底关闭连接

触发服务端主动断连的具体代码问题有三个：

接收循环没有判断recv返回值，收到空字节时没有做断连处理，反而持续空转
没有处理SOCK_STREAM的粘包/半包问题，只是无脑把所有收到的字节拼到一个大变量里，不解析、不响应合法的JSON-RPC消息，导致服务端长期收不到协议要求的响应包
发送端无节制死循环发请求，完全不匹配接收处理速度，导致未处理的响应在服务端的单连接队列里持续堆积，超过阈值就会被服务端强制踢掉连接

修复方案

直接按下面的逻辑调整客户端代码即可：

接收逻辑增加空返回值判断，识别到连接被对端关闭时立刻触发重连，不要无效阻塞
接收缓冲区按JSON格式做消息切分，收到完整JSON-RPC消息后立刻处理，需要回响应的消息及时回包，不要让数据无限堆积在内存里
控制发送速率，发送请求后及时消费对应的响应，不要让未处理消息队列打满
增加合理的超时和保活逻辑，避免长期无数据传输被服务端回收连接

修正后的最小可用接收代码参考：

import socket
import json

# 初始化连接
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(socketpath)
s.settimeout(15)  # 设置合理超时，避免永久阻塞
read_buf = b""

while True:
    try:
        chunk = s.recv(4096)  # 调大单块接收大小，减少系统调用开销
        # 识别对端断连
        if not chunk:
            print("Connection closed by geth, reconnecting...")
            s.close()
            # 重连逻辑
            s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
            s.connect(socketpath)
            s.settimeout(15)
            read_buf = b""
            continue
        
        read_buf += chunk
        # 循环切分缓冲区里的完整JSON消息，处理粘包半包
        while True:
            try:
                msg, end_idx = json.JSONDecoder().raw_decode(read_buf.decode("utf-8"))
                read_buf = read_buf[end_idx:]
                # 业务层处理收到的JSON-RPC消息，需要响应的请求在此处回包即可
                print(f"Processed message: {msg}")
            except json.JSONDecodeError:
                # 剩余内容是不完整的半包，退出继续等数据
                break
    except socket.timeout:
        # 超时发个轻量请求保活
        ping_msg = json.dumps({
            "jsonrpc": "2.0",
            "method": "eth_chainId",
            "params": [],
            "id": 0
        }).encode()
        s.sendall(ping_msg)

另外注意发送逻辑不要写无间隔死循环狂发请求，最好发一批等对应响应处理完再发下一批，从根源避免消息堆积。

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