Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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.