Timeout и Throttle: защита от перегрузки

middleware.Timeout(duration) оборачивает всю дальнейшую цепочку таймером: middleware запускает её в отдельной горутине и сам ждёт — либо хендлер закончится, либо истечёт срок. Во втором случае клиенту уходит 504 Gateway Timeout, а контекст запроса гаснет через context.WithTimeout на r.Context(). Код ответа выбран не случайно: 504 по спецификации HTTP означает, что время ожидания истекло — ровно то, что произошло; 503 в chi уже занят Throttle-ом, и смешивать эти два отказа не нужно: мониторинг по ним различает перегрузку и дедлайн. Уровень важен не меньше кода: Timeout ставится одним r.Use и выдаёт дедлайн каждому хендлеру ниже по цепочке, а не выборочно. В связке chi timeout throttle это первое кольцо защиты — второе про количество, о нём ниже. Словарь тот же, что в уроке про context.Context: Done(), Err(), Deadline() — обычные таймеры контекста, только включённые на весь роутер.

Главное, что нужно понять про chi timeout: дедлайн не убивает хендлер. В Go нет механизма выстрелить горутину насквозь — runtime не отнимает управление. Когда дедлайн истёк, middleware просто пишет клиенту 504, а ваш хендлер продолжает жить в своей горутине и делает свою работу, пусть её результат уже никому не достанется. Middleware лишь включает сигнал: канал r.Context().Done() закрывается, Err() начинает возвращать context.DeadlineExceeded. Хендлер обязан сам следить за этим сигналом — через select вокруг долгих операций — и, что важнее, прокидывать контекст вниз: в запросы к БД и внешним API. Тогда дедлайн доезжает до самого медленного места, запрос отменяется там, и горутина освобождается по-настоящему. Хендлер без этой дисциплины формально «поддерживает» таймауты, а фактически работает до конца — правильная форма выглядит так.

Пусть хендлер отработал по-честному: увидел закрытый Done() и вернулся. Но внутри него была запущена горутина с buildReport, а она контекста не получает и про 504 не знает. Результат её труда уже никому не нужен, но она доработает до конца — потратит процессор, память и соединение с базой. Это не баг, а цена модели Go: горутину нельзя убить со стороны, с ней можно только договориться через канал или контекст. Отсюда правило: каждую запущенную горутину снабжайте контекстом — buildReport(ctx) вместо buildReport() — и внутри неё тем же select следите за Done(). Второй нюанс: если к моменту пробуждения select готово несколько случаев — и Done() закрыт, и результат уже лежит в канале, — Go выбирает среди готовых случайно, поэтому в ветке с результатом первым делом проверяйте ctx.Err(). Больше про устройство горутин — в уроке про горутины.

Второй предохранитель смотрит не на время, а на количество. middleware.Throttle(n) держит счётчик одновременных запросов: пока работают не больше n — всё проходит, как только n-е место занято, следующий запрос получает 503 Service Unavailable мгновенно, не вставая в очередь. Это предохранитель от толпы: толпа всё равно не обслужится, и честнее отказать сразу, чем копить висящие соединения. Мягкая версия — middleware.ThrottleBacklog(limit, backlog, timeout): до limit запросов работают, до backlog ждут в очереди не дольше timeout, переполнение очереди или просрочка ожидания дают тот же 503. Разница для клиента ощутимая: короткий всплеск ThrottleBacklog переживёт ожиданием, и лишь настоящий затор кончается отказом. Оба middleware — из того же пакета chi/middleware, что Logger и Recoverer из урока про встроенные слои, и оба возвращают именно 503, а не 504.

Порядок регистрации решает, что увидит предохранитель. Правило простое: страховки — раньше, бизнес-логика — позже. Recoverer ставят первым, чтобы паника в любом слое ниже была поймана; Timeout и Throttle следуют сразу за ним и перед собственной бизнес-логикой. Логика такая: Throttle должен считать запросы до того, как они потратят силы на декодирование тела или проверку токена, — иначе толпа всё равно выполнит дорогую часть работы. А Timeout обязан отсчитывать дедлайн с самого начала пути, а не с середины цепочки. В боевой конфигурации предохранители занимают место между служебными слоями вроде RequestID и Logger и регистрацией маршрутов — причём служебные полезно иметь раньше: тогда даже отклонённый по 503 запрос оставит в логах строку с идентификатором, и по ней найдут инцидент.

Middleware работают внутри вашего кода, но у сервера есть собственный заслон. У http.Server есть ReadTimeout, WriteTimeout и IdleTimeout: первый ограничивает время на чтение запроса — от accept до полного тела, второй — время на запись ответа, третий держит паузу между keep-alive запросами. Это внешний барьер против внутреннего: Throttle и Timeout защищают ваш бизнес-код, а серверные таймауты — само соединение, включая клиентов, которые открыли соединение и молчат, как slowloris. Настраиваются они при создании сервера, а не через middleware: srv := &http.Server{ReadTimeout: 5 time.Second, WriteTimeout: 10 time.Second} вместо голого http.ListenAndServe. Правильная сборка — оба уровня сразу: сервер обрезает протокольные хвосты и медленных клиентов, middleware управляет дедлайнами конкретных хендлеров. Термины вроде OOM, keep-alive и slowloris разобраны в глоссарии.