요청 빈도
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 문서는 다음 메서드에 적용됩니다.
Update API (v4):
fullHashes.find
Update API (v4):
threatListUpdates.fetch
업데이트 요청
업데이트 API (v4)는 서버 과부하를 방지하고 최적의 보호 기능을 활용하기 위해
클라이언트가 세이프 브라우징 서버에 요청을 보낼 수 있는 빈도에 대한 시간 간격
URL 검사 수행
(fullHashes.find)
로컬 데이터베이스 업데이트
(threatListUpdates.fetch).
데이터의 초기 요청은
시작됩니다. 후속 요청은
최소 대기 시간 또는
백오프 모드 시간 제한이
확인할 수 있습니다
최소 대기 시간
그리고
fullHashes.find 응답 및
threatListUpdates.fetch 응답
클라이언트가 준수해야 하는 minimumWaitDuration
필드가 있습니다.
응답에 minimumWaitDuration
필드가 설정되지 않은 경우 클라이언트는
원하는 만큼 자주 업데이트하고 가능한 한 많은 threatListUpdates
또는 fullHashes
요청을 전송합니다.
확인할 수 있습니다
응답에 minimumWaitDuration
필드가 설정된 경우 클라이언트는 다음 작업을 수행할 수 없습니다.
대기 시간보다 더 자주 업데이트됩니다. 예를 들어 fullHashes
응답이
최소 대기 시간이 1시간입니다. 클라이언트는 fullHashes
요청을 전송하면 안 됩니다.
사용자가 해시 접두사가 로컬
데이터베이스입니다. 클라이언트는 최소 대기 시간보다 더 적게 업데이트할 수 있지만 이 작업은
보호에 부정적인 영향을 미칠 수 있습니다.)
백오프 모드
자동 백오프는
fullHashes.find 응답 및
threatListUpdates.fetch 응답의 응답입니다.
실패한 HTTP 응답 (즉, 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 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-25(UTC)
[null,null,["최종 업데이트: 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."]]