Dokumen ini berlaku untuk metode berikut:
Tentang penyimpanan dalam cache
Untuk mengurangi penggunaan bandwidth klien dan untuk melindungi Google dari lonjakan traffic, klien dari
Lookup API dan Update API diperlukan untuk membuat dan mengelola cache lokal data ancaman.
Untuk Lookup API, cache digunakan untuk mengurangi jumlah threatMatches
yang dikirim klien ke Google. Untuk Update API, cache digunakan untuk mengurangi jumlah
fullHashes meminta yang dikirim klien ke Google. Protokol caching untuk setiap API adalah
diuraikan di bawah ini.
Lookup API
Klien Lookup API harus meng-cache setiap item ThreatMatch yang ditampilkan selama durasi yang ditentukan
menurut bidang cacheDuration. Klien kemudian harus melihat cache sebelum melakukan
Permintaan threatMatches ke server. Jika durasi cache untuk ThreatMatch yang ditampilkan sebelumnya
belum kedaluwarsa, klien harus beranggapan bahwa item masih tidak aman. Menyimpan ThreatMatch item ke dalam cache
dapat mengurangi jumlah permintaan API yang dibuat oleh klien.
Contoh: ancamanMatches.find
Klik link permintaan dan respons di header tabel untuk melihat contoh lengkap.
| Pemeriksaan URL Permintaan ThreatMatches |
Kecocokan URL Respons terhadap Ancaman |
Perilaku Penyimpanan dalam Cache |
|---|---|---|
"threatEntries": [
{"url": "http://www.urltocheck.org/"}
]
|
"matches": [{
"threat": {"url": "http://www.urltocheck.org/"},
"cacheDuration": "300.000s"
}]
|
Kecocokan. Klien harus menunggu 5 menit sebelum mengirim permintaan threatMatches baru yang mencakup
URL http://www.urltocheck.org/.
|
Update API
Untuk mengurangi jumlah keseluruhan permintaan fullHashes yang dikirim ke Google menggunakan Update API, klien
diperlukan untuk mempertahankan
{i>cache<i} lokal. API menetapkan dua jenis caching, positif dan negatif.
Cache positif
Agar klien tidak berulang kali menanyakan status hash lengkap tertentu yang tidak aman,
setiap ThreatMatch yang ditampilkan berisi durasi cache positif (didefinisikan oleh kolom cacheDuration),
yang menunjukkan berapa lama {i>hash<i} lengkap
akan dianggap tidak aman.
Cache negatif
Agar klien tidak berulang kali menanyakan status hash lengkap tertentu yang aman,
setiap respons fullHashes menentukan durasi cache negatif untuk awalan yang diminta (ditentukan oleh
kolom negativeCacheDuration). Durasi ini menunjukkan berapa lama semua {i>hash<i}
penuh dengan {i>hash<i} yang diminta
dianggap aman untuk daftar yang diminta, kecuali yang ditampilkan oleh server sebagai
tidak aman. Cache ini sangat penting karena mencegah kelebihan traffic yang dapat disebabkan
oleh tabrakan awalan {i>hash<i} dengan
URL aman yang menerima banyak lalu lintas.
Mempelajari cache
Saat ingin memeriksa status URL, klien akan menghitung hash lengkapnya terlebih dahulu. Jika penuh
awalan hash ada di database lokal, klien harus memeriksa cache-nya sebelum
membuat permintaan fullHashes ke server.
Pertama, klien harus memeriksa apakah ditemukan cache yang positif. Jika ada cache positif yang belum habis masa berlakunya
entri untuk {i>hash<i} yang lengkap, maka
itu harus dianggap tidak aman. Jika entri cache positif
tidak berlaku lagi, klien harus mengirimkan permintaan fullHashes untuk awalan lokal terkait. Sesuai dengan
, jika server mengembalikan {i>hash<i}
secara lengkap, maka hal itu dianggap tidak aman; jika tidak, dianggap
aman.
Jika tidak ada entri cache positif untuk hash lengkap, klien harus memeriksa nilai negatif
cache ditemukan. Jika ada entri cache negatif yang belum habis masa berlakunya untuk awalan lokal terkait,
{i>hash<i} yang benar-benar lengkap
dianggap aman. Jika entri cache negatif sudah tidak berlaku, atau entri tidak ada, klien
harus mengirim permintaan fullHashes untuk awalan lokal yang terkait dan menafsirkan respons seperti biasa.
Memperbarui cache
Cache klien harus diperbarui setiap kali respons fullHashes diterima. Cache positif
entri harus dibuat atau diperbarui untuk hash lengkap per kolom cacheDuration. Awalan hash
durasi cache negatif juga harus dibuat atau diperbarui sesuai dengan negativeCacheDuration respons
kolom tersebut.
Jika permintaan fullHashes berikutnya tidak menampilkan hash lengkap yang saat ini bernilai positif
di-cache, maka klien tidak perlu menghapus entri cache positif. Jangan khawatir
karena durasi cache positif biasanya singkat (beberapa menit) agar cepat
koreksi positif palsu (PP).
Contoh skenario
Pada contoh berikut, asumsikan h(url) adalah awalan hash URL dan H(url) adalah awalan {i>hash<i} URL yang lengkap. Yaitu, h(url) = SHA256(url).substr(4), H(url) = SHA256(url).
Sekarang, asumsikan klien (dengan cache kosong) mengunjungi example.com/ dan melihat bahwa h(example.com/) adalah dalam {i>database<i} lokal. Klien meminta hash lengkap untuk awalan hash h(example.com/) dan menerima kembali hash panjang penuh H(example.com/) bersama dengan durasi cache positif 5 dalam menit dan durasi cache negatif 1 jam.
Durasi cache positif selama 5 menit memberi tahu klien berapa lama hash panjang penuh
H(example.com/) harus dianggap tidak aman tanpa mengirim permintaan fullHashes lainnya. Setelah 5
menit, klien harus mengeluarkan permintaan fullHashes lain untuk awalan h(example.com/) tersebut jika
klien mengunjungi example.com/ lagi. Klien harus mereset durasi cache negatif awalan hash
sesuai dengan respons baru.
Durasi cache negatif 1 jam memberi tahu klien berapa lama semua hash lengkap lainnya
selain H(example.com/) yang memiliki awalan h(example.com/) yang sama harus dianggap aman. Sebagai
berdurasi 1 jam, setiap URL sedemikian rupa sehingga h(URL) = h(example.com/) harus dianggap aman, dan
oleh karena itu tidak menghasilkan permintaan fullHashes (dengan asumsi bahwa H(URL) != H(example.com/)).
Jika respons fullHashes berisi nol kecocokan dan durasi cache negatif ditetapkan, maka
klien tidak boleh mengeluarkan permintaan fullHashes apa pun untuk awalan apa pun yang diminta untuk
durasi cache negatif.
Jika respons fullHashes berisi satu atau beberapa kecocokan, durasi cache negatif masih ditetapkan
untuk seluruh respons. Dalam hal ini, durasi cache dari
satu {i>hash<i} penuh menunjukkan berapa lama
{i>hash <i}yang lengkap itu harus
dianggap tidak aman oleh klien. Setelah cache ThreatMatch
durasi berlalu, klien harus memuat ulang hash lengkap dengan mengeluarkan permintaan fullHashes untuk
awalan {i>hash<i} tersebut jika URL yang diminta cocok
dengan {i>hash<i} lengkap yang ada di {i>cache<i}. Di sana
jika durasi cache negatif tidak berlaku. Durasi cache negatif respons hanya berlaku
ke hash lengkap yang tidak ada dalam respons fullHashes. Untuk {i>hash<i} lengkap yang
tidak ada dalam respons, klien tidak boleh mengeluarkan permintaan fullHashes apa pun
hingga durasi cache negatif berlalu.
Contoh: fullHashes.find
Klik link permintaan dan respons di header tabel untuk melihat contoh lengkap.
| Awalan Hash Permintaan fullHashes |
Kecocokan Hash Panjang Respons fullHashes |
Perilaku Penyimpanan dalam Cache |
|---|---|---|
"threatEntries": [
{"hash": "0xaaaaaaaa"}
]
|
"matches": [], "negativeCacheDuration": "3600.000s" |
Tidak ada yang cocok. Klien tidak boleh mengirim permintaan fullHashes untuk awalan hash 0xaaaaaaaa setidaknya selama satu jam.
Setiap hash dengan awalan 0xaaaaaaaa dianggap aman selama satu jam. |
"threatEntries": [
{"hash": "0xbbbbbbbb"}
]
|
"matches": [
"threat": {"hash": "0xbbbbbbbb0000..."}
"cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"
|
Kemungkinan kecocokan. Klien harus mempertimbangkan URL dengan hash lengkap 0xbbbbbbbb0000... tidak aman selama 10 menit. Tujuan klien harus mempertimbangkan semua URL lain dengan awalan {i>hash <i}0xbbbbbbbb yang aman selama 5 menit. Setelah 5 menit, entri cache negatif awalan hash akan kedaluwarsa. Karena entri cache positif untuk 0xbbbbbbbb0000... belum berakhir, klien harus mengirimkan permintaan fullHashes untuk semua hash
kecuali yang itu. |
"threatEntries": [
{"hash": "0xcccccccc"}
]
|
"matches": [
"threat": {"hash": "0xccccccccdddd..."},
"cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"
|
Kemungkinan kecocokan. Klien tidak boleh mengirim permintaan fullHashes untuk awalan hash 0xcccccccc setidaknya selama 1 jam dan mengasumsikan
agar awalan tersebut aman — kecuali jika hash lengkap URL cocok dengan hash lengkap yang di-cache
0xccccccccdddd.... Dalam hal ini, klien harus menganggap URL tersebut tidak aman selama 10 menit.
Setelah 10 menit, hash lengkap akan berakhir masa berlakunya. Pencarian berikutnya untuk
hash lengkap itu harus
memicu permintaan fullHashes baru. |