Resumen

  • RFC 2186 definió ICPv2 como un protocolo ligero de consulta entre cachés para apoyar decisiones rápidas de selección, no como un sistema de autenticación ni como garantía de que un objeto acabaría entregándose correctamente.
  • Cada respuesta tenía un alcance preciso: HIT sugería disponibilidad local para ese solicitante, MISS indicaba ausencia, MISS_NOFETCH añadía una restricción temporal y DENIED expresaba una negativa contextual. Ninguna de esas señales demostraba por sí sola autoridad de origen, frescura HTTP, identidad autenticada o integridad completa.
  • HIT_OBJ intentaba evitar la recuperación HTTP posterior, pero al hacerlo también podía omitir controles que normalmente residían en HTTP; por eso su uso estaba desaconsejado y requería aceptación explícita.

Publicado como RFC Informational en septiembre de 1997 y firmado por D. Wessels y K. Claffy, RFC 2186 fijó la versión 2 del Internet Cache Protocol. El objetivo no era transportar normalmente el contenido web ni sustituir HTTP. ICP ofrecía a una caché una forma rápida de preguntar a otras cachés cercanas si conocían una URL y de utilizar sus respuestas como información para decidir dónde intentar obtenerla.

La economía del protocolo refleja esa función. La cabecera fija ocupa 20 octetos y el mensaje completo no puede superar 16.384 octetos. El proceso de consulta estaba pensado para desenvolverse en una ventana corta: típicamente uno o dos segundos. Una respuesta que llegara demasiado tarde perdía buena parte de su utilidad para una decisión cuyo valor dependía precisamente de no retrasar la recuperación.

La elección de UDP encajaba con esa lógica. Cuando un vecino no respondía, la caché consultante no necesitaba averiguar antes de continuar si había congestión, una ruta interrumpida o un fallo del host o de su software. Para la selección inmediata, esas causas diferentes podían desembocar en la misma conducta: no escoger ahora ese vecino. Esa simplificación era una propiedad del uso que ICP hacía del silencio; no convierte la experiencia de ICP en una regla general para todas las aplicaciones que usan UDP.

Correlacionar una respuesta no es autenticarla

ICP incluía mecanismos suficientes para relacionar una respuesta con una consulta. El Request Number era opaco y debía copiarse de la petición a la respuesta. La URL también tenía que coincidir exactamente. Ambas condiciones ayudaban a determinar a qué intercambio pertenecía un mensaje.

Ese emparejamiento no resolvía la identidad del emisor. ICPv2 no proporcionaba autenticación de sus respuestas. RFC 2187 desarrolló precisamente las consecuencias de esa limitación: una respuesta falsa podía alterar la selección de vecinos, ya fuera provocando una preferencia indebida o evitando que una caché legítima fuese elegida.

También conviene separar dos campos que cumplen funciones distintas. Sender Host Address pertenecía a la cabecera ICP, pero RFC 2186 no aconsejaba confiar en él frente a la dirección del peer observada por el transporte y señalaba que el campo no se utilizaba en la práctica descrita. Requester Host Address, en cambio, aparecía en la consulta como información sobre el solicitante; un valor compuesto enteramente por ceros significaba que no se había especificado esa dirección. El cero pertenece a la semántica de Requester Host Address, no a la de Sender Host Address.

HIT decía algo útil, pero mucho menos de lo que su nombre podría sugerir

ICP_OP_HIT informaba de que la URL estaba presente en la caché consultada y de que el solicitante estaba autorizado para recuperarla. Era información suficiente para influir en la elección del vecino, pero la recuperación del objeto seguía realizándose normalmente después mediante HTTP.

Por eso HIT no es una credencial de entrega. No demuestra que la transferencia posterior vaya a completarse, que los bytes recibidos sean íntegros, que el contenido esté fresco conforme a HTTP, que el origen tenga una autoridad determinada ni que la identidad del vecino haya sido autenticada. Tampoco acredita que el objeto pueda procesarse o representarse de forma segura, que ese vecino sea la mejor fuente posible o que siga disponible unos instantes después.

La distinción entre autorización y autenticación es especialmente importante. En un HIT, la afirmación relevante es que el solicitante está autorizado para obtener el objeto de esa caché. Eso no autentica la respuesta ICP ni identifica criptográficamente a quien la envió.

MISS, MISS_NOFETCH y DENIED describían situaciones diferentes

ICP_OP_MISS significaba que el objeto solicitado no estaba presente. Sin embargo, ese resultado no excluía necesariamente utilizar al vecino: según la relación configurada entre cachés, un MISS todavía podía servir como invitación para recuperar el objeto a través de él.

ICP_OP_MISS_NOFETCH comunicaba otra condición. La caché estaba activa, pero no quería aceptar misses en ese momento. RFC 2186 citaba como ejemplo una caché que estuviera reconstruyendo su almacén durante el arranque. La señal no equivalía a declarar caído el sistema: limitaba lo que el vecino estaba dispuesto a hacer en esa fase.

ICP_OP_DENIED también debía interpretarse dentro de su contexto. Indicaba que ese solicitante no estaba autorizado para esa URL en ese momento. No establecía una prohibición universal ni permanente. Una proporción muy elevada de respuestas DENIED podía ser indicio de una configuración incorrecta; el propio dato no justificaba atribuir una intención maliciosa.

Eco y RTT eran datos auxiliares, no promesas

Los mecanismos SECHO y DECHO permitían utilizar eco en el proceso de selección. Su capacidad probatoria era mínima: que el eco funcionara no demostraba que el software de caché estuviera operativo. El sistema podía contestar al eco mientras la aplicación de caché permanecía caída.

El RTT de origen tenía un límite parecido. La información procedía de mediciones ya almacenadas por la caché. Podía no existir, podía expresarse como cero y no debía provocar que la respuesta ICP se retrasara mientras se realizaba una nueva medición. Era, por tanto, un dato histórico disponible para apoyar una elección, no una garantía sobre la latencia de la siguiente transferencia ni una demostración de que ese camino fuera óptimo.

HIT_OBJ mostraba qué se pierde al saltarse HTTP

ICP_OP_HIT_OBJ llevaba la optimización más lejos: permitía incorporar el objeto directamente a la respuesta ICP y evitar una transacción HTTP adicional. Ese ahorro cambiaba también la frontera de seguridad y validación.

Al no pasar por el procesamiento HTTP habitual, HIT_OBJ eludía controles de autorización HTTP y la validación de antigüedad. Además, el tamaño podía llevar a fragmentación si el mensaje superaba la MTU del trayecto. RFC 2186 no recomendaba esta modalidad y exigía que el solicitante hubiera indicado expresamente que estaba dispuesto a aceptarla.

La recepción parcial tampoco podía hacerse pasar por éxito. Si no se obtenían todos los octetos del objeto anunciado, la respuesta debía degradarse a un HIT normal: todavía había una señal de presencia, pero no un objeto completo recibido mediante ICP.

RFC 2187 añadía el riesgo de falsificación. Una respuesta manipulada podía inducir o impedir la selección de un vecino; en entornos multicast debían ignorarse respuestas de direcciones que no estuvieran configuradas como vecinas. Con HIT_OBJ, la combinación de spoofing y datos transportados directamente ampliaba el daño potencial: una respuesta falsa podía introducir contenido incorrecto en la caché.

La frontera correcta de la evidencia

ICPv2 es más fácil de entender cuando cada señal se mantiene dentro de la pregunta para la que fue diseñada. HIT informa sobre una condición declarada por un vecino en un intercambio concreto. MISS describe ausencia local. MISS_NOFETCH incorpora una restricción operacional. DENIED refleja autorización contextual. RTT resume una medición previa. Eco comprueba eco. Silencio significa que, para esa decisión inmediata, no hay una respuesta aprovechable.

Ninguna de ellas prueba por sí sola autoridad del origen, frescura, validación HTTP, identidad autenticada, recepción completa de bytes, ejecución segura del contenido, superioridad de una fuente, disponibilidad futura, entrega a una aplicación o resultado comercial.

La misma disciplina evita mezclar dominios distintos. ICP no es caché DNS. RFC 2186 tampoco constituye una historia general de las CDN. Y su manera de tratar una ausencia de respuesta UDP pertenece a su propio mecanismo de selección; no es un principio universal aplicable a cualquier protocolo sobre datagramas.

Lo que el documento conserva con especial claridad es una arquitectura de decisiones bajo evidencia incompleta: actuar con una pista suficientemente útil, pero sin inflar esa pista hasta convertirla en una afirmación que el protocolo nunca pudo demostrar.