このドキュメントは、次のメソッドに適用されます。
更新リクエスト
サーバーの過負荷を防ぎ、最適な保護のメリットを得るため、Update API（v4）では クライアントがセーフ ブラウジング サーバーにリクエストを送信できる頻度 URL チェックを実行 （fullHashes.find） ローカルデータベースを更新するか (threatListUpdates.fetch).
最初のデータ リクエストは、リクエストから 0 ～ 1 分の間のランダムな間隔で 起動またはスリープ解除します。後続のリクエストは、 最小待機時間 バックオフ モードの時間制限が 表示されます。
最小待機期間
また、
fullHashes.find レスポンスと
threatListUpdates.fetch レスポンス
クライアントが従う必要がある minimumWaitDuration フィールドがある。
レスポンスで minimumWaitDuration フィールドが設定されていない場合、クライアントは
必要な頻度で更新し、threatListUpdates または fullHashes リクエストを必要なだけ送信します。
実現できます。
レスポンスで minimumWaitDuration フィールドが設定されている場合、クライアントは
待機時間の長さよりも頻繁に更新されます。たとえば、fullHashes レスポンスが
最小待機時間が 1 時間の場合、クライアントは fullHashes リクエストを送信してはいけません。
その 1 時間が経過するまでは、ユーザーがアクセスした URL のハッシュ接頭辞が
データベースです（クライアントは更新頻度が最小待機時間より少ないこともありますが、
保護に悪影響を及ぼす可能性があります）。
バックオフ モード
自動バックオフは、 fullHashes.find レスポンスと threatListUpdates.fetch レスポンス。
失敗した HTTP レスポンス（つまり、HTTP レスポンス以外の HTTP ステータス コード）を
200 OK など）をバックオフ モードに切り替える必要があります。バックオフ モードになると、クライアントは計算された時間を
サーバーに再度リクエストを送信できるようになるまでに時間がかかることが予想されます。
クライアントは、次の数式を使用してバックオフ時間を計算する必要があります。
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)N は、クライアントで連続して失敗したリクエストの数に対応します。 （最初のリクエストの失敗後は N=1 から開始します）。RAND は 0 ～ 1 の乱数 更新に失敗するたびに それを選択する必要があるからです
クライアントは、正常な HTTP レスポンスを受信したらバックオフ モードを終了し、その後、 最小待機時間 指定します。