一次 Node.js http 连接池无法复用的问题排查

5,236 阅读4分钟

一次压测中阿里云 SLB 的并发连接数被打满了,导致服务之间的 HTTP 调用延迟很大。当时 SLB 的并发连接数情况如下图所示。

登录容器终端查看,发现某个前端 Node.js 服务中的单个容器的 ESTABLISH 状态的连接数达到 2 万多个,几十个容器直接把连接数占满了。

通过 tcpdump 抓包发现了如下的情况:

  • http 连接请求头都有带上 Connection: Keep-Alive
  • 连接全部都没有复用,一个连接三次握手完,隔了 65s 才会被 nginx 超时发送 fin 包断开

因此连接既有 Keep-Alive,不会在 http 请求处理完以后关闭,又没有被复用,因此压测请求一上来,连接蹭蹭蹭的往上涨,马上就达到了 SLB 的瓶颈。

一开始我们以为是 Node.js 的 http.Agent 的参数设置有错误,Node.js 通过http.Agent 来管理可复用的连接,创建 http.Agent 实例的方法如下:

var agent = new http.Agent();

请求头 Connection: Keep-Alive 就是在 http.Agent 中指定的,如下所示。

var agent = new http.Agent({keepAlive: true})

我们来写一个最简单的例子,代码如下所示。

let http = require('http');

const agent = new http.Agent({keepAlive: true,});

function sendHttp() {
    http.get({
        hostname: 'ya.test.me',
        port: 80,
        path: '/',
        agent: agent
    }, (res) => {
        console.log('STATUS: ' + res.statusCode);
        res.on('data', chunk => {
            console.log('BODY: ' + chunk);
        });
    });
}

sendHttp();

setTimeout(function () {
    console.log("start sleep");
    sendHttp();
}, 10 * 1000);

setTimeout(function () {
}, 100000);

执行上面的 Node.js 代码,得到的抓包结果如下

可用看到这次实验中的包,间隔 10s 的两次 HTTP 请求复用了 TCP 连接,这个连接在空闲 65s 左右以后被 Nginx 断开。

排查到这里,貌似思路就断了。Node.js 明明有复用连接的能力,为什么这里没有生效。只能去阅读 Node.js 的 Agent 的源码,发现它在底层维护了requests、freeSockets 等数据结构,如下所示。

function Agent(options) {
  this.requests = {};
  this.sockets = {};
  /**
  *  freeSockets 是一个 map,结构如下:
  *  test.ye.me:80 -> [socket1, socket2, socket3...]
  *  xxx.com:8080 -> [socket1, socket2, socket3...]
  **/
  this.freeSockets = {}; 
  this.keepAliveMsecs = this.options.keepAliveMsecs || 1000;
  this.keepAlive = this.options.keepAlive || false;
  // 允许对单个 host:port 最大的连接数
  this.maxSockets = this.options.maxSockets || Agent.defaultMaxSockets;
  // 允许对单个 host:port 最大的空闲连接数
  this.maxFreeSockets = this.options.maxFreeSockets || 256;
}

当连接空闲时,会回调 free 事件,核心代码注释如下所示。

 this.on('free', (socket, options) => {
    // name 是域名和端口的拼接字符串 test.ya.me:80:
    var name = this.getName(options);
        // 得到当前的域名端口对应的 freeSockets 数组
        var freeSockets = this.freeSockets[name];
        var freeLen = freeSockets ? freeSockets.length : 0;
        var count = freeLen;
        // 如果当前空闲连接大于配置的 maxSockets 或 maxFreeSockets 值,直接关闭当前这个 socket
        if (count > this.maxSockets || freeLen >= this.maxFreeSockets) {
          socket.destroy(); // 关闭 socket
        } else if (this.keepSocketAlive(socket)) {
          如果是 Keep-Alive 的 socket,将它加入到 freeSockets 数组中
          freeSockets = freeSockets || [];
          this.freeSockets[name] = freeSockets;
          socket[async_id_symbol] = -1;
          socket._httpMessage = null;
          this.removeSocket(socket, options);
          freeSockets.push(socket); 
        } else {
          前面都不满足要它何用,关掉
          // Implementation doesn't want to keep socket alive
          socket.destroy();
        }
    }
  });
}

通过调试,发现线上服务的代码,确实有回调到 free 事件,但是没有调用过 reuseSocket 方法。后来前端大佬去看代码发现了一点蛛丝马迹,每次请求时,都新建了一个 http.Agent 对象,这样就相当于每次 http 调用都新建了一个连接池,每次 HTTP 请求完以后这个连接池的空闲连接数都是 1。下面来进行实验,代码如下。

let express = require("express");
let app = express();
let http = require('http');

app.get("/", function (req, res) {
    http.get({
        hostname: 'ya.test.me',
        port: 80,
        path: '/',
        agent: new http.Agent({keepAlive: true,})
    }, (result) => {
        console.log('STATUS: ' + result.statusCode);
        result.on('data', chunk => {
            console.log('BODY: ' + chunk);
        });
        res.send("hello");
    });
});
app.listen(3000);

启动这个 Node.js 服务,同时开始抓取 80 端口的包,使用 ab 工具(其它能批量发起 http 调用工具也行)调用这个 node 服务,

ab -n 5000 -c 10  'http://10.211.55.10:3000/'

短短时间内 ESTABLISH 的连接就达到了几千个,这些连接全部没有复用。与线上的现象一样。

netstat -lnpa | grep :80 | grep -v 8080  | awk '{print $6}' | sort | uniq -c | sort -rn

   2038 ESTABLISHED
      1 LISTEN

跟踪其中一个包,它的包交互过程如下。

这个连接保持了 65s 才被 Nginx 超时断开,既占了连接,又没有复用,比短连接危害更大。

接下来我们把 http.Agent 对象改为了全局公用,重新来一遍实验,使用 netstat 的结果如下所示。

netstat -lnpa | grep :80 | grep -v 8080  | awk '{print $6}' | sort | uniq -c | sort -rn

     10 ESTABLISHED
      1 LISTEN

可以看到全程最多只创建了 10 个连接,相比于之前的 2000 多个,降了几个数量级。wireshark 跟踪一个包的结果如下。

可以看到连接终于被复用起来了。

小结

这个问题本来比较简单,只是因为对封装过很多层以后的 Node.js 不太熟悉,导致排查花了一些时间。这个问题在 Java 中很早也犯过错,使用 OkHttp 发起连接时,如果 OkHttpClient 实例没有被单例,每次调用都 new 一个的话,那就是一个灾难。因为 OkHttpClient 内部也是维护了一个连接池。

public class OkHttpClient implements Cloneable, Call.Factory, WebSocket.Factory {
  final ConnectionPool connectionPool;
}

教训告诉我们,连接池使用需谨慎,连接池需要共享。

有问题可以扫描下面的二维码关注我的公众号到联系我。