将获取的响应通过管道传输到客户端时如何防范内存与TCP连接泄漏

结合你的代码和服务器监控数据，我梳理了几个可能导致TCP连接/内存泄漏的场景，以及对应的解决方法：

1. 客户端提前断开连接，上游fetch请求未终止 #

当用户关闭浏览器标签、网络中断或客户端主动取消请求时，Express的response流会触发close事件，但你的代码目前只监听了response的error事件——正常断开不会触发error，只会触发close。此时如果不终止上游的fetch请求，node-fetch会继续从cdn.example.com下载数据，持续占用TCP连接和内存，最终导致ESTABLISHED或CLOSE_WAIT连接数上升，内存累积。

修复方法： #

监听response的close事件，一旦触发就取消上游的fetch响应流：

const { pipeline } = require('stream');
const express = require("express");
const app = express();
const fetch = require('node-fetch');

app.get("/file/:path", async function(request, response) {
  const path = request.params.path;
  const reqController = new AbortController();
  const reqTimeout = setTimeout(() => reqController.abort(), 10000);

  let r;
  try {
    r = await fetch(`https://cdn.example.com/${encodeURIComponent(path)}`, {
      signal: reqController.signal,
    });
  } catch (e) {
    // 完善你的错误处理逻辑
    return response.send("error");
  } finally {
    clearTimeout(reqTimeout);
  }

  if (!r.ok) {
    return response.send("error");
  }

  // 客户端断开时，终止上游fetch流
  response.on('close', () => {
    r.body.cancel('Client disconnected');
  });

  // 上游流出错时，终止响应
  r.body.on('error', (err) => {
    if (!response.headersSent) {
      response.status(500).send("error");
    } else {
      response.destroy(err);
    }
  });

  // 使用stream.pipeline替代pipe，自动处理流的错误和资源清理
  pipeline(r.body, response, (err) => {
    if (err) {
      // 处理管道错误，比如传输中断
      console.error('Pipeline failed:', err);
    }
  });
});

2. 使用pipe而非stream.pipeline导致资源未清理 #

原生的stream.pipe()方法不会自动处理所有错误场景：如果中间某个流出错，可能会导致其他流处于挂起状态，无法释放TCP连接和内存。而Node.js内置的stream.pipeline()会自动管理流的生命周期，在完成或出错时销毁所有相关流，避免资源泄漏。

修复方法： #

直接替换r.body.pipe(response)为stream.pipeline，如上例所示。pipeline会自动处理流的错误、关闭和清理，比pipe更可靠。

3. node-fetch timeout选项的局限性（及AbortSignal的补充） #

你提到的node-fetch v2的timeout选项仅控制从请求发起至响应头接收的时间，一旦响应头成功返回，这个超时就不再生效。如果响应体传输非常缓慢（比如CDN服务器卡顿，分块传输耗时超过10秒），原来的AbortController超时是从请求开始计算的，可能在响应体传输到一半时就触发中止，但如果响应头是在第9秒收到的，响应体仅能传输1秒就被中止——这可能不是你想要的，同时如果超时逻辑覆盖不全，也会导致连接长期占用。

修复方法： #

添加响应体传输的超时监控：在响应体开始传输后，设置一个基于最后一次数据接收的超时，若长时间没有数据传输，则中止请求：

// 在pipeline之前添加
let transferTimeout;
const resetTransferTimeout = () => {
  clearTimeout(transferTimeout);
  // 如果10秒没有收到数据块，中止请求
  transferTimeout = setTimeout(() => {
    reqController.abort('Transfer timeout');
  }, 10000);
};

// 每次收到数据块时重置超时
r.body.on('data', resetTransferTimeout);
// 流结束或出错时清除超时
r.body.on('end', () => clearTimeout(transferTimeout));
r.body.on('error', () => clearTimeout(transferTimeout));

4. CLOSE_WAIT连接堆积的根源 #

从你的netstat数据看，CLOSE_WAIT连接数从1涨到37，说明你的Express服务器收到了客户端的FIN包（客户端已断开），但没有主动关闭对应的TCP socket。这通常是因为响应流没有被正确销毁，或者上游的fetch流没有被终止，导致socket资源被挂起。

修复方法： #

结合前面的response.close事件监听和stream.pipeline的自动清理，确保任何客户端断开或流错误场景下，都能销毁响应流并终止上游请求，让TCP连接正常关闭。

额外建议 #

1. 升级node-fetch版本：node-fetch v2.6.1存在一些已知的流处理和超时相关的bug，升级到v2的最新稳定版（v2.6.12）或v3+（注意v3是ESM，需要调整代码结构）可以修复部分问题。
2. 监控未处理的Promise拒绝：在Node.js中添加process.on('unhandledRejection', (err) => console.error(err))，排查是否有未捕获的Promise拒绝导致资源泄漏。
3. 调整TCP内核参数：如果TIME_WAIT连接数过高（比如你的4000+），可以调整/proc/sys/net/ipv4/tcp_tw_reuse为1，减少TIME_WAIT的资源占用，但这是系统层面的优化，核心还是要先修复代码层面的泄漏。

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