Кратко

  • В RFC 2187 parent и sibling задавали разные отношения обработки запросов. Sibling мог обслужить подтверждённый HIT, но не должен был становиться транзитным путём для MISS; parent мог принять получение и при наличии объекта, и при его отсутствии.
  • ICP query/reply давал локальное свидетельство для выбора следующего источника. Роль соседа, ограничения по классам запросов и доменам, доступ, веса, задержки, multicast, firewall, security и fallback определялись вне самого сообщения.
  • HIT, измеренный delay, сохранённый RTT, настроенный weight, членство в multicast-группе, возвращённый object и успешный fetch подтверждали только собственный ограниченный слой. По отдельности они не доказывали взаимные полномочия, аутентифицированную identity, freshness, безопасность, будущую capacity или полный результат доставки.
  • RFC 2186 описывал ICPv2 на уровне протокольной семантики, RFC 2187 — его применение в иерархиях кэшей, RFC 3040 позднее помещал ICP в более широкую классификацию взаимодействия прокси, а RFC 9211 относится уже к наблюдаемому описанию обработки HTTP-кэшем.

«Выше» и «рядом» были ролями обработки, а не координатами

RFC 2187, опубликованный в сентябре 1997 года как Informational RFC, документировал применение ICPv2 в тогдашних иерархиях веб-кэшей. Само слово hierarchy могло подталкивать к географическому прочтению: parent находился «на уровень выше», sibling — «на том же уровне». Но для работы системы важным было другое — что соседу разрешено сделать с запросом после ответа о состоянии его кэша.

Если локальный кэш не имел нужного объекта, он мог запросить соседей через ICP. Подтверждённый HIT позволял начать получение как от parent, так и от sibling. После MISS различие становилось принципиальным. Sibling мог предоставить только то, что уже находилось в его кэше; разрешать через него дальнейшее получение отсутствующего объекта не следовало. Parent, напротив, мог использоваться как транзитный следующий шаг независимо от того, был объект у него закэширован или нет. После соседских MISS запрос должен был уйти либо к parent, либо непосредственно к origin.

Именно это отделяло отношение от предполагаемой близости. RFC 2187 связывал роль parent с возможностью предоставить транзит, когда он необходим, и поэтому отмечал, что такой узел в идеале может находиться внутри транзитного ISP или на пути к нему. Но это было следствием функции, а не определением через физическое положение. Видимая топология сама по себе не давала узлу право разрешать MISS.

Роль могла быть ещё уже, чем имя конкретной машины. Squid и Harvest позволяли ограничивать соседа определёнными классами запросов или DNS-доменами. Один и тот же neighbour мог рассматриваться как sibling для одной части запросов и как parent для другой. Следовательно, parent или sibling — это не постоянный «тип узла», а применяемая к некоторому трафику политика отношений.

Две стороны конфигурации не превращались в одно утверждение протокола

Peering требовал ручной настройки на обоих концах. Запрашивающий кэш задавал для соседа роль parent или sibling. На отвечающей стороне доступ запрашивающего обычно регулировался ACL. Если другой узел получал HTTP- и ICP-доступ, включая возможность проходить через MISS, это соответствовало поведению parent. Чтобы действительно удержать отношение в пределах sibling, сторона, предоставляющая доступ, должна была запрещать обслуживание MISS и согласовать эту роль с другой стороной.

При этом ICP-сообщение не несло поля, которое объявляло бы: «этот neighbour является parent» или «этот neighbour является sibling». HIT и MISS приходилось толковать через локальную конфигурацию. Запрашивающая сторона отвечала за то, чтобы не разрешать MISS через sibling; отвечающая могла поддерживать нужную границу косвенно, ограничивая доступ.

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

Это важно и для чтения самого HIT. HIT — ответ о состоянии кэша в рамках конкретного обмена, а не самостоятельный мандат на любые дальнейшие действия. Его операционное значение определяется сочетанием сигнала и роли. То же относится к parent MISS: он может быть основанием продолжить получение через этого parent, но такое продолжение существует потому, что конфигурация допускает транзит, а не потому, что MISS сам по себе создаёт полномочие.

Иерархия охватывала не каждый запрос

RFC 2187 не описывал универсальную обязанность направлять весь трафик через соседей. Некоторые запросы могли вообще обходить ICP. К таким случаям относились локальные HIT, настроенные локальные origin, запросы не-GET и URL из stop-list. Для них прямое обращение к origin оставалось отдельным путём.

Даже внутри набора запросов, где соседи могли участвовать, политика заранее сужала круг кандидатов. Ограничения могли исключить конкретного peer. Sibling не следовало опрашивать для запроса с Pragma: no-cache, потому что выполнение такого запроса потребовало бы недопустимого для sibling транзита. Если был настроен один parent, параметр single_parent_bypass позволял использовать его, не ожидая ICP-обмена.

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

Сигнал выбора не был доказательством лучшего пути

После ICP-ответов локальный кэш должен был принять следующий выбор. Подтверждённый HIT указывал на peer, от которого можно начать retrieval. MISS от parent мог допускать retrieval через этого parent. Если HIT не пришёл, при выборе среди parents могли учитываться измеренная задержка ответа, сохранённый RTT до источника, настроенный weight и порядок, связанный с multicast.

Но каждый такой вход оставался ограниченным свидетельством. Delay доказывал измеренный delay. RTT — сохранённое измерение. Weight — предпочтение, заданное конфигурацией. Multicast membership — участие в соответствующей группе. Ни один из этих фактов отдельно не удостоверял, что выбранный путь будет самым дешёвым, самым свежим, самым безопасным или лучшим при будущей нагрузке.

RFC 2187 сам фиксировал неоднозначность между двумя применениями ICP: поиском объекта и выбором peer с элементами распределения нагрузки. Быстрый ответ иногда мог коррелировать со свободной capacity, но время ответа не было полным прогнозом способности доставить объект. Контрольный сигнал и итоговая передача оставались разными стадиями.

Позднее RFC 3143 описал архитектурные и эксплуатационные проблемы прокси и кэшей, включая случай, где стратегия первого ответа предпочитает peer с меньшей задержкой, хотя peer с большей задержкой и большей полосой мог бы передать данные лучше. В приведённом там примере такой высокополосный узел мог подходить как parent, но не как sibling. Этот пример усиливает ту же границу: наблюдаемая latency не определяет роль и не исчерпывает качество будущей передачи.

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

Multicast и поддельные ответы показывали предел доверия

В multicast-сценарии локальный кэш мог получать ответы от нескольких участников, но сам факт членства в группе не был удостоверением identity. RFC 2187 предупреждал о рисках ложных ответов и изменённых значений RTT: такой сигнал мог заставить систему выбрать neighbour либо, наоборот, помешать его использованию.

ICP не предоставлял встроенной гарантии аутентифицированной identity. Поэтому security и firewall оставались ответственностью развёртывания. Адрес ответа, HIT или иное наблюдение могли участвовать в выборе только в пределах той политики доверия, которую задавал оператор.

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

Именно поэтому multicast membership, HIT и RTT нужно держать на своих местах в цепочке доказательств. Они помогают принять решение о следующем шаге, но не заменяют настройку neighbours, ACL, miss policy и security-контроль.

Управление иерархией оставалось у развёртывающей стороны

В RFC 2187 значительная часть поведения системы определяется тем, что оператор настроил до конкретного обмена: какие neighbours существуют, где они считаются parent или sibling, какие классы запросов и домены им доступны, что разрешают ACL, когда допускается MISS-транзит, какие запросы идут напрямую, сколько ждать ответов и какие входы использовать при выборе.

Эта контрольная поверхность включала также weights, RTT-данные, multicast, firewall, security и fallback. ICP не превращал её в автоматическое свойство сети. Протокол давал ограниченные наблюдения, а конфигурация связывала эти наблюдения с разрешёнными действиями.

Из-за этого одинаковый ответ мог иметь разное практическое значение в разных отношениях. HIT от parent и HIT от sibling мог вести к получению объекта. MISS от parent мог оставить путь через этот neighbour открытым; MISS от sibling не должен был делать то же самое. Значение сигнала неотделимо от границы полномочий, заданной ролью.

Локальная роль меняла и последствия ошибок. Если система неверно допускает MISS через узел, который должен действовать как sibling, результатом может стать отказ там, где ожидался транзит. Если ложный или устаревший сигнал влияет на peer selection, он может изменить концентрацию трафика, распространение отказов и latency exposure. Поэтому конфигурация роли — не декоративная метка, а один из механизмов управления путём запроса.

RFC 2186, RFC 3040 и RFC 9211 относятся к другим слоям

RFC 2186 и RFC 2187 связаны, но выполняют разные задачи. RFC 2186 относится к семантике ICPv2 на протокольном уровне; RFC 2187 документирует, как ICPv2 применялся в иерархиях веб-кэшей. Разделение важно: wire format и opcodes не определяют сами по себе, кому разрешено разрешать MISS и какие соседские отношения настроены.

RFC 3040 позднее классифицировал ICP как loosely coupled inter-proxy communication и ссылался на RFC 2186 для протокольной семантики, а на RFC 2187 — для применения. Это ещё раз отделяет формат межпрокси-сигнала от политики иерархии.

RFC 9211 находится на иной стадии evidence. Он стандартизирует Cache-Status — метаданные HTTP-ответа после обработки, предназначенные для описания того, как кэш обработал запрос. Такой observability-сигнал не назначает соседу роль parent или sibling и не выдаёт ему разрешение на транзит при MISS.

Поэтому эти документы нельзя сворачивать в одну шкалу «больше информации — больше полномочий». Сведения о состоянии кэша, локальная роль, выбор источника, transfer, validation и наблюдаемый результат — разные звенья. RFC 2187 полезен именно тем, что позволяет удерживать их раздельно.

Что именно можно считать доказанным

Для анализа этой архитектуры полезно формулировать утверждения настолько узко, насколько позволяет наблюдение. Настроенный neighbour label доказывает локальную политику одного endpoint. Совпадающие роли на двух концах поддерживают вывод о взаимной конфигурации, но не о симметрии всех request classes. HIT подтверждает один cache-state answer. Parent MISS может открыть путь к транзиту, если это разрешено отношением.

Измеренный reply delay, сохранённый RTT и настроенный weight подтверждают соответствующее измерение или предпочтение. Multicast membership подтверждает членство. Возвращённый object подтверждает возврат данных на этой стадии. Успешный fetch подтверждает успешность fetch. Ни один из этих фактов отдельно не доказывает аутентифицированную identity, reciprocal authority, object freshness, safe content, future capacity, complete delivery, application receipt, user-visible success или business outcome.

Такое разделение также задаёт предел исторической интерпретации. RFC 2187 сообщает о семантике, примерах и эксплуатационных уроках своей эпохи. Он не является свидетельством современной распространённости ICP, универсальным рейтингом производительности или описанием современной CDN-модели. Его предмет — конкретная операционная граница между отношением к соседу, разрешением продолжить MISS, локальным свидетельством для выбора и последующим retrieval.