本文件適用於下列方法：
更新要求
為避免伺服器過載，同時享有最佳防護效果，Update API (v4) 將 用戶端可將要求傳送至安全瀏覽伺服器的頻率時間間隔 執行網址檢查 (fullHashes.find) 或更新本機資料庫 (threatListUpdates.fetch).
資料的初始要求必須在 0 到 1 分鐘的 啟動或喚醒用戶端。後續要求只有在 最短等待時間，或 已設下輪詢模式時間限制 。
最短等待時間長度
兩者
fullHashes.find response 和
threatListUpdates.fetch 回應
用戶端必須遵循 minimumWaitDuration 欄位。
如果回應中的 minimumWaitDuration 欄位未設定，用戶端可以
彈性更新，且可視需要一次傳送最多的 threatListUpdates 或 fullHashes 要求
他們的資料。
如果回應中的 minimumWaitDuration 欄位「已設定」，用戶端就無法
更新的頻率會高於等待時間長度。舉例來說，如果回應 fullHashes 回應
包含最短等待時間為 1 小時，用戶端不得傳送任何 fullHashes 要求
直到該小時結束為止。就算使用者造訪的網址雜湊前置字元與本機相符
資料庫請注意，用戶端更新的頻率可以低於最短等待時間
可能會使防護功能受到負面影響)。
輪詢模式
自動輪詢會同時套用至 fullHashes.find response 和 threatListUpdates.fetch 回應。
接收失敗 HTTP 回應的用戶端 (也就是說，
200 OK) 必須進入輪詢模式。進入輪詢模式後，用戶端必須等待運算時間
才能再次向伺服器發出要求
用戶端必須使用以下公式計算輪詢持續時間：
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)N 代表用戶端遇到的連續失敗要求數量 (在第一個失敗的請求後從 N=1 開始)。RAND 是介於 0 到 1 之間的隨機數字 必須在每次成功更新後選取
用戶端收到成功的 HTTP 回應後，必須結束輪詢模式，並遵循 最短等待時間 。