معدّل تكرار الطلب
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ينطبق هذا المستند على الطرق التالية:
تحديث واجهة برمجة التطبيقات (الإصدار 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 و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eThe Google Safe Browsing Update API (v4) enforces request frequency limits to prevent server overload and maintain optimal protection.\u003c/p\u003e\n"],["\u003cp\u003eClients should adhere to the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e field provided in API responses to determine update frequency.\u003c/p\u003e\n"],["\u003cp\u003eIf the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e field is not set, clients can update as frequently as needed; if set, updates should not exceed the specified duration.\u003c/p\u003e\n"],["\u003cp\u003eUpon receiving unsuccessful HTTP responses, clients must enter back-off mode, delaying subsequent requests using a calculated time duration formula.\u003c/p\u003e\n"],["\u003cp\u003eAfter a successful response, clients exit back-off mode and resume following the \u003ccode\u003eminimumWaitDuration\u003c/code\u003e guidelines for updates.\u003c/p\u003e\n"]]],["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"],null,["# Request Frequency\n\nThis document applies to the following methods:\n- [Update API (v4)](/safe-browsing/v4/update-api): [fullHashes.find](/safe-browsing/v4/update-api#example-fullHashesfind)\n- [Update API (v4)](/safe-browsing/v4/update-api): [threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatListUpdatesfetch)\n\nUpdate requests\n---------------\n\n- To prevent server overload and to benefit from optimal protection, the Update API (v4) imposes time intervals for how often a client can send requests to the Safe Browsing server to perform URL checks ([fullHashes.find](/safe-browsing/v4/update-api#example-fullhashesfind)) or to update the local database ([threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatlistupdatesfetch)).\n- The initial request for data must happen at a random interval between 0 and 1 minutes after the client starts or wakes up. Subsequent requests can happen only after the [minimum wait duration](/safe-browsing/v4/request-frequency#minimum-wait-duration) or [back-off mode](/safe-browsing/v4/request-frequency#back-off-mode) time limit has been observed.\n\nMinimum wait duration\n---------------------\n\n- Both the [fullHashes.find response](/safe-browsing/v4/update-api#http-post-response_2) and [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response) have a `minimumWaitDuration` field that clients must obey.\n- If the `minimumWaitDuration` field **is not set** in the response, clients can update as frequently as they want and send as many `threatListUpdates` or `fullHashes` requests as they want.\n- If the `minimumWaitDuration` field **is set** in the response, clients cannot update more frequently than the length of the wait duration. For example, if a `fullHashes` response contains a minimum wait duration of 1 hour, the client must not send send any `fullHashes` requests until that hour passes, even if the user is visiting a URL whose hash prefix matches the local database. (Note that clients can update less frequently than the minimum wait duration but this may negatively affect protection.)\n\nBack-off mode\n-------------\n\n- Automatic back-off applies to both the [fullHashes.find response](/safe-browsing/v4/update-api#http-post-response_2) and [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response).\n- Clients that receive an unsuccessful HTTP response (that is, any HTTP status code other than `200 OK`) must enter back-off mode. Once in back-off mode, clients must wait the computed time duration before they can issue another request to the server.\n- Clients must use the following formula to compute the back-off time duration: \n\n```scdoc\nMIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)\n```\n- N corresponds to the number of consecutive, unsuccessful requests that the client experiences (starting with N=1 after the first unsuccessful request). RAND is a random number between 0 and 1 that needs to be picked after every unsuccessful update.\n- Once a client receives a successful HTTP response, the client must exit back-off mode and follow the [minimum wait duration](/safe-browsing/v4/request-frequency#minimum-wait-duration) specified above."]]
