更新限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
這份文件適用於以下方法: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 deltas,那麼當用戶端實際過時時,伺服器可能會將用戶端重設為 2048 資料庫。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 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."]]