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...
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. |