এই নথিটি নিম্নলিখিত পদ্ধতিতে প্রযোজ্য:
ক্যাশিং সম্পর্কে
ক্লায়েন্ট ব্যান্ডউইথের ব্যবহার কমাতে এবং ট্রাফিক স্পাইক থেকে Google কে রক্ষা করতে, লুকআপ এপিআই এবং আপডেট এপিআই উভয়ের ক্লায়েন্টদের হুমকি ডেটার স্থানীয় ক্যাশে তৈরি এবং বজায় রাখতে হবে। Lookup API-এর জন্য, ক্লায়েন্টরা Google-এ যে threatMatches অনুরোধ পাঠায় তার সংখ্যা কমাতে ক্যাশে ব্যবহার করা হয়। Update API-এর জন্য, ক্লায়েন্টরা Google-এ পাঠানো fullHashes অনুরোধের সংখ্যা কমাতে ক্যাশে ব্যবহার করা হয়। প্রতিটি API-এর জন্য ক্যাশিং প্রোটোকল নীচে বর্ণিত হয়েছে।
লুকআপ API
লুকআপ এপিআই-এর ক্লায়েন্টদের ক্যাশে ডিউরেশন ফিল্ড দ্বারা নির্ধারিত সময়কালের জন্য প্রতিটি ফেরত দেওয়া ThreatMatch আইটেম ক্যাশে করা উচিত। ক্লায়েন্টদের তারপর সার্ভারে পরবর্তী threatMatches অনুরোধ করার আগে ক্যাশের সাথে পরামর্শ করতে হবে। যদি পূর্বে ফিরে আসা ThreatMatch এর ক্যাশের সময়কাল এখনও মেয়াদোত্তীর্ণ না হয়, তাহলে ক্লায়েন্টকে ধরে নিতে হবে যে আইটেমটি এখনও অনিরাপদ। ThreatMatch আইটেম ক্যাশিং ক্লায়েন্ট দ্বারা করা API অনুরোধের সংখ্যা কমাতে পারে।
উদাহরণ: ਧਮਕੀম্যাচস.ফাইন্ড
সম্পূর্ণ উদাহরণের জন্য টেবিল হেডারে অনুরোধ এবং প্রতিক্রিয়া লিঙ্কে ক্লিক করুন।
| ইউআরএল চেক হুমকি ম্যাচ অনুরোধ | ইউআরএল মিল হুমকি ম্যাচ প্রতিক্রিয়া | ক্যাশিং আচরণ |
|---|---|---|
"threatEntries": [
{"url": "http://www.urltocheck.org/"}
]
|
"matches": [{
"threat": {"url": "http://www.urltocheck.org/"},
"cacheDuration": "300.000s"
}]
| ম্যাচ. URL http://www.urltocheck.org/ সহ একটি নতুন threatMatches অনুরোধ পাঠানোর আগে ক্লায়েন্টকে অবশ্যই 5 মিনিট অপেক্ষা করতে হবে। |
এপিআই আপডেট করুন
আপডেট API ব্যবহার করে Google-এ পাঠানো fullHashes অনুরোধের সামগ্রিক সংখ্যা কমাতে, ক্লায়েন্টদের একটি স্থানীয় ক্যাশে বজায় রাখতে হবে। API দুই ধরনের ক্যাশে স্থাপন করে, পজিটিভ এবং নেগেটিভ।
ইতিবাচক ক্যাশিং
ক্লায়েন্টদের বারবার একটি নির্দিষ্ট অনিরাপদ পূর্ণ হ্যাশের অবস্থা সম্পর্কে জিজ্ঞাসা করা থেকে বিরত রাখতে, প্রতিটি ফেরত দেওয়া 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/) এর জন্য পূর্ণ-দৈর্ঘ্যের হ্যাশের জন্য অনুরোধ করে এবং 5 মিনিটের একটি ইতিবাচক ক্যাশে সময়কাল এবং 1 ঘন্টার একটি নেতিবাচক ক্যাশে সময়কাল সহ পূর্ণ-দৈর্ঘ্যের হ্যাশ H(example.com/) ফিরে পায়। .
5 মিনিটের ইতিবাচক ক্যাশের সময়কাল ক্লায়েন্টকে বলে যে কতক্ষণ পূর্ণ-দৈর্ঘ্যের হ্যাশ H(example.com/) অন্য একটি fullHashes অনুরোধ না পাঠিয়ে অনিরাপদ বিবেচিত হবে। 5 মিনিটের পরে ক্লায়েন্টকে অবশ্যই সেই উপসর্গ h(example.com/) এর জন্য আরেকটি fullHashes অনুরোধ জারি করতে হবে যদি ক্লায়েন্ট আবার example.com/ ভিজিট করে। নতুন প্রতিক্রিয়া অনুযায়ী ক্লায়েন্টের হ্যাশ প্রিফিক্সের নেতিবাচক ক্যাশে সময়কাল রিসেট করা উচিত।
1 ঘন্টার নেতিবাচক ক্যাশে সময়কাল ক্লায়েন্টকে বলে যে H(example.com/) ছাড়াও অন্যান্য সমস্ত পূর্ণ-দৈর্ঘ্যের হ্যাশগুলি যেগুলি h(example.com/) এর একই উপসর্গ ভাগ করে সেগুলিকে নিরাপদ বলে বিবেচনা করা আবশ্যক৷ 1 ঘন্টার জন্য, প্রতিটি ইউআরএল যেমন h(URL) = h(example.com/) অবশ্যই নিরাপদ বলে বিবেচিত হবে এবং এর ফলে fullHashes অনুরোধ আসবে না (ধরে নিচ্ছি যে H(URL)!= H(example.com) /))।
যদি fullHashes প্রতিক্রিয়াতে শূন্য ম্যাচ থাকে এবং একটি নেতিবাচক ক্যাশে সময়কাল সেট করা থাকে, তাহলে ক্লায়েন্টকে প্রদত্ত নেতিবাচক ক্যাশে সময়কালের জন্য অনুরোধকৃত উপসর্গগুলির জন্য কোনও fullHashes অনুরোধ জারি করা উচিত নয়।
যদি fullHashes প্রতিক্রিয়াতে এক বা একাধিক মিল থাকে, তবে সম্পূর্ণ প্রতিক্রিয়ার জন্য একটি নেতিবাচক ক্যাশের সময়কাল এখনও সেট করা থাকে। সেক্ষেত্রে, একটি একক পূর্ণ হ্যাশের ক্যাশের সময়কাল নির্দেশ করে যে নির্দিষ্ট পূর্ণ-দৈর্ঘ্যের হ্যাশটিকে ক্লায়েন্টের দ্বারা কতক্ষণ অনিরাপদ ধরে নিতে হবে। ThreatMatch ক্যাশের সময়কাল শেষ হয়ে যাওয়ার পরে, ক্লায়েন্টকে সেই হ্যাশ উপসর্গের জন্য একটি fullHashes অনুরোধ জারি করে পূর্ণ-দৈর্ঘ্যের হ্যাশ রিফ্রেশ করতে হবে যদি অনুরোধ করা URL ক্যাশে বিদ্যমান পূর্ণ-দৈর্ঘ্য হ্যাশের সাথে মেলে। সেই ক্ষেত্রে নেতিবাচক ক্যাশে সময়কাল প্রযোজ্য নয়। প্রতিক্রিয়ার নেতিবাচক ক্যাশের সময়কাল শুধুমাত্র পূর্ণ-দৈর্ঘ্যের হ্যাশগুলিতে প্রযোজ্য যা fullHashes প্রতিক্রিয়াতে উপস্থিত ছিল না। পূর্ণ-দৈর্ঘ্যের হ্যাশগুলির জন্য যা প্রতিক্রিয়াতে উপস্থিত নেই, ক্লায়েন্টকে অবশ্যই নেতিবাচক ক্যাশে সময়কাল অতিবাহিত না হওয়া পর্যন্ত কোনও fullHashes অনুরোধ জারি করা থেকে বিরত থাকতে হবে।
উদাহরণ: fullHashes.find
সম্পূর্ণ উদাহরণের জন্য টেবিল হেডারে অনুরোধ এবং প্রতিক্রিয়া লিঙ্কে ক্লিক করুন।
| হ্যাশ উপসর্গ fullHashes অনুরোধ | পূর্ণ-দৈর্ঘ্যের হ্যাশ মিল fullHashes প্রতিক্রিয়া | ক্যাশিং আচরণ |
|---|---|---|
"threatEntries": [
{"hash": "0xaaaaaaaa"}
]
| "matches": [], "negativeCacheDuration": "3600.000s" | মিল নেই. ক্লায়েন্টকে অন্তত এক ঘণ্টার জন্য হ্যাশ প্রিফিক্স 0xaaaaaaaa-এর জন্য কোনো fullHashes অনুরোধ পাঠাতে হবে না। 0xaaaaaaaa উপসর্গ সহ যেকোন হ্যাশ এক ঘন্টার জন্য নিরাপদ বলে মনে করা হয়। |
"threatEntries": [
{"hash": "0xbbbbbbbb"}
]
|
"matches": [
"threat": {"hash": "0xbbbbbbbb0000..."}
"cacheDuration": "600.000s",
],
"negativeCacheDuration": "300.000s"
| সম্ভাব্য মিল। ক্লায়েন্টকে 10 মিনিটের জন্য সম্পূর্ণ হ্যাশ 0xbbbbbbbb0000… অনিরাপদ যুক্ত URL বিবেচনা করা উচিত। ক্লায়েন্টকে 5 মিনিটের জন্য হ্যাশ প্রিফিক্স 0xbbbbbbbb সহ অন্যান্য সমস্ত URL গুলিকে নিরাপদ বিবেচনা করা উচিত। 5 মিনিট পরে, হ্যাশ প্রিফিক্স নেতিবাচক ক্যাশে এন্ট্রির মেয়াদ শেষ হয়ে যাবে। যেহেতু 0xbbbbbbbb0000...এর জন্য ইতিবাচক ক্যাশে এন্ট্রির মেয়াদ এখনও শেষ হয়নি, তাই ক্লায়েন্টকে সেই একটি ছাড়া সব হ্যাশের জন্য fullHashes অনুরোধ পাঠাতে হবে। |
"threatEntries": [
{"hash": "0xcccccccc"}
]
|
"matches": [
"threat": {"hash": "0xccccccccdddd..."},
"cacheDuration": "600.000s"
],
"negativeCacheDuration": "3600.000s"
| সম্ভাব্য মিল। ক্লায়েন্টকে অবশ্যই কমপক্ষে 1 ঘন্টার জন্য হ্যাশ প্রিফিক্স 0xcccccccc-এর জন্য কোনো fullHashes অনুরোধ পাঠাতে হবে না এবং সেই উপসর্গটিকে নিরাপদ বলে ধরে নিতে হবে — ব্যতীত যদি URL এর সম্পূর্ণ হ্যাশ ক্যাশে করা সম্পূর্ণ হ্যাশ 0xccccccccdddd-এর সাথে মেলে.... সেক্ষেত্রে ক্লায়েন্টের সেই URLটি বিবেচনা করা উচিত 10 মিনিটের জন্য অনিরাপদ হতে। 10 মিনিটের পরে পূর্ণ-দৈর্ঘ্যের হ্যাশের মেয়াদ শেষ হয়ে যায়। সেই পূর্ণ হ্যাশের জন্য পরবর্তী যে কোনো লুকআপ একটি নতুন fullHashes অনুরোধ ট্রিগার করবে। |