İstek Sıklığı
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu belge aşağıdaki yöntemler için geçerlidir:
API'yi (v4) güncelleyin:
fullHashes.find
API'yi (v4) güncelleyin:
threatListUpdates.fetch
Güncelleme istekleri
Güncelleme API'si (v4), sunucuya aşırı yüklenmeyi önlemek ve optimum korumadan yararlanmak için
bir istemcinin Güvenli Tarama sunucusuna ne sıklıkta istek gönderebileceğini
URL kontrolleri gerçekleştirme
(fullHashes.find)
veya yerel veritabanını güncellemek
(threatListUpdates.fetch).
İlk veri isteği,
veya uyanık kalır. Sonraki istekler yalnızca
minimum bekleme süresi veya
geri çekme modu süre sınırı aşıldı
gözlemlendi.
Minimum bekleme süresi
Hem
fullHashes.find yanıtı ve
threatListUpdates.fetch yanıtı
müşterilerin uymak zorunda olduğu bir minimumWaitDuration alanı vardır.
minimumWaitDuration alanı yanıtta ayarlanmadıysa istemciler
istedikleri sıklıkta güncelleme yapabilir ve istedikleri kadar threatListUpdates veya fullHashes isteği gönderebilirler
istiyorlar.
Yanıtta minimumWaitDuration alanı ayarlanırsa istemciler
daha sık güncellenir. Örneğin, fullHashes yanıtı
minimum 1 saatlik bekleme süresi içeriyorsa istemci herhangi bir fullHashes isteği göndermemelidir
Kullanıcı, karma öneki yerel ile eşleşen bir URL'yi ziyaret ediyor olsa bile, o saat geçene kadar
(Müşterilerin minimum bekleme süresinden daha seyrek güncelleme yapabileceğini ancak bu süre
korumayı olumsuz etkileyebilir.)
Geri yükleme modu
Otomatik geri yükleme, hem
fullHashes.find yanıtı ve
threatListUpdates.fetch yanıtı.
Başarısız bir HTTP yanıtı (yani
200 OK) geri çekilme moduna geçmelidir. Geri yükleme modundayken müşteriler hesaplanan süreyi beklemelidir
sunucuya başka bir istek gönderebilmelerini sağlar.
Müşterilerin geri çekilme süresini hesaplamak için aşağıdaki formülü kullanması gerekir:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N, müşterinin deneyimlediği art arda başarısız isteklerin sayısına karşılık gelir.
(ilk başarısız istekten sonra N=1 ile başlar). RAND, 0 ile 1 arasında rastgele bir sayıdır
seçmeniz gerekir.
İstemci başarılı bir HTTP yanıtı aldıktan sonra, istemcinin geri çekilme modundan çıkması ve
minimum bekleme süresi
belirtildiğinden emin olun.
Aksi belirtilmediği sürece bu sayfanın içeriği Creative Commons Atıf 4.0 Lisansı altında ve kod örnekleri Apache 2.0 Lisansı altında lisanslanmıştır. Ayrıntılı bilgi için Google Developers Site Politikaları'na göz atın. Java, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-25 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
