caching - 谷歌网络风险 API TTL

Question

Google Webrisk 如何评估特定 UpdateAPi 请求的 expiryTime 和negativeExpiryTime。

有时 GWR api 会返回 5-10 分钟到期的响应，因此我们必须在 5-10 分钟后再次对 GWR 进行 API 调用，这很快。

有什么办法可以优化过期时间来降低成本？

标签： cachingttlgoogle-cloud-webrisk

Answer 1

expireTime和negativeExpireTime字段指示在更新API 中哈希必须分别被视为不安全或安全的时间。

为了减少使用 Update API 发送给 Google 的 hashes.search 请求的总数，客户端需要维护本地缓存。API 建立了两种类型的缓存，正面和负面。

正向缓存 (expireTime)

为了防止客户端重复询问特定不安全完整哈希的状态，每个返回的 ThreatHash 都包含一个正缓存时间（由 expireTime 字段定义）。在此之前，完整的散列可以被认为是不安全的。应该为每个 expireTime 字段的完整哈希创建或更新一个正缓存条目。

负缓存（negativeExpireTime）

为了防止客户端重复询问特定安全完整哈希的状态，响应定义了请求前缀的负缓存持续时间（由negativeExpireTime 字段定义）。在此之前，所有具有请求前缀的完整哈希对于请求的威胁类型都被认为是安全的，但服务器返回的那些不安全的除外。哈希前缀的负缓存持续时间也应该根据响应的negativeExpireTime 字段创建或更新。

例如：

假设具有空缓存的客户端访问 example.com/ 并看到 h(example.com/) 在本地数据库中。客户端请求哈希前缀 h(example.com/) 的全长哈希，并接收回全长哈希 H(example.com/) 以及从现在起 5 分钟的正缓存 expireTime 和负缓存 expireTime 1小时后。

5 分钟的正缓存持续时间告诉客户端在不发送另一个 hashes.search 请求的情况下，必须将全长哈希 H(example.com/) 视为不安全多长时间。5 分钟后，如果客户端再次访问 example.com/，则客户端必须针对该前缀 h(example.com/) 发出另一个 hashes.search 请求。客户端应根据新响应重置哈希前缀的负缓存 expireTime。有关更新 API的更多信息，请参阅链接。