Lưu vào bộ nhớ đệm

Tài liệu này áp dụng cho các phương pháp sau:

• Tra cứu API (phiên bản 4): threatMatches.find
• Cập nhật API (phiên bản 4): fullHashes.find

Giới thiệu về việc lưu vào bộ nhớ đệm

Để giảm mức sử dụng băng thông của ứng dụng và để bảo vệ Google khỏi tình trạng lưu lượng truy cập tăng đột biến, các ứng dụng của cả Bạn cần có Lookup API và Update API để tạo và duy trì bộ nhớ đệm cục bộ cho dữ liệu về các mối đe doạ. Đối với Lookup API, bộ nhớ đệm được dùng để giảm số lượng threatMatches các yêu cầu mà khách hàng gửi tới Google. Đối với Update API, bộ nhớ đệm được dùng để giảm số lượng fullHashes yêu cầu ứng dụng gửi cho Google. Giao thức lưu vào bộ nhớ đệm cho mỗi API là trình bày bên dưới.

API Lookup

Ứng dụng của Lookup API nên lưu từng mục ThreatMatch được trả về vào bộ nhớ đệm trong khoảng thời gian đã xác định bởi trường cacheDuration. Sau đó, khách hàng cần tham khảo bộ nhớ đệm trước khi thực hiện Yêu cầu threatMatches đến máy chủ. Nếu thời lượng bộ nhớ đệm cho một ThreatMatch đã trả về trước đó chưa hết hạn, khách hàng nên giả định rằng mặt hàng đó vẫn không an toàn. Đang lưu ThreatMatch mục vào bộ nhớ đệm có thể làm giảm số lượng yêu cầu API mà ứng dụng đưa ra.

Ví dụ: shouldMatch.find

Nhấp vào đường liên kết đến yêu cầu và phản hồi trong tiêu đề bảng để xem đầy đủ các ví dụ.

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

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

Cập nhật API

Để giảm tổng số yêu cầu fullHashes được gửi tới Google bằng Update API, ứng dụng để duy trì bộ nhớ đệm cục bộ. API này thiết lập hai kiểu lưu vào bộ nhớ đệm: tích cực và phủ định.

Lưu vào bộ nhớ đệm tích cực

Để ngăn khách hàng liên tục hỏi về trạng thái của một hàm băm đầy đủ không an toàn cụ thể, mỗi ThreatMatch được trả về chứa một thời lượng bộ nhớ đệm dương (do trường cacheDuration xác định), cho biết khoảng thời gian toàn bộ hàm băm được coi là không an toàn.

Lưu vào bộ nhớ đệm phủ định

Để ngăn khách hàng liên tục hỏi về trạng thái của một hàm băm đầy đủ an toàn cụ thể, mỗi phản hồi fullHashes xác định thời lượng bộ nhớ đệm âm cho tiền tố được yêu cầu (được xác định bởi negativeCacheDuration). Thời lượng này cho biết thời lượng mà tất cả hàm băm đầy đủ chứa phần tử được yêu cầu tiền tố sẽ được coi là an toàn cho các danh sách được yêu cầu, ngoại trừ những danh sách được máy chủ trả về dưới dạng không an toàn. Việc lưu vào bộ nhớ đệm này đặc biệt quan trọng vì nó ngăn chặn tình trạng quá tải lưu lượng truy cập có thể xảy ra do xung đột tiền tố hàm băm với một URL an toàn nhận được nhiều lưu lượng truy cập.

Tham khảo bộ nhớ đệm

Khi muốn kiểm tra trạng thái của một URL, trước tiên, ứng dụng sẽ tính toán toàn bộ hàm băm. Nếu toàn bộ tiền tố của hàm băm có trong cơ sở dữ liệu cục bộ, ứng dụng phải tham khảo bộ nhớ đệm trước khi gửi một yêu cầu fullHashes đến máy chủ.

Trước tiên, khách hàng nên kiểm tra xem có lượt truy cập bộ nhớ đệm dương hay không. Nếu có một bộ nhớ đệm xác định chưa hết hạn mục nhập cho toàn bộ hàm băm quan tâm, thì mục nhập này sẽ được coi là không an toàn. Nếu mục bộ nhớ đệm dương đã hết hạn thì ứng dụng phải gửi yêu cầu fullHashes đối với tiền tố cục bộ liên quan. Theo giao thức, nếu máy chủ trả về hàm băm đầy đủ, thì giao thức này sẽ được coi là không an toàn; nếu không, nó sẽ được coi là an toàn.

Nếu không có mục nhập bộ nhớ đệm dương nào cho toàn bộ hàm băm, thì ứng dụng nên kiểm tra xem có giá trị âm không kết quả tìm kiếm trong bộ nhớ cache. Nếu có một mục nhập bộ nhớ đệm phủ định chưa hết hạn cho tiền tố cục bộ được liên kết, toàn bộ hàm băm được coi là an toàn. Nếu mục nhập bộ nhớ đệm phủ định đã hết hạn hoặc không tồn tại, thì ứng dụng phải gửi một yêu cầu fullHashes đối với tiền tố cục bộ được liên kết và diễn giải phản hồi như bình thường.

