این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

ذخیره سازی

این سند برای روش های زیر اعمال می شود:

درباره کش

برای کاهش استفاده از پهنای باند مشتری و محافظت از Google در برابر افزایش ترافیک، مشتریان هر دو API Lookup و Update API ملزم به ایجاد و نگهداری حافظه پنهان محلی از داده‌های تهدید هستند. برای Lookup API، حافظه پنهان برای کاهش تعداد درخواست‌های threatMatches که مشتریان به Google ارسال می‌کنند، استفاده می‌شود. برای Update API، حافظه پنهان برای کاهش تعداد درخواست‌های fullHashes که مشتریان به Google ارسال می‌کنند، استفاده می‌شود. پروتکل کش برای هر API در زیر مشخص شده است.

جستجوی API

کلاینت های Lookup API باید هر مورد ThreatMatch بازگشتی را برای مدت زمانی که توسط فیلد cacheDuration آن تعریف شده است، در حافظه پنهان نگه دارند. پس از آن، کلاینت‌ها باید قبل از درخواست بعدی threatMatches با سرور، با کش مشورت کنند. اگر مدت زمان کش برای ThreatMatch قبلاً بازگردانده شده هنوز منقضی نشده باشد، مشتری باید فرض کند که مورد هنوز ایمن نیست. ذخیره موارد ThreatMatch ممکن است تعداد درخواست های API ارائه شده توسط مشتری را کاهش دهد.

مثال: gefMatches.find

برای مثال های کامل روی پیوندهای درخواست و پاسخ در سرفصل جدول کلیک کنید.

بررسی URL درخواست تطبیق تهدید	URL مطابقت دارد پاسخ به تهدیدات	رفتار حافظه پنهان
"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 دو نوع حافظه پنهان، مثبت و منفی ایجاد می کند.

ذخیره سازی مثبت

برای جلوگیری از پرسیدن مکرر مشتریان در مورد وضعیت یک هش کامل ناامن خاص، هر 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 دقیقه، اگر مشتری دوباره از example.com/ بازدید کند، مشتری باید یک درخواست fullHashes دیگر برای آن پیشوند h(example.com/) صادر کند. مشتری باید مدت زمان کش منفی پیشوند هش را در هر پاسخ جدید بازنشانی کند.

مدت زمان کش منفی 1 ساعت به مشتری می گوید که چه مدت باید تمام هش های تمام قد به غیر از H(example.com/) که پیشوند یکسانی h(example.com/) دارند، ایمن در نظر گرفته شوند. برای مدت 1 ساعت، هر URL به گونه‌ای که h(URL) = h(example.com/) باید ایمن در نظر گرفته شود، و بنابراین منجر به درخواست fullHashes نمی‌شود (با فرض اینکه H(URL) != H(example.com /)).

اگر پاسخ fullHashes حاوی صفر منطبق باشد و مدت زمان کش منفی تنظیم شده باشد، کلاینت نباید هیچ درخواست fullHashes برای هیچ یک از پیشوندهای درخواستی برای مدت زمان کش منفی داده شده صادر کند.

اگر پاسخ fullHashes شامل یک یا چند مورد منطبق باشد، مدت زمان کش منفی همچنان برای کل پاسخ تنظیم می شود. در آن صورت، مدت زمان کش یک هش کامل نشان می‌دهد که چه مدت باید آن هش تمام طول خاص توسط مشتری ناامن فرض شود. پس از سپری شدن مدت زمان کش ThreatMatch ، اگر URL درخواستی با هش تمام طول موجود در حافظه پنهان مطابقت داشته باشد، مشتری باید با صدور یک درخواست fullHashes برای آن پیشوند هش، هش کامل را بازخوانی کند. در آن صورت مدت زمان کش منفی اعمال نمی شود. مدت زمان کش منفی پاسخ فقط برای هش های تمام طولی اعمال می شود که در پاسخ fullHashes وجود نداشتند. برای درهم‌سازی‌های تمام‌قد که در پاسخ وجود ندارند، مشتری باید تا زمان سپری شدن مدت زمان کش منفی از صدور هرگونه درخواست fullHashes خودداری کند.

مثال: fullHashes.find

برای مثال های کامل روی پیوندهای درخواست و پاسخ در سرفصل جدول کلیک کنید.

پیشوندهای هش درخواست fullHashs	مسابقات هش تمام قد پاسخ fullHashes	رفتار حافظه پنهان
"threatEntries": [ {"hash": "0xaaaaaaaa"} ]	"matches": [], "negativeCacheDuration": "3600.000s"	مطابقت ندارد. مشتری نباید برای حداقل یک ساعت هیچ درخواست `fullHashes` برای پیشوند هش 0xaaaaaaaa ارسال کند. هر هش با پیشوند 0xaaaaaaaa به مدت یک ساعت بی خطر در نظر گرفته می شود.
"threatEntries": [ {"hash": "0xbbbbbbbb"} ]	"matches": [ "threat": {"hash": "0xbbbbbbbb0000..."} "cacheDuration": "600.000s", ], "negativeCacheDuration": "300.000s"	مسابقات احتمالی مشتری باید URL را با هش کامل 0xbbbbbbbb0000… برای 10 دقیقه ناامن در نظر بگیرد. مشتری باید همه URL های دیگر با پیشوند هش 0xbbbbbbbb را به مدت 5 دقیقه امن در نظر بگیرد. پس از 5 دقیقه، ورودی کش منفی پیشوندهای هش منقضی می شود. از آنجایی که ورودی cache مثبت برای 0xbbbbbbbb0000… هنوز منقضی نشده است، مشتری باید برای همه هش ها به جز آن یک درخواست `fullHashes` ارسال کند.
"threatEntries": [ {"hash": "0xcccccccc"} ]	"matches": [ "threat": {"hash": "0xccccccccdddd..."}, "cacheDuration": "600.000s" ], "negativeCacheDuration": "3600.000s"	مسابقات احتمالی کلاینت نباید هیچ درخواست `fullHashes` برای پیشوند هش 0xcccccccc حداقل به مدت 1 ساعت ارسال کند و آن پیشوند را ایمن فرض کند - مگر اینکه هش کامل URL با هش کامل ذخیره شده 0xccccccccdddd مطابقت داشته باشد... در این صورت مشتری باید آن URL را در نظر بگیرد. تا 10 دقیقه ناامن باشد. پس از 10 دقیقه هش کامل منقضی می شود. هر جستجوی بعدی برای آن هش کامل باید یک درخواست `fullHashes` جدید ایجاد کند.