深入Node.js http模块：请求-响应、流与连接管理全链路解析

早几年带团队排查过一次线上接口抖动，最后定位到的根因让我印象很深：不是业务代码慢，也不是数据库有慢查询，而是几个后端同学对 Node.js 的 HTTP 模块理解停留在“会调 Express 就行”的层面。请求对象什么时候能读、响应流什么时候真正发出去、连接什么时候复用，这些底层行为一旦没搞懂，出问题时就只能靠猜。从那以后我养成了一个习惯，不管是带新人还是自己做技术方案，都先回到 Node.js 的 http 模块把链路讲清楚。

这篇文章只聚焦一件事：用 Node.js 自带的 http 模块，把一个 HTTP 服务从创建、接收请求、返回响应，到作为客户端主动请求上游接口的完整链路走一遍。内容包括每一步的代码怎么写、背后的机制是什么、哪些地方最容易踩坑，以及我实际调试线上问题时的处理思路。不管你是刚学 Node.js 不久、还在被各种框架“保护”着，还是写接口已经写了挺久但想补一补底层知识，这篇都值得你花十几分钟读完。

1. 最小 HTTP 服务器跑通之后，先看清请求响应模型

1.1 从 createServer 说起：回调不是“死循环”，而是事件驱动

很多人第一次接触 Node.js HTTP 服务，看到的都是这段代码：

javascript复制const http = require('http');

const server = http.createServer((req, res) => {
  console.log(`${req.method} ${req.url}`);
  res.end('hello world');
});

server.listen(3000, () => {
  console.log('server is running at http://localhost:3000');
});

代码确实能跑，curl 一下也能看到 hello world。但你有没有想过一个问题：createServer 传入的回调，到底在什么时刻执行？它是不是像 while(true) 一样在循环处理请求？

Node.js 的单线程事件循环决定了这两者完全不同。createServer 的回调并不是自己在一个死循环里等待请求，而是由底层 libuv 负责监听 TCP 端口。当有 HTTP 请求到达、并且解析出完整的请求头之后，Node 才会触发一次 request 事件，刚才传入的回调才会被事件循环推入调用栈执行。也就是说，回调的每次调用，都对应一个真实到达的 HTTP 请求。

同一个时间段里，事件循环可以在多个请求之间快速切换。比如请求 A 的回调里遇到异步 I/O（读数据库、读文件），回调会先返回，事件循环继续处理请求 B、请求 C 的事件。等数据库结果回来了，再把 A 的剩余逻辑推入执行。这也是 Node.js 面对高并发 I/O 密集场景时不吃亏的根本原因。

还有一个容易被忽略的概念：createServer 创建出来的 server 对象，本身是一个 EventEmitter。它支持的事件远不止 request 一个，常见的还有 connection、clientError、upgrade、listening 等。后面排查错误的时候，这些事件会派上大用场。比如 clientError 事件如果不监听，某些畸形 HTTP 请求可能导致连接被直接粗暴处理，甚至把进程搞出意外表现。

1.2 listen 参数与端口被占用

server.listen 看似简单，参数细节却经常导致新手上线时翻车。listen 最常用的形式是 server.listen(port, host, backlog, callback)，其中 host 默认是 0.0.0.0，也就是监听所有网卡地址。开发环境用 localhost 没问题，但部署到服务器上如果只想让内网访问，至少要写成 server.listen(3000, '127.0.0.1')，否则公网可能直接就能扫到你的服务。

端口被占用是启动阶段最常见的问题，报错信息是 EADDRINUSE。原因很直白，端口已经被另一个进程占用了。我习惯的排查方式是：

bash复制# Linux / macOS
lsof -i :3000

# Windows
netstat -ano | findstr :3000

看到占用进程的 PID 之后，再决定是 kill 掉对方，还是让当前服务换个端口。还有一个开发时很实用的小技巧：传入端口 0，Node 会自动分配一个空闲端口：

javascript复制const server = http.createServer(handler);
server.listen(0, () => {
  console.log(`listening on port ${server.address().port}`);
});

