Almacenamiento en caché
Este documento se aplica a los siguientes métodos:
Acerca del almacenamiento en caché
Para reducir el uso de la banda ancha del cliente y proteger a Google de los aumentos repentinos del tráfico, los clientes de la API de Lookup y la API de Update deben crear y mantener una caché local de datos de amenazas. La API de Lookup usa la caché para reducir la cantidad de solicitudes uris.search que los clientes envían a Google.
En el caso de la API de Update, la caché se usa para reducir la cantidad de solicitudes de hashes.search que los clientes envían a Google. A continuación, se describe el protocolo de almacenamiento en caché para cada API.
API de Lookup
Los clientes de la API de Lookup deben almacenar en caché cada elemento ThreatUrl que se muestra hasta el momento definido en el campo expireTime. Luego, los clientes deben consultar
la caché antes de realizar una solicitud uris.search posterior al servidor. Si la entrada de caché de un ThreatUrl que se mostró anteriormente aún no venció, el cliente debe suponer que el elemento aún no es seguro. La caché de elementos ThreatUrl puede reducir la cantidad de solicitudes a la API que realiza el cliente.
API de Update
Para reducir la cantidad total de solicitudes de hashes.search que se envían a Google con la API de Update, los clientes deben mantener una caché local. La API establece dos tipos de almacenamiento en caché, positivo y negativo.
Almacenamiento en caché positivo
Para evitar que los clientes pregunten de forma reiterada sobre el estado de un hash completo no seguro en particular, cada ThreatHash que se muestra contiene un tiempo de caché positivo (definido por el campo expireTime). El hash completo se puede considerar
inseguro hasta este momento.
Almacenamiento en caché negativo
Para evitar que los clientes pregunten de forma reiterada sobre el estado de un hash completo seguro en particular, la respuesta define una duración de caché negativa para el prefijo solicitado (definido por el campo negativeExpireTime). Todos los valores hash completos con el prefijo solicitado se deben considerar seguros para los tipos de amenazas solicitados hasta este momento, excepto los que el servidor muestra como no seguros.
Esta almacenamiento en caché es particularmente importante, ya que evita la sobrecarga de tráfico que podría causar una colisión de prefijo de hash con una URL segura que recibe mucho tráfico.
Cómo consultar la caché
Cuando el cliente quiere verificar el estado de una URL, primero calcula su hash completo. Si el prefijo del hash completo está presente en la base de datos local, el cliente debe consultar su caché antes de realizar una solicitud hashes.search al servidor.
Primero, los clientes deben verificar si hay un acierto de caché positivo. Si existe una entrada de caché positiva sin vencer para el hash completo de interés, se debe considerar que no es segura. Si la entrada de caché positiva venció, el cliente debe enviar una solicitud hashes.search para el prefijo local asociado. Según el protocolo, si el servidor muestra el hash completo, se considera no seguro; de lo contrario, se considera seguro.
Si no hay entradas de caché positiva para el hash completo, el cliente debe verificar si hay un acierto de caché negativa. Si existe una entrada de caché negativa sin vencer para el prefijo local asociado, el hash completo se considera seguro. Si la entrada de caché negativa venció o no existe, el cliente debe enviar una solicitud hashes.search para el prefijo local asociado y, luego, interpretar la respuesta como normal.
Actualiza la caché
La caché del cliente se debe actualizar cada vez que se recibe una respuesta hashes.search.
Se debe crear o actualizar una entrada de caché positiva para el hash completo según el campo expireTime. La duración de la caché negativa del prefijo de hash también debe crearse o actualizarse según el campo negativeExpireTime de la respuesta.
Si una solicitud hashes.search posterior no muestra un hash completo que actualmente está almacenado en caché de forma positiva, el cliente no tiene que quitar la entrada de caché positiva. Esto no es motivo de preocupación en la práctica, ya que las duraciones de la caché positivas suelen ser cortas (unos minutos) para permitir la corrección rápida de los falsos positivos.
Situación de ejemplo
En el siguiente ejemplo, supongamos que h(url) es el prefijo de hash de la URL y H(url) es el hash de la URL de longitud completa. Es decir, h(url) = SHA256(url).substr(4), H(url) = SHA256(url).
Supongamos que un cliente con una caché vacía visita example.com/ y ve que h(example.com/) está en la base de datos local. El cliente solicita los hash completos para el prefijo hash h(example.com/) y recibe el hash completo H(example.com/) junto con un tiempo de vencimiento de caché positivo de 5 minutos a partir de ahora y un tiempo de vencimiento de caché negativo de 1 hora a partir de ahora.
La duración de caché positiva de 5 minutos le indica al cliente durante cuánto tiempo el hash completo H(ejemplo.com/) debe considerarse no seguro sin enviar otra solicitud hashes.search. Después de 5 minutos, el cliente debe emitir otra solicitud hashes.search para ese prefijo h(example.com/) si vuelve a visitar example.com/. El cliente debe restablecer el tiempo de vencimiento de la caché negativa del prefijo de hash según la respuesta nueva.
La duración de caché negativa de 1 hora le indica al cliente cuánto tiempo todos los demás hash completos, que no son H(ejemplo.com/) y que comparten el mismo prefijo que h(ejemplo.com/), deben considerarse seguros. Durante 1 hora, cada URL como h(URL) = h(example.com/) debe considerarse segura y, por lo tanto, no debe generar una solicitud hashes.search (suponiendo que H(URL) != H(ejemplo.com/)).
Si la respuesta fullHashes contiene cero coincidencias y se establece un tiempo de vencimiento de caché negativa, el cliente no debe emitir ninguna solicitud hashes.search para ninguno de los prefijos solicitados para el tiempo de caché negativa determinado.
Si la respuesta hashes.search contiene una o más coincidencias, se sigue estableciendo un tiempo de vencimiento de caché negativa para toda la respuesta. En ese caso, el tiempo de vencimiento de la caché de un solo hash completo indica durante cuánto tiempo el cliente debe suponer que el hash completo en particular no es seguro. Después de que venza la duración de la caché de ThreatHash, el cliente debe actualizar el hash de longitud completa emitiendo una solicitud hashes.search para ese prefijo hash si la URL solicitada coincide con el hash de longitud completa existente en la caché. En ese caso, no se aplica la duración de la caché negativa. La duración de la caché negativa de la respuesta solo se aplica a los hash de longitud completa que no estaban presentes en la respuesta hashes.search. En el caso de los hashes de longitud completa que no están presentes en la respuesta, el cliente debe abstenerse de emitir solicitudes hashes.search hasta que transcurra la duración de la caché negativa.