Frequência de solicitações
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento se aplica aos seguintes métodos:
API Update (v4):
fullHashes.find
API Update (v4):
threatListUpdates.fetch
Solicitações de atualização
Para evitar a sobrecarga do servidor e aproveitar a proteção ideal, a API Update (v4) impõe
intervalos de tempo para a frequência com que um cliente pode enviar solicitações ao servidor da Navegação segura para
realizar verificações de URL
(fullHashes.find).
ou atualizar o banco de dados local
(threatListUpdates.fetch).
A solicitação inicial de dados deve acontecer em um intervalo aleatório entre 0 e 1 minuto após a
cliente inicia ou acorda. As solicitações subsequentes só podem acontecer depois que o
duração mínima de espera ou
O limite de tempo do modo de espera foi
observados.
Duração mínima de espera
Tanto o
fullHashes.find response e
Resposta threatListUpdates.fetch
têm um campo minimumWaitDuration
que os clientes precisam obedecer.
Se o campo minimumWaitDuration
não estiver definido na resposta, os clientes poderão
atualizar com a frequência que quiser e enviar quantas solicitações threatListUpdates
ou fullHashes
forem necessárias
o que eles querem.
Se o campo minimumWaitDuration
estiver definido na resposta, os clientes não poderão
são atualizados com mais frequência do que a duração da espera. Por exemplo, se uma resposta fullHashes
contiver uma duração mínima de espera de 1 hora, o cliente não poderá enviar solicitações fullHashes
até que essa hora tenha passado, mesmo que o usuário esteja visitando um URL com um prefixo de hash que corresponde ao local
no seu banco de dados. Os clientes podem atualizar com menos frequência do que a duração mínima de espera, mas esse
podem afetar negativamente a proteção.)
Modo de retirada
A espera automática se aplica ao
fullHashes.find response e
threatListUpdates.fetch.
Clientes que recebem uma resposta HTTP com falha (ou seja, qualquer código de status HTTP diferente
200 OK
) precisa entrar no modo de espera. No modo de espera, os clientes precisam aguardar o tempo calculado
antes de emitir outra solicitação ao servidor.
Os clientes precisam usar a seguinte fórmula para calcular a duração do tempo de espera:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N corresponde ao número de solicitações consecutivas e malsucedidas realizadas pelo cliente
(começando com N=1 após a primeira solicitação malsucedida). RAND é um número aleatório entre 0 e 1
que precisa ser selecionado
após cada atualização malsucedida.
Quando um cliente recebe uma resposta HTTP bem-sucedida, ele deve sair do modo de espera e seguir
a duração mínima de espera
especificado acima.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-07-25 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]