กำลังแคช

เอกสารนี้ใช้กับวิธีการต่อไปนี้

เกี่ยวกับการแคช

ในการลดการใช้แบนด์วิดท์ของไคลเอ็นต์ และเพื่อปกป้อง Google จากการรับส่งข้อมูลที่เพิ่มขึ้นอย่างรวดเร็ว ไคลเอ็นต์ของทั้ง ต้องใช้ Lookup API และ Update API เพื่อสร้างและคงแคชข้อมูลภัยคุกคามไว้ในเครื่อง สำหรับ Lookup API แคชจะใช้เพื่อลดจำนวน threatMatches คำขอที่ลูกค้าส่งถึง Google สำหรับ Update API แคชจะใช้ในการลดจำนวน fullHashes คำขอที่ลูกค้าส่งถึง Google โปรโตคอลการแคชสำหรับ API แต่ละรายการคือ ตามที่ระบุไว้ด้านล่าง

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/

อัปเดต API

หากต้องการลดจำนวนคำขอ fullHashes โดยรวมที่ส่งไปยัง Google โดยใช้ Update API ไคลเอ็นต์ เพื่อดูแลรักษาแคชในเครื่อง 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/) และรับแฮชแบบเต็ม H(example.com/) พร้อมกับระยะเวลาของแคชที่เป็นบวกอยู่ที่ 5 นาที และระยะเวลาแคชเชิงลบ 1 ชั่วโมง

ระยะเวลาแคชบวก 5 นาทีจะบอกไคลเอ็นต์ว่าแฮชแบบเต็มยาวเพียงใด H(example.com/) ต้องถือว่าไม่ปลอดภัยโดยไม่ส่งคำขอ fullHashes อีก หลังผ่านไป 5 นาทีที่ไคลเอ็นต์ต้องส่งคำขอ fullHashes อีกรายการสำหรับคำนำหน้า h(example.com/) หาก เข้าชม example.com/ อีกครั้ง ไคลเอ็นต์ควรรีเซ็ตระยะเวลาแคชเชิงลบของคำนำหน้าแฮช ตามการตอบกลับใหม่

ระยะเวลาแคชเชิงลบ 1 ชั่วโมงจะบอกไคลเอ็นต์ว่าแฮชแบบเต็มอื่นๆ ทั้งหมดมีระยะเวลานานเท่าใด นอกเหนือจาก H(example.com/) ที่ใช้คำนำหน้า h(example.com/) เหมือนกันต้องถือว่าปลอดภัย สำหรับ ระยะเวลา 1 ชั่วโมง ทุก URL ที่ h(URL) = h(example.com/) ต้องถือว่าปลอดภัย และ ดังนั้นจึงไม่แสดงผลเป็นคำขอ fullHashes (สมมติว่า H(URL) != H(example.com/))

ถ้าการตอบสนองของ fullHashes มีรายการที่ตรงกันเป็น 0 และมีการตั้งค่าระยะเวลาของแคชเชิงลบ ค่า ลูกค้าต้องไม่ส่งคำขอ fullHashes สำหรับคำนำหน้าที่ระบุสำหรับ ระยะเวลาของแคชเชิงลบ

หากการตอบกลับ "fullHashes" มีรายการที่ตรงกันอย่างน้อย 1 รายการ ระบบจะยังคงตั้งค่าระยะเวลาของแคชเชิงลบไว้ สำหรับคำตอบทั้งหมด ในกรณีดังกล่าว ระยะเวลาแคชของแฮชแบบเต็มรายการเดียวจะระบุระยะเวลา ไคลเอ็นต์จะต้องคิดว่าแฮชแบบเต็มนั้นไม่ปลอดภัย หลังแคช ThreatMatch ผ่านไปแล้ว ไคลเอ็นต์ต้องรีเฟรชแฮชแบบเต็มโดยส่งคำขอ fullHashes สำหรับ หาก URL ที่ขอตรงกับแฮชแบบเต็มที่มีอยู่ในแคช ในนั้น ระบบจะไม่ใช้ระยะเวลาของแคชที่เป็นค่าลบ ระยะเวลาแคชเชิงลบของการตอบสนองจะมีผลเท่านั้น เป็นแฮชแบบเต็มที่ไม่ได้อยู่ในคำตอบ fullHashes สำหรับแฮชแบบเต็มที่ ไม่อยู่ในการตอบกลับ ไคลเอ็นต์ต้องไม่ส่งคำขอ fullHashes จนกว่าจะหมดระยะเวลาของแคชที่ลบ

ตัวอย่าง: FullHashes.find

คลิกลิงก์คำขอและการตอบกลับในส่วนหัวของตารางเพื่อดูตัวอย่างที่สมบูรณ์

คำนำหน้าแฮช
คำขอfullHashes
การจับคู่แฮชแบบเต็ม
การตอบกลับ FullHashes
ลักษณะการแคช
"threatEntries": [
  {"hash": "0xaaaaaaaa"}
]
"matches": [],
"negativeCacheDuration": "3600.000s"
ไม่มีรายการที่ตรงกัน
ไคลเอ็นต์ต้องไม่ส่งคำขอ fullHashes สำหรับคำนำหน้าแฮช 0xaaaaaaa เป็นเวลาอย่างน้อย 1 ชั่วโมง แฮชที่มีคำนำหน้า 0xaaaaaaaa จะได้รับการพิจารณาว่าปลอดภัยเป็นเวลา 1 ชั่วโมง
"threatEntries": [
  {"hash": "0xbbbbbbbb"}
]
"matches": [
 "threat": {"hash": "0xbbbbbbbb0000..."}
 "cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"
ผลลัพธ์ที่เป็นไปได้
ไคลเอ็นต์ควรพิจารณา URL ที่มีแฮชแบบเต็มเป็น 0xbbbbbb0000... ซึ่งไม่ปลอดภัยเป็นเวลา 10 นาที ควรพิจารณา URL อื่นทั้งหมดที่มีเครื่องหมายแฮชเป็น 0xbbbbbb ลักษณะนี้เป็นเวลา 5 นาที หลัง 5 แฮชนำหน้ารายการแคชเชิงลบจะหมดอายุ เนื่องจากรายการแคชเชิงบวกสำหรับ 0xbbbbbb0000... ยังไม่หมดอายุ ไคลเอ็นต์ควรส่งคำขอ fullHashes รายการสำหรับแฮชทั้งหมด ยกเว้นอันนั้น
"threatEntries": [
  {"hash": "0xcccccccc"}
]
"matches": [
 "threat": {"hash": "0xccccccccdddd..."},
 "cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"
ผลลัพธ์ที่เป็นไปได้
ไคลเอ็นต์ต้องไม่ส่งคำขอ fullHashes สำหรับคำนำหน้าแฮช 0xcccccccc เป็นเวลาอย่างน้อย 1 ชั่วโมง และถือว่า คำนำหน้าดังกล่าวเพื่อความปลอดภัย ยกเว้นในกรณีที่แฮชแบบเต็มของ URL ตรงกับแฮชแบบเต็มที่แคชไว้ 0xccccccccdddd.... ในกรณีนี้ ไคลเอ็นต์ควรถือว่า URL นั้นไม่ปลอดภัยเป็นเวลา 10 นาที หลังจาก 10 นาที แฮชแบบเต็มจะหมดอายุ การค้นหาแฮชแบบเต็มดังกล่าวในภายหลังควร เรียกคำขอ fullHashes ใหม่