Memorizzazione nella cache

Questo documento si applica ai seguenti metodi:

Informazioni sulla memorizzazione nella cache

Per ridurre l'utilizzo della larghezza di banda dei client e per proteggere Google da picchi di traffico, i client di L’API Lookup e l’API Update sono necessarie per creare e gestire una cache locale dei dati sulle minacce. Per l'API Lookup, la cache viene utilizzata per ridurre il numero di threatMatches richieste che i client inviano a Google. Per l'API Update, la cache viene utilizzata per ridurre il numero di fullHashes richiede che i client inviino a Google. Il protocollo di memorizzazione nella cache per ogni API descritti di seguito.

API Lookup

I client dell'API Lookup devono memorizzare nella cache ogni elemento ThreatMatch restituito per il periodo di tempo definito. in base al campo cacheDuration. I client devono poi consultare la cache prima di eseguire una Richiesta threatMatches al server. Se la durata della cache per un valore ThreatMatch restituito in precedenza non è ancora scaduto, il client dovrebbe presumere che l'elemento non sia ancora sicuro. Memorizzazione nella cache di ThreatMatch elementi in corso... potrebbe ridurre il numero di richieste API effettuate dal client.

Esempio: threatMatches.find

Fai clic sui link di richiesta e risposta nell'intestazione della tabella per esempi completi.

Controllo URL
Richiesta per ThreatMatch
Corrispondenza URL
risposta athreatMatch
Comportamento memorizzazione nella cache
"threatEntries": [
 {"url": "http://www.urltocheck.org/"}
]
"matches": [{
 "threat": {"url": "http://www.urltocheck.org/"},
 "cacheDuration": "300.000s"
}]
Corrispondenza.
Il client deve attendere 5 minuti prima di inviare una nuova richiesta threatMatches che include URL http://www.urltocheck.org/.

Aggiorna l'API

Per ridurre il numero complessivo di richieste fullHashes inviate a Google utilizzando l'API Update, i client per mantenere una cache locale. L'API stabilisce due tipi di memorizzazione nella cache: positiva e negativa.

Memorizzazione nella cache positiva

Per evitare che i clienti chiedano ripetutamente informazioni sullo stato di un determinato hash completo non sicuro, ogni ThreatMatch restituito contiene una durata positiva della cache (definita dal campo cacheDuration), che indica per quanto tempo l'hash completo deve essere considerato non sicuro.

Memorizzazione nella cache negativa

Per evitare che i clienti chiedano ripetutamente informazioni sullo stato di un determinato hash completo sicuro, ogni risposta fullHashes definisce una durata negativa della cache per il prefisso richiesto (definito negativeCacheDuration). Questa durata indica per quanto tempo tutti gli hash completi con la richiesta devono essere considerati sicuri per gli elenchi richiesti, ad eccezione di quelli restituiti dal server come non sicuri. Questa memorizzazione nella cache è particolarmente importante in quanto impedisce il sovraccarico del traffico che potrebbe essere causato da una collisione di prefisso hash con un URL sicuro che riceve molto traffico.

Consultazione della cache

Quando il client desidera controllare lo stato di un URL, prima calcola il suo hash completo. Se l'intero di hash sia presente nel database locale, il client deve quindi consultare la propria cache prima inviando una richiesta fullHashes al server.

Innanzitutto, i client dovrebbero verificare la presenza di un successo positivo della cache. Se esiste una cache positiva non scaduta per l'hash completo di interesse, dovrebbe essere considerato non sicuro. Se la voce positiva della cache è scaduto, il client deve inviare una richiesta fullHashes per il prefisso locale associato. In base alle non sicuro, se il server restituisce l'hash completo. altrimenti viene considerato in tutta sicurezza.

Se non sono presenti voci di cache positive per l'hash completo, il client deve verificare la presenza di un valore negativo un successo della cache. Se è presente una voce negativa della cache non scaduta per il prefisso locale associato, l'hash completo è considerato sicuro. Se la voce negativa della cache è scaduta o non esiste, il client deve inviare una richiesta fullHashes per il prefisso locale associato e interpretare la risposta come di consueto.

Aggiornamento della cache in corso...

La cache del client deve essere aggiornata ogni volta che si riceve una risposta fullHashes. Una cache positiva deve essere creata o aggiornata per l'hash completo in base al campo cacheDuration. Il valore del prefisso hash la durata negativa della cache deve essere creata o aggiornata anche in base al valore negativeCacheDuration della risposta .

Se una richiesta fullHashes successiva non restituisce un hash completo al momento positivo memorizzato nella cache, non è necessario che il client rimuova la voce positiva della cache. Non c'è motivo di preoccuparsi In pratica, poiché le durate positive della cache sono in genere brevi (alcuni minuti) per consentire la correzione dei falsi positivi.

