请求频率
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本文档适用于以下方法:
Update API (v4):
fullHashes.find
Update API (v4):
threatListUpdates.fetch
更新请求
为防止服务器过载并受益于最佳保护,Update API (v4) 将
客户端向安全浏览服务器发送请求的频率
执行网址检查
(fullHashes.find)
或者更新本地数据库
(threatListUpdates.fetch).
数据的初始请求必须在事件发生后的 0 到 1 分钟之间
启动或唤醒。只有在
最短等待时长或
已采用退避模式时间限制
。
最短等待时长
fullHashes.find 响应和
threatListUpdates.fetch 响应
包含客户端必须遵守的 minimumWaitDuration
字段。
如果响应中未设置 minimumWaitDuration
字段,则客户端可以
根据需要随时更新,并尽可能多地发送 threatListUpdates
或 fullHashes
请求
理想选择。
如果在响应中设置了 minimumWaitDuration
字段,则客户端无法
更新频率超过等待时长。例如,如果 fullHashes
响应
包含的最短等待时长为 1 小时,因此客户端不得发送任何 fullHashes
请求
即使用户所访问的网址的哈希前缀与本地
数据库。(请注意,客户端的更新频率可以低于最短等待时长,但
可能会对保护产生负面影响。)
退避模式
自动退避算法适用于
fullHashes.find 响应和
threatListUpdates.fetch 响应。
收到失败 HTTP 响应(即除
200 OK
)必须进入退避模式。进入退避模式后,客户端必须等待计算出的时间
然后才能向服务器发出另一个请求。
客户端必须使用以下公式计算退避时长:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N 对应于客户端遇到的连续失败请求的数量
(在第一次请求失败后从 N=1 开始)。RAND 为介于 0 到 1 之间的随机数
需要在每次更新失败后选择。
一旦客户端收到成功的 HTTP 响应,就必须退出退避模式,并按照
最短等待时长
。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\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."]]