Cập nhật bộ nhớ đệm

Bộ nhớ đệm của ứng dụng cần được cập nhật mỗi khi nhận được phản hồi fullHashes. Một bộ nhớ đệm dương mục nhập cần được tạo hoặc cập nhật để có hàm băm đầy đủ cho mỗi trường cacheDuration. Tiền tố hàm băm thời lượng âm của bộ nhớ đệm cũng nên được tạo hoặc cập nhật theo negativeCacheDuration của phản hồi .

Nếu yêu cầu fullHashes tiếp theo không trả về giá trị băm đầy đủ hiện mang giá trị dương đã lưu vào bộ nhớ đệm, nên máy khách không cần xoá mục nhập bộ nhớ đệm dương. Đây không phải là vấn đề đáng lo ngại trên thực tế, vì thời lượng của bộ nhớ đệm dương thường ngắn (vài phút) để có thể sửa lỗi dương tính giả.

Tình huống ví dụ

Trong ví dụ sau, giả sử h(url) là tiền tố hàm băm của URL và H(url) là hàm băm đầy đủ của URL. Tức là h(url) = SHA256(url).substr(4), H(url) = SHA256(url).

Bây giờ, giả sử một ứng dụng khách (có bộ nhớ đệm trống) truy cập example.com/ và thấy rằng h(example.com/) là trong cơ sở dữ liệu cục bộ. Máy khách yêu cầu tiền tố hàm băm h(example.com/) có độ dài đầy đủ và nhận lại hàm băm có độ dài đầy đủ H(example.com/) cùng với thời lượng bộ nhớ đệm dương là 5 phút và thời lượng bộ nhớ đệm âm là 1 giờ.

Thời lượng 5 phút dương của bộ nhớ đệm sẽ cho ứng dụng biết hàm băm có độ dài đầy đủ trong bao lâu H(example.com/) phải được xem là không an toàn khi không gửi một yêu cầu fullHashes khác. Sau 5 phút thì khách hàng phải đưa ra một yêu cầu fullHashes khác cho tiền tố h(example.com/) nếu giá trị khách hàng truy cập lại vào example.com/. Ứng dụng nên đặt lại thời lượng bộ nhớ đệm âm của tiền tố hàm băm theo phản hồi mới.

Thời lượng âm của bộ nhớ đệm (1 giờ) sẽ cho ứng dụng biết tất cả các hàm băm có độ dài đầy đủ khác trong bao lâu ngoài H(example.com/) dùng chung tiền tố h(example.com/) phải được xem là an toàn. Cho thời lượng 1 giờ, thì mọi URL sao cho h(URL) = h(example.com/) đều phải được xem là an toàn, và do đó không dẫn đến yêu cầu fullHashes (giả sử H(URL) != H(example.com/)).

Nếu phản hồi fullHashes không chứa kết quả trùng khớp và thời lượng bộ nhớ đệm âm được đặt, thì ứng dụng không được đưa ra bất kỳ yêu cầu fullHashes nào cho bất kỳ tiền tố được yêu cầu nào cho thời lượng bộ nhớ đệm âm.

Nếu phản hồi fullHashes chứa một hoặc nhiều kết quả trùng khớp, thì thời lượng bộ nhớ đệm âm vẫn được đặt cho toàn bộ câu trả lời. Trong trường hợp đó, thời lượng bộ nhớ đệm của một hàm băm đầy đủ sẽ cho biết khoảng thời gian ứng dụng phải giả định rằng hàm băm đủ thời lượng đó là không an toàn. Sau bộ nhớ đệm ThreatMatch thời lượng trôi qua, ứng dụng phải làm mới hàm băm đầy đủ bằng cách đưa ra yêu cầu fullHashes cho tiền tố hàm băm đó nếu URL được yêu cầu khớp với hàm băm đầy đủ hiện có trong bộ nhớ đệm. Trong đó trong trường hợp không áp dụng thời lượng bộ nhớ đệm âm. Thời lượng bộ nhớ đệm âm của phản hồi chỉ áp dụng vào các hàm băm có độ dài đầy đủ không có trong phản hồi fullHashes. Đối với các hàm băm có độ dài đầy đủ không có trong phản hồi, ứng dụng phải không đưa ra bất kỳ yêu cầu fullHashes nào cho đến khi thời lượng bộ nhớ đệm phủ định trôi qua.

Ví dụ: fullHashes.find

Nhấp vào đường liên kết đến yêu cầu và phản hồi trong tiêu đề bảng để xem đầy đủ các ví dụ.

"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"