यह दस्तावेज़ नीचे दिए गए तरीकों पर लागू होता है:
कैशिंग के बारे में
क्लाइंट बैंडविथ का इस्तेमाल कम करने और Google को ट्रैफ़िक में आने वाली बढ़ोतरी से बचाने के लिए,
lookup API और Update API, दोनों के क्लाइंट को खतरे से जुड़े डेटा का लोकल कैश मेमोरी बनाना और उसे बनाए रखना ज़रूरी होगा.
लुकअप एपीआई के लिए, कैश मेमोरी का इस्तेमाल threatMatches
अनुरोधों की संख्या को कम करने के लिए किया जाता है, जो क्लाइंट Google को भेजते हैं. Update API के लिए, कैश मेमोरी का इस्तेमाल किया जाता है. इससे, क्लाइंट की ओर से Google को भेजे जाने वाले fullHashes अनुरोधों की संख्या कम हो जाती है. हर एपीआई के लिए कैश मेमोरी का प्रोटोकॉल नीचे बताया गया है.
लुकअप एपीआई
लुकअप एपीआई के क्लाइंट को, लौटाए गए हर ThreatMatch आइटम को कैश अवधि फ़ील्ड के हिसाब से तय की गई अवधि तक कैश मेमोरी में रखना चाहिए. क्लाइंट को बाद में सर्वर को threatMatches का अनुरोध करने से पहले, कैश मेमोरी से सलाह लेनी होगी. अगर पहले लौटाए गए ThreatMatch की कैश मेमोरी की अवधि अभी तक खत्म नहीं हुई है, तो क्लाइंट को यह मानना चाहिए कि आइटम अब भी असुरक्षित है. ThreatMatch आइटम कैश मेमोरी में सेव करने से,
क्लाइंट के एपीआई अनुरोधों की संख्या कम हो सकती है.
उदाहरण: धमकी Matches.find
सभी उदाहरणों के लिए, टेबल हेडर में अनुरोध और जवाब के लिंक पर क्लिक करें.
| यूआरएल की जांच threatmatches अनुरोध |
यूआरएल मैच threatmatches जवाब |
कैश मेमोरी में सेव होने वाला व्यवहार |
|---|---|---|
"threatEntries": [
{"url": "http://www.urltocheck.org/"}
]
|
"matches": [{
"threat": {"url": "http://www.urltocheck.org/"},
"cacheDuration": "300.000s"
}]
|
मिलता-जुलता वीडियो. यूआरएल http://www.urltocheck.org/ वाला नया threatMatches अनुरोध भेजने से पहले, क्लाइंट को पांच मिनट तक इंतज़ार करना होगा.
|
एपीआई अपडेट करें
Update API का इस्तेमाल करके, Google को भेजे जाने वाले fullHashes अनुरोधों की कुल संख्या को कम करने के लिए, क्लाइंट को लोकल कैश मेमोरी बनाए रखनी होगी. यह एपीआई दो तरह से कैश मेमोरी में सेव करने के दो तरीके तय करता है, पॉज़िटिव और नेगेटिव.
पॉज़िटिव कैशिंग
क्लाइंट को किसी खास असुरक्षित हैश की स्थिति के बारे में बार-बार पूछने से रोकने के लिए, रिस्पॉन्स में मिले हर ThreatMatch में कैश मेमोरी का कुल समय (cacheDuration फ़ील्ड से तय किया जाता है) होता है. इससे पता चलता है कि पूरे हैश को कितने समय तक असुरक्षित माना जाना चाहिए.
नेगेटिव कैश मेमोरी
क्लाइंट को किसी खास सुरक्षित हैश की स्थिति के बारे में बार-बार पूछने से रोकने के लिए,
हर fullHashes रिस्पॉन्स, अनुरोध किए गए प्रीफ़िक्स (negativeCacheDuration फ़ील्ड से तय किया गया) के लिए कैश मेमोरी की अवधि के बारे में बताता है. इस अवधि से पता चलता है कि अनुरोध किए गए प्रीफ़िक्स वाले सभी हैश को कितनी देर तक, अनुरोध की गई सूचियों के लिए सुरक्षित माना जाता है. हालांकि, सर्वर से मिले सभी हैश को असुरक्षित माना जाता है. यह कैश मेमोरी खास तौर पर अहम होती है, क्योंकि यह बहुत ज़्यादा ट्रैफ़िक पाने वाले सुरक्षित यूआरएल के साथ हैश प्रीफ़िक्स की टकराव की वजह से ट्रैफ़िक ओवरलोड को रोकती है.
कैश मेमोरी से जुड़ी जानकारी
जब क्लाइंट किसी यूआरएल की स्थिति की जांच करना चाहता है, तो वह पहले पूरे हैश की गिनती करता है. अगर पूरा हैश प्रीफ़िक्स लोकल डेटाबेस में मौजूद है, तो क्लाइंट को सर्वर को fullHashes अनुरोध करने से पहले कैश मेमोरी से जुड़ी जानकारी देखनी चाहिए.
सबसे पहले, क्लाइंट को पॉज़िटिव कैश हिट की जांच करनी चाहिए. अगर इंटरेस्ट के पूरे हैश के लिए ऐसी पॉज़िटिव कैश एंट्री मौजूद है जिसकी समयसीमा खत्म नहीं हुई है, तो इसे असुरक्षित माना जाना चाहिए. अगर पॉज़िटिव कैश एंट्री की समयसीमा खत्म हो जाती है, तो क्लाइंट को इससे जुड़े लोकल प्रीफ़िक्स के लिए, fullHashes अनुरोध भेजना होगा. प्रोटोकॉल के मुताबिक, अगर सर्वर पूरा हैश लौटाता है, तो उसे असुरक्षित माना जाता है. ऐसा न करने पर उसे सुरक्षित माना जाता है.
अगर पूरे हैश के लिए कोई पॉज़िटिव कैश एंट्री नहीं है, तो क्लाइंट को नेगेटिव कैश हिट की जांच करनी चाहिए. अगर इससे जुड़े लोकल प्रीफ़िक्स के लिए ऐसी नेगेटिव कैश एंट्री मौजूद है जिसकी समयसीमा खत्म नहीं हुई है, तो पूरे हैश को सुरक्षित माना जाता है. अगर नेगेटिव कैश एंट्री की समयसीमा खत्म हो गई है या वह मौजूद नहीं है, तो क्लाइंट को इससे जुड़े लोकल प्रीफ़िक्स के लिए, fullHashes अनुरोध भेजना होगा. साथ ही, रिस्पॉन्स को सामान्य तौर पर समझना होगा.
कैश मेमोरी अपडेट की जा रही है
fullHashes रिस्पॉन्स मिलने पर, क्लाइंट कैश मेमोरी को अपडेट कर दिया जाना चाहिए. हर cacheDuration फ़ील्ड के लिए, पूरे हैश के लिए एक पॉज़िटिव कैश एंट्री बनाई या अपडेट की जानी चाहिए. हैश प्रीफ़िक्स की नेगेटिव कैश अवधि को रिस्पॉन्स के negativeCacheDuration फ़ील्ड के मुताबिक भी बनाया या अपडेट किया जाना चाहिए.
अगर बाद के fullHashes अनुरोध से, पॉज़िटिव कैश मेमोरी में सेव किया गया पूरा हैश नहीं मिलता है, तो क्लाइंट को पॉज़िटिव कैश एंट्री हटाने की ज़रूरत नहीं है. ऐसा इसलिए नहीं होना चाहिए, क्योंकि फ़ॉल्स पॉज़िटिव को तुरंत ठीक करने के लिए पॉज़िटिव कैश मेमोरी की अवधि आम तौर पर कम (कुछ मिनट) होती है.
उदाहरण के तौर पर
नीचे दिए गए उदाहरण में, मान लें कि h(url) यूआरएल का हैश प्रीफ़िक्स है और H(url), यूआरएल का पूरी लंबाई वाला हैश है. इसका मतलब है कि h(url) = SHA256(url).substr(4), H(url) = SHA256(url).
अब, मान लें कि कोई क्लाइंट (खाली कैश मेमोरी वाला) example.com/ पर जाता है और देखता है कि h(example.com/) लोकल डेटाबेस में मौजूद है. क्लाइंट, हैश प्रीफ़िक्स h(example.com/) के लिए, पूरी अवधि वाले हैश का अनुरोध करता है. इसके बाद, वह पांच मिनट की पॉज़िटिव कैश अवधि और एक घंटे की नेगेटिव कैश अवधि के साथ, पूरी लंबाई वाले हैश H(example.com/) को वापस पाता है.
पांच मिनट की पॉज़िटिव कैश अवधि से क्लाइंट को यह पता चलता है कि पूरी अवधि वाले हैश
H(example.com/) को कितनी देर तक असुरक्षित माना जाना चाहिए. इसके लिए, fullHashes का दूसरा अनुरोध नहीं भेजा जाना चाहिए. अगर क्लाइंट पांच मिनट बाद फिर से example.com/ पर जाता है, तो उसे h(example.com/) प्रीफ़िक्स के लिए, एक और fullHashes अनुरोध भेजना होगा. क्लाइंट को नए रिस्पॉन्स के हिसाब से, हैश प्रीफ़िक्स की नेगेटिव कैश अवधि को रीसेट करना होगा.
एक घंटे की नेगेटिव कैश अवधि से क्लाइंट को यह पता चलता है कि H(example.com/) के अलावा, h(example.com/) के एक जैसे प्रीफ़िक्स वाले, बाकी पूरी अवधि वाले हैश को कितना सुरक्षित माना जाना चाहिए. एक घंटे की अवधि के लिए, हर यूआरएल, जैसे कि h(URL) = h(example.com/) को सुरक्षित माना जाना चाहिए. इस वजह से, fullHashes अनुरोध नहीं मिलता (यह मानते हुए कि H(URL) != H(example.com/)).
अगर fullHashes रिस्पॉन्स में शून्य मैच होता है और कैश मेमोरी की अवधि नेगेटिव सेट की जाती है, तो क्लाइंट को दी गई नेगेटिव कैश अवधि के लिए, अनुरोध किए गए किसी भी प्रीफ़िक्स के लिए कोई fullHashes अनुरोध जारी नहीं करना चाहिए.
अगर fullHashes रिस्पॉन्स में एक या उससे ज़्यादा मैच होते हैं, तो पूरे रिस्पॉन्स के लिए नेगेटिव कैश मेमोरी अब भी सेट है. ऐसे मामले में, किसी एक पूरे हैश की कैश मेमोरी की अवधि से पता चलता है कि क्लाइंट के लिए उस पूरी लंबाई वाले हैश को कितनी देर तक असुरक्षित माना जाना चाहिए. अगर अनुरोध किया गया यूआरएल, कैश मेमोरी में मौजूद पूरी अवधि वाले हैश से मेल खाता है, तो ThreatMatch कैश मेमोरी की अवधि खत्म होने के बाद, क्लाइंट को उस हैश प्रीफ़िक्स के लिए fullHashes अनुरोध जारी करके, पूरी अवधि वाले हैश को रीफ़्रेश करना होगा. उस स्थिति में
नेगेटिव कैश अवधि लागू नहीं होती. रिस्पॉन्स की नेगेटिव कैश मेमोरी सिर्फ़ उन पूरी हैश पर लागू होती है जो fullHashes रिस्पॉन्स में मौजूद नहीं थे. रिस्पॉन्स में मौजूद नहीं होने वाले पूरी लंबाई वाले हैश के लिए, क्लाइंट को तब तक कोई भी fullHashes अनुरोध जारी नहीं करना चाहिए, जब तक नेगेटिव कैश मेमोरी की अवधि खत्म न हो जाए.
उदाहरण: FullHashes.find
सभी उदाहरणों के लिए, टेबल हेडर में अनुरोध और जवाब के लिंक पर क्लिक करें.
| हैश प्रीफ़िक्स fullHashes अनुरोध |
पूरी अवधि वाले हैश, से मेल खाते हैं fullHashes रिस्पॉन्स |
कैश मेमोरी में सेव होने वाला व्यवहार |
|---|---|---|
"threatEntries": [
{"hash": "0xaaaaaaaa"}
]
|
"matches": [], "negativeCacheDuration": "3600.000s" |
कोई मिलान नहीं. क्लाइंट को कम से कम एक घंटे तक, हैश प्रीफ़िक्स 0xaaaaaaa के लिए fullHashes का कोई अनुरोध नहीं भेजना चाहिए.
0xaaaaaaa प्रीफ़िक्स वाले किसी भी हैश को एक घंटे के लिए सुरक्षित माना जाता है. |
"threatEntries": [
{"hash": "0xbbbbbbbb"}
]
|
"matches": [
"threat": {"hash": "0xbbbbbbbb0000..."}
"cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"
|
संभावित मिलान. क्लाइंट को पूरे हैश 0xbbbbbb0000... वाले यूआरएल को 10 मिनट तक असुरक्षित समझना चाहिए. क्लाइंट को पांच मिनट के लिए, हैश प्रीफ़िक्स 0xbbbbbbb वाले दूसरे सभी यूआरएल को सुरक्षित रखना चाहिए. पांच मिनट के बाद, हैश प्रीफ़िक्स नेगेटिव कैश एंट्री की समयसीमा खत्म हो जाएगी. 0xbbbbbb00000... के लिए कैश एंट्री की समय सीमा अभी तक खत्म नहीं हुई है. इसलिए, क्लाइंट को हैश के अलावा सभी हैश के लिए fullHashes अनुरोध भेजने चाहिए. |
"threatEntries": [
{"hash": "0xcccccccc"}
]
|
"matches": [
"threat": {"hash": "0xccccccccdddd..."},
"cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"
|
संभावित मिलान. क्लाइंट को कम से कम 1 घंटे तक, हैश प्रीफ़िक्स 0xcccccc के लिए fullHashes अनुरोध नहीं भेजना चाहिए. साथ ही, यह समझना ज़रूरी है कि प्रीफ़िक्स सुरक्षित है. अगर यूआरएल का पूरा हैश, कैश मेमोरी में सेव किए गए पूरे हैश से मेल खाता है, तो ऐसे में, क्लाइंट को यह समझना चाहिए कि वह यूआरएल 10 मिनट तक असुरक्षित है.
10 मिनट के बाद, हैश की समयसीमा खत्म हो जाती है. पूरे हैश के बाद के किसी भी लुकअप से एक नया fullHashes अनुरोध ट्रिगर होना चाहिए. |