معدّل تكرار الطلب

ينطبق هذا المستند على الطرق التالية:

  • تحديث واجهة برمجة التطبيقات (الإصدار 4): fullHashes.find
  • تحديث واجهة برمجة التطبيقات (الإصدار 4): threatListUpdates.fetch
  • تحديث الطلبات

    لتجنُّب زيادة الحمل على الخادم والاستفادة من الحماية المثلى، تفرض "واجهة برمجة تطبيقات التحديث" (الإصدار 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 ناجحة، على العميل الخروج من وضع التراجع واتّباع الحد الأدنى لمدة الانتظار المحدّد أعلاه.