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