Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Almacenamiento en caché

Este documento se aplica a los siguientes métodos:

Información sobre el almacenamiento en caché

A fin de reducir el uso del ancho de banda del cliente y proteger a Google de los picos de tráfico, se requiere que los clientes de la API de Lookup y la API de Update creen y mantengan 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 del cliente que hashes.search 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 búsqueda deben almacenar en caché cada elemento ThreatUrl que se muestre 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é para un ThreatUrl que se muestra previamente no ha expirado, el cliente debe asumir que el elemento sigue siendo inseguro. Si almacenas en caché los elementos ThreatUrl, es posible que se reduzca la cantidad de solicitudes a la API que envió el cliente.

API de Update

Para reducir la cantidad total de solicitudes hashes.search enviadas a Google mediante la API de Update, los clientes deben mantener una caché local. La API establece dos tipos de almacenamiento en caché: positivos y negativos.

Almacenamiento en caché positivo

Para evitar que los clientes pregunten reiteradamente sobre el estado de un hash completo no seguro, cada ThreatHash que se muestra contiene un tiempo de caché positivo (definido por el campo expireTime) para crear el adjunto de VLAN de supervisión. El hash completo se puede considerar no seguro hasta este momento.

Almacenamiento en caché negativo

Para evitar que los clientes soliciten repetidamente el estado de un hash completo seguro, la respuesta define una duración de caché negativa para el prefijo solicitado (definido por el campo negativeExpireTime). para crear el adjunto de VLAN de supervisión. Todos los hash completos con el prefijo solicitado se consideran seguros para los tipos de amenazas solicitadas hasta este momento, excepto aquellos que el servidor muestra como no seguros. Este almacenamiento en caché es particularmente importante, ya que evita la sobrecarga de tráfico que podría deberse a una colisión de prefijo hash con una URL segura que recibe una gran cantidad de tráfico.

Consulta la caché

Cuando el cliente desea 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.

En primer lugar, los clientes deben comprobar si hay un acierto de caché positivo. Si existe una entrada de caché positiva sin caducidad para el hash completo de interés, se la debe considerar no segura. Si la entrada positiva de la caché caducó, 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 siempre que se reciba una respuesta hashes.search. Debe crearse 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 está almacenado en caché de manera positiva, el cliente no necesita quitar 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 (en unos 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 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 hash completos para el prefijo de hash h(example.com/) y recibe el hash de longitud completa H(example.com/) junto con un tiempo de caché positivo de 5 minutos. y una caché negativa vence el tiempo de 1 hora.

La duración positiva de la caché de 5 minutos le indica al cliente cuánto tiempo el hash completo de 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/ de nuevo. 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, aún se establece un tiempo de vencimiento de la caché negativa para toda la respuesta. En ese caso, el tiempo de vencimiento de la caché de un hash completo único indica que el cliente debe asumir que el hash de longitud completa no es seguro. Después de que venza la duración de la caché ThreatHash, el cliente debe actualizar el hash completo a fin de emitir una solicitud hashes.search para ese prefijo de hash si la URL solicitada coincide con la longitud completa existente. hash en la caché. En este 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 evitar emitir cualquier solicitud hashes.search hasta que se agote la duración negativa de la caché.