Стриминг и backpressure: когда клиент читает медленнее, чем вы пишете

Сервис отчётов стримит CSV-экспорт на 400 МБ. В тестах работает. В проде он OOM-ится и перезапускается каждый день после обеда. Код экспорта в порядке — он читает строки и вызывает res.write() в плотном цикле. Баг в том, что один клиент скачивает через телефон на раздаче в 200 КБ/с, и сервер генерирует строки куда быстрее, чем телефон успевает их читать. Непрочитанные байты копятся в куче процесса, пока ядро его не убьёт.

Буфер против стрима

Есть два способа отправить тело. Буфер: собрать весь ответ в памяти, выставить Content-Length, отправить. Просто, но экспорт на 400 МБ означает 400 МБ резидентной памяти на каждую одновременную загрузку. Стрим: производить тело по частям и писать каждую часть, как только она готова, используя Transfer-Encoding: chunked, чтобы общий размер не нужно было знать заранее. Стриминг держит память плоской — если вы уважаете backpressure.

Backpressure: запись, которая говорит «стоп»

У каждого writable-стрима есть буфер с порогом, называемым high-water mark (дефолт Node — 16 КБ для байтовых стримов, 64 КБ для файловых). Механизм:

• res.write(chunk) возвращает true, пока внутренний буфер ниже high-water mark — пишите дальше.
• Возвращает false, когда буфер полон — прекратите писать и ждите события 'drain', прежде чем продолжить.

write(), вернувший false, не означает, что запись провалилась. Он означает, что потребитель отстаёт и буфер полон. Если вы проигнорируете false и продолжите писать, данные не исчезают — они накапливаются во внутреннем буфере стрима в куче вашего процесса. Это и есть OOM. Лечение — соблюсти сигнал: приостановить производство до 'drain'. pipe() и pipeline() делают это за вас автоматически, поэтому pipeline(source, res) — безопасный дефолт, а самописный while-цикл из write() — классический футган.

Почему буфер наполняется: это черепахи до самого TCP

Backpressure — не изобретение Node; это прикладная поверхность цепочки окон управления потоком. TCP-окно приёма клиента сообщает, сколько он может принять. Когда приложение клиента читает медленно, его буфер приёма наполняется, оно сжимает анонсированное окно, и буфер отправки в ядре сервера перестаёт сливаться. Тогда writable-стрим в userland перестаёт сливаться, write() возвращает false — и, если вы слушаете, ваш код прекращает производить. Каждый слой давит назад на тот, что выше. Игнорировать backpressure — значит расцепить вашу скорость производства со всей этой цепочкой, и разрыв накапливается в единственном месте без управления потоком: в вашей куче.

Атака медленного потребителя

Тот же механизм — вектор отказа в обслуживании. Slowloris и slow-read атаки намеренно читают ответы по одному байту, чтобы держать соединения открытыми и занимать буферы на стороне сервера. Сервер, буферизующий на соединение и игнорирующий backpressure, можно исчерпать горсткой медленных клиентов — без всякого объёма. Защиты те же, что и исправления корректности, плюс лимиты: уважать backpressure, ограничивать буферизацию на соединение и ставить таймауты записи/простоя, чтобы застрявший слив был брошен, а не удержан навсегда (тема следующего урока).