Модуль http: серверы, клиенты и потоки

req — это Readable, res — это Writable

http.createServer((req, res) => …) отдаёт тебе два объекта-потока, и самая частая ошибка новичка — забыть об этом. req — это IncomingMessage — Readable-поток тела запроса, украшенный req.method, req.url и req.headers. Заголовки разобраны и доступны сразу, но тело за тебя не буферизуется: оно приходит чанками потока, и если ты их не читаешь, ты не получишь тело (а сокет может застрять). res — это ServerResponse — Writable-поток. Ты начинаешь его через res.writeHead(status, headers), толкаешь байты через res.write(chunk) и завершаешь через res.end().

Поскольку тело — это поток, ты потребляешь его потоковыми идиомами, а не тянешься к магическому свойству .body:

import { createServer } from "node:http";

const server = createServer(async (req, res) => {
  if (req.method === "POST") {
    let body = "";
    // req — async-iterable: каждый чанк это Buffer
    for await (const chunk of req) {
      body += chunk;            // (см. предупреждение про лимит размера ниже)
    }
    res.writeHead(200, { "content-type": "application/json" });
    res.end(JSON.stringify({ received: body.length }));
    return;
  }
  res.writeHead(405).end();
});

server.listen(3000);

Эквивалентный событийный API — req.on("data", chunk => …), затем req.on("end", …) — делает то же самое; for await — это просто современная обёртка над ним. В любом случае обрабатывай ещё req.on("error", …) и случай 'aborted'/'close': клиент, отвалившийся посреди загрузки, генерит ошибку на потоке запроса, а необработанное событие 'error' потока роняет процесс.

Backpressure: write() может сказать «стоп»

Когда ты шлёшь большой или неизвестной длины ответ, нельзя просто долбить res.write() в цикле. res.write() возвращает булево: true — чанк сброшен в буфер сокета ядра; false — он поставлен в очередь в памяти твоего процесса, потому что буфер полон. Игнорировать этот false и продолжать писать — это как один медленный клиент раздувает heap Node: ты буферизуешь данные, которые сеть пока не может слить. Контракт такой: когда write() вернул false, остановись и жди событие 'drain' прежде чем писать дальше.

// Ручной backpressure — продолжаем только когда в буфере есть место
function writeChunk(res, chunk, next) {
  if (res.write(chunk)) {
    next();                       // в буфере было место, идём дальше
  } else {
    res.once("drain", next);      // ждём, пока опустеет
  }
}

На практике этот цикл почти никогда не пишут руками. Если твой источник сам поток — файл, ответ апстрима, трансформ — пайпи его и дай Node управлять backpressure из конца в конец:

import { createReadStream } from "node:fs";
// pipeline пробрасывает backpressure И сводит ошибки в одно место
import { pipeline } from "node:stream/promises";

await pipeline(createReadStream("./big.csv"), res);

Когда длина тела неизвестна (поток без content-length), Node автоматически переключает ответ на chunked transfer encoding, отправляя каждый write() как свой обрамлённый чанк, завершаемый нулевым чанком на end().

Клиент, Agent и keep-alive

Когда сервис делает тысячи исходящих запросов в секунду, стоимость установки соединения накапливается быстро — и именно для этого существует Agent (менеджер пула сокетов, управляющий keep-alive-соединениями). Тот же модуль — ещё и HTTP-клиент: http.request(options, cb) возвращает writable-поток запроса, а http.get — сокращение, которое вызывает req.end() за тебя. Ответ приходит как ещё один IncomingMessage, который ты обязан слить.

import { request } from "node:http";

const req = request("http://api.internal/users/1", (res) => {
  let data = "";
  res.on("data", (c) => (data += c));   // ты ОБЯЗАН потребить ответ
  res.on("end", () => console.log(res.statusCode, data));
});
req.on("error", console.error);          // сетевые ошибки прилетают сюда
req.end();

За каждым клиентским запросом стоит Agent, который пулит сокеты. Смысл пула — keep-alive: переиспользование живого TCP-соединения между запросами пропускает свежий TCP-хендшейк (~1 RTT) и, на HTTPS, полный TLS-хендшейк сверху — большая экономия на запрос, когда ты часто зовёшь один и тот же хост. Глобальный agent включает keepAlive по умолчанию с Node 19; до этого ты включал его явно через new Agent({ keepAlive: true }). Кнопка, которая кусается под нагрузкой, — maxSockets — предел числа параллельных соединений, которые agent открывает на хост. По умолчанию Infinity, так что неограниченный fan-out может открыть тысячи сокетов разом и исчерпать порты или захлестнуть апстрим; задай разумный maxSockets, когда жёстко молотишь одну зависимость.

Таймауты и лимиты тела: чего http НЕ делает за тебя

Это сеньорская часть, и она вся про то, что http опускает. Сырой http по умолчанию позволит клиенту не торопиться и прислать тело любого размера. И то и другое — векторы отказа в обслуживании. Кнопки таймаутов, ограничивающие медленного клиента, — это свойства сервера:

Хук — ровно та брешь, которую закрывают requestTimeout и headersTimeout: атака Slowloris капает заголовками или телом медленно, чтобы держать сокеты открытыми. С дефолтным 300-секундным requestTimeout и 60-секундным headersTimeout полуоткрытый сокет отбирается, а не течёт вечно — но если ты сделаешь req.socket.setTimeout(0) или отключишь их на самописном сервере, ты снова откроешь дверь.

Другое упущение — размер тела. Встроенного лимита нет: for await (const chunk of req) body += chunk радостно накопит многогигабайтную загрузку в твой heap и убьёт процесс по OOM. Ты обязан ограничить его сам (это одна из главных вещей, что express.json({ limit }) или body-parser делают за тебя):

const MAX = 1_000_000; // 1 МБ
let size = 0, chunks = [];
for await (const chunk of req) {
  size += chunk.length;
  if (size > MAX) {
    res.writeHead(413).end("payload too large"); // 413 Payload Too Large
    req.destroy();                                // прекрати чтение, освободи сокет
    return;
  }
  chunks.push(chunk);
}