请求频率

本文档适用于以下方法:

  • 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 字段,则客户端可以 根据需要随时更新,并尽可能多地发送 threatListUpdatesfullHashes 请求 理想选择。

    如果在响应中设置了 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 响应,就必须退出退避模式,并按照 最短等待时长