Almacenar en caché
Este documento se aplica a los siguientes métodos:
Acerca del 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 de 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 a fin de reducir la cantidad 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 de Lookup
Los clientes de la API de Lookup deben almacenar en caché cada elemento ThreatUrl que se muestre hasta la hora definida 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 mostró anteriormente aún no ha vencido, el cliente debe suponer que el elemento aún no es seguro. El almacenamiento en caché de los elementos de 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 mediante la API de actualización, 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 de caché negativa para el prefijo solicitado (definido por el campo negativeExpireTime). , Todos los hash completos con el prefijo solicitado deben considerarse seguros para los tipos de amenazas solicitados hasta este momento, excepto aquellos que el servidor muestra como no seguros.
Este almacenamiento en caché es muy importante porque evita la sobrecarga de tráfico que podría deberse a una colisión de prefijo de hash con una URL segura que recibe mucho tráfico.
Consulta la caché
Cuando el cliente desea verificar el estado de una URL, primero calcula su hash completo. Si el prefijo de 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 verificar si hay un acierto de caché positivo. Si existe una entrada de caché positiva no vencida para el hash completo de interés, se debe considerar no segura. Si la entrada de caché positiva 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 lo 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 por el campo expireTime. La duración de caché negativa del prefijo de hash también debe crearse o actualizarse de acuerdo con el campo negativeExpireTime de la respuesta.
Si una solicitud hashes.search posterior no muestra un hash completo que se almacena en caché de forma positiva, el cliente no tiene la obligación de 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 (unos minutos) para permitir la corrección rápida de 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 completo de la URL. Es decir, h(url) =SHA256(url).substr(4), H(url) = SHA256(url).
Supongamos que un cliente que tiene una caché vacía visita example.com/ y ve que h(example.com/) se encuentra 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 de longitud completa H(example.com/) junto con un tiempo de vencimiento de caché positivo de 5 minutos. ahora y un tiempo de caducidad negativo de 1 hora a partir de ahora.
La duración de caché positiva de 5 minutos le indica al cliente cuánto tiempo debe considerarse el hash completo H(example.com/) como 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 de hash por cada 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 de 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 cuánto tiempo el cliente debe asumir que el hash completo en particular no es seguro. Una vez transcurrido el período de almacenamiento en caché de ThreatHash, el cliente debe actualizar el hash de longitud completa mediante una solicitud hashes.search para ese prefijo de hash si la URL solicitada coincide con la longitud completa existente. hash en la caché. En ese caso, no se aplica la duración de caché negativa. La duración de caché negativa de la respuesta solo se aplica a los hashes de longitud completa que no estaban presentes en la respuesta hashes.search. Para los hashes de larga duración que no están presentes en la respuesta, el cliente debe abstenerse de emitir solicitudes hashes.search hasta que transcurra la duración de caché negativa.