Undici项目中SocketError: other side closed问题的深度解析

问题现象与背景

在Node.js生态中，Undici作为新一代HTTP客户端库，因其高性能特性被广泛使用。近期社区反馈在使用fetch API时频繁遇到"SocketError: other side closed"错误，特别是在处理大量数据流传输场景下。该问题表现为客户端连接被意外终止，导致数据传输中断。

问题根源分析

经过技术团队深入排查，发现问题主要源于以下几个技术层面：

1. 服务器端连接管理：当服务器使用res.write()连续写入大量数据且未采用回调机制时，会导致TCP缓冲区过载，最终触发服务器主动关闭连接。

2. 客户端重连机制缺失：Undici的Agent在连接断开后不会自动重建连接，需要应用层自行处理重连逻辑。

3. 流控机制不足：在高速数据传输场景下，缺乏有效的背压(backpressure)控制机制，容易造成数据积压。

典型重现场景

通过最小化复现案例可以清晰展示问题特征：

• 连续发起多个大体积数据请求(如10MB以上)
• 使用流式传输模式(isStream: true)
• 服务器采用Express等框架快速写入响应
• 客户端使用Readable.fromWeb转换数据流

解决方案与实践建议

服务器端优化

1. 实现背压控制：使用promisify包装res.write，确保每次写入完成后再继续：

const resWrite = promisify(res.write.bind(res));
await resWrite(data);

2. 分块传输优化：对大响应体采用分块编码传输，避免单次写入过大缓冲区。

3. 连接超时配置：合理设置keepAlive超时时间，避免空闲连接被意外关闭。

客户端处理

1. 重试机制实现：对fetch请求封装自动重试逻辑，建议采用指数退避算法：

async function fetchWithRetry(url, options, maxRetries = 3) {
  let lastError;
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fetch(url, options);
    } catch (err) {
      lastError = err;
      await new Promise(r => setTimeout(r, 100 * Math.pow(2, i)));
    }
  }
  throw lastError;
}

2. 连接池监控：定期检查连接池状态，及时释放异常连接。

3. 响应流处理：确保正确消费响应流数据，避免数据积压：

const stream = Readable.fromWeb(response.body);
stream.on('data', chunk => {
  // 及时处理数据
});

版本兼容性说明

该问题在不同Node.js版本表现有所差异：

• Node 18/20版本均有报告
• 部分用户反馈Node 18相对稳定
• 根本解决方案需结合应用场景调整

最佳实践总结

1. 生产环境建议实现完整的错误监控和重试机制
2. 大数据传输场景务必实现背压控制
3. 保持Undici和Node.js版本更新
4. 考虑使用成熟的HTTP客户端库封装基础功能

通过以上技术方案，开发者可以有效解决"SocketError: other side closed"问题，构建更健壮的HTTP通信系统。