TCP客户端向已断开socket首次send()成功后续返回Errno 32 Broken pipe问题

1. 现象产生原因 #

TCP协议中send()方法的成功返回仅代表数据被成功拷贝到操作系统内核的套接字发送缓冲区，不代表数据已经成功发送到服务端并被接收，该现象的完整流程如下：

• 服务端关闭连接后会向客户端发送FIN包，客户端TCP状态进入CLOSE_WAIT，此时客户端内核还未检测到连接不可写
• 首次调用send()时，内核直接将数据写入发送缓冲区就返回成功，随后内核尝试把缓冲区的数据发送给服务端，已经断开连接的服务端会响应RST包
• 客户端内核收到RST包后会标记套接字为异常状态，后续所有调用send()的请求都会直接触发SIGPIPE信号，Python中会抛出[Errno 32] Broken pipe异常

2. 需求实现方案 #

a) 让首次发送请求也直接报错 #

该需求的核心是在调用send()前提前感知到连接已经断开，避免执行实际发送逻辑：
在每次发送数据前，先调用非阻塞模式的recv探测连接状态，示例代码如下：

def is_conn_alive(s):
    s.setblocking(False)
    try:
        # MSG_PEEK标识只读取数据不移出发送缓冲区，不影响后续正常读操作
        data = s.recv(1, socket.MSG_PEEK)
        if len(data) == 0:
            # 收到空字节代表对方已关闭连接
            return False
    except BlockingIOError:
        # 无数据可读，连接正常
        return True
    except:
        return False
    finally:
        s.setblocking(True)
    return True

每次调用send()前先调用该函数，如果返回False直接抛出异常即可实现首次发送直接报错的效果。

b) 发送数据前检测连接是否存活 #

常用的检测方案有三种，可根据场景选择：

• 方案1：上述非阻塞recv探测方案，优点是实现简单无额外开销，缺点是只能检测到已经完成FIN/RST交互的断开场景，无法检测中间链路中断等静默断连场景
• 方案2：开启TCP内置keepalive机制，操作系统会自动定期发送探测包检测连接状态，示例配置：

# 开启keepalive
s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
# 连接空闲3秒后开始发探测包
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 3)
# 探测包每隔1秒发一次
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 1)
# 连续3次探测失败判定连接断开
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)

优点是内核自动处理不需要应用层逻辑，缺点是配置依赖操作系统，探测粒度较粗

• 方案3：应用层自定义心跳协议，客户端定期向服务端发送心跳包，要求服务端返回指定响应，如果超过阈值未收到响应则判定连接断开。优点是准确性最高、可控性强，可自定义探测频率和超时规则，缺点是需要修改应用层通信逻辑，有额外的心跳包开销

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