캐싱

이 문서는 다음 메서드에 적용됩니다.

• Lookup API (v4) threatMatches.find
• Update API (v4): fullHashes.find

캐싱 정보

클라이언트 대역폭 사용량을 줄이고 트래픽 급증으로부터 Google을 보호하기 위해 Lookup API 및 Update API는 위협 데이터의 로컬 캐시를 생성하고 유지하는 데 필요합니다. Lookup API의 경우 캐시를 사용하여 threatMatches 수를 줄입니다. 요청을 전송하는 데 사용됩니다. Update API의 경우 캐시를 사용하여 클라이언트가 Google에 보내는 fullHashes 요청 수를 줄입니다. 각 API의 캐싱 프로토콜은 참조하세요.

Lookup API

Lookup API의 클라이언트는 반환된 각 ThreatMatch 항목을 정의된 기간 동안 캐시해야 합니다. cacheDuration 필드를 기준으로 합니다. 그런 다음 클라이언트는 후속 작업을 수행하기 전에 캐시를 참조해야 합니다. threatMatches 요청을 서버에 보냅니다. 이전에 반환된 ThreatMatch의 캐시 기간이 다음과 같은 경우 만료되지 않은 경우 클라이언트는 항목이 여전히 안전하지 않다고 가정해야 합니다. 항목 ThreatMatch개 캐싱 중 클라이언트의 API 요청 수를 줄일 수 있습니다.

예: ThreatMatch.find

전체 예를 보려면 표 헤더에서 요청 및 응답 링크를 클릭하세요.

"threatEntries": [
 {"url": "http://www.urltocheck.org/"}
]

"matches": [{
 "threat": {"url": "http://www.urltocheck.org/"},
 "cacheDuration": "300.000s"
}]

Update API

Update API를 사용하여 Google에 전송되는 전체 fullHashes 요청 수를 줄이기 위해 클라이언트 몇 가지 요구사항이 있을 수 있습니다 API는 양성 및 음성의 두 가지 캐싱 유형을 설정합니다.

양성 캐싱

클라이언트가 특정 안전하지 않은 전체 해시의 상태에 대해 반복적으로 묻지 않도록 하려면 반환된 각 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/)에 대한 전체 길이 해시를 요청합니다. 전체 길이 해시 H(example.com/)를 다시 수신하여 포지티브 캐시 기간 5 1시간의 음수 캐시 기간이 있습니다

포지티브 캐시 기간 5분은 클라이언트에게 전체 길이 해시가 얼마나 긴지 알려줍니다. H(example.com/)는 다른 fullHashes 요청을 전송하지 않으면 안전하지 않은 것으로 간주되어야 합니다. 5일 후 분에 해당하는 경우 클라이언트는 해당 접두사 h(example.com/)에 대해 또 다른 fullHashes 요청을 실행해야 합니다. 고객이 example.com/ 을 다시 방문합니다. 클라이언트는 해시 프리픽스의 음수 캐시 기간을 재설정해야 합니다. 새 응답마다

1시간의 네거티브 캐시 기간은 다른 모든 전체 길이 해시가 얼마나 긴지를 클라이언트에 알려줍니다. H(example.com/) 외에도 h(example.com/)의 동일한 접두사를 공유하는 모든 URL이 안전한 것으로 간주되어야 합니다. 대상 h(URL) = h(example.com/) 와 같은 모든 URL은 안전한 것으로 간주되어야 합니다. 따라서 fullHashes 요청이 발생하지 않습니다 (H(URL) != H(example.com/)라고 가정).

fullHashes 응답에 일치하는 항목이 0개 포함되어 있고 캐시 기간이 음수로 설정되어 있으면 클라이언트는 지정된 fullHashes 음수 캐시 기간

fullHashes 응답에 일치하는 항목이 하나 이상 포함된 경우에도 음수 캐시 기간이 설정됩니다. 확인할 수 있습니다 이 경우, 단일 전체 해시의 캐시 기간은 특정 전체 길이 해시를 클라이언트가 안전하지 않은 것으로 간주해야 합니다. ThreatMatch 캐시 이후 기간이 경과하면 클라이언트는 fullHashes 요청에 대해 전체 길이 해시를 새로 고쳐야 합니다. 해당 해시 접두어를 추가합니다. 그 안에서 음수 캐시 기간이 적용되지 않습니다 응답의 음성 캐시 기간은 fullHashes 응답에 없는 전체 길이의 해시로 변환되었습니다. 전체 길이 해시의 경우 응답이 없는 경우 클라이언트는 fullHashes 요청을 실행해서는 안 됩니다. 네거티브 캐시 기간이 경과할 때까지

예: fullHashes.find

전체 예를 보려면 표 헤더에서 요청 및 응답 링크를 클릭하세요.

"threatEntries": [
  {"hash": "0xaaaaaaaa"}
]

"matches": [],
"negativeCacheDuration": "3600.000s"

"threatEntries": [
  {"hash": "0xbbbbbbbb"}
]

"matches": [
 "threat": {"hash": "0xbbbbbbbb0000..."}
 "cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"

"threatEntries": [
  {"hash": "0xcccccccc"}
]

"matches": [
 "threat": {"hash": "0xccccccccdddd..."},
 "cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"