Сокеты в продакшене: таймауты, лимиты и исчерпание fd

Простаивающим сокетам нужен таймаут, иначе они держат fd вечно

Инцидент из хука воспроизводим в любом Node-сервере, который выезжает без трёх осознанных защит. Вот как работает каждый режим отказа и что именно его останавливает.

TCP-сокет после принятия занимает файловый дескриптор — конечный per-process ресурс ядра (часто по умолчанию 1024 или ограничен ulimit -n). Node не накладывает idle-таймаут по умолчанию: сокет, что подключился и затем замолчал, будет висеть открытым бесконечно. Плохой или мёртвый клиент — упавший без чистого закрытия или half-open соединение, чей FIN так и не пришёл — поэтому течёт дескриптором, который никогда не возвращается. Накопи достаточно — и процесс больше не может ничего accept()-ить: зависание из хука.

Защита — socket.setTimeout(ms), который эмитит событие 'timeout' после ms бездействия (нет ни чтений, ни записей). Важно: событие таймаута не закрывает сокет за тебя — оно лишь уведомляет — поэтому ты обязан действовать:

server.on("connection", (socket) => {
  socket.setTimeout(30_000);                 // 30с бюджет простоя
  socket.on("timeout", () => {
    socket.destroy(new Error("idle timeout")); // ТЫ обязан закрыть
  });
  socket.on("error", () => {});               // глушим ошибки после destroy
});

Для HTTP-серверов та же идея даётся как server.setTimeout(), плюс server.headersTimeout, server.requestTimeout и server.keepAliveTimeout — последний охраняет промежуток между keep-alive запросами. Атака Slowloris (DoS через тысячи медленных соединений, держащих сервер занятым) — ровно оружейная версия хука: атакующий открывает много соединений и капает байты медленно, держа каждое чуть под любым наивным таймаутом, исчерпывая ёмкость соединений почти без трафика. Таймауты заголовков и запроса — то, что её останавливает.

Keep-alive: переиспользуй рукопожатие, но ограничь простой

Keep-alive — переиспользование одного TCP-соединения для многих запросов, избегающее свежего рукопожатия (и TLS-согласования) каждый раз — большой выигрыш по задержке. Но простаивающее keep-alive соединение всё равно держит файловый дескриптор и слот. Натяжение настройки реально: слишком короткий keepAliveTimeout — и ты выбрасываешь выгоду переиспользования, переподключаясь постоянно; слишком долгий — и простаивающие клиенты копят дескрипторы, что ты мог бы отдать активным.

Есть и пресловутая гонка между сервером, закрывающим простаивающее keep-alive соединение, и клиентом, шлющим ещё один запрос по нему: запрос приземляется на сокет, который сервер разбирает, порождая ECONNRESET, который клиент видит как упавший запрос. Смягчение — сделать keepAliveTimeout сервера длиннее idle-таймаута вышестоящего балансировщика, чтобы LB всегда закрывал первым, на соединении, которое знает простаивающим — классический источник прерывистых 502, если порядок обратный.

ECONNRESET и EPIPE — не баги, а вторник

Два кода ошибок доминируют в продакшн-логах сокетов, и относиться к ним как к экзотике — ошибка.

Оба эмитятся как события 'error' на сокете, и железное правило из урока про TCP применяется в продакшене с силой: необработанное 'error' сокета кидает исключение и роняет весь процесс, убивая вместе с ним каждое другое соединение в полёте. Один плохой клиент никогда не должен мочь уронить сервер, обслуживающий тысячи. Поэтому каждому сокету — принятому на сервере и открытому на клиенте — нужен обработчик 'error', который логирует-и-очищает, а не перебрасывает. Асимметрия для усвоения: ECONNRESET — это то, что сделали с тобой (пир сбросил), EPIPE — это ты пишешь в закрытую трубу — но оба сводятся к «это одно соединение мертво, отпусти его, продолжай обслуживать остальных».

Ограничь соединения, затем сливай аккуратно

Корневая причина в хуке — безграничный рост ресурса. server.maxConnections ограничивает одновременные сокеты: за лимитом сервер перестаёт принимать (OS backlog поглощает несколько, затем отказывает), что сбрасывает нагрузку вместо коллапса в исчерпание fd. Это грубый инструмент, но реальный страховочный трос. Соедини его с поднятым осознанно ulimit -n — и у тебя верхняя граница, что ты выбрал, а не обнаружил в 3 ночи.

Вторая половина — graceful shutdown. На SIGTERM (деплой, scale-down) ты обязан слить, а не бросить: server.close() перестаёт принимать новые соединения и зовёт колбэк, как только все существующие завершатся — но он будет ждать вечно на долгоживущем простаивающем keep-alive сокете, поэтому ты также проходишь по активным сокетам, сигналишь им завершиться и destroy()-ишь отставших после дедлайна. Пропуск этого превращает каждый деплой в волну ECONNRESET для пользователей в полёте.