Каждый HTTP-запрос проходит один и тот же путь — accept, парсинг, маршрутизация, middleware, обработка, сериализация, drain. Знание карты подсказывает, где прячутся задержка, сбой и уязвимость.
Пользователь нажимает «Сохранить». Через 180 мс он видит зелёную галочку. За эти 180 мс запрос прошёл через балансировщик, полежал в очереди ядра, был разобран байт за байтом, сопоставлен с таблицей маршрутов, прошёл стопку middleware, выполнил ваш обработчик, был сериализован в JSON и отправлен обратно потоком — пройдя семь разных стадий, у каждой свой режим отказа. Большинство инженеров назовут обработчик. Немногие назовут остальные шесть.
Семь остановок
Уберите фреймворк — и любой серверный запрос имеет одну и ту же форму. Названия отличаются в Express, Spring, net/http Go и Rails, но стадии — нет:
Accept — ядро завершает TCP-рукопожатие и передаёт процессу установленный сокет.
Парсинг — байты из сокета превращаются в строку запроса, заголовки и тело.
Маршрутизация — метод и путь сопоставляются с одним обработчиком.
Middleware — сквозные слои выполняются по порядку: auth, логирование, парсинг тела, rate limiting.
Обработка — выполняется бизнес-логика, обычно в ожидании БД или другого сервиса.
Сериализация — результат становится байтами: JSON, HTML, поток.
Drain — ответ записывается в сокет, который может быть медленнее обработчика, и соединение удерживается (keep-alive) или закрывается.
Вместе эти семь остановок образуют цепочку: пропустишь или неверно настроишь любую — получишь сбой, который выглядит загадочно, пока не знаешь карту. Следующие несколько минут сделают эту карту рефлексом.
Перед остановкой 1 обычно стоит reverse proxy (обратный прокси-сервер) (nginx, Envoy, облачный балансировщик): он терминирует TLS, выбирает бэкенд и может буферизовать весь запрос. Этот прокси — отдельный жизненный цикл со своими семью остановками на другой стороне.
Где прячется каждая проблема
Карта важна потому, что каждый класс ошибок живёт на конкретной остановке. Отладка вслепую — это проверка всех семи; отладка с картой — это прыжок к одной.
Симптом
Подозреваемая остановка
Соединения отклоняются под нагрузкой
Accept — переполнилась очередь accept в ядре
431 / 400 на больших cookie
Парсинг — превышен буфер заголовков
Срабатывает не тот обработчик
Маршрутизация — пересекающиеся шаблоны путей
Обход auth на одном эндпоинте
Middleware — порядок: обработчик сработал до слоя auth
p50 быстрый, p99 ужасный
Обработка — медленная нижестоящая зависимость
Высокий CPU на больших ответах
Сериализация — JSON.stringify на огромном объекте
Память растёт на медленных клиентах
Drain — backpressure проигнорирован, ответ буферизован в RAM
Задержка суммируется, а не локализуется
Полное время запроса — это сумма всех остановок плюс время ожидания в очередях между ними. Обработчик, выполняющийся за 5 мс, всё равно может дать ответ за 200 мс, если очередь accept была глубокой, тело буферизовал прокси, а клиент читал ответ медленно. Поэтому «код быстрый» и «эндпоинт медленный» истинны одновременно — они описывают разные остановки.
Обработчик — лишь малая доля ответа; задержка это сумма по всем семи остановкам плюс ожидание в очередях, поэтому быстрый код всё равно может ощущаться медленным.
Senior-навык — не запоминание семи названий. Это рефлекс: по этому симптому — какая остановка? Когда увидишь всплеск p99 или лавину отклонённых соединений, первый вопрос должен быть «на какой остановке?», а не «что делает код?». Дальше юнит проходит каждую остановку в продакшн-деталях.
Викторина
Completed
У сервиса обработчик 3 мс, но под нагрузкой пользователи видят ответы по 250 мс. Какие остановки наиболее вероятны?
Heads-up Обработчик — лишь одна из семи остановок. Быстрый обработчик не делает ответ быстрым; ожидание в очередях и drain происходят вне его.
Heads-up Сопоставление маршрута — это микросекунды даже на сотнях маршрутов. Оно почти никогда не доминирует в 250 мс.
Heads-up Сериализация маленького ответа — доли миллисекунды. Заметной её делают только очень большие объекты.
Викторина
Completed
Почему reverse proxy перед сервером приложений важен для жизненного цикла запроса?
Heads-up У прокси свой жизненный цикл. Ваше приложение всё равно выполняет accept, парсинг, маршрутизацию и т. д. — прокси стоит перед всем этим.
Heads-up Reverse proxy пересылает запросы; он не выполняет ваши обработчики. Бизнес-логика остаётся в сервере приложений.
Heads-up Прокси никак не влияет на то, сколько обработчик ждёт БД — это полностью ниже прокси по течению.
Расставь шаги по порядку
Completed
Расставьте семь остановок запроса в порядке их прохождения:
2Парсинг — байты становятся строкой запроса, заголовками, телом
3Маршрутизация — метод и путь сопоставлены с обработчиком
4Middleware — auth, логирование, парсинг тела выполняются по порядку
5Обработка — выполняется бизнес-логика, ждёт зависимости
6Сериализация — результат становится байтами
7Drain — ответ записан в сокет, соединение удержано или закрыто
1. Acceptпереполнение очереди ядра → отказ
2. Парсингбольшие заголовки → 431/400
3. Маршрутизацияпересечение путей → не тот обработчик
4. Middlewareневерный порядок → обход auth
5. Обработкамедленная зависимость → скачок p99
6. Сериализациябольшой объект → CPU на цикле
7. Drainигнор backpressure → память
Каждый запрос проходит одни и те же семь остановок по порядку; общая задержка — их сумма плюс ожидание в очередях, и каждый класс ошибок живёт ровно на одной остановке.
Вспомните перед уходом
01
Назовите семь остановок жизненного цикла запроса по порядку и по одной проблеме на каждой.
02
Почему у сервиса может быть обработчик 3 мс, но время ответа 250 мс?
03
Что добавляет reverse proxy перед семью остановками и почему у него свой жизненный цикл?
Итог
Любой серверный HTTP-запрос проходит одни и те же семь остановок: accept (ядро передаёт сокет), парсинг (байты становятся запросом), маршрутизация (путь к обработчику), middleware (сквозные слои по порядку), обработка (бизнес-логика), сериализация (результат в байты) и drain (запись в сокет, keep-alive или закрытие). Reverse proxy спереди добавляет свою копию этого цикла. Полная задержка — сумма по остановкам плюс ожидание в очередях, поэтому быстрый обработчик всё равно может дать медленный эндпоинт. Каждый класс ошибок живёт на конкретной остановке — ценность карты в рефлексе прыжка к нужной. Теперь, когда встретишь сервис, который «медленный, но код в порядке», первый шаг — назвать остановку, а не читать обработчик. Следующий урок углубляется в первые две остановки: как ядро принимает соединение и как сырые байты становятся разобранным запросом.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.