本文档适用于以下方法:
更新请求
为了防止服务器过载并受益于最佳保护,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 响应后,必须退出退避模式,并遵循上文指定的最短等待时长。