Кратко

  • RFC 9808 даёт нижестоящей CDN способ объявить для заданного охвата пределы, которые нельзя превышать, и указать согласованные источники телеметрии. Эти сведения помогают вышестоящей CDN делегировать трафик, но не являются гарантией, обязательством или резервом.
  • Проверяемое решение сохраняет все применимые ограничения, мягкий и жёсткий максимумы, охват, TTL, источник, метрику, интервал, среднее или процентиль, задержку и агрегирование. Само делегирование, приём запроса, доставка, качество и договорное возмещение требуют следующих квитанций.

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

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

Документ вышел в июле 2025 года на Standards Track и расширил интерфейс Footprint & Capabilities Advertisement из RFC 8008. FCI.CapacityLimits описывает объявленную оболочку ёмкости, а FCI.Telemetry — источники наблюдения за её текущим использованием. Карточка RFC Editor и IETF Datatracker называют авторами Andrew Ryan, Ben Rosenblum и Nir B. Sopher. Реестр параметров CDNI IANA закрепляет общие имена.

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

Однако совместимый формат не расширяет власть сообщения. RFC 9808 прямо называет информацию advisory и отрицает гарантию, обязательство или резерв. maximum-hard сообщает максимум, доступный для использования в соответствующем контексте по заявлению нижестоящей CDN. Он не доказывает, что часть ресурса выделена исключительно этому партнёру и останется свободной до следующего запроса.

Разделение следует архитектуре CDNI. RFC 6707 описывает поставщика контентной услуги, авторитетную или вышестоящую CDN и нижестоящую CDN, но оставляет коммерческие договорённости вне технической спецификации. Цена, приоритет, вытеснение, эксклюзивность и компенсация возникают из отдельного договора, а не из корректно разобранного поля.

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

Зарегистрированы шесть типов ограничений: исходящий поток, запросы, объём хранения, число хранимых объектов, сессии и размер кэша. Каждое имеет обязательный maximum-hard. Возможен меньший maximum-soft, после которого вышестоящая сторона должна сокращать трафик до достижения жёсткой границы. Если мягкий максимум отсутствует, он равен жёсткому.

Все применимые пределы соединены логическим И. Свободный исходящий канал не отменяет исчерпанное число сессий. Свободные байты не снимают предел количества объектов. Выбрать самый широкий показатель и проигнорировать остальные — значит превратить многомерную оболочку в рекламную цифру.

Расстояние между мягкой и жёсткой границами — время на реакцию. Наблюдение запаздывает, контроллер работает по циклу, решение распространяется, часть трафика уже движется. Если сокращение начинается только на жёстком максимуме, действие может прийти после пересечения. Запас должен учитывать скорость роста, возраст данных, период регулирования и последствия отказа.

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

Сам охват — часть значения. RFC 8008 допускает footprint по адресам, ASN, странам и другим зарегистрированным типам. Несколько условий могут совместно сужать пригодность. Десять тысяч запросов в секунду могут относиться к стране, диапазону или пересечению правил. Запрос за пределами области не получает права воспользоваться числом.

Следующее измерение — срок. Предел наследует TTL транспорта, например HTTP Cache-Control. Если механизма TTL нет, стороны согласуют срок вне протокола. Стандарт предполагает относительно устойчивую разумную пиковую цель. Текущая загрузка меняется быстрее. Действующее объявление подтверждает жизнь оболочки, но не свободное место внутри неё.

Для состояния служит FCI.Telemetry. Объект объявляет источники почти реального агрегированного использования, относящиеся к конкретной паре вышестоящей и нижестоящей CDN. Идентификатор источника уникален в объявлении и стабилен, пока обозначает ту же ссылку. Имя метрики следует тому же правилу. Предел ссылается на оба, чтобы сравнение шло с предназначенным счётчиком.

time-granularity указывает представленный интервал. data-percentile задаёт процентиль; без него значение является средним за интервал. latency показывает отставание от настоящего. Среднее за минуту с десятисекундной задержкой и 95-й процентиль за пять минут с двухминутной задержкой могут быть точными одновременно, но требуют разных решений.

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

Универсальный тип источника оставляет конфигурацию доступа за рамками стандарта. Это осознанная граница. Общий слой фиксирует идентичность и смысл сравнения, не навязывая всем один транспорт, учётные данные, цену и модель защиты. Будущее решение остаётся у сторон, несущих риск.

При цепочке делегирования учёт должен следовать графу. Если вышестоящая CDN отчитывается об общем использовании, она обязана агрегировать нижестоящее потребление. Иначе переданный дальше трафик исчезает с локальной панели, хотя продолжает занимать ёмкость. Кажущийся запас становится следствием неполной бухгалтерии.

Для простых случаев предусмотрен inline-показатель current, но быстро меняющуюся загрузку не рекомендуется помещать в кэшируемое объявление. Разделение устойчивой оболочки и часто опрашиваемого состояния даёт им разные частоты обновления. Одновременно требуется правило отказа: что делать, если предел свежий, а источник стар, недоступен, переименован или изменил гранулярность?

Молчаливое использование последнего благоприятного значения не нейтрально. Контроллер может понизить оболочку, остановить новые делегирования, вернуться к согласованному статическому распределению или пропускать лишь трафик с малыми последствиями. Выбор зависит от модели сбоя. RFC 9808 даёт поля для исполняемой политики, но не выбирает её.

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

RFC 8007 задаёт отдельный интерфейс триггеров и статусов и тем самым показывает: получение команды, её выполнение и наблюдаемый эффект имеют разные циклы. Аналогично нельзя сводить в один зелёный статус «объявлено, измерено, делегировано, принято, доставлено, испытано, возмещено».

Надёжный журнал начинает с точного FCI-документа, времени получения, footprint, TTL и полного набора ограничений. Он хранит soft/hard, источник, метрику, время измерения, гранулярность, среднее или процентиль, задержку и способ агрегации. Затем добавляет версию роутера, запас, прогноз, объём и основание решения. Приём, доставка, качество и договор — отдельные записи.

В Minimum Initial Specification Heng Lu объясняет ценность тонкого общего слоя: переносимыми становятся имена и базовый смысл, а будущее решение остаётся у локального участника, несущего последствия. Reality Layers не позволяют превратить символическое заявление в техническое состояние, действие и исход. Running-Code Primacy требует проверить, получила ли реальная программа объекты, учла ли возраст, сравнила ли все условия и что затем сделал контур доставки.

RFC 9808 стандартизирует не запас, а честный разговор о нём. Объявить, измерить, делегировать, принять, доставить, испытать и возместить — семь разных глаголов с разными квитанциями. Новые объекты отвечают только за первые два.

Источники