javascript - 与浏览器相比，通过 Node.js 的 HTTP 请求延迟

Question

使用 Node.js 通过 HTTP 请求查询一些公共(public) API。因此，我正在使用 request 模块。我正在测量我的应用程序中的响应时间，并看到我的应用程序从 API 查询返回的结果比通过 curl 或浏览器中的“直接”请求慢 2-3 倍。此外，我注意到与启用 HTTPS 的服务的连接通常比普通的 HTTP 连接花费更长的时间，但这可能是巧合。

我尝试优化我的 request 选项，但无济于事。比如我查询

https://www.linkedin.com/countserv/count/share?url=http%3A%2F%2Fwww.google.com%2F&lang=en_US

我正在使用 request.defaults 来设置所有请求的整体默认值:

var baseRequest = request.defaults({
    pool: {maxSockets: Infinity},
    jar: true,
    json: true,
    timeout: 5000,
    gzip: true,
    headers: {
        'Content-Type': 'application/json'
    }
});

实际的请求是通过

...
var start = new Date().getTime();

var options = {
    url: 'https://www.linkedin.com/countserv/count/share?url=http%3A%2F%2Fwww.google.com%2F&lang=en_US',
    method: 'GET'
};

baseRequest(options, function(error, response, body) {

    if (error) {
        console.log(error);
    } else {
        console.log((new Date().getTime()-start) + ": " + response.statusCode);
    }

});

有人看到优化潜力吗？我做错了什么吗？提前感谢您的任何建议!

Answer 1

鉴于我从您的架构中了解到的情况，您需要解决几个潜在问题。它们没有特定的顺序:

• 使用 request 总是比直接使用 http 慢，因为正如智者所说:“抽象成本”。 ;) 事实上，为了尽可能提高性能，我会直接使用 Node 的 net 模块处理所有 HTTP 请求。对于 HTTPS，不值得重写 https 模块。需要说明的是，由于需要握手加密 key 和对有效负载进行加密/解密工作，HTTPS 始终比 HTTP 慢。
• 如果您的要求包括从任何单个服务器检索多个资源，请确保这些请求使用 http KeepAlive 集按顺序发出，以便您可以从已经打开的套接字中受益。与在已打开的套接字上发出请求相比，握手新 TCP 套接字所需的时间巨大。
• 确保禁用 http 连接池(请参阅 Nodejs Max Socket Pooling Settings)
• 确保您的操作系统和外壳不限制可用套接字的数量。见 How many socket connections possible?提示。
• 如果您使用的是 linux，请查看 Increasing the maximum number of tcp/ip connections in linux我还强烈建议微调内核套接字缓冲区。

我会在遇到更多建议时添加它们。

更新

更多关于对同一端点的多个请求的主题:

如果您需要从同一端点检索大量资源，将您的请求分段到与该端点保持开放连接的特定工作人员会很有用。这样，您可以放心，您可以尽快获得请求的资源，而不会产生初始 TCP 握手的开销。

TCP 握手是一个三阶段的过程。

第一步:客户端向远程服务器发送一个SYN包。第二步:远程服务器向客户端回复一个SYN+ACK。第三步:客户端用 ACK 回复远程服务器。

根据客户端对远程服务器的延迟，这可以加起来(正如 William Proxmire 曾经说过的)“真钱”，或者在这种情况下，延迟。

在我的桌面上，2K 八位字节数据包到 www.google.com 的当前延迟(通过 ping 测量的往返时间)在 37 到 227 毫秒之间。

所以假设我们可以依赖 95ms 的往返平均值(通过完美连接)，初始 TCP 握手的时间大约为 130ms 或 SYN(45ms) + SYN+ACK(45ms) + ACK( 45 毫秒)，这只是建立初始连接的十分之一秒。

如果连接需要重新传输，则可能需要更多更长的时间。

这是假设您通过新的 TCP 连接检索单个资源。

为了改善这种情况，我会让您的工作人员保持一个与“已知”目的地的开放连接池，然后他们会将这些连接池通告回主管进程，以便它可以将请求定向到具有“实时”连接的负载最少的服务器到目标服务器。