这在写自动化测试、需要并行起多个临时服务时非常省心，再也不用到处找空闲端口了。

1.3 别漏掉一个核心认知：req 和 res 本质上是两条流

回调签名是 (req, res)，很多人只把它当成两个普通对象，拿到 req.url 和 res.end 就开始写业务，其实它们真正的身份是流对象。

req 是一个 Readable 流，也就是一个可读流，表示从客户端传来的请求数据。请求头可能先到的，所以回调触发时，你可以立刻读取 req.method、req.url、req.headers。但请求体不一定已经完整到达，要等流被消费的过程中，数据块一个接一个地冒出来。

res 是一个 Writable 流，表示将要写回给客户端的响应数据。你调用 res.write 是往流里写数据，调用 res.end 表示数据写完了、这段响应到此结束。如果回调执行完却始终没有调用 res.end，客户端会一直转圈等待，直到服务端超时断开连接。很多新手本地调试时看到请求迟迟不返回，却没有意识到是服务端忘了结束响应。

因为 res 是 Writable 流，所以它天然支持 pipe 的“另一头”。比如读取一个本地文件，直接把文件流接到 res 上，大文件下载就这么几行代码完成。这个我们放到响应章节细说。

2. 请求处理：URL、请求头、请求体的完整读取方式

2.1 手动路由怎么解析？方法加路径，别忽略查询串

常见面试题里都有一道：“不用 Express，怎么用原生 http 写一个路由？” 新手写出来往往是这样：

javascript复制const server = http.createServer((req, res) => {
  if (req.url === '/') {
    res.end('home');
  } else if (req.url === '/users') {
    res.end('users');
  } else {
    res.statusCode = 404;
    res.end('not found');
  }
});

这段代码用 curl 测试带查询参数的请求时会立刻露馅：/users?page=1 和 /users 显然是同一个资源，但用 === 判断时，前者直接走到 404。正确做法是先把 URL 解析出路径和查询参数，再做路由匹配：

javascript复制const server = http.createServer((req, res) => {
  const url = new URL(req.url, `http://${req.headers.host}`);
  const { pathname, searchParams } = url;

  if (req.method === 'GET' && pathname === '/users') {
    const page = searchParams.get('page') || '1';
    res.end(`page: ${page}`);
    return;
  }

  res.statusCode = 404;
  res.end('not found');
});

这里用 new URL 解析有两个好处：一是 query 解析由标准 URL API 完成，不会出现自己 split('?') 时漏掉边界的情况；二是中文、特殊字符等 URL 编码会被正确解码。解析时用 req.headers.host 拼出完整地址，是因为 req.url 里通常只有路径和查询串，没有协议和主机名。

实际项目里如果路由数量很多，我仍然建议用框架或者轻量路由库，没必要自己造轮子。但理解这个解析过程仍然有价值——它决定了你在框架里写的路由如何与真实请求对应，排查路由不生效的问题时，你能立刻想到是不是查询串、斜杠、编码在捣乱。

2.2 请求头不是“字典”？大小写、重复头与转发

req.headers 在 Node.js 中是一个对象，但和普通 JavaScript 对象有几个重要差异。首先，属性名全部转为小写。客户端发来的 Content-Type、content-type、CONTENT-TYPE，在 req.headers 里统一是 content-type。如果你代码里写 req.headers['Content-Type']，取到的永远是 undefined。这个坑在对接外部接口时尤其容易出现，对方文档写的是大写，抄代码时没注意就翻了车。

其次，某些请求头在 HTTP 协议里允许重复出现，比如 Accept、Cookie、Set-Cookie。Node 对重复头的处理方式是：能合并的用逗号拼成字符串；不能合并的，比如 set-cookie，则可能是数组。判断类型时不要写死，要用 Array.isArray 做兼容。

请求头在做代理转发、网关类服务时有一个经典问题：要不要把客户端的请求头完整透传给上游？我的经验是，基础的 Content-Type、Accept、Authorization 应该透传；但 Connection、Host、Transfer-Encoding、Content-Length 这类属于连接层的头，转发时通常需要由代理层重新计算或去掉，否则上游解析会出错。http 模块自带的 http.request 会自动处理一部分，但如果你手动从 req.headers 里复制所有字段再发给上游，很容易把 hop-by-hop 头带过去，导致上游响应异常。

2.3 请求体读取：必须主动消费，否则真的会挂起

GET 请求一般没有请求体，但 POST、PUT 请求的请求体必须主动读取。原因是 req 是 Readable 流，默认处于暂停模式，不监听 data 事件、不调用 resume 或 pipe，数据不会自己跑出来。

一个标准的读取方式是这样：

javascript复制function readBody(req) {
  return new Promise((resolve, reject) => {
    const chunks = [];
    let size = 0;

    req.on('data', (chunk) => {
      chunks.push(chunk);
      size += chunk.length;
      if (size > 1 * 1024 * 1024) {
        reject(new Error('body too large'));
        req.removeAllListeners('data');
        req.resume();
        return;
      }
    });

    req.on('end', () => {
      resolve(Buffer.concat(chunks).toString('utf-8'));
    });

    req.on('error', reject);
  });
}

这里有两个细节值得展开。第一，chunk 是 Buffer，不能直接用 += 拼接字符串，否则二进制内容会出现乱码，正确做法是收集 Buffer 数组，最后 Buffer.concat。如果你确定 body 是纯文本，也可以在读取前调用 req.setEncoding('utf-8')，这样 data 事件拿到的就是 string，直接累加也行。

第二，请求体超限之后不能只 reject，还要考虑连接的处理。上面代码里我用 req.resume() 把剩余数据读掉并丢弃，目的是让连接上的数据被清空。否则你直接返回 413 后，客户端可能还在继续发数据，连接状态就乱了。

还有一个特别隐蔽的问题：如果业务根本不需要读取请求体，比如只根据 URL 和请求头做处理，也建议至少调用一次 req.resume() 清空数据。否则在 keep-alive 长连接场景下，请求体数据残留会导致连接无法被安全复用，表现出来的现象就是连接被服务端关闭，客户端下一个请求又要重新建连，高并发时性能会明显下降。

2.4 为每个请求生成 requestId，排查问题就靠它

现在很多线上服务日志里都能看到类似这样的记录：

text复制client -> server, requestId: 178792012522211000001

这种一长串数字就是一个请求的唯一标识。原生 http 模块里没有内置 requestId，但你可以自己加，成本极低，收益却非常大。

最简单的方案是：服务端收到请求时，先看请求头里有没有 x-request-id，有就沿用；没有就自己生成一个。生成方式可以用随机数加时间戳，也可以用 crypto.randomUUID()。如果后续要把请求转发给上游服务，把同一个 requestId 再透传到上游，整条链路就能靠这个 ID 串起来，排查问题时就再也不用来回问“这条日志是哪个请求的”。

我实际写的简化版本大概是这样：

javascript复制const crypto = require('crypto');

const server = http.createServer((req, res) => {
  const requestId = req.headers['x-request-id'] || crypto.randomUUID();
  res.setHeader('x-request-id', requestId);

  console.log(`${new Date().toISOString()} ${req.method} ${req.url} requestId=${requestId}`);

  res.end('ok');
});

线上服务并发一高，没有 requestId 的日志基本等于一堆废纸。这是我在微服务链路追踪还没普及的时期踩过的坑，现在已经成为我写所有 HTTP 服务的默认习惯。

3. 响应发送：状态码、响应头和实用流式返回

3.1 写 HTTP 应答的正确打开方式：writeHead 与 setHeader 二选一

设置响应状态码和响应头有两条路线。第一条是用 res.statusCode 配合 res.setHeader：

javascript复制res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain; charset=utf-8');
res.end('ok');

第二条是用 res.writeHead 一次性设置：

javascript复制res.writeHead(200, {
  'Content-Type': 'text/plain; charset=utf-8',
});
res.end('ok');

两条路线都能用，但我的建议是同一个处理分支里不要混用。原因是 writeHead 的参数头会覆盖之前通过 setHeader 设置的同类头，用混了容易产生“为什么我明明 setHeader 了，响应里却没有”的困惑。特别是当你先调用 setHeader，再调用 writeHead 时，writeHead 里的同名头会赢。如果代码逻辑复杂，我倾向于统一走 setHeader 路线，因为可以在不同条件分支里单独追加头，最后再 end，灵活性更高。

另一点需要注意的是，状态消息（statusMessage）参数已经属于过时用法，不需要手动去写。Node 会根据状态码自动生成对应的原因短语，你传不传都不影响客户端解析。

3.2 Content-Type 踩坑与一个常用对照表

响应头里最容易被忽略的就是 Content-Type 的 charset 部分。一个非常典型的场景：服务端返回中文文本，代码写的是 res.setHeader('Content-Type', 'text/plain')，没有带 charset=utf-8。浏览器收到后按默认编码解析，中文直接乱码。调试了半天，最后发现只是少了个 charset。

如果是写接口返回 JSON，还容易犯另一个错误：Content-Type 写成 application/json，但没有 charset。虽然 JSON 标准默认 UTF-8，绝大多数客户端都能正确处理，但为了稳妥避免极端情况下的解析问题，我建议显式写成：

javascript复制res.setHeader('Content-Type', 'application/json; charset=utf-8');
res.end(JSON.stringify(data));

这里顺手整理一份我常用的 Content-Type 对照表，遇到下载、页面、接口场景可以直接抄：

3.3 Content-Length 与 chunked：Node 自动处理但你要知道规则

响应体发送给客户端时，传输层有两种长度表达方式：Content-Length 和 Transfer-Encoding: chunked。

Content-Length 表示响应体总字节数，客户端可以提前知道下载进度；chunked 表示数据分成一块一块发送，每一块自带长度，直到一个零长度块结束，适合动态生成的响应内容。

Node 的自动处理规则大致是这样：如果你只调用一次 res.end(data) 且没有预先设置 Content-Length，Node 会计算 data 的字节长度，自动在响应头里加上 Content-Length。但如果你先 res.write(chunk) 分块写入，最后再 res.end()，因为总长度无法提前确定，Node 会自动使用 Transfer-Encoding: chunked。

这意味着，如果你希望响应头里明确带 Content-Length，最好在 res.end 里一次把数据传完，或者提前自己计算好长度并 setHeader。对于业务接口返回的 JSON，我通常都是直接 res.end(JSON.stringify(data))，让 Node 自动处理即可。只有当响应体特别大、必须流式输出时，才需要走 chunked。

3.4 流式响应实战：大文件下载 / SSE 实时推送

用原生 http 返回一个几百 MB 的大文件，如果你先把整个文件读到内存再用 res.end 发送，进程内存会瞬间飙升。正确做法是把文件流接到响应流上，让数据一块一块地从磁盘流到客户端，内存占用始终维持在一个很小的水平：

javascript复制const http = require('http');
const fs = require('fs');
const path = require('path');

const server = http.createServer((req, res) => {
  if (req.url === '/download') {
    const filePath = path.join(__dirname, 'bigfile.zip');
    const stat = fs.statSync(filePath);

    res.writeHead(200, {
      'Content-Type': 'application/octet-stream',
      'Content-Disposition': 'attachment; filename="bigfile.zip"',
      'Content-Length': stat.size,
    });

    const stream = fs.createReadStream(filePath);
    stream.pipe(res);
    return;
  }

  res.statusCode = 404;
  res.end('not found');
});

server.listen(3000);

注意这里我提前通过 fs.statSync 拿到了文件大小，并设置 Content-Length，这样客户端能显示真实的下载进度。pipe 方式由 Node 内部处理背压，文件流读取速度不会超过响应流写入速度，不会把内存打爆。

另一个常见场景是 Server-Sent Events（SSE），它依赖 chunked 响应，动态推送数据给客户端。一个最小示例是这样：

javascript复制const server = http.createServer((req, res) => {
  if (req.url === '/events') {
    res.writeHead(200, {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
    });

    const timer = setInterval(() => {
      res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`);
    }, 1000);

    req.on('close', () => clearInterval(timer));
    return;
  }

  res.statusCode = 404;
  res.end('not found');
});

这里有两点经验：一是 SSE 场景不能提前设置 Content-Length，因为数据是持续生成的，必须依赖 chunked；二是如果内容产生是异步的，例如要等一个文件读完再推第一个事件，Node 默认不会立刻发送响应头，这时可以在确认要开始推送后调用 res.flushHeaders()，强制先把响应头发出去，客户端就能更早开始等待数据。

4. 做客户端主动发请求：http.get 与 http.request 的细节

4.1 最简 GET 请求与 JSON 封装

Node.js 的 http 模块不仅能当服务端，也能当 HTTP 客户端。和常见库 axios、node-fetch 不同，http.get 和 http.request 没有任何第三方依赖，深入理解它们之后，你就能明白那些 HTTP 客户端库在底层到底做了什么。

一个最简单的 GET 请求如下：

javascript复制const http = require('http');

const req = http.get('http://example.com/api/users', (res) => {
  console.log('status:', res.statusCode);
  res.setEncoding('utf-8');

  let body = '';
  res.on('data', (chunk) => {
    body += chunk;
  });
  res.on('end', () => {
    console.log('body:', body);
  });
});

req.on('error', (err) => {
  console.error('request error:', err.message);
});

http.get 是 http.request 的便捷封装，默认使用 GET 方法，并且会自动调用 req.end() 表示请求写完了。第三个参数回调里的 res 也是一个流，必须监听 data 事件把数据读出来。

实际业务中大部分请求都涉及 JSON 响应，我倾向于封装成一个 Promise 函数，用起来方便很多：

javascript复制function httpGetJson(url) {
  return new Promise((resolve, reject) => {
    const req = http.get(url, (res) => {
      res.setEncoding('utf-8');

      let raw = '';
      res.on('data', (chunk) => {
        raw += chunk;
      });

      res.on('end', () => {
        if (res.statusCode < 200 || res.statusCode >= 300) {
          reject(new Error(`HTTP ${res.statusCode}: ${raw}`));
          return;
        }

        try {
          resolve(JSON.parse(raw));
        } catch (err) {
          reject(new Error(`JSON parse failed: ${err.message}`));
        }
      });
    });

    req.on('error', reject);
    req.setTimeout(5000, () => {
      req.destroy(new Error('request timeout'));
    });
  });
}

这段代码里我同时处理了三个问题：非 2xx 状态码要当成错误处理、JSON 解析失败要单独报错、请求长时间不返回要有超时机制。没有这些兜底，一个网络抖动就能让你的服务挂起好几个小时。

4.2 带 JSON body 的 POST：Content-Length 要用字节数算

发送 POST 请求需要用到 http.request，并且要主动把请求体写入 req。一个常见到几乎每个人都会踩的坑是 Content-Length 的计算。很多人写成 body.length，但 JavaScript 字符串的 length 是 UTF-16 字符数量，不是字节数。如果 body 里有中文，Content-Length 就会偏小，服务端读取的时候可能读不完整，导致请求体被截断。

正确做法是用 Buffer.byteLength 计算：

javascript复制const http = require('http');

const postData = JSON.stringify({
  name: '张三',
  age: 18,
});

const options = {
  hostname: 'example.com',
  port: 80,
  path: '/api/users',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json; charset=utf-8',
    'Content-Length': Buffer.byteLength(postData),
  },
};

const req = http.request(options, (res) => {
  res.setEncoding('utf-8');

  let body = '';
  res.on('data', (chunk) => {
    body += chunk;
  });
  res.on('end', () => {
    console.log('response:', body);
  });
});

req.on('error', (err) => {
  console.error('request error:', err.message);
});

req.write(postData);
req.end();

要理解为什么最后需要 req.end()，可以把 http.request 返回的 req 当成一个可写流。你 write 请求体内容之后，必须调用 end 表示“请求体已经写完”，这个时候底层才会真正把整个请求发送出去。如果写了 body 却忘记 end，连接就会挂在那里，服务端永远收不到完整请求。

headers 里也可以加 Authorization、Cookie 等业务头，格式和请求头一致。如果只想请求外部 HTTPS 接口，把 require('http') 换成 require('https') 即可，方法签名几乎一样，唯一要注意的是证书问题，一般不要粗暴关闭证书校验，优先排查根证书配置。

4.3 响应流不消费会有什么后果

客户端发起请求后，响应 res 是个 Readable 流。很多人在拿到状态码之后就懒得读响应体了，特别是 DELETE、HEAD 一类不需要返回内容的请求。但在 keep-alive 场景下，不消费响应体会产生一个问题：底层 socket 上还残留着未读取的数据，Agent 无法确定这个连接是否可以安全归还给连接池，于是连接只能被关闭，下一个请求需要重新建连。

高并发时这会让 TCP 连接频繁创建销毁，表现为大量 TIME_WAIT 连接，QPS 上不去。如果你确实不关心响应体内容，最简单的处理方式是调用一次 res.resume()，让数据被读取并丢弃，之后再考虑连接复用的事。

我在排查一个内部服务时遇到过类似情况：某个定时任务每小时调用一次上游接口，响应体只有几百字节，代码里没消费直接忽略了，导致每跑一次就积累几百个 TIME_WAIT。当时看起来不严重，但任务频率提高后，连接表被占满的迹象就出现了。最终修复方案就是在回调里加了一行 res.resume()。

4.4 超时控制：没有默认超时，必须自己兜底

http.request 默认没有请求超时，只要对方服务器不返回，连接就会一直挂着。Node.js 文档里虽然提供了 req.setTimeout，但它设置的是“套接字空闲超时”，不是“整个请求完成超时”。也就是说，如果对端每 30 秒发一个字节保活，套接字永远不会超时，请求可能被拖到天荒地老。

更可控的做法是用 AbortController 或者手动 destroy：

javascript复制const http = require('http');

function requestWithTimeout(options, timeout = 5000) {
  return new Promise((resolve, reject) => {
    const req = http.request(options, (res) => {
      let data = '';
      res.setEncoding('utf-8');
      res.on('data', (chunk) => { data += chunk; });
      res.on('end', () => resolve({ statusCode: res.statusCode, data }));
    });

    req.setTimeout(timeout, () => {
      req.destroy(new Error(`request timed out after ${timeout}ms`));
    });

    req.on('error', reject);
    req.end();
  });
}

这里的思路是：超过指定时间后主动 destroy 请求，并在 error 回调中拿到我们注册的超时错误。实际运行时还要在 res 的 data 事件里也关注一下整体时间吗？如果响应已经开始流动，说明请求已经成功，通常不会再触发 req.setTimeout 的超时销毁，因为事件循环在不同阶段会重新调度。更严谨的话，可以结合客户端代码给整个流程加一个总计时器。但作为兜底，req.setTimeout 配合 destroy 已经能防住绝大多数无响应场景。

5. 从能用到扛得住：连接池、超时参数和上线被实际踩过的错误

5.1 启动期的 EADDRINUSE 不只是端口占用那么简单

前面提到端口被占用会报 EADDRINUSE，这里再补一个容易忽略的场景：多个 Node.js 进程同时监听同一个端口。我见过有部署脚本在服务没有完全退出时就启动了新进程，结果新进程反复崩溃，老进程还占着端口，看起来像是端口没释放。排查时第一件事是确认到底哪个 PID 在监听，而不是盲目重启。

如果监听的是 1024 以下的端口，还需要检查当前用户是否有权限。Linux 下普通用户默认不能监听 80、443，否则会报 EACCES。解决办法一般是使用 nginx 等反向代理监听 80/443，再转发到 Node.js 的高位端口，而不是让 Node 进程直接跑 root 权限去监听特权端口。让应用进程以普通用户运行，也是基本的运维安全习惯。

如果启动阶段希望捕获这类错误，而不是让进程直接带栈信息崩溃退出，可以监听 server 的 error 事件：

javascript复制server.on('error', (err) => {
  if (err.code === 'EADDRINUSE') {
    console.error(`port ${port} is already in use`);
    process.exit(1);
  } else {
    console.error('server error:', err);
    process.exit(1);
  }
});

5.2 服务端超时参数不是摆设

Node.js 的 HTTP Server 有几个超时参数，配置不当会影响线上行为：

• server.headersTimeout：接收完整请求头的最长等待时间，超过则返回 408 或直接断开。
• server.requestTimeout：接收完整请求的最长时间，包括请求体。Node.js 18 起默认是 300 秒。
• server.keepAliveTimeout：keep-alive 连接在空闲多久之后关闭，默认 5 秒。
• server.maxHeadersCount：限制最大请求头数量，默认 2000。可以防止请求头过多导致的内存占用。

按需调整这些参数能解决两类问题。第一类，客户端连上服务端但迟迟不发完整请求头，如果 headersTimeout 太长，攻击者可以用大量半开连接占满文件描述符；第二类，keepAliveTimeout 设置得过短，会让本来可以复用的连接频繁关闭；设置得过长，又可能让空闲连接占着资源不释放。线上环境我一般会在压测之后根据实际请求到达间隔进行微调。

服务端还有一类 clientError 事件值得关注，它会在客户端发送不符合 HTTP 协议的请求时触发。默认行为是向客户端发送 400 响应并销毁 socket，但在某些二进制协议探测、不完整 HTTP 请求场景下，如果没有监听该事件，你可能看不到任何日志。加上监听后，可以把异常客户端 IP 也记录下来：

javascript复制server.on('clientError', (err, socket) => {
  if (err.code === 'ECONNRESET' || !socket.writable) {
    return;
  }
  socket.end('HTTP/1.1 400 Bad Request\r\n\r\n');
});

5.3 HTTP Agent 与 keep-alive 连接复用

ClientRequest 默认通过全局 Agent 管理连接，也就是 http.globalAgent。Agent 的作用是连接池。在较新的 Node.js 版本中，全局 Agent 默认已经开启 keepAlive。也就是说，同一进程内多次请求同一个服务端，底层 TCP 连接可以被复用，不需要每次重新握手。

但是在高并发场景下，默认的连接池参数不一定够用。一个常见问题是同主机连接数限制过小，大量并发请求被排队，延迟被拉高。可以通过自定义 Agent 调整：

javascript复制const http = require('http');

const agent = new http.Agent({
  keepAlive: true,
  maxSockets: 50,
  maxFreeSockets: 10,
  timeout: 60_000,
});

const options = {
  hostname: 'example.com',
  path: '/api/xxx',
  method: 'GET',
  agent,
};

const req = http.request(options, (res) => {
  res.resume();
  res.on('end', () => console.log('done'));
});
req.end();

maxSockets 表示单个主机最多允许同时打开的 socket 数量，maxFreeSockets 表示空闲状态时保留的最大 socket 数量。这两个值建议根据上游接口的容量和自身业务的并发量压测调整，不是越大越好。设得过大，如果上游扛不住，只会加剧上游的雪崩。

代理场景里还有一个常见坑：当 http.request 复用一个 keep-alive socket 时，如果同一个 socket 上还有未结束的上一个响应就开始发送下一个请求，会造成协议错乱。Node.js 的 Agent 会保证同一 socket 上的请求串行执行，但如果你自己实现了连接复用逻辑，就必须非常小心这个顺序问题。这也是为什么非必要不要自己手写连接池。

5.4 被慢请求拖垮的往往是事件循环

原生的 http.Server 在高并发下有一个天然的弱点：它的所有代码都在同一个事件循环里跑。如果某个请求的回调里出现 CPU 密集操作，比如对大数组做多层循环排序、同步解密超大字符串、生成巨大 JSON 字符串等，事件循环会被长时间阻塞。