Almacenamiento en caché

Este documento se aplica a los siguientes métodos:

• API de Lookup: uris.search
• API de Update: hashes.search

Acerca del almacenamiento en caché

Para reducir el uso del ancho de banda del cliente y proteger a Google de los aumentos de 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. Para la API de Update, la caché se usa para reducir la cantidad de solicitudes hashes.search que los clientes envían a Google. El protocolo de almacenamiento en caché para cada API se describe a continuación.

API de Lookup

Los clientes de la API de Lookup deben almacenar en caché cada elemento ThreatUrl que 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 objeto ThreatUrl que se mostró anteriormente todavía no venció, el cliente debe suponer que el elemento todavía no es seguro. Almacenar en caché 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 hashes.search enviadas 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 repetidamente 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 puede considerarse no seguro hasta este momento.

Almacenamiento en caché negativo

Para evitar que los clientes pregunten repetidamente sobre el estado de un hash completo seguro en particular, la respuesta define una duración negativa de la caché para el prefijo solicitado (definido por el campo negativeExpireTime). Hasta este momento, todos los hashes completos con el prefijo solicitado se consideran seguros para los tipos de amenazas solicitados, excepto los que el servidor muestre como no seguros. Este almacenamiento en caché es muy importante, ya que evita la sobrecarga de tráfico que podría deberse a una colisión de prefijos de hash con una URL segura que recibe mucho tráfico.

Consulta 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 comprobar si hay un acierto de caché positivo. Si existe una entrada de caché positiva sin vencer para el hash de interés completo, debe considerarse no 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 debe actualizarse 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 negativa de la caché negativa del prefijo de hash también se debe crear o actualizar según el campo negativeExpireTime de la respuesta.

Si una solicitud hashes.search posterior no muestra un hash completo que en este momento esté almacenado en caché de forma positiva, no es necesario que el cliente quite la entrada de caché positiva. Esto no es motivo de preocupación en la práctica, ya que las duraciones positivas de la caché suelen ser cortas (algunos minutos) para permitir una 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 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 para el prefijo de hash h(example.com/) y recibe el hash completo 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 negativo de 1 hora a partir de este momento.

La duración positiva de la caché de 5 minutos le indica al cliente por cuánto tiempo el hash de longitud completa H(example.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 el cliente visita example.com/ nuevamente. El cliente debe restablecer el tiempo de vencimiento de la caché negativa del prefijo 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 establece 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 durante cuánto tiempo el cliente debe asumir que el hash de longitud completa en particular no es seguro. Una vez transcurrido la duración de la caché ThreatHash, el cliente debe actualizar el hash completo mediante la emisión de una solicitud hashes.search para ese prefijo de 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 negativa de la caché. La duración negativa de la caché 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 debe abstenerse de emitir solicitudes hashes.search hasta que transcurra la duración negativa de la caché.