Almacenamiento en caché

Este documento se aplica a los siguientes métodos:

• API de Lookup (v4): threatMatches.find
• API de Update (v4): fullHashes.find

Acerca del almacenamiento en caché

Para reducir el uso del ancho de banda del cliente y proteger a Google de los aumentos repentinos de tráfico, los clientes de La API de Lookup y la API de Update son necesarias para crear y mantener una caché local de datos de amenazas. En el caso de la API de Lookup, se usa la caché para reducir la cantidad de threatMatches. que los clientes envían a Google. Para la API de Update, la caché se usa para reducir la cantidad de Solicitudes de fullHashes que los clientes envían a Google. El protocolo de almacenamiento en caché para cada API que se describen a continuación.

API de Lookup

Los clientes de la API de Lookup deben almacenar en caché cada elemento ThreatMatch devuelto durante el tiempo definido según su campo cacheDuration. Los clientes deben consultar la caché antes de hacer una threatMatches al servidor Si la duración de la caché para un ThreatMatch que se mostró anteriormente aún no venció, el cliente debe asumir que el elemento sigue siendo inseguro. Almacenando en caché ThreatMatch elemento puede reducir la cantidad de solicitudes a la API que realiza el cliente.

Ejemplo: ThreatMatches.find

Haz clic en los vínculos de solicitud y respuesta que se encuentran en el encabezado de la tabla para ver ejemplos completos.

"threatEntries": [
 {"url": "http://www.urltocheck.org/"}
]

"matches": [{
 "threat": {"url": "http://www.urltocheck.org/"},
 "cacheDuration": "300.000s"
}]

API de Update

Para reducir la cantidad total de solicitudes fullHashes enviadas a Google con la API de Update, los clientes necesarios para mantener una caché local. La API establece dos tipos de almacenamiento en caché: el positivo y el negativo.

Almacenamiento en caché positivo

Para evitar que los clientes pregunten varias veces sobre el estado de un hash completo no seguro específico, haz lo siguiente: Cada ThreatMatch que se muestra contiene una duración de caché positiva (definida por el campo cacheDuration). que indica cuánto tiempo se considerará que el hash completo no es seguro.

Almacenamiento en caché negativo

Para evitar que los clientes pregunten varias veces sobre el estado de un hash completo seguro específico, haz lo siguiente: Cada respuesta fullHashes define una duración negativa de caché para el prefijo solicitado (definido por el negativeCacheDuration). Esta duración indica por cuánto tiempo se generan todos los hashes prefijo se consideran seguras para las listas solicitadas, excepto aquellas devueltas por el servidor como no seguro. Este almacenamiento en caché es particularmente importante, ya que previene la sobrecarga de tráfico que podría causarse. por una colisión de prefijo de hash con una URL segura que reciba mucho tráfico.

Consulta la caché

Cuando el cliente quiere verificar el estado de una URL, primero calcula su hash completo. Si la columna hash está presente en la base de datos local, el cliente debe consultar su caché antes realiza una solicitud fullHashes al servidor.

En primer lugar, los clientes deben verificar si hay un acierto de caché positivo. Si hay una caché positiva no vencida para el hash completo de interés, se debe considerar no segura. Si la entrada de caché positiva vencido, el cliente debe enviar una solicitud fullHashes para el prefijo local asociado. Según las si el servidor devuelve el hash completo, se considera no seguro. De lo contrario, se considera la seguridad de los recursos aprovisionados.

Si no hay entradas de caché positivas para el hash completo, el cliente debe verificar si hay un valor negativo. acierto de caché. 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 Debes enviar una solicitud fullHashes 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 de fullHashes. Una caché positiva una entrada debe crearse o actualizarse para el hash completo según el campo cacheDuration. El prefijo de hash La duración negativa de la caché también debe crearse o actualizarse según el negativeCacheDuration de la respuesta. .

Si una solicitud fullHashes posterior no muestra un hash completo que, por el momento, esté de forma positiva almacenada en caché, el cliente no necesita quitar la entrada de caché positiva. Esto no es motivo de preocupación. dado que las duraciones positivas de la caché suelen ser cortas (unos minutos) para permitir una la corrección 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 completo de la URL. Es decir, h(url) = SHA256(url).substr(4), H(url) = SHA256(url).

Ahora, supongamos que un cliente (con una caché vacía) visita example.com/ y ve que h(example.com/) es en la base de datos local. El cliente solicita los hashes completos para el prefijo de hash h(example.com/). y vuelve a recibir el hash completo H(example.com/) junto con una duración de caché positiva de 5. minutos y una duración negativa de caché de 1 hora.

La duración positiva de la caché de 5 minutos le indica al cliente por cuánto tiempo el hash completo H(example.com/) debe considerarse no seguro sin enviar otra solicitud fullHashes. Después de las 5 minutos, el cliente debe emitir otra solicitud fullHashes para ese prefijo h(example.com/) si el el cliente visita example.com/ nuevamente. El cliente debe restablecer la duración de la caché negativa del prefijo hash según la respuesta nueva.

La duración de la caché negativa de 1 hora le indica al cliente la duración de todos los demás hashes completos. además de H(example.com/), que comparten el mismo prefijo de h(example.com/), deben considerarse seguras. Para la duración de 1 hora, cada URL cuya condición sea h(URL) = h(example.com/) debe considerarse segura por lo tanto, no se generará una solicitud de fullHashes (suponiendo que H(URL) != H(example.com/)).

Si la respuesta fullHashes contiene cero coincidencias y se establece una duración negativa de la caché, el valor el cliente no debe emitir ninguna solicitud fullHashes para ninguno de los prefijos solicitados para el duración de caché negativa.

Si la respuesta fullHashes contiene una o más coincidencias, se establecerá una duración negativa de la caché. para toda la respuesta. En ese caso, la duración de la caché de un solo hash completo indica ese hash completo en particular debe considerarse no seguro por el cliente. Después de almacenar la caché ThreatMatch transcurra, el cliente debe actualizar el hash completo mediante la emisión de una solicitud fullHashes para el prefijo de hash si la URL solicitada coincide con el hash de longitud completo existente en la caché. En ese en caso de que no se aplique la duración negativa de la caché. La duración de la caché negativa de la respuesta solo se aplica a hashes completos que no estaban presentes en la respuesta de fullHashes. Para hashes completos que no están presentes en la respuesta, el cliente debe abstenerse de emitir solicitudes fullHashes hasta que finalice la duración negativa de la caché.

Ejemplo: fullHashes.find

Haz clic en los vínculos de solicitud y respuesta que se encuentran en el encabezado de la tabla para ver ejemplos completos.

"threatEntries": [
  {"hash": "0xaaaaaaaa"}
]

"matches": [],
"negativeCacheDuration": "3600.000s"

"threatEntries": [
  {"hash": "0xbbbbbbbb"}
]

"matches": [
 "threat": {"hash": "0xbbbbbbbb0000..."}
 "cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"

"threatEntries": [
  {"hash": "0xcccccccc"}
]

"matches": [
 "threat": {"hash": "0xccccccccdddd..."},
 "cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"