Tần suất yêu cầu
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tài liệu này áp dụng cho các phương pháp sau:
Cập nhật API (phiên bản 4):
fullHashes.find
Cập nhật API (phiên bản 4):
threatListUpdates.fetch
Yêu cầu cập nhật
Để ngăn tình trạng quá tải của máy chủ và hưởng lợi từ khả năng bảo vệ tối ưu, Update API (v4) áp dụng
khoảng thời gian về tần suất ứng dụng có thể gửi yêu cầu tới máy chủ Duyệt web an toàn để
thực hiện kiểm tra URL
(fullHashes.find)
hoặc để cập nhật cơ sở dữ liệu cục bộ
(threatListUpdates.fetch).
Yêu cầu ban đầu về dữ liệu phải xảy ra trong khoảng ngẫu nhiên trong khoảng từ 0 đến 1 phút sau khi
máy khách khởi động hoặc đánh thức. Các yêu cầu tiếp theo chỉ có thể xảy ra sau
thời gian chờ tối thiểu hoặc
Đã đặt giới hạn thời gian cho chế độ đợi
quan sát thấy.
Thời gian chờ tối thiểu
Cả hai thuộc tính
trả lời fullHashes.find và
phản hồi threatListUpdates.fetch
có trường minimumWaitDuration
mà ứng dụng phải tuân theo.
Nếu trường minimumWaitDuration
không được thiết lập trong phản hồi, ứng dụng có thể
cập nhật bao nhiêu lần tuỳ thích và gửi bao nhiêu yêu cầu threatListUpdates
hoặc fullHashes
tuỳ ý
mà họ muốn.
Nếu trường minimumWaitDuration
được đặt trong phản hồi thì ứng dụng không thể
cập nhật thường xuyên hơn khoảng thời gian chờ. Ví dụ: nếu một phản hồi fullHashes
có thời gian chờ tối thiểu là 1 giờ, ứng dụng không được gửi bất kỳ yêu cầu fullHashes
nào
cho đến khi qua giờ đó, ngay cả khi người dùng đang truy cập vào một URL có tiền tố hàm băm khớp với
cơ sở dữ liệu. (Lưu ý rằng ứng dụng có thể cập nhật ít thường xuyên hơn thời gian chờ tối thiểu, nhưng điều này
có thể ảnh hưởng tiêu cực đến khả năng bảo vệ.)
Chế độ đợi
Tính năng đợi tự động áp dụng cho cả
trả lời fullHashes.find và
phản hồi threatListUpdates.fetch.
Máy khách nhận được phản hồi HTTP không thành công (tức là bất kỳ mã trạng thái HTTP nào không phải
200 OK
) phải chuyển sang chế độ đợi. Khi ở chế độ đợi, khách hàng phải đợi thời gian đã tính
trước khi chúng có thể gửi một yêu cầu khác đến máy chủ.
Khách hàng phải sử dụng công thức sau đây để tính khoảng thời gian đợi:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N tương ứng với số yêu cầu không thành công liên tiếp mà khách hàng gặp phải
(bắt đầu bằng N=1 sau yêu cầu đầu tiên không thành công). RAND là một số ngẫu nhiên từ 0 đến 1
cần được chọn sau mỗi lần cập nhật không thành công.
Sau khi nhận được phản hồi HTTP thành công, máy khách phải thoát khỏi chế độ đợi và làm theo các bước sau
thời gian chờ tối thiểu
đã chỉ định ở trên.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-25 UTC."],[[["\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."]]