Cache Response Rules: Control de Caching Post-Origen en CDNs

La eficiencia de una Content Delivery Network (CDN) depende críticamente de la correcta interacción entre el servidor de origen y el caché de borde. Un problema fundamental en la computación distribuida es cómo desacoplar las decisiones de caching del origen cuando este, por diseño o configuración, emite respuestas que impiden un caching óptimo. Tradicionalmente, las decisiones de caché se toman en la fase de solicitud, basándose en la URL, headers de solicitud, etc. Sin embargo, muchos factores que determinan la cacheabilidad de un recurso (como la presencia de un Set-Cookie o directivas Cache-Control inapropiadas) solo se manifiestan en la fase de respuesta, después de que el origen ha sido contactado. Esto lleva a un 'cache hit ratio' subóptimo, aumentando la latencia y los costos de infraestructura del origen.

Cache Response Rules abordan este problema introduciendo una fase de procesamiento de respuesta en la CDN, permitiendo la manipulación de headers y directivas de caché antes de que el contenido sea almacenado. Esto permite a los operadores de CDN corregir comportamientos de origen sin modificar el código o la configuración del servidor, desacoplando efectivamente la lógica de caching del origen y mejorando la eficiencia general del sistema de entrega de contenido. Este enfoque es crucial en arquitecturas de microservicios o sistemas heredados donde el control sobre las respuestas del origen puede ser limitado o costoso de modificar.

Arquitectura del Sistema

El sistema de caching de Cloudflare opera en dos fases principales: la fase de solicitud y la fase de respuesta. Las Cache Rules existentes operan en la fase de solicitud, decidiendo si se debe buscar en caché y bajo qué clave de caché, antes de contactar al origen. Estas reglas utilizan parámetros de la solicitud (URL, headers de solicitud, geografía, etc.) para determinar la elegibilidad y la estrategia de caching (TTL de borde, TTL de navegador, etc.).

Cache Response Rules introducen una nueva etapa en la fase de respuesta. Se ejecutan después de que la respuesta del servidor de origen llega a Cloudflare, pero antes de que el contenido sea escrito en el caché de la CDN. Estas reglas pueden realizar tres tipos de acciones principales: 1) 'Strip headers' (eliminar headers como Set-Cookie, ETag, Last-Modified) para hacer que un recurso sea cacheable o para evitar 'revalidation thrash'. 2) 'Manage cache tags' (añadir, eliminar o establecer tags de caché) para facilitar la purga por tag, incluso traduciendo formatos de 'Surrogate-Keys' de otros CDNs. 3) 'Modify Cache-Control directives' (establecer o eliminar directivas como max-age, s-maxage, no-cache, no-store), con la opción 'cloudflare_only: true' para aplicar la directiva solo al caché de Cloudflare, dejando la directiva para el navegador inalterada. La implementación de estas reglas se realiza a través de un 'ruleset' configurable vía dashboard o API, que se evalúa sobre los headers de respuesta HTTP. Cuando hay un conflicto entre una Cache Rule y una Cache Response Rule, esta última tiene precedencia, actuando como el 'final word' sobre cómo y si se cachea un objeto.

{
  "expression": "http.request.uri.path.extension in {\"js\" \"css\" \"woff2\" \"woff\" \"ttf\" \"png\" \"jpg\" \"svg\"}",
  "action": "set_cache_settings",
  "action_parameters": {
    "strip_set_cookie": true
  }
}

{
  "expression": "http.request.uri.path.extension in {\"js\" \"css\" \"woff2\"}",
  "action": "set_cache_control",
  "action_parameters": {
    "s-maxage": {
      "operation": "set",
      "value": 2592000,
      "cloudflare_only": true
    },
    "immutable": {
      "operation": "set"
    },
    "max-age": {
      "operation": "set",
      "value": 86400,
      "cloudflare_only": false
    }
  }
}

Fundamentos Teóricos

El problema de la coherencia y eficiencia del caché en sistemas distribuidos ha sido un tema central en la investigación de sistemas desde los primeros días de la World Wide Web. Principios como la 'coherencia débil' y la 'eventual consistencia' son relevantes, ya que las CDNs operan bajo estas premisas para maximizar la disponibilidad y el rendimiento a expensas de una consistencia estricta. La manipulación de headers de respuesta para influir en el comportamiento del caché se alinea con el concepto de 'cache invalidation' y 'cache validation' que se discute en trabajos fundamentales sobre sistemas de archivos distribuidos y bases de datos. Aunque no hay un paper único que prediga directamente las 'Cache Response Rules', el concepto de 'proxy caching' y la necesidad de 'cache control mechanisms' se exploran en trabajos como 'Harvest: A Scalable System for Internet Cache' de Michael Bowman et al. (1995), que sentó las bases para la arquitectura de los proxies web y CDNs. La capacidad de modificar el comportamiento de caching en el borde, desacoplado del origen, es una evolución práctica de estos principios, adaptándose a las complejidades de las aplicaciones web modernas y la necesidad de un control granular sobre la política de caché.