HTTP429 и Retry After при восстановлении группы шлюзов

Запросить

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

Распознать ограничение правильно

RFC6585 описывает HTTP429 как ответ об избыточной частоте запросов и допускает Retry-After. (IETF — RFC6585 Additional HTTP Status Codes) Формат соответствующего поля определяется HTTP семантикой. (IETF — RFC9110 HTTP Semantics) Проверьте, какие варианты действительно поддерживает клиент, включая интервал и календарную дату по контракту сервиса.

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

Сохранить состояние задания

Пакет остаётся связанным с исходными идентификаторами записей и локальной очередью. Отдельно храните номер попытки, причину ожидания и следующее допустимое действие. Не пересоздавайте физическое измерение с новым временем только потому, что транспортный запрос пришлось отправить снова.

Ответ HTTP 429 и доступный Retry-After определяют условия ожидания. На учебной шкале три клиента выполняют разнесённые попытки после условной границы, без числовых интервалов. Локальная очередь сохраняет исходные ID и время измерений и отдельно учитывает транспортные попытки. — Учебная схема показывает проектное разнесение повторов с соблюдением условий сервера. Она не задаёт обязательной формулы ожидания и не меняет идентичность измерений; формат Retry-After, часы клиента и предел накопителя учитываются отдельно.

Если Retry-After задан календарной датой, учтите состояние часов клиента. Исходное значение ответа сохраните без изменения. При неизвестной синхронизации нельзя уверенно вычислить ожидание простой разностью несопоставимых отметок; допустимое резервное поведение определяется проектом и должно оставаться наблюдаемым.

Разнести повторы группы

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

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

Ограничить неопределённость

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

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

Все разборы