Кратко

  • RFC 2186 — Informational RFC сентября 1997 года, подготовленный Wessels и Claffy. ICPv2 обменивается между соседними кэшами лёгкими сведениями о наличии URL, а получение самого объекта обычно остаётся задачей HTTP.
  • HIT означает, что URL присутствует и его использование разрешено. Из этого не следует, что объект уже доставлен, свеж, получен целиком, имеет доказанное происхождение или успешно дошёл до приложения.
  • Поля и ответы ICP требуют разной степени осторожности: Sender Host Address не сильнее адреса peer, видимого транспортом, Requester Host Address может быть all-zero со значением «не указан», а Request Number не несёт интерпретируемого прикладного смысла.
  • HIT_OBJ требует opt-in и не рекомендуется; он обходит HTTP authorization и Age Validation. Это отдельный вопрос от отсутствия аутентификации самих ICP-ответов.

RFC 2186 задаёт ICPv2 как механизм предварительного выбора, а не как протокол подтверждения результата. Кэш может спросить соседей о конкретном URL, получить ответы и на их основе выбрать, к кому обратиться дальше. Передача объекта после этого решения относится к HTTP.

Такое разделение ролей объясняет почти все ограничения доказательности ICP. Ответ должен быть достаточно лёгким и быстрым, чтобы использоваться при выборе, а не настолько богатым, чтобы подтверждать весь путь объекта до конечного потребителя. Заголовок ICPv2 занимает 20 октетов, полный размер сообщения ограничен 16384 октетами, а типичное ожидание ответов составляет примерно одну-две секунды.

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

HIT подтверждает состояние выбора, а не завершённую доставку

Положительный ответ HIT означает, что запрошенный URL присутствует у отвечающей стороны и что его использование разрешено. После этого requester может перейти к HTTP и запросить сам объект.

Между этими событиями остаётся принципиальная граница.

HIT не говорит, что HTTP-запрос уже произошёл. Он не говорит, что передача завершилась. Он не подтверждает получение всех байтов приложением. Он не устанавливает свежесть объекта и не доказывает, что выбранный сосед окажется лучшим из возможных источников.

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

Все эти утверждения находятся дальше по цепочке и требуют собственных наблюдений.

Отсюда следует точная операционная трактовка: HIT даёт основание предпочесть или рассмотреть конкретного соседа. Он не закрывает вопрос о том, чем закончится последующий запрос.

Поля адресов имеют разные значения и разные пределы доверия

Формат сообщения не создаёт автоматически надёжной идентичности отправителя.

Sender Host Address не заслуживает большего доверия, чем адрес peer, который непосредственно виден транспортному уровню. Назначение этого поля было неоднозначным, а на практике оно не использовалось. Поэтому считать его дополнительным подтверждением источника нельзя.

Отдельно существует Requester Host Address в запросе. Его значение может быть all-zero. В этом случае смысл конкретен: адрес requester не указан.

Эти две особенности нельзя смешивать. Нулевой Requester Host Address не описывает Sender Host Address и не объясняет его использование. Sender Host Address характеризуется иной проблемой — неоднозначностью назначения и отсутствием практической опоры на это поле.

Request Number также не расширяет доказательную картину. Он непрозрачен. Его можно использовать в работе протокола для связывания запроса и ответа, но интерпретировать его как идентификатор объекта, пользователя, доверенной стороны или более широкого события нельзя.

MISS не равен окончательному отсутствию возможности получить объект

ICPv2 различает несколько вариантов ответа, которые на первый взгляд могут выглядеть как разновидности неудачи, но операционно означают разные вещи.

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

MISS_NOFETCH говорит больше: узел доступен и отвечает, но при промахе не станет извлекать объект. Это не то же самое, что обычный MISS, и не то же самое, что молчание.

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

Эти различия нужны именно для принятия решений. Если свести MISS, MISS_NOFETCH и DENIED в единую категорию «отрицательный ответ», система потеряет информацию о том, какие действия ещё имеют смысл.

Отсутствие UDP-ответа не устанавливает причину

Молчание в ICPv2 имеет особенно узкую доказательную ценность.

Если ожидаемый UDP-ответ не пришёл, практический смысл состоит в том, что этого соседа не следует выбирать сейчас на основании данного обмена. Из молчания нельзя установить, отсутствует ли URL, отказало ли приложение, недоступен ли хост или произошло что-то ещё.

То есть молчание — результат наблюдения, но не диагноз.

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

Echo позволяет отдельно проверить достижимость. Но успешный Echo не подтверждает работоспособность приложения кэша. Он сужает неопределённость лишь на уровне достижимости, не заменяя проверку более высокого уровня.

Source RTT — вспомогательный сигнал, которому разрешено быть неполным

Source RTT может использоваться при выборе, но протокол не требует, чтобы это всегда было свежим измерением текущего пути.

Значение может быть сохранено ранее, быть нулевым или отсутствовать. Кроме того, его получение не должно задерживать ICP-ответ.

Это важная конструктивная деталь. Протокол предпочитает своевременность ответа полноте дополнительной метрики. Значит, система, использующая Source RTT, должна сохранять информацию о его неопределённости.

Ноль нельзя автоматически читать как измеренный нулевой RTT. Отсутствие значения не следует считать самостоятельным доказательством сбоя. Сохранённое значение нельзя без оговорок принимать за состояние пути в данный момент.

Если эту разницу убрать, приблизительный параметр начнёт выглядеть точнее, чем он есть.

HIT_OBJ меняет путь объекта и поэтому требует отдельной осторожности

HIT_OBJ позволяет передать объект непосредственно в ответе ICP. Этот механизм не рекомендуется и требует opt-in.

Он отличается от обычного HIT не только количеством данных. При HIT_OBJ объект проходит в обход HTTP authorization — авторизации, то есть проверки полномочий, — и Age Validation. Поэтому использование такого ответа затрагивает проверки, которые при обычной схеме оставались бы на HTTP-этапе.

Здесь важно не подменять терминологию. Речь идёт именно об обходе HTTP authorization и Age Validation, а не HTTP authentication.

Отдельная проблема безопасности состоит в том, что ответы ICP не аутентифицированы. Это самостоятельное свойство протокола и не является другим названием обхода HTTP authorization.

HIT_OBJ также создаёт риск MTU fragmentation: помещение объекта в UDP-сообщение увеличивает размер передаваемых данных. Если объект нельзя вернуть полностью, должен использоваться обычный HIT, после чего объект запрашивается отдельно.

Тем самым протокол возвращается к своей базовой модели: ICP даёт информацию для выбора, а получение содержимого остаётся последующим действием.

Отсутствие аутентификации влияет прежде всего на доверие к решению

RFC 2187 фиксирует отсутствие аутентификации ICP-ответов. Следовательно, полученный ответ нельзя считать подтверждённым только на основании того, что он пришёл в ожидаемом формате.

Поддельный HIT может изменить выбор источника.

Поддельный MISS_NOFETCH способен заставить requester отказаться от соседа, который при реальном обмене мог бы вести себя иначе.

Поддельный DENIED может создать ложное представление о действующем ограничении.

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

Особенно опасно сочетание spoofing и HIT_OBJ. Если обычная подделка ответа в первую очередь воздействует на решение, к кому обратиться, то HIT_OBJ позволяет перенести воздействие непосредственно на содержимое. В этом случае появляется риск отравления контента.

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

Семантика HTTP caching остаётся отдельным слоем

RFC 9111 описывает правила HTTP caching независимо от ICP. Это различие не формальное, а смысловое.

ICP HIT не заменяет HTTP-семантику свежести и использования кэшированных ответов. Равным образом HTTP-результат не задним числом превращает ICP-сигнал в доказательство происхождения или идентичности.

У каждого слоя свой объект наблюдения.

ICP помогает выбрать соседа.

HTTP отвечает за последующее получение и собственные правила кэширования.

Приложение располагает данными о том, было ли содержимое действительно принято и обработано.

Если интерес представляет бизнес-результат, потребуется ещё одно независимое событие уже на соответствующем уровне.

Чем шире утверждение, тем больше отдельных свидетельств нужно для его подтверждения.

Где заканчивается доказательная сила ICPv2

Наиболее полезно сформулировать границу прямо.

HIT не доказывает происхождение объекта.

Он не доказывает свежесть.

Он не устанавливает личность отвечающей стороны.

Он не подтверждает наличие полного набора байтов.

Он не свидетельствует о безопасном отображении.

Он не доказывает, что данный сосед является оптимальным источником.

Он не обещает будущую доступность.

Он не подтверждает доставку приложению.

И он ничего сам по себе не говорит о бизнес-результате.

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

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

Если HIT объявить фактом доставки, исчезает возможность измерять разрыв между выбором и HTTP-результатом.

Если HIT принять за подтверждение свежести, смешиваются ICP и HTTP caching.

Если HIT считать доказательством личности, игнорируется отсутствие аутентификации ICP.

Если HIT напрямую связать с конечным прикладным результатом, из анализа выпадет вся промежуточная цепочка событий.

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