Кратко

  • В draft-ietf-httpapi-ratelimit-headers-11 параметр t ограничивает расход объявленного r в эффективном окне, но не сообщает, когда и насколько квота восстановится.
  • Retry-After советует время следующей попытки, а не гарантирует её допуск. Безопасный клиент погашает старое наблюдение, добавляет разброс, делает ограниченную пробу и сохраняет собственные пределы скорости и параллелизма.

Сервис ответил 429, указал Retry-After: 30 и передал RateLimit: "adaptive";r=0;t=30. Планировщик аккуратно подождал тридцать секунд. Затем он восстановил локальный лимит до полной величины и одновременно выпустил все накопленные задания.

За эти тридцать секунд нагрузка не исчезла. Следующий ответ увеличил t. Первая волна клиентов уже находилась в пути.

Сервер разрешил не немедленную отправку, а более позднюю попытку. Клиент сам превратил её в гарантированный допуск.

Рабочая группа IETF HTTPAPI опубликовала редакцию 11 документа RateLimit header fields for HTTP 23 мая 2026 года. Это активный Internet-Draft, предназначенный для Standards Track и истекающий 24 ноября 2026 года. Он не является RFC и не доказывает существование внедрения, инцидента или совместимости продуктов. Здесь важны только заявленные проектом границы фактов.

Одна длительность, разные полномочия

t — относительное число секунд, в течение которых клиенту не следует расходовать больше доступного r. Относительный формат не требует синхронных часов и снижает риск одновременного пробуждения по одному абсолютному времени сброса.

Retry-After относится к следующей попытке. Если оба значения присутствуют, проект рекомендует не назначать повтор раньше окончания эффективного окна. Это согласование советов, а не объединение их смысла.

Окончание t не обещает пополнение. Документ прямо запрещает считать, что сервисный предел полностью восстановится. Сервер может изменить и r, и t между ответами из-за скользящего окна, насыщения или адаптивного управления. Следующее окно может оказаться длиннее предыдущего.

Поэтому таймер должен аннулировать старое наблюдение. Он не должен пополнять локальный бак. После ожидания клиент посылает ограниченную пробу, получает новый ответ и постепенно меняет темп внутри собственных границ.

Политика и наблюдение живут в разном времени

RateLimit-Policy описывает именованную политику. Обязательный q задаёт объём, дополнительные qu, w и pk — единицу, окно и раздел квоты. Редакция 11 вводит единицы запросов, байтов содержимого и одновременных запросов.

RateLimit сообщает текущий сервисный предел для политики и раздела. r — доступная квота, t — эффективное окно. Политика может быть стабильной, когда наблюдение уже устарело.

Несколько политик могут действовать одновременно. Дневной, часовой и параллельный пределы не исключают друг друга. Сервер может показать только ближайший к исчерпанию. Отсутствующая строка не доказывает отсутствие правила.

Запись должна включать сервис, время ответа, имя политики, единицу, раздел, q, w, r, t, статус и признаки исходного запроса. Единственный remaining не сохраняет утверждение, которое сделал сервер.

Положительное число не является пропуском

Проект требует не считать положительное r гарантией обслуживания следующих запросов. В разделе безопасности доступные единицы названы подсказками, а не выданными запросами или соглашением об уровне сервиса.

Между наблюдением и следующей попыткой меняется нагрузка. Другая политика может стать ограничивающей. Защита может искусственно снизить значения. Запрос может не пройти аутентификацию, авторизацию или прикладную проверку. RateLimit не принимает эти решения.

Обратная ситуация также допустима: сервис может обслужить запрос при r=0. Спецификация не связывает жёстко значения с кодом состояния. Власть применить политику остаётся у сервиса.

Клиент может отметить работу как соответствующую последней известной подсказке. Он не может отметить её как принятую до следующего ответа. Исполнение требует квитанции приложения, а бизнес-результат — доказательства от потребителя или управляемого объекта.

Раздел квоты не равен субъекту

pk обозначает раздел, к которому относится запрос. Сервер может делить мощность по пользователю, приложению, методу, ресурсу или их сочетанию. Документированная функция помогает предсказать, какой пул затронет будущий запрос.

Стабильный ключ не удостоверяет человека. Общие учётные данные объединяют пользователей; один пользователь может работать в нескольких разделах; алгоритм может измениться. Проект просит не включать чувствительные данные и учитывать подмену, если ключ содержит идентифицирующую информацию.

Авторизация прямо исключена из назначения полей. Запрос может находиться в пределах квоты и быть запрещённым. Он может быть разрешённым и ограниченным. Даже 401 и 403 иногда расходуют единицы — это зависит от реализации.

Нужно связывать, но не сливать аутентифицированного субъекта, решение доступа, раздел квоты, наблюдение, допуск и результат.

Посредник создаёт невидимые попытки

Прокси способен повторить запрос без уведомления пользовательского агента. Клиент видит одно задание, а сервис — две попытки и, возможно, две списанные единицы. Локальный счётчик не обязан совпадать с серверным.

Внешний посредник не должен делать политику origin более разрешающей. Он может передать более строгий предел, если понимает единицу и действительно применяет собственное ограничение.

Даже предполагая отказ, посреднику обычно следует переслать запрос. Сервис, вернувший поля, отвечает за исполнение и свободен обслужить запрос. Прогноз промежуточного узла не становится решением origin.

Расхождение требует идентификатора запроса, идентификаторов попыток, хопов, причин повтора, ответов и применённых политик. Два числа без происхождения не доказывают ни злоупотребление, ни потерю.

Большой остаток может превратиться в атаку

Если поделить большое r на короткое t, получится скорость, значительно превышающая среднюю q/w. Документ приводит этот механизм как риск истощения: сигнал, предназначенный для кооперации, может подтолкнуть простой алгоритм к всплеску.

Чрезмерное значение может быть ошибкой конфигурации, вмешательством посредника или реальным кратким запасом. Клиенту не обязательно сначала устанавливать причину. Он сохраняет собственные потолки скорости, параллелизма, памяти, стоимости и давления на зависимые системы.

Безопасная автоматика ограничивает удалённые значения, вводит случайный разброс, наращивает нагрузку ступенчато и держит автоматический выключатель. Подсказка выбирает действие внутри локальной политики, но не отменяет её.

Статус относится к уже обработанному запросу

Поля могут приходить с успешными, неуспешными и ограниченными ответами. Обязательной корреляции с кодом состояния нет. 200 сообщает итог текущего запроса; r и t дают текущую подсказку для последующих решений.

RFC 6585 определяет 429, а Retry-After может сопровождать его. Но 429 не раскрывает универсальный алгоритм, и наступление указанного времени не гарантирует успех. Точно так же текущий 200 не резервирует будущую мощность.

Операционный журнал хранит два времени и две области утверждения. Иначе «последний запрос успешен» превращается в «сервис гарантированно доступен», а «остаток ноль» — в «сервис недоступен всем».

Тип проблемы — классификация, а не доказательство намерения

Редакция 11 предлагает типы проблем для превышенной квоты, временного превышения и обнаруженного аномального использования. Они могут перечислять нарушенные политики и поддерживать разные реакции.

«Аномальное использование» остаётся классификацией отвечающего сервиса. Оно не доказывает злой умысел, личность или правильность модели. На его основе разумно замедлить, остановить пакет и начать проверку. Для необратимой блокировки или публичного обвинения нужны дополнительные данные.

RFC 9457 задаёт контейнер, RFC 9651 — структурированный синтаксис, RFC 9110 — общую семантику HTTP. Машиночитаемость повышает качество квитанции, но не власть её автора.

Источники и ограничения

Замороженный пакет включает редакцию 11, её статус, историю и ссылки Datatracker, материалы HTTPAPI и проект о приватности, RFC 9110, 9651, 6585, 9457 и 9205, а также реестры IANA. Он подтверждает предлагаемый механизм и его границы, но не реализацию, продукт, инцидент, распространённость, производительность или совместимость.

Источники