Scenario di esempio

Nell'esempio seguente, supponiamo che h(url) sia il prefisso hash dell'URL e che H(url) sia il hash completo dell'URL. In altre parole, h(url) = SHA256(url).substr(4), H(url) = SHA256(url).

Ora, supponiamo che un client (con la cache vuota) visiti example.com/ e veda che h(example.com/) è nel database locale. Il client richiede gli hash completi per il prefisso hash h(example.com/) e riceve l'hash a lunghezza intera H(example.com/) insieme a una durata della cache positiva pari a 5 minuti e una durata della cache negativa di 1 ora.

La durata positiva della cache di 5 minuti indica al client per quanto tempo l'hash a lunghezza intera H(example.com/) deve essere considerato non sicuro senza inviare un'altra richiesta fullHashes. Dopo le 5 minuti in cui il client deve inviare un'altra richiesta fullHashes per quel prefisso h(example.com/) se il cliente visita di nuovo example.com/. Il client deve reimpostare la durata negativa della cache del prefisso hash in base alla nuova risposta.

La durata della cache negativa di un'ora indica al client per quanto tempo tutti gli altri hash completi oltre a H(example.com/) che condividono lo stesso prefisso di h(example.com/) devono essere considerati sicuri. Per per un'ora, ogni URL in modo tale che h(URL) = h(example.com/) sia considerato sicuro; e pertanto non genererà una richiesta fullHashes (supponendo che H(URL) != H(example.com/)).

Se la risposta fullHashes non contiene zero corrispondenze ed è impostata una durata della cache negativa, la il client non deve inviare richieste fullHashes per nessuno dei prefissi richiesti una durata negativa della cache.

Se la risposta fullHashes contiene una o più corrispondenze, è comunque impostata una durata negativa della cache per l'intera risposta. In questo caso, la durata della cache di un singolo hash completo indica per quanto tempo quel particolare hash a lunghezza intera deve essere considerato non sicuro dal client. Dopo la memorizzazione nella cache di ThreatMatch una volta trascorso il tempo, il client deve aggiornare l'hash a lunghezza intera inviando una richiesta fullHashes per quel prefisso hash se l'URL richiesto corrisponde all'hash a lunghezza intera esistente nella cache. In questo se la durata negativa della cache non è applicabile. La durata della cache negativa della risposta si applica solo agli hash completi non presenti nella risposta fullHashes. Per gli hash completi che non sono presenti nella risposta, il cliente deve evitare di inviare richieste fullHashes fino a quando non sarà trascorsa la durata della cache negativa.

Esempio: fullHashes.find

Fai clic sui link di richiesta e risposta nell'intestazione della tabella per esempi completi.

Prefissi hash
Richiesta fullHashes
Corrisponde all'hash completo
Risposta fullHashes
Comportamento memorizzazione nella cache
"threatEntries": [
  {"hash": "0xaaaaaaaa"}
]
"matches": [],
"negativeCacheDuration": "3600.000s"
Nessuna corrispondenza.
Il client non deve inviare richieste fullHashes per il prefisso hash 0xaaaaaaaa per almeno un'ora. Qualsiasi hash con prefisso 0xaaaaaaaa è considerato sicuro per un'ora.
"threatEntries": [
  {"hash": "0xbbbbbbbb"}
]
"matches": [
 "threat": {"hash": "0xbbbbbbbb0000..."}
 "cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"
Possibili corrispondenze.
Il client dovrebbe considerare non sicuro l'URL con l'hash completo 0xbbbbbbbb0000... per 10 minuti. La considerare come sicuri per 5 minuti tutti gli altri URL con prefisso hash 0xbbbbbbbb. Dopo le 5 minuti, la voce di cache negativa dei prefissi hash scadrà. Poiché la voce positiva della cache per 0xbbbbbbbb0000... non è ancora scaduto, il client deve inviare fullHashes richieste per tutti gli hash tranne questo.
"threatEntries": [
  {"hash": "0xcccccccc"}
]
"matches": [
 "threat": {"hash": "0xccccccccdddd..."},
 "cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"
Possibili corrispondenze.
Il client non deve inviare alcuna richiesta fullHashes per il prefisso hash 0xCcCCC per almeno 1 ora e presupporre quel prefisso per essere sicuro, tranne nel caso in cui l'hash completo dell'URL corrisponda all'hash completo memorizzato nella cache 0xCcCCCdddd... In questo caso, il client dovrebbe considerare l'URL non sicuro per 10 minuti. Dopo 10 minuti, l'hash completo scade. Eventuali ricerche successive dell'hash completo attivare una nuova richiesta fullHashes.