このドキュメントは、次のメソッドに適用されます。
キャッシュについて
クライアントの帯域幅の使用量を減らし、Google をトラフィックの急増から保護するために、両方の
Lookup API と Update API は、脅威データのローカル キャッシュを作成して維持するために必要です。
Lookup API では、キャッシュを使用して threatMatches
の数を減らす
クライアントが Google に送信するリクエストの数を表します。Update API では、クライアントが Google に送信する fullHashes
リクエストの数を減らすためにキャッシュが使用されます。各 API のキャッシュ プロトコルは、
下で説明します
Lookup API
Lookup API のクライアントは、返された ThreatMatch
アイテムを、定義された期間、キャッシュに保存する必要があります
「cacheDuration」フィールドで指定されています。この場合、クライアントは次のキャッシュを参照する前にキャッシュを参照する必要がある
threatMatches
リクエストをサーバーに送信します。以前に返された ThreatMatch
のキャッシュ期間
の期限が切れていない場合、クライアントはその商品アイテムがまだ安全ではないと想定する必要があります。ThreatMatch
個のアイテムをキャッシュしています
クライアントが行う API リクエストの数が減る場合があります。
例: threatMatches.find
完全な例については、テーブル ヘッダーのリクエストとレスポンスのリンクをクリックしてください。
URL チェック threatMatches リクエスト |
URL の一致: threatMatches レスポンス |
キャッシュの動作 |
---|---|---|
"threatEntries": [ {"url": "http://www.urltocheck.org/"} ] |
"matches": [{ "threat": {"url": "http://www.urltocheck.org/"}, "cacheDuration": "300.000s" }] |
一致 クライアントは、5 分待ってから次のものを含む新しい threatMatches リクエストを送信する必要があります。
URL http://www.urltocheck.org/。
|
Update API
Update API を使用して Google に送信される fullHashes
リクエストの総数を減らすには、
ローカル キャッシュを維持するために必要です。API は、ポジティブとネガティブの 2 種類のキャッシュを確立します。
ポジティブ キャッシュ
クライアントが特定の安全でないフルハッシュの状態について繰り返し質問しないようにするには、
返される各 ThreatMatch
には、正のキャッシュ期間(cacheDuration
フィールドで定義)が含まれます。
これは、完全なハッシュが安全でないとみなされる期間を示します。
ネガティブ キャッシュ
クライアントが特定の安全なフルハッシュの状態について繰り返し質問しないようにするには、
各 fullHashes
レスポンスは、リクエストされたプレフィックスのネガティブ キャッシュ期間(
negativeCacheDuration
フィールド)。この期間は、リクエストされたハッシュ値と
としてサーバーから返されたものを除き、要求されたリストでは安全とみなされます。
安全ではありません。このキャッシュは、トラフィックの過剰な負荷が引き起こされることを防ぐため、特に重要です。
多くのトラフィックを受信する安全な URL とハッシュ接頭辞が衝突することによるものです。
キャッシュに関するコンサルティング
クライアントが URL の状態を確認する場合は、まずフルハッシュを計算します。完全な
ハッシュの接頭辞がローカル データベースに存在している場合、クライアントは事前にキャッシュを参照する必要があります。
サーバーへの fullHashes
リクエスト。
まず、クライアントがキャッシュ ヒットを確認する必要があります。期限切れでないポジティブ キャッシュが存在する場合
含まれている場合、これは安全でないと見なされます。ポジティブ キャッシュ エントリが
期限切れの場合、クライアントは関連するローカル プレフィックスに対する fullHashes
リクエストを送信する必要があります。「
サーバーが完全なハッシュを返すと、安全でないとみなされます。そうでない場合は
保護します。
フルハッシュに対応するポジティブのキャッシュエントリがない場合、クライアントはネガティブ
できます。関連付けられたローカル接頭辞に期限切れでないネガティブ キャッシュ エントリがある場合、
完全なハッシュは安全とみなされます。ネガティブ キャッシュ エントリが期限切れの場合、またはエントリが存在しない場合、クライアントは
関連するローカル プレフィックスの fullHashes
リクエストを送信し、レスポンスを通常どおり解釈する必要があります。
キャッシュの更新
クライアント キャッシュは、fullHashes
レスポンスを受信するたびに更新する必要があります。ポジティブ キャッシュ
エントリは、cacheDuration
フィールドに従って完全なハッシュ用に作成または更新する必要があります。ハッシュ接頭辞の
ネガティブ キャッシュ期間もレスポンスの negativeCacheDuration
に従って作成または更新する必要があります。
表示されます。
後続の fullHashes
リクエストで、現時点で正の値であるフルハッシュが返されない場合
ポジティブ キャッシュ エントリを削除する必要はありません。これは懸念材料ではない
実際には、ポジティブのキャッシュ保存期間は通常、短時間(数分)です。
偽陽性の修正に使用されます。
状況の例
次の例では、h(url) が URL のハッシュ プレフィックス、H(url) が URL のフルレングスのハッシュ。つまり、h(url) = SHA256(url).substr(4)、H(url) = SHA256(url) となります。
ここで、キャッシュが空になっているクライアントが example.com/ にアクセスすると、h(example.com/) が ローカルデータベースに格納されますクライアントがハッシュ接頭辞 h(example.com/)の完全長のハッシュをリクエストする場合 正のキャッシュ期間 5 とともに、完全長のハッシュ H(example.com/)が返されます。 マイナスのキャッシュ保存期間は 1 時間です
正のキャッシュ保存期間である 5 分は、クライアントに完全長のハッシュの長さを示します。
H(example.com/)は、別の fullHashes
リクエストを送信しないと安全でないとみなされます。5 以降
プレフィックス h(example.com/)に対して別の fullHashes
リクエストを発行する必要がある分。
クライアントが example.com/ に再度アクセスします。クライアントがハッシュ接頭辞のネガティブ キャッシュ期間をリセットする必要がある
回答が返されます
ネガティブ キャッシュの継続時間を 1 時間に設定すると、他のすべてのフルレングスのハッシュ時間がクライアントに伝えることができます。
H(example.com/)を除き、同じ接頭辞 h(example.com/)を共有しているものは安全とみなされます。対象
制限あり、h(URL) = h(example.com/) となる URL はすべて安全とみなす必要があります。
そのため、fullHashes
リクエストは行われません(H(URL) != H(example.com/) と仮定します)。
fullHashes
レスポンスにゼロの一致が含まれ、ネガティブ キャッシュ期間が設定されている場合、
クライアントは、指定されたリクエストのどの接頭辞に対しても fullHashes
リクエストを発行することはできません
ネガティブキャッシュ期間。
fullHashes
レスポンスに 1 つ以上の一致が含まれている場合でも、ネガティブ キャッシュ期間が設定されます。
表示されます。その場合、1 つのフルハッシュのキャッシュ期間は、
クライアントが安全でないと想定する必要があります。ThreatMatch
キャッシュの後
時間が経過すると、クライアントは、に対する fullHashes
リクエストを発行してハッシュ全体を更新する必要があります。
リクエストされた URL がキャッシュ内の既存のフルレングスのハッシュと一致する場合、そのハッシュ接頭辞。その
ネガティブキャッシュ期間は適用されませんレスポンスのネガティブ キャッシュ期間が適用されるのは、
fullHashes
レスポンスにはなかったフルレングスのハッシュに変換できます。フルレングスのハッシュ値の場合、
レスポンスに存在しない場合、クライアントは fullHashes
リクエストを発行しないようにする必要があります。
ネガティブ キャッシュ期間が経過するまで保持されます。
例: fullHashes.find
完全な例については、テーブル ヘッダーのリクエストとレスポンスのリンクをクリックしてください。
ハッシュ接頭辞 fullHashes リクエスト |
完全長のハッシュ一致 fullHashes レスポンス |
キャッシュの動作 |
---|---|---|
"threatEntries": [ {"hash": "0xaaaaaaaa"} ] |
"matches": [], "negativeCacheDuration": "3600.000s" |
一致する結果はありません。 クライアントは、ハッシュ接頭辞 0xaaaaaaa の fullHashes リクエストを少なくとも 1 時間送信してはなりません。
接頭辞が 0xaaaaaaaa のハッシュは、1 時間安全とみなされます。 |
"threatEntries": [ {"hash": "0xbbbbbbbb"} ] |
"matches": [ "threat": {"hash": "0xbbbbbbbb0000..."} "cacheDuration": "600.000s", ], "negativeCacheDuration": "300.000s" |
一致する可能性があります。 クライアントは、フルハッシュ 0xbbbbbbbb0000... を含む URL が 10 分間安全でないとみなす必要があります。「 クライアントは、ハッシュ接頭辞が 0xbbbbbbbb の他のすべての URL は 5 分間は安全であるとみなす必要があります。5 以降 ハッシュ接頭辞のネガティブ キャッシュ エントリは期限切れになります。ポジティブ キャッシュ エントリは 0xbbbbbbbb0000... はまだ有効期限が切れていません。クライアントはすべてのハッシュに対して fullHashes リクエストを送信する必要があります
1 つだけです |
"threatEntries": [ {"hash": "0xcccccccc"} ] |
"matches": [ "threat": {"hash": "0xccccccccdddd..."}, "cacheDuration": "600.000s" ], "negativeCacheDuration": "3600.000s" |
一致する可能性があります。 クライアントは少なくとも 1 時間、ハッシュ接頭辞 0xcccccccc の fullHashes リクエストを送信してはならず、
安全です。ただし、URL の完全なハッシュが、キャッシュされたフルハッシュと一致する場合は除きます。
0xccccccccdddd....この場合、クライアントはその URL が 10 分間安全でないとみなす必要があります。
10 分後に完全なハッシュは期限切れになります。それ以降そのフルハッシュのルックアップは
新しい fullHashes リクエストをトリガーします。 |