本文档适用于以下方法：
更新请求
为了防止服务器过载并受益于最佳保护，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 以外的任何 HTTP 状态代码）的客户端必须进入退避模式。进入退避模式后，客户端必须等待计算出的时长，然后才能向服务器发出另一个请求。
客户端必须使用以下公式计算退避时长：
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N 对应于客户端经历的连续失败请求数量（从第一个不成功请求后 N=1 开始）。RAND 是一个介于 0 到 1 之间的随机数字，在每次更新失败后都需要选择。
客户端收到成功的 HTTP 响应后，必须退出退避模式，并遵循上文指定的最短等待时长。