Кратко

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

Пакеты больше не объясняли всё

Браузер запрашивал изображение. Исходный сервер мог находиться далеко, ближайший кэш — не хранить нужный объект, а одному провайдеру могло не хватать площадок для обслуживания всех пользователей. В начале 2000-х часть решения перемещалась в инфраструктуру, анализирующую запросы приложений и контент, а не только заголовки IP.

Опубликованная в феврале 2003 года RFC 3466 назвала эту область «сетью контента». Её терминология описывала функции уровней с четвёртого по седьмой: они обрабатывают запросы и ответы для объектов, разбитых на множество пакетов. Это не замена IP-маршрутизации, а дополнительный уровень координации: что доступно, куда направить запрос, как перемещать копии и как учитывать действия.

Документ отказался и от заманчивой аналогии. «Content peering» или «CDN peering» звучало как соединение IP-сетей и могло подразумевать открытый обмен, взаимность или расчёты. Рабочая группа выбрала термин «content internetworking». Новое название не решило вопрос сотрудничества, но не позволило знакомой аналогии заранее определить ответ.

Одна доставка — четыре разные функции

RFC 3466 разделила четыре функции. Маршрутизация запросов направляет пользовательский агент к подходящему суррогату. Распространение переносит контент под контролем издателя от источника к суррогатам — заранее или после запроса. Доставка — это ответ суррогата клиенту. Учёт регистрирует действия маршрутизации, распространения и доставки, иногда для последующего перевода денег, товаров или обязательств.

Эти функции оставляют разные свидетельства. Перенаправление не доказывает, что контент прибыл. Копия на суррогате не доказывает, что клиента направили туда. Успешный ответ не обязательно показывает, какая вышестоящая сеть предоставила объект. Запись в журнале ещё не является счётом, признанным обеими сторонами. Модель была ценна тем, что позволяла обозначить события по отдельности.

Контроль также распределён. Издатель управляет контентом и его распространением; источник хранит главную или авторитетную копию; суррогат доставляет объект, но не становится его источником. Шлюз взаимодействия сетей контента может обслуживать распространение, маршрутизацию, учёт или только часть этих функций.

Даже чёрному ящику нужно соглашение

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

Шлюз способен расширить охват, тогда как внешнее соглашение ограничит допустимые объекты, детализацию учёта и ответственность. Технически корректный маршрут не даёт права доставлять любой контент. Необходимо также учитывать идентичность партнёра, целостность контента и аудит учётных данных. RFC 3466 обозначила эти вопросы безопасности, но не расписала все механизмы.

Сначала карта, потом механизмы

RFC 3466 была документом Informational: она предложила модель, но не стандартизировала протокол обмена. В 2012 году RFC 6707 всё ещё оформляла взаимодействие CDN как область проблемы, описывая интерфейсы управления, маршрутизации запросов, метаданных и журналирования; коммерческие отношения оставались за рамками. Этот позднейший этап не доказывает нынешнее внедрение.

Исторический вклад RFC 3466 — в обозначении границы. Сети могли обсуждать расширение охвата, не притворяясь, что общий словарь автоматически создаёт открытый рынок. Для маршрута, копии, разрешения на услугу и счёта по-прежнему требовались отдельные подтверждения.

Источники