Almacenamiento en caché

Este documento se aplica a los siguientes métodos:

Acerca del almacenamiento en caché

Para reducir el uso de ancho de banda del cliente y proteger a Google de los picos de tráfico, los clientes de la API Lookup y de la API Update deben crear y mantener una caché local de datos de amenazas. La API Lookup usa la caché para reducir el número de solicitudes uris.search que los clientes envían a Google. En el caso de la API Update, la caché se usa para reducir el número de solicitudes hashes.search que los clientes envían a Google. A continuación, se describe el protocolo de almacenamiento en caché de cada API.

API Lookup

Los clientes de la API Lookup deben almacenar en caché cada elemento ThreatUrl devuelto hasta la hora definida en el campo expireTime. A continuación, los clientes deben consultar la caché antes de hacer una solicitud uris.search al servidor. Si la entrada de caché de un ThreatUrl devuelto anteriormente aún no ha caducado, el cliente debe asumir que el elemento sigue siendo no seguro. Almacenar en caché ThreatUrl elementos puede reducir el número de solicitudes a la API que realiza el cliente.

API Update

Para reducir el número total de solicitudes hashes.search enviadas a Google mediante la API 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 repetidamente sobre el estado de un hash completo no seguro concreto, cada ThreatHash devuelto contiene un tiempo de caché positivo (definido por el campo expireTime). El hash completo se puede considerar no seguro hasta ese momento.

Almacenamiento en caché negativo

Para evitar que los clientes pregunten repetidamente sobre el estado de un hash completo seguro concreto, la respuesta define una duración de caché negativa para el prefijo solicitado (definido por el campo negativeExpireTime). Todos los hashes completos con el prefijo solicitado se considerarán seguros para los tipos de amenazas solicitados hasta esta hora, excepto los que el servidor haya devuelto como no seguros. Este almacenamiento en caché es especialmente importante, ya que evita la sobrecarga de tráfico que podría provocar una colisión de prefijos de hash con una URL segura que recibe mucho tráfico.

Consultar la caché

Cuando el cliente quiere comprobar 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 hacer una solicitud hashes.search al servidor.

En primer lugar, los clientes deben comprobar si se ha encontrado una coincidencia en la caché. Si existe una entrada de caché positiva no caducada para el hash completo de interés, se debe considerar no segura. Si la entrada de caché positiva ha caducado, el cliente debe enviar una solicitud hashes.search para el prefijo local asociado. Según el protocolo, si el servidor devuelve el hash completo, se considera que no es seguro. De lo contrario, se considera seguro.

Si no hay entradas de caché positivas para el hash completo, el cliente debe comprobar si hay un acierto de caché negativo. Si existe una entrada de caché negativa no caducada para el prefijo local asociado, el hash completo se considera seguro. Si la entrada de caché negativa ha caducado o no existe, el cliente debe enviar una solicitud hashes.search para el prefijo local asociado e interpretar la respuesta de forma normal.

Actualizar la caché

La caché del cliente debe actualizarse cada vez que se reciba 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 hash también debe crearse o actualizarse según el campo negativeExpireTime de la respuesta.

Si una solicitud hashes.search posterior no devuelve un hash completo que esté almacenado en caché de forma positiva, el cliente no tiene que quitar la entrada de caché positiva. En la práctica, no hay motivo para preocuparse, ya que las duraciones positivas de la caché suelen ser cortas (unos minutos) para permitir una corrección rápida de los falsos positivos.

Caso de ejemplo

En el siguiente ejemplo, supongamos que h(url) es el prefijo hash de la URL y H(url) es el hash de longitud completa de la URL. 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 hashes de longitud completa del prefijo de hash h(example.com/) y recibe el hash de longitud completa H(example.com/) junto con un tiempo de vencimiento de la caché positivo de 5 minutos a partir de ahora y un tiempo de vencimiento de la caché negativo de 1 hora a partir de ahora.

La duración positiva de la caché de 5 minutos indica al cliente cuánto tiempo se debe considerar que el hash de longitud completa H(example.com/) no es seguro sin enviar otra solicitud hashes.search. Al cabo de 5 minutos, el cliente debe enviar 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 hash según la nueva respuesta.

La duración de la caché negativa de una hora indica al cliente durante cuánto tiempo se deben considerar seguros todos los demás hashes de longitud completa, además de H(example.com/), que comparten el mismo prefijo de h(example.com/). Durante una hora, todas las URLs para las que h(URL) = h(example.com/) deben considerarse seguras y, por lo tanto, no deben dar lugar a una solicitud hashes.search (suponiendo que H(URL) != H(example.com/)).

Si la respuesta fullHashes contiene cero coincidencias y se ha definido un tiempo de vencimiento de caché negativo, el cliente no debe enviar ninguna solicitud hashes.search para ninguno de los prefijos solicitados durante el tiempo de caché negativo indicado.

Si la respuesta hashes.search contiene una o varias coincidencias, se sigue definiendo un tiempo de vencimiento de la caché negativo para toda la respuesta. En ese caso, el tiempo de vencimiento de la caché de un solo hash completo indica cuánto tiempo debe asumir el cliente que el hash de longitud completa concreto no es seguro. Una vez que haya transcurrido la ThreatHash duración de la caché, el cliente debe actualizar el hash de longitud completa enviando una solicitud hashes.search para ese prefijo de hash si la URL solicitada coincide con el hash de longitud completa de 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 hashes 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 no debe enviar ninguna solicitud de hashes.search hasta que haya transcurrido el periodo de duración de la caché negativa.