リクエスト頻度

このドキュメントは、次のメソッドに適用されます。

  • Update API(v4): fullHashes.find
  • Update API(v4): threatListUpdates.fetch
  • 更新リクエスト

    サーバーの過負荷を防ぎ、最適な保護を実現するために、Update API(v4)では、クライアントがセーフ ブラウジング サーバーにリクエストを送信して URL チェック(fullHashes.find)またはローカル データベースの更新(threatListUpdates.fetch)を行える頻度の間隔を設けています。

    データの最初のリクエストは、クライアントが起動または復帰してから 0 ~ 1 分の間のランダムな間隔で発生する必要があります。後続のリクエストは、最小待機時間またはバックオフ モードの時間制限が経過した後にのみ行われます。

    最小待機期間

    fullHashes.find レスポンスthreatListUpdates.fetch レスポンスには、クライアントが従う必要がある minimumWaitDuration フィールドがあります。

    レスポンスで minimumWaitDuration フィールドが設定されていない場合、クライアントは必要なだけ更新し、必要なだけ threatListUpdates または fullHashes リクエストを送信できます。

    レスポンスで minimumWaitDuration フィールドが設定されている場合、クライアントは待機時間の長さを超える頻度で更新できません。たとえば、fullHashes レスポンスの最小待機時間が 1 時間の場合、ユーザーがハッシュ プレフィックスがローカル データベースと一致する URL にアクセスしている場合でも、その 1 時間経過するまでクライアントは fullHashes リクエストを送信できません。(クライアントの更新頻度は最小待機時間より短くなる可能性がありますが、保護に悪影響を及ぼす可能性があります)。

    バックオフ モード

    自動バックオフは、fullHashes.find レスポンスthreatListUpdates.fetch レスポンスの両方に適用されます。

    失敗した HTTP レスポンス(つまり、200 OK 以外の HTTP ステータス コード)を受信したクライアントは、バックオフ モードに入る必要があります。バックオフ モードに設定されたクライアントは、サーバーに次のリクエストを発行する前に、計算された時間を待機する必要があります。

    クライアントは、次の式を使用してバックオフ時間を計算する必要があります。

    MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)

    N は、クライアントで連続して失敗したリクエストの数に対応します(最初に失敗したリクエストの後の N=1 から始まります)。RAND は 0 ~ 1 の乱数で、更新に失敗するたびに選択する必要があります。

    クライアントが成功の HTTP レスポンスを受信したら、バックオフ モードを終了し、上記の最小待機時間に従う必要があります。