تحديث القيود
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ينطبق هذا المستند على الطريقة التالية:
Update API (v4):
threatListUpdates.fetch.
فرض قيود
عند تحديث قواعد البيانات المحلية
(راجع تحديثات قاعدة البيانات)
يمكن للعملاء استخدام الحقلين maxUpdateEntries وmaxDatabaseEntries في
طلب threatListUpdates.fetch
لتحديد قيود الحجم. على العملاء وضع قيود للحفاظ على الاستهلاك المتوقّع لذاكرة الوصول العشوائي (RAM) الخاصة بالعميل والقرص ومعدل نقل البيانات، والحماية من نمو القائمة.
- يمكن للعملاء تحديد حدّ أقصى لحجم الاستجابة للتحديث (
maxUpdateEntries) في عدد الإدخالات
(إدخال واحد = إضافة واحدة أو عملية إزالة واحدة).
- يمكن للعملاء تحديد حد أقصى لحجم قاعدة البيانات (
maxDatabaseEntries) في عدد الإدخالات (الغالبية العظمى من الإدخالات في قاعدة البيانات هي بادئات تجزئة مكونة من 4 بايت، لذا من العدل
افتراض أن إدخال واحد ≈ 4 بايت).
معدل نقل البيانات مقابل مساحة التخزين
على الرغم من أنّ العملاء قد يحدّدون أحجامًا عشوائية لأحجام استجابة التحديث وقواعد البيانات، لا ينشئ خادم
التصفّح الآمن مسبقًا سوى عدد محدود من أحجام قواعد البيانات واستجابات التحديث الممكنة.
- على البرامج استخدام حجم استجابة التحديث (
maxUpdateEntries) للحدّ من استخدام معدل نقل البيانات.
- على البرامج استخدام حجم قاعدة البيانات (
maxDatabaseEntries) للحدّ من مساحة ذاكرة الوصول العشوائي (RAM)
أو مساحة التخزين على القرص المطلوبة على الجهاز.
يؤثر كلا الحدين في حجم قاعدة البيانات التي يتم تحديثها، وبالتالي
يؤثران في مقدار الحماية المقدّمة للمستخدم (أي كلما زاد حجم قاعدة البيانات المحلية، تحسّنت الحماية).
إرشادات لوضع القيود
يمكن أن يتغير حجم قوائم التصفح الآمن تدريجيًا أو فجأة. على العملاء ضبط maxUpdateEntries لطلبات تعديل القائمة، ما يحدّ من الحدّ الأقصى لحجم الاستجابة لتحديث القائمة ويحسِّن الموثوقية عندما يتعذّر معالجة التحديثات الكبيرة.
في حال عدم صرامة متطلبات أو متطلبات أكثر صرامة،
تنصح Google باستخدام السمة maxUpdateEntries=16777216. يساوي حجم إدخال القائمة النموذجي الذي يبلغ 4 بايت لكل بادئة تجزئة 67 ميغابايت تقريبًا لكل قائمة. تنصح Google باستخدام الحدّ الأصغر
maxUpdateEntries=2097152 لعملاء الأجهزة الجوّالة،
لأنّها عادةً ما تكون أقل فعالية. يساوي حجم إدخال القائمة النموذجي الذي يبلغ 4 بايت لكل بادئة تجزئة 8 ميغابايت تقريبًا لكل قائمة.
تختلف قوائم "التصفّح الآمن" من حيث الحجم ومعدّل النمو. ومع ذلك، يجب على العملاء وضع القيود نفسها لجميع القوائم، بناءً على الحد الأقصى المسموح به لاستخدام الذاكرة أو معدل نقل البيانات لكل قائمة.
لتحسين الموثوقية، تنصح Google العملاء بتنفيذ القياس عن بُعد لرصد الاستخدام الزائد للذاكرة أو معدّل نقل البيانات، بالإضافة إلى آليات لفرض قيود جديدة على العملاء بشكل سريع.
حالة العميل
لا يرسل خادم التصفح الآمن مطلقًا تحديثًا يترك العميل في حالة قديمة، وسيتم تحديث البرامج بالكامل بعد كل طلب تحديث. على سبيل المثال، إذا كان لدى العميل حاليًا قاعدة بيانات مكونة من 4096 إدخالاً ولكنه يريد فقط تنزيل 2048 دلتا كحد أقصى، فقد يعيد الخادم تعيين العميل إلى قاعدة بيانات 2048 إذا كان العميل قديمًا حقًا.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eThe Safe Browsing API allows clients to set constraints on update and database sizes to manage resource usage.\u003c/p\u003e\n"],["\u003cp\u003eClients can limit bandwidth with \u003ccode\u003emaxUpdateEntries\u003c/code\u003e and storage with \u003ccode\u003emaxDatabaseEntries\u003c/code\u003e to optimize performance.\u003c/p\u003e\n"],["\u003cp\u003eGoogle provides recommended constraint values for different client types to balance protection and resource consumption.\u003c/p\u003e\n"],["\u003cp\u003eThe Safe Browsing server ensures clients remain up-to-date even with constrained updates, potentially resetting the database if necessary.\u003c/p\u003e\n"]]],["Clients updating local databases via the `threatListUpdates.fetch` API can set size constraints using `maxUpdateEntries` (for update response size, limiting bandwidth) and `maxDatabaseEntries` (for database size, limiting storage). Google recommends `maxUpdateEntries=16777216` (67MB) for most clients and `2097152` (8MB) for mobile. These constraints should be consistently applied across all lists, with telemetry to detect overusage. The server ensures clients are always fully updated, potentially resetting to smaller databases if necessary.\n"],null,["# Update Constraints\n\nThis document applies to the following method:\n[Update API (v4)](/safe-browsing/v4/update-api):\n[threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatListUpdatesfetch).\n\nSetting constraints\n-------------------\n\nWhen updating local databases\n(see [Database Updates](/safe-browsing/v4/local-databases#database-updates))\nclients can use the `maxUpdateEntries` and `maxDatabaseEntries` fields in the\n[threatListUpdates.fetch request](/safe-browsing/v4/update-api#http-post-request)\nto specify size constraints. Clients should set constraints to maintain\npredictable consumption of client RAM, disk, and bandwidth, and to safeguard\nagainst list growth.\n\n- Clients can specify a maximum update response size (`maxUpdateEntries`) in number of entries (1 entry = 1 addition or 1 removal).\n- Clients can specify a maximum database size (`maxDatabaseEntries`) in number of entries (the vast majority of entries in the database are 4-byte hash prefixes so it's fair to assume that 1 entry ≈ 4 bytes).\n\nBandwidth vs. storage\n---------------------\n\nWhile clients may specify arbitrary sizes for the update response and database sizes, the Safe\nBrowsing server only pre-generates a finite number of possible update response and database sizes.\n\n- Clients should use the update response size (`maxUpdateEntries`) to limit bandwidth usage.\n- Clients should use the database size (`maxDatabaseEntries`) to limit the amount of RAM or disk storage needed on the device.\n\nBoth of these limits have an effect on the size of the database that is being updated and therefore have an impact on the amount of protection provided to the user (that is, the larger the local database size the better the protection).\n\n\u003cbr /\u003e\n\nGuidance for setting constraints\n--------------------------------\n\nSafe Browsing lists can gradually or suddenly change in size. Clients should\nset the `maxUpdateEntries` for list update requests, which limits the\nmaximum list update response size and improves reliability when large updates\ncannot be processed.\n\nIn the absence of stricter requirements or requirements that are less strict,\nGoogle recommends using `maxUpdateEntries=16777216`. With the typical\nlist entry size of 4 bytes per hash prefix, this equates to approximately 67\nmegabytes per list. Google recommends using the smaller limit\n`maxUpdateEntries=2097152` for mobile clients, because they are\nusually less powerful. At the typical list entry size of 4 bytes per hash\nprefix, this equates to approximately 8 megabytes per list.\n\nSafe Browsing lists differ in size and growth rate. However, clients should\nset the same constraints for all lists, based on the maximum allowed memory or\nbandwidth usage for each list.\n\nTo improve reliability, Google recommends that clients implement telemetry\nfor detecting memory or bandwidth overusage, as well as mechanisms to quickly\ndeliver new constraints to clients.\n\nClient state\n------------\n\nThe Safe Browsing server never sends an update that leaves the client in an outdated state;\nclients will be fully up-to-date after every update request. For example, if a client currently has\na database of 4096 entries but only wants to download at most 2048 deltas, the server may reset the\nclient to a 2048 database if the client is really out-of-date."]]
