Блокирующий vs неблокирующий I/O: два способа ждать

Замерь время типичного обработчика запроса — и удивишься, насколько мало в нём твоего кода. Он читает строку из Postgres, дёргает платёжный API, пишет строку в лог — и тратит 95% реального времени просто на ожидание ответа. Вся суть бэкенд-конкурентности сводится к одному: что делает программа, пока ждёт? На этот вопрос есть два ответа, делящие всю область пополам. Один паркует поток на каждое ожидание. Другой отказывается кого-либо парковать и просит ядро тронуть его за плечо, когда данные готовы.

Ожидание — это и есть работа

Бэкенд — это в основном I/O-машина. Чтение с диска, запросы к базе, исходящий HTTP, запись в сокет — каждая операция медленная относительно CPU (микросекунды и миллисекунды, тогда как процессор выполняет миллиарды инструкций в секунду). Поэтому первый вопрос проектирования никогда не «как быстр мой код», а «как рантайм проводит ожидание». Две модели I/O дают противоположные ответы, и выбор определяет, как сервер масштабируется, сколько памяти ест и как падает под нагрузкой.

Блокирующий I/O: поток на соединение

В блокирующей модели поток вызывает read(), и операционная система приостанавливает этот поток до прихода байтов. Поток запаркован — занимает свой стек и слот планировщика — и ничего полезного не делает. Чтобы обслужить второе соединение конкурентно, нужен второй поток, третьему — третий, и так далее: поток-на-соединение (thread-per-connection).

Это просто и легко рассуждать — код читается сверху вниз, каждая строка ждёт предыдущую — но масштабируется добавлением потоков, а потоки не бесплатны. Каждый поток ОС резервирует примерно 1–2 МБ стека, поэтому 10 000 конкурентных соединений означают порядка 10+ ГБ памяти только под стеки, плюс тысячи переключений контекста в секунду, пока планировщик тасует запаркованные потоки. Модель меняет память на простоту.

Неблокирующий I/O: один поток, много сокетов

В неблокирующей модели сокет переводится в неблокирующий режим, и read() возвращается немедленно — либо с данными, либо с «пока не готово». Вместо того чтобы парковаться, поток регистрирует интерес к множеству сокетов через средство ядра — epoll на Linux, kqueue на BSD/macOS — и задаёт один вопрос: «кто из этих тысяч файловых дескрипторов готов прямо сейчас?» Ядро возвращает только готовые, примерно за O(1) независимо от того, сколько их под наблюдением. Поток обслуживает эти, затем спрашивает снова. Этот цикл и есть event loop.

Один поток поэтому способен тянуть десятки тысяч соединений, потому что трогает только те сокеты, у которых есть реальная работа. Цена — другая форма кода: нельзя читать сверху вниз и «ждать» — ты регистрируешь колбэк (или await), и цикл вызовет тебя позже. Логика, которая была прямой линией, превращается в набор продолжений (continuations).

Постановка C10k и реальный компромисс

Этот раскол назвали проблемой C10k (~1999): как обслужить 10 000 конкурентных клиентов на одной машине? Поток-на-соединение упёрся в стену памяти и переключений контекста; модель event loop — Nginx, Node.js, Netty, Redis — стала ответом. Честная сводка:

• Блокирующий / поток-на-соединение меняет память и накладные расходы на переключение контекста на простоту. Хорош, когда число соединений умеренное или работа CPU-тяжёлая; код остаётся линейным.
• Неблокирующий / event loop меняет сложность кода (колбэки, продолжения, никакой парковки) на масштабируемость при множестве конкурентных, в основном простаивающих соединений.

Ни одна не «быстрее» в принципе. Для I/O-нагрузок с высокой конкурентностью event loop решительно выигрывает по памяти и числу соединений. Для CPU-нагрузок один поток event loop не быстрее любого другого одного потока — предел, который следующие уроки сделают резким.