Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Häufigkeit der Anfragen
Aktualisierungs-Anfragen
Um eine Serverüberlastung zu vermeiden und optimal geschützt zu sein, legt die Update API Zeitintervalle fest, wie oft ein Client Anfragen an den Web Risk Server senden kann, um URL-Prüfungen (hashes.search) durchzuführen oder die lokale Datenbank (threatLists.computeDiff) zu aktualisieren.
Die erste Datenanfrage muss in einem zufälligen Intervall zwischen 0 und 1 Minute nach dem Starten oder Aufwachen des Clients erfolgen. Nachfolgende Anfragen können erst erfolgen, wenn die Mindestwartezeit oder die Zeitspanne für den Backoff-Modus eingehalten wurde.
Wenn das Feld minimumWaitDuration in der Antwort nicht festgelegt ist, können Clients beliebig oft aktualisieren und beliebig viele threatListUpdates- oder fullHashes- Anfragen senden.
Wenn das Feld minimumWaitDuration in der Antwort festgelegt ist, können Clients nicht häufiger als die Dauer der Wartezeit aktualisiert werden. Wenn eine fullHashes-Antwort beispielsweise eine Mindestwartezeit von 1 Stunde enthält, darf der Client keine fullHashes-Anfragen senden, bis diese Stunde verstrichen ist, auch wenn der Nutzer eine URL besucht, deren Hash-Präfix mit der lokalen Datenbank übereinstimmt.
Beachten Sie, dass Clients seltener als die Mindestwartezeit aktualisiert werden können. Dies kann sich jedoch negativ auf den Schutz auswirken.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-03 (UTC)."],[],[],null,["# Request Frequency\n=================\n\nUpdate requests\n---------------\n\nTo prevent server overload and to benefit from optimal protection, the Update\nAPI imposes time intervals for how often a client can send requests to the\nWeb Risk server to perform URL checks\n([`hashes.search`](/web-risk/docs/update-api#example-hashessearch))\nor to update the local database\n([`threatLists.computeDiff`](/web-risk/docs/update-api#example-threatlistsComputediff)).\n\nThe initial request for data must happen at a random interval between 0 and 1\nminutes after the client starts or wakes up. Subsequent requests can happen only\nafter the\n[minimum wait duration](/web-risk/docs/request-frequency#minimum_wait_duration)\nor\n[back-off mode](/web-risk/docs/request-frequency#back_off_mode)\ntime limit has been observed.\n\nMinimum wait duration\n---------------------\n\nBoth the\n[hashes.search response](/web-risk/docs/update-api#http_post_response_2)\nand\n[threatLists.computeDiff response](/web-risk/docs/update-api#http_post_response)\nhave a `minimumWaitDuration` field that clients must obey.\n\nIf the `minimumWaitDuration` field **is not set** in the\nresponse, clients can update as frequently as they want and send as many\n`threatListUpdates` or `fullHashes` requests as they want.\n\nIf the `minimumWaitDuration` field **is set** in the response,\nclients cannot update more frequently than the length of the wait duration. For\nexample, if a `fullHashes` response contains a minimum wait duration of 1 hour,\nthe client must not send send any `fullHashes` requests until that hour passes,\neven if the user is visiting a URL whose hash prefix matches the local database.\n(Note that clients can update less frequently than the minimum wait duration but\nthis may negatively affect protection.)\n\nBack-off mode\n-------------\n\nFor the recommended backoff procedure, read our\n[Service Level Agreement](/web-risk/sla)."]]
