Memorizzazione nella cache
Questo documento si applica ai seguenti metodi:
Informazioni sulla memorizzazione nella cache
Per ridurre l'utilizzo della larghezza di banda client e proteggere Google da picchi di traffico, i client dell'API Lookup e dell'API Update sono necessari per creare e mantenere una cache locale di dati sulle minacce. L'API Lookup utilizza la cache
per ridurre il numero di richieste uris.search
inviate dai client a Google.
Per l'API Update, la cache viene utilizzata per ridurre il numero di
hashes.search
richieste inviate ai client da Google. Di seguito è riportato il protocollo di memorizzazione nella cache per ogni API.
API Lookup
I client dell'API Lookup devono memorizzare ogni elemento ThreatUrl
restituito fino al
tempo definito nel campo expireTime
. I client devono consultare la cache prima di inviare una richiesta uris.search
successiva al server. Se
la voce memorizzata nella cache di un elemento ThreatUrl
restituito in precedenza non è ancora scaduta,
il client dovrebbe presumere che l'elemento sia ancora non sicuro. Memorizzare nella cache ThreatUrl
elementi
può ridurre il numero di richieste API effettuate dal client.
API Update
Per ridurre il numero complessivo di richieste hashes.search
inviate a Google utilizzando l'API
Update, i client devono mantenere una cache locale. L'API determina due tipi di memorizzazione nella cache: positiva e negativa.
Memorizzazione nella cache positiva
Per evitare che i client chiedano ripetutamente di conoscere lo stato di un determinato hash completo non sicuro, ogni ThreatHash
restituito contiene un tempo di cache positivo (definito dal campo expireTime
). Fino a questo momento l'hash completo potrebbe essere considerato non sicuro.
Memorizzazione nella cache negativa
Per evitare che i client chiedano ripetutamente di conoscere lo stato di un determinato hash completo sicuro, la risposta definisce una durata della cache negativa per il prefisso richiesto (definito dal campo negativeExpireTime
). Tutti gli hash completi con il prefisso richiesto sono considerati sicuri per i tipi di minacce richiesti fino a questo momento, 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 del prefisso hash con un URL sicuro che riceve molto traffico.
Consultazione della cache
Quando il client vuole verificare lo stato di un URL, prima calcola l'hash completo. Se nel database locale è presente il prefisso hash completo, il client deve consultare la sua cache prima di inviare una richiesta hashes.search
al server.
Innanzitutto, i client devono verificare la presenza di un hit cache positivo. Se esiste una voce positiva della cache per l'hash completo di questo interesse, deve essere considerata non sicura. Se la voce della cache positiva è scaduta, il client deve inviare una richiesta hashes.search
per il prefisso locale associato. In base al protocollo, se il server restituisce l'hash completo, questo viene considerato non sicuro, altrimenti viene considerato sicuro.
Se non sono presenti voci di cache positive per l'hash completo, il client deve verificare la presenza di un hit cache negativo. Se esiste una voce di cache esclusa illimitata per il prefisso locale associato, l'hash completo è considerato sicuro. Se la voce della cache negativa è scaduta o non esiste, il client deve inviare una richiesta hashes.search
per il prefisso locale associato e interpretare la risposta normalmente.
Aggiornamento della cache in corso...
La cache del client deve essere aggiornata ogni volta che viene ricevuta una risposta hashes.search
.
Deve essere creata o aggiornata una voce della cache positiva per l'hash completo del campo expireTime
. Anche la durata della cache negativa del prefisso hash deve essere creata o aggiornata in base al campo negativeExpireTime
della risposta.
Se una richiesta hashes.search
successiva non restituisce un hash completo attualmente memorizzato nella cache positiva, il client non è tenuto a rimuovere la voce positiva della cache. Questo non è motivo di preoccupazione nella pratica, poiché le durate positive della cache sono in genere brevi (alcuni minuti) per consentire una rapida correzione dei falsi positivi.
Scenario di esempio
Nell'esempio seguente, supponiamo che h(url) sia il prefisso hash dell'URL e H(url) sia l'hash completo dell'URL. Vale a dire che h(url) = SHA256(url).substr(4), H(url) = SHA256(url).
Supponiamo che un client con una cache vuota visiti example.com/ e che h(example.com/) sia nel database locale. Il client richiede!
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 hashes.search
. Dopo 5 minuti il client deve inviare un'altra richiesta
hashes.search
per quel prefisso h(example.com/), se il cliente visita
example.com/. Il client deve reimpostare il timeout della cache negativa del prefisso hash in base alla nuova risposta.
La durata della cache negativa di 1 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 un'ora di tempo, ogni URL
in modo che h(URL) = h(example.com/) debba essere considerato sicuro e, di conseguenza,
non generare una richiesta hashes.search
(supponendo che H(URL) != H(example.com/)).
Se la risposta fullHashes
contiene zero corrispondenze e viene impostata una data di scadenza della cache negativa, il client non deve inviare richieste hashes.search
per nessuno dei prefissi richiesti per un determinato tempo di cache negativa.
Se la risposta hashes.search
contiene una o più corrispondenze, viene comunque impostata un'ora di scadenza della cache negativa per l'intera risposta. In questo caso, la durata della cache di un singolo hash completo indica per quanto tempo il client deve presumere che un determinato hash completo non sia sicuro. Una volta scaduta la durata della cache ThreatHash
, il client deve aggiornare l'hash a lunghezza intera inviando una richiesta hashes.search
per il prefisso hash in questione se l'URL richiesto corrisponde all'hash a lunghezza intera esistente nella cache. In tal caso, la durata della cache negativa non verrà applicata. La durata della cache negativa della risposta si applica solo agli hash completi che non erano presenti nella risposta hashes.search
. Per gli hash completi che non sono presenti nella risposta, il client deve astenersi dall'eseguire richieste hashes.search
fino al termine della durata della cache negativa.