معدّل تكرار الطلب
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ينطبق هذا المستند على الطرق التالية:
تحديث واجهة برمجة التطبيقات (الإصدار 4):
fullHashes.find
تحديث واجهة برمجة التطبيقات (الإصدار 4):
threatListUpdates.fetch
طلبات التحديث
لمنع الحمل الزائد على الخادم والاستفادة من الحماية المثلى، تفرض واجهة برمجة التطبيقات Update API (الإصدار 4)
فواصل زمنية لعدد المرات التي يمكن للعميل فيها إرسال طلبات إلى خادم التصفح الآمن إلى
إجراء عمليات التحقّق من عناوين URL
(fullHashes.find)
أو لتحديث قاعدة البيانات المحلية
(threatListUpdates.fetch).
يجب أن يحدث الطلب الأولي للبيانات على فترات عشوائية تتراوح بين 0 ودقيقة بعد
العميل أو يستيقظ. لا يمكن أن تحدث الطلبات اللاحقة إلا بعد
الحد الأدنى لمدة الانتظار أو
تم بلوغ الحد الزمني الخاص بوضع التراجع
ملاحظتها.
الحد الأدنى لمدة الانتظار
يتم تحديث
استجابة fullHashes.find و
ردّ threatListUpdates.fetch
أن يتضمّن حقل minimumWaitDuration يجب على العملاء الالتزام به.
إذا لم يتم ضبط الحقل minimumWaitDuration في الردّ، يمكن للعملاء
يتم التعديل بالقدر الذي يريده وإرسال أكبر عدد ممكن من طلبات threatListUpdates أو fullHashes
التي يريدونها.
إذا تم ضبط الحقل minimumWaitDuration في الردّ، لن تتمكّن العملاء
يتم تحديثه بشكل متكرر أكثر من طول مدة الانتظار. على سبيل المثال، إذا كانت الاستجابة fullHashes
يحتوي على حد أدنى لمدة الانتظار يبلغ ساعة واحدة، ويجب ألا يرسل العميل أي طلبات باللغة fullHashes
حتى مرور هذه الساعة، حتى إذا انتقل المستخدم إلى عنوان URL تتطابق بادئة تجزئةه مع العنوان المحلي
قاعدة البيانات. (لاحظ أنه يمكن للعملاء التحديث بشكل أقل من الحد الأدنى لمدة الانتظار ولكن هذا
قد تؤثر سلبًا على الحماية).
وضع التراجع
وينطبق التراجع التلقائي على كل من
استجابة fullHashes.find و
رد threatListUpdates.fetch
العملاء الذين يتلقون استجابة HTTP غير ناجحة (أي أي رمز حالة HTTP بخلاف
200 OK) في وضع التراجع. بمجرد دخول وضع التراجع، يجب على العملاء انتظار الوقت المحسوب
المدة قبل إصدار طلب آخر إلى الخادم.
يجب على العملاء استخدام الصيغة التالية لحساب مدة فترة التراجع:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
يتوافق N مع عدد الطلبات المتتالية غير الناجحة التي يجربها العميل
(يبدأ بـ N=1 بعد أول طلب غير ناجح). RAND هو رقم عشوائي بين 0 و1.
يجب اختياره بعد كل تحديث غير ناجح.
بمجرد أن يتلقى العميل استجابة HTTP ناجحة، يجب على العميل الخروج من وضع التراجع والمتابعة
الحدّ الأدنى لمدة الانتظار
المحددة أعلاه.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2024-10-14 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2024-10-14 (حسب التوقيت العالمي المتفَّق عليه)"],[[["The Google Safe Browsing Update API (v4) enforces request frequency limits to prevent server overload and maintain optimal protection."],["Clients should adhere to the `minimumWaitDuration` field provided in API responses to determine update frequency."],["If the `minimumWaitDuration` field is not set, clients can update as frequently as needed; if set, updates should not exceed the specified duration."],["Upon receiving unsuccessful HTTP responses, clients must enter back-off mode, delaying subsequent requests using a calculated time duration formula."],["After a successful response, clients exit back-off mode and resume following the `minimumWaitDuration` guidelines for updates."]]],["The Update API v4's `fullHashes.find` and `threatListUpdates.fetch` methods require clients to adhere to request time intervals. Initial requests must be sent within 0-1 minutes of startup, and subsequent requests must observe the `minimumWaitDuration` or `back-off mode`. If `minimumWaitDuration` isn't set, clients can update freely; if set, they must wait for the specified duration. Unsuccessful HTTP responses trigger back-off mode, using a formula to determine the wait time, until a successful response occurs.\n"]]
