Frekuensi Permintaan
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini berlaku untuk metode berikut:
Update API (v4):
fullHashes.find
Update API (v4):
threatListUpdates.fetch
Permintaan pembaruan
Untuk mencegah kelebihan beban server dan mendapatkan manfaat dari perlindungan yang optimal, Update API (v4) memberlakukan
interval waktu untuk seberapa sering klien dapat mengirim permintaan ke server Safe Browsing untuk
lakukan pemeriksaan URL
(fullHashes.find)
atau untuk memperbarui {i>database<i} lokal
(threatListUpdates.fetch).
Permintaan awal untuk data harus terjadi pada interval acak antara 0 dan 1 menit setelah
klien memulai atau bangun. Permintaan berikutnya hanya dapat terjadi setelah
durasi waktu tunggu minimum atau
Batas waktu mode back-off telah
diamati.
Durasi tunggu minimum
Baik
respons fullHashes.find dan
responsthreatListUpdates.fetch
memiliki kolom minimumWaitDuration
yang harus dipatuhi oleh klien.
Jika kolom minimumWaitDuration
tidak ditetapkan dalam respons, klien dapat
mengupdate sesering yang mereka inginkan dan mengirim permintaan threatListUpdates
atau fullHashes
sebanyak
yang mereka inginkan.
Jika kolom minimumWaitDuration
ditetapkan dalam respons, klien tidak dapat
diperbarui lebih sering dari
panjang durasi tunggu. Misalnya, jika respons fullHashes
berisi durasi tunggu minimum 1 jam, klien tidak boleh mengirim permintaan fullHashes
apa pun
hingga jam tersebut berlalu, meskipun pengguna mengunjungi URL yang awalan hash-nya cocok dengan
di skrip untuk menyiapkan database. (Perhatikan bahwa klien bisa memperbarui lebih jarang dari durasi tunggu minimum, tetapi
dapat berdampak negatif terhadap perlindungan.)
Mode back-off
Back-off otomatis berlaku untuk
respons fullHashes.find dan
responsthreatListUpdates.fetch.
Klien yang menerima respons HTTP yang gagal (yaitu, kode status HTTP apa pun selain
200 OK
) harus memasuki mode back-off. Setelah dalam mode {i>back-off<i}, klien harus menunggu waktu yang dihitung
durasi sebelum mereka dapat mengirimkan
permintaan lain ke server.
Klien harus menggunakan formula berikut untuk menghitung durasi waktu back-off:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N sesuai dengan jumlah permintaan berturut-turut dan gagal yang dialami klien
(dimulai dengan N=1 setelah permintaan pertama yang gagal). RAND adalah angka acak antara 0 dan 1
yang harus dipilih setelah
setiap pembaruan gagal.
Setelah klien menerima respons HTTP yang berhasil, klien
harus keluar dari mode {i>back-off<i} dan mengikuti
durasi tunggu minimum
yang ditentukan di atas.
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-25 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-25 UTC."],[[["\u003cp\u003eThe Google Safe Browsing Update API (v4) enforces request frequency limits to prevent server overload and maintain optimal protection.\u003c/p\u003e\n"],["\u003cp\u003eClients should adhere to the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e field provided in API responses to determine update frequency.\u003c/p\u003e\n"],["\u003cp\u003eIf the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e field is not set, clients can update as frequently as needed; if set, updates should not exceed the specified duration.\u003c/p\u003e\n"],["\u003cp\u003eUpon receiving unsuccessful HTTP responses, clients must enter back-off mode, delaying subsequent requests using a calculated time duration formula.\u003c/p\u003e\n"],["\u003cp\u003eAfter a successful response, clients exit back-off mode and resume following the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e guidelines for updates.\u003c/p\u003e\n"]]],["The Update API v4's `fullHashes.find` and `threatListUpdates.fetch` methods require clients to adhere to request time intervals. Initial requests must be sent within 0-1 minutes of startup, and subsequent requests must observe the `minimumWaitDuration` or `back-off mode`. If `minimumWaitDuration` isn't set, clients can update freely; if set, they must wait for the specified duration. Unsuccessful HTTP responses trigger back-off mode, using a formula to determine the wait time, until a successful response occurs.\n"],null,["# Request Frequency\n\nThis document applies to the following methods:\n- [Update API (v4)](/safe-browsing/v4/update-api): [fullHashes.find](/safe-browsing/v4/update-api#example-fullHashesfind)\n- [Update API (v4)](/safe-browsing/v4/update-api): [threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatListUpdatesfetch)\n\nUpdate requests\n---------------\n\n- To prevent server overload and to benefit from optimal protection, the Update API (v4) imposes time intervals for how often a client can send requests to the Safe Browsing server to perform URL checks ([fullHashes.find](/safe-browsing/v4/update-api#example-fullhashesfind)) or to update the local database ([threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatlistupdatesfetch)).\n- The initial request for data must happen at a random interval between 0 and 1 minutes after the client starts or wakes up. Subsequent requests can happen only after the [minimum wait duration](/safe-browsing/v4/request-frequency#minimum-wait-duration) or [back-off mode](/safe-browsing/v4/request-frequency#back-off-mode) time limit has been observed.\n\nMinimum wait duration\n---------------------\n\n- Both the [fullHashes.find response](/safe-browsing/v4/update-api#http-post-response_2) and [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response) have a `minimumWaitDuration` field that clients must obey.\n- If the `minimumWaitDuration` field **is not set** in the response, clients can update as frequently as they want and send as many `threatListUpdates` or `fullHashes` requests as they want.\n- If the `minimumWaitDuration` field **is set** in the response, clients cannot update more frequently than the length of the wait duration. For example, if a `fullHashes` response contains a minimum wait duration of 1 hour, the client must not send send any `fullHashes` requests until that hour passes, even if the user is visiting a URL whose hash prefix matches the local database. (Note that clients can update less frequently than the minimum wait duration but this may negatively affect protection.)\n\nBack-off mode\n-------------\n\n- Automatic back-off applies to both the [fullHashes.find response](/safe-browsing/v4/update-api#http-post-response_2) and [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response).\n- Clients that receive an unsuccessful HTTP response (that is, any HTTP status code other than `200 OK`) must enter back-off mode. Once in back-off mode, clients must wait the computed time duration before they can issue another request to the server.\n- Clients must use the following formula to compute the back-off time duration: \n\n```scdoc\nMIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)\n```\n- N corresponds to the number of consecutive, unsuccessful requests that the client experiences (starting with N=1 after the first unsuccessful request). RAND is a random number between 0 and 1 that needs to be picked after every unsuccessful update.\n- Once a client receives a successful HTTP response, the client must exit back-off mode and follow the [minimum wait duration](/safe-browsing/v4/request-frequency#minimum-wait-duration) specified above."]]