संचय कर रहा है

यह दस्तावेज़ इन तरीकों पर लागू होता है:

• lookup API (v4): threatMatches.find
• एपीआई अपडेट करें (v4): fullHashes.find

कैश मेमोरी में सेव करने के बारे में जानकारी

क्लाइंट बैंडविड्थ के उपयोग को कम करने और Google को ट्रैफ़िक बढ़ने से बचाने के लिए, दोनों लुकअप एपीआई और अपडेट एपीआई की ज़रूरत, खतरे से जुड़े डेटा की लोकल कैश मेमोरी बनाने और उसे बनाए रखने के लिए होती है. लुकअप API के लिए, कैश मेमोरी का इस्तेमाल, threatMatches की संख्या कम करने के लिए किया जाता है आपके क्लाइंट के Google को भेजे जाने वाले अनुरोध शामिल हैं. अपडेट एपीआई के लिए, कैश मेमोरी का इस्तेमाल fullHashes अनुरोध, जिन्हें क्लाइंट Google को भेजते हैं. हर एपीआई के लिए कैश मेमोरी का प्रोटोकॉल है नीचे बताया गया है.

लुकअप एपीआई

लुकअप एपीआई के क्लाइंट को, दी गई अवधि के दौरान लौटाए गए हर ThreatMatch आइटम को कैश मेमोरी में सेव करना चाहिए इसके लिए, कैश मेमोरी की अवधि वाले फ़ील्ड का इस्तेमाल करें. फिर क्लाइंट को अगला कदम उठाने से पहले, कैश मेमोरी से सलाह लेनी होगी threatMatches ने सर्वर से अनुरोध किया. अगर पहले से लौटाए गए ThreatMatch के लिए कैश मेमोरी की अवधि अभी तक खत्म नहीं हुआ है, तो क्लाइंट को यह मान लेना चाहिए कि आइटम अब भी असुरक्षित है. ThreatMatch आइटम को कैश मेमोरी में सेव किया जा रहा है क्लाइंट की ओर से किए गए एपीआई अनुरोधों की संख्या कम कर सकता है.

उदाहरण: audienceMatches.find

सभी उदाहरणों के लिए टेबल हेडर में अनुरोध और रिस्पॉन्स लिंक पर क्लिक करें.

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

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

एपीआई अपडेट करें

अपडेट एपीआई का इस्तेमाल करके 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

सभी उदाहरणों के लिए टेबल हेडर में अनुरोध और रिस्पॉन्स लिंक पर क्लिक करें.

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