Resumen

  • RFC 2187 definió parent y sibling por lo que una caché podía pedir a otra, no por una distancia física: un sibling podía servir un HIT, mientras un parent podía dar tránsito también cuando había MISS.
  • ICP era un mecanismo de pistas para selección inmediata. Su evidencia debía combinarse con configuración, listas de acceso, temporizadores, condiciones de red, reglas de firewall, multicast y rutas de fallback.
  • Las señales observadas —HIT, RTT, pertenencia a un grupo multicast, objeto devuelto o recuperación exitosa— no deben inflarse hasta convertirlas en pruebas de autoridad recíproca, identidad autenticada, seguridad, capacidad futura o valor económico.

La jerarquía era una política de tránsito

La figura central de RFC 2187 no es una topología física sino un diagrama de posibilidades. La caché local puede recuperar HITs de un sibling; puede resolver HITs y MISSes mediante un parent; y puede enviar determinadas solicitudes directamente al servidor de origen. El documento llama “nivel” superior al parent y “mismo nivel” al sibling, pero convierte esas palabras en una regla operativa: la diferencia esencial está en qué ocurre ante un MISS.

Si el vecino es sibling, la caché que consulta sólo puede pedirle objetos que ya tenga. Si es parent, puede pedirle que recupere un objeto aunque no esté almacenado. El parent ofrece tránsito; el sibling no lo ofrece por el mero hecho de ser vecino. Por eso “sibling” no declara reciprocidad general y “parent” no prueba política simétrica.

RFC 2187 añade que un mismo vecino podía tratarse como sibling para unas solicitudes y parent para otras, con restricciones por dominios y otras condiciones. La relación estaba compuesta por decisiones del desplegador, no por proximidad física ni por responder rápido.

La vía directa al origen completa el modelo. Cuando todos los vecinos daban MISS, la caché debía elegir un parent o el origen. Si la consulta ICP no producía un parent apropiado, el comportamiento descrito era ir al origen, salvo que el firewall lo impidiera. El origen era una alternativa distinta, no un parent implícito.

ICP observaba una capa pequeña y útil

RFC 2187 separa la aplicación de ICP de la definición del protocolo. RFC 2186 especifica el formato de ICPv2, incluidos encabezado, opcodes, número de solicitud, opciones y límites de tamaño. RFC 2187 explica cómo usar esas piezas en una jerarquía: a quién consultar, qué respuesta esperar, cuánto esperar y qué fuente escoger.

Ese reparto evita atribuir a un opcode más significado del que tiene. Un ICP_OP_HIT indica que, en ese momento, el vecino considera que una posterior solicitud HTTP para esa URL debería producir un hit. En la implementación descrita, el objeto debía existir y ser considerado fresco durante al menos 30 segundos según reglas locales de refresh o TTL. Pero el propio RFC señala una carrera: el objeto podía ser purgado antes de la solicitud HTTP. Un HIT era evidencia operativa acotada, no garantía duradera.

Con MISS la semántica depende del rol. El MISS de un sibling se ignoraba como candidato de tránsito; el de un parent podía invitar a recuperar la URL a través de él; MISS_NOFETCH prohibía reenviar la solicitud a ese peer. La información útil surgía de rol configurado, opcode y reglas de selección, no de la palabra “vecino”.

La medición de retraso tampoco convertía a ICP en un oráculo de coste. RFC 2187 describe selección por respuestas y RTT, incluso con pesos para MISS de parents. RFC 3143 documentó después un problema en redes heterogéneas: el peer que responde antes a ICP no tiene por qué entregar antes un objeto grande si su enlace tiene menos ancho de banda. Latencia de señal y rendimiento de transferencia son variables diferentes.

El operador conservaba la autoridad

La jerarquía dependía de configuración manual. RFC 2187 explica que una caché debía declarar al otro extremo como parent o sibling y que el receptor normalmente debía ajustar sus listas de control de acceso. El tipo de relación no viajaba codificado en la consulta ICP. El receptor podía aceptar HTTP e ICP, denegar MISSes o imponer reglas propias sin que la consulta afirmara de forma vinculante qué relación existía.

La política podía ser asimétrica. Llamar parent a un vecino no lo obliga a conceder tránsito. Si el receptor quiere imponer una relación sibling, debe impedir acceso a MISSes; si el emisor sigue tratándolo como parent, puede pedir un objeto ausente y recibir un error. La etiqueta local expresa intención; la conducta efectiva depende de configuraciones compatibles.

Los tiempos de espera eran otra palanca. ICP usaba UDP y podía perder mensajes. Squid y Harvest instalaban un timeout —dos segundos por defecto en la práctica descrita— y después elegían una fuente aunque faltaran respuestas. La ausencia podía sugerir congestión, caída del camino o indisponibilidad de la aplicación; era una señal para no usar al vecino en ese momento, no un diagnóstico completo.

El firewall podía cambiar el fallback. Si bloqueaba acceso directo al origen, la caché tenía que escoger un parent incluso sin respuestas ICP útiles. En una configuración con un único parent obligatorio, podía no haber razón para usar ICP.

Multicast tampoco daba autoridad. Una caché podía enviar consultas a un grupo, pero RFC 2187 exige no confiar automáticamente en quien responda: los mensajes de direcciones no configuradas como vecinos debían ignorarse. Como cualquiera podía unirse al grupo, membresía no equivalía a identidad autorizada.

Seguridad: una respuesta no era autenticación

La limitación más contundente está escrita en el propio diseño: ICPv2 no incluía campos de autenticación. RFC 2187 recomendaba comprobar la dirección IP de origen y aceptar respuestas sólo de vecinos conocidos, pero también advertía del spoofing de direcciones. Un tercero capaz de insertar o alterar respuestas podía cambiar un HIT por un MISS o viceversa y desviar la elección de peer.

Eso impide saltar de “recibí un ICP_OP_HIT” a “he autenticado a la fuente” o “el contenido es seguro”. El documento incluso usa multicast para ilustrar el riesgo: una caché ilegítima podía unirse al grupo, contestar HIT a todo y entregar contenido falso si el receptor confiara automáticamente en cualquiera que respondiese. La seguridad requería controles adicionales; la señal ICP por sí sola no la suministraba.

ICP_OP_HIT_OBJ tampoco cambia esa conclusión. Ese mensaje podía incluir el objeto completo cuando cabía, dentro del máximo de mensaje, y evitaba una solicitud HTTP posterior. Lo que prueba es que se devolvieron bytes junto con una respuesta concreta. No demuestra autoridad sobre el recurso, autenticación criptográfica de la identidad, capacidad futura ni equivalencia con una política completa de seguridad de contenido.

No confundir ICP con control de caché, observabilidad o economía CDN

RFC 3040 ayuda a separar vocabulario y capas. Su taxonomía define caché, caching proxy, surrogate, meshes y relaciones entre proxies, y recuerda que una respuesta puede ser cacheable sin que eso implique que una copia almacenada sea utilizable para cualquier solicitud. Las reglas generales de cacheabilidad y uso pertenecen a la semántica HTTP y a Cache-Control; la consulta ICP decide entre vecinos a partir de información mucho más estrecha. Un HIT ICP no sustituye la evaluación completa de las condiciones HTTP que gobiernan una respuesta.

RFC 9211 aparece mucho después y resuelve otro problema: estandariza Cache-Status para describir cómo una caché manejó una solicitud y una respuesta. Puede indicar, por ejemplo, si hubo hit, por qué se reenvió una solicitud, cuánto tiempo de frescura calculaba una caché o si almacenó la respuesta. Esa observabilidad es valiosa, pero sigue siendo una descripción de procesamiento. Incluso los detalles pueden tener significado específico para la caché que los emite. Cache-Status no convierte una observación en prueba de autoridad comercial, identidad autenticada o política recíproca.

También conviene mantener aparte la economía CDN moderna. Ninguna de estas seis fuentes permite derivar de un HIT, un RTT, una ruta elegida o una descarga exitosa un coste comercial, una ventaja económica o un resultado de negocio. Las RFC describen protocolos, taxonomía, problemas operativos y observabilidad. Usarlas para inferir consecuencias comerciales sin evidencia adicional sería cruzar una frontera que las fuentes no documentan.

La lección duradera es epistemológica

La utilidad histórica de RFC 2187 está en su modestia. ICP ayudaba a contestar una pregunta local: “¿qué fuente parece apropiada para esta solicitud ahora?”. La respuesta podía apoyarse en disponibilidad aparente, RTT, rol de peer, timeout y restricciones configuradas, pero cada señal conservaba alcance limitado.

Un neighbor configurado prueba una relación declarada localmente. Un HIT prueba una expectativa bajo las condiciones del responder y en ese instante. Un RTT mide retraso, no coste total de transferencia. Un peso expresa preferencia, no calidad intrínseca. La membresía multicast prueba recepción del grupo, no confianza. Un objeto devuelto prueba datos en esa respuesta, no autoridad general. Una recuperación exitosa no demuestra capacidad futura ni política recíproca.

RFC 2187 no presenta una red donde las máquinas descubren por sí solas quién manda. Presenta una red donde el operador predefine relaciones, límites y rutas de escape, y usa ICP como evidencia incompleta para elegir dentro de ese espacio.