要求頻率

本文件適用於下列方法：

  • Update API (v4)： fullHashes.find
  • Update API (v4)： threatListUpdates.fetch

    • 更新要求

    為避免伺服器過載，同時享有最佳防護效果，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 回應後，必須結束輪詢模式，並遵循 最短等待時間 。