更新限制
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本文档适用于以下方法:Update API (v4):threatListUpdates.fetch。
设置限制
更新本地数据库(请参阅数据库更新)时,客户端可以使用 threatListUpdates.fetch 请求中的 maxUpdateEntries
和 maxDatabaseEntries
字段来指定大小限制。客户端应设置限制条件,以保持客户端 RAM、磁盘和带宽的可预测性,并防止名单增长。
- 客户端可以指定更新响应大小 (
maxUpdateEntries
) 的条目数上限(1 个条目 = 1 次添加或移除 1 次)。
- 客户端可以在条目数中指定数据库大小上限 (
maxDatabaseEntries
)(数据库中的大部分条目是 4 字节的哈希前缀,因此可以合理地假设 1 个条目约为 4 个字节)。
带宽与存储空间
虽然客户端可以指定任意大小的更新响应和数据库大小,但安全浏览服务器只会预先生成有限数量可能的更新响应大小和数据库大小。
- 客户端应使用更新响应大小 (
maxUpdateEntries
) 来限制带宽用量。
- 客户端应使用数据库大小 (
maxDatabaseEntries
) 来限制设备上所需的 RAM 或磁盘存储空间容量。
这两项限制都会影响正在更新的数据库的大小,因此会影响为用户提供的保护量(即,本地数据库越大,保护效果越好)。
限制条件设置指南
安全浏览列表的大小可能会逐渐或突然发生变化。客户端应为列表更新请求设置 maxUpdateEntries
,这样可以限制列表更新响应大小的最大值,并提高无法处理大型更新时的可靠性。
如果没有更严格的要求或没有不太严格的要求,Google 建议使用 maxUpdateEntries=16777216
。根据每个哈希前缀的典型列表条目大小(4 个字节),这相当于每个列表大约 67 MB。Google 建议为移动客户端使用较小的限制 maxUpdateEntries=2097152
,因为它们的功能通常不太强大。按照每个哈希前缀的典型列表条目大小(4 个字节),这相当于每个列表大约 8 MB。
安全浏览名单的大小和增长率各不相同。但是,客户端应根据每个列表允许的最大内存或带宽用量,为所有列表设置相同的限制。
为了提高可靠性,Google 建议客户端实现用于检测内存或带宽用量超额的遥测,以及能够快速为客户端提供新限制的机制。
客户端状态
安全浏览服务器绝不会发送会导致客户端处于过时状态的更新;每次发出更新请求后,客户端都会保持最新状态。例如,如果客户端当前的数据库包含 4096 个条目,但只想下载最多 2048 个增量,如果客户端确实过旧,服务器可能会将客户端重置为 2048 数据库。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):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."]]