Google Webrisk如何评估特定UpdateAPi请求的expiryTime和negativeExpiryTime。
有时GWR api返回响应的过期时间为5-10分钟,因此我们必须在5-10分钟后再次对GWR进行API调用,这是非常快的。
有没有办法优化expiryTime以降低成本?
发布于 2021-07-17 11:35:57
expireTime and negativeExpireTime字段指示在更新API中必须分别将散列视为不安全或安全的时间。
为了减少使用Update API发送到Google的hashes.search请求的总数,客户端需要维护一个本地缓存。API建立了两种类型的缓存:正缓存和负缓存。
积极缓存(expireTime)
为防止客户端重复询问特定不安全完全哈希的状态,每个返回的ThreatHash都包含一个正缓存时间(由expireTime字段定义)。在此之前,可以认为完整的散列是不安全的。应该为每个expireTime字段的完整散列创建或更新正高速缓存条目。
负缓存(NegativeExpireTime)
为防止客户端重复询问特定safe完全哈希的状态,响应为所请求的前缀定义了负缓存持续时间(由negativeExpireTime字段定义)。在此之前,所有带有所请求前缀的完整哈希对于所请求的威胁类型都被认为是安全的,但服务器作为不安全返回的哈希除外。散列前缀的负缓存持续时间也应该根据响应的negativeExpireTime字段创建或更新。
为例:
假设一个缓存为空的客户机访问example.com/,发现h(example.com/)在本地数据库中。客户端请求散列前缀h(example.com/)的全长散列,并接收回全长散列H(example.com/)以及5分钟后的正缓存expireTime和1小时后的负缓存expireTime。
5分钟的正缓存持续时间告诉客户端,在不发送另一个hashes.search请求的情况下,必须在多长时间内将全长散列H(example.com/)视为不安全。5分钟后,如果客户端再次访问example.com/,则客户端必须发出另一个针对该前缀h(example.com/)的hashes.search请求。客户端应该根据新的响应重置散列前缀的负缓存expireTime。有关Update API的更多信息,请参阅该链接。
https://stackoverflow.com/questions/68403718
复制相似问题