Antworten>Erfahren Sie mehr über RPC und APIs>Was ist RPC-Ratenbegrenzung?
Was versteht man unter RPC-Ratenbegrenzung?
// Tags
RPC-RatenbegrenzungAPI-Ratenbegrenzung
TL;DR: Die RPC-Ratenbegrenzung ist ein Mechanismus, der festlegt, wie viele Anfragen Ihre Anwendung innerhalb eines bestimmten Zeitfensters an einen Blockchain-Knoten senden darf. Wenn Sie das Limit überschreiten, werden nachfolgende Anfragen abgelehnt (in der Regel mit einem HTTP-429-Fehler), bis das Zeitfenster zurückgesetzt wird. Ratenbegrenzungen dienen dazu, die gemeinsam genutzte Infrastruktur vor Missbrauch zu schützen und einen fairen Zugang für alle Nutzer zu gewährleisten. Das Verständnis und die Verwaltung von Ratenbegrenzungen sind unerlässlich für die Entwicklung zuverlässiger Blockchain-Anwendungen, die auch unter hoher Auslastung nicht ausfallen.
Die einfache Erklärung
Stellen Sie sich eine Restaurantküche vor, die 100 Mahlzeiten pro Stunde zubereiten kann. Wenn 50 Gäste jeweils 3 Gerichte bestellen, ist die Küche voll ausgelastet. Versucht ein Gast, 50 Gerichte zu bestellen, muss die Küche ihn abweisen, damit alle anderen weiterhin essen können. Die Ratenbegrenzung funktioniert auf die gleiche Weise. Ein Blockchain-Knoten verfügt über eine begrenzte Verarbeitungskapazität, und Ratenbegrenzungen stellen sicher, dass keine einzelne Anwendung diese Kapazität auf Kosten aller anderen Nutzer derselben Infrastruktur monopolisiert.
Wenn Ihre Anwendung zu viele RPC-Anfragen zu schnell sendet, antwortet der Knoten mit einem Fehler statt mit den von Ihnen angeforderten Daten. Bei den meisten Anbietern handelt es sich dabei um den HTTP-Statuscode 429 „Too Many Requests“, oft begleitet von einem JSON-RPC-Fehlertext, der Ihnen mitteilt, wie viele Anfragen zulässig sind, wie viele Sie versucht haben und wie lange Sie warten müssen, bevor Sie es erneut versuchen können. Wenn Ihre Anwendung diese Signale ignoriert und weiterhin Anfragen sendet, kann der Anbieter Ihre IP-Adresse oder Ihren API-Schlüssel vorübergehend oder sogar vollständig sperren.
Ratenbegrenzungen werden in der Regel in Anfragen pro Sekunde (RPS), Anfragen pro Minute oder einer Kombination aus beidem angegeben. Ein Anbieter könnte beispielsweise 25 RPS in der kostenlosen Stufe, 300 RPS in der Wachstumsstufe und über 1.000 RPS in der Unternehmensstufe zulassen. Einige Anbieter wenden zudem Begrenzungen pro Methode an, was bedeutet, dass bestimmte rechenintensive Methoden wie „debug_traceTransaction“ oder „eth_getLogs“ mit großen Blockbereichen niedrigere individuelle Obergrenzen haben als ressourcenschonende Methoden wie „eth_blockNumber“.
Warum es Ratenbegrenzungen gibt
Ratenbegrenzungen dienen drei Hauptzwecken. Erstens schützen sie die Stabilität der Infrastruktur. Blockchain-Knoten sind zustandsbehaftete Systeme, die die gesamten Daten der Blockchain verwalten und komplexe Operationen wie EVM-Aufrufe und Zustandsabfragen ausführen. Eine ungebremste Flut von Anfragen kann die CPU, den Arbeitsspeicher, die Festplatten-E/A oder die Netzwerkbandbreite eines Knotens überlasten, was die Leistung für alle Nutzer beeinträchtigt oder den Knoten vollständig zum Absturz bringt. Ratenbegrenzungen fungieren als Schutzschalter, der verhindert, dass ein einzelner Client Kettenausfälle verursacht.
Zweitens gewährleisten Ratenbegrenzungen eine faire Ressourcenzuweisung. Bei einer gemeinsam genutzten Infrastruktur (die von den meisten Entwicklern genutzt wird) teilen sich Hunderte oder Tausende von Anwendungen denselben Knotenpool. Ohne Ratenbegrenzungen könnte eine einzelne Anwendung, auf der ein aggressives Indizierungsskript läuft oder die eine falsch konfigurierte Abfrageschleife ausführt, den Großteil der verfügbaren Kapazität beanspruchen und anderen Anwendungen die benötigten Ressourcen vorenthalten. Ratenbegrenzungen setzen eine Fair-Use-Richtlinie durch, die garantiert, dass jede Anwendung einen angemessenen Anteil erhält.
Drittens dienen Ratenbegrenzungen als Schutz vor Missbrauch. Denial-of-Service-Angriffe – ob absichtlich oder versehentlich – können die Infrastruktur lahmlegen, auf die viele Anwendungen angewiesen sind. Ratenbegrenzungen verhindern sowohl, dass böswillige Akteure öffentliche Endpunkte als Waffe einsetzen, als auch, dass gut gemeinte Entwickler versehentlich einen Knoten mit einem außer Kontrolle geratenen Skript einem DDoS-Angriff aussetzen.
Wie sich Ratenbegrenzungen auf Ihre Anwendung auswirken
Wenn Ihre Anwendung nicht für die Einhaltung von Ratenbeschränkungen ausgelegt ist, wird sie im Produktivbetrieb ausfallen. Die häufigste mode eine Abfrageschleife, die die Blockchain zu häufig abfragt. Eine Anwendung, die alle 100 ms „eth_blockNumber“ aufruft, um nach neuen Blöcken zu suchen, sendet allein über diese Methode 600 Anfragen pro Minute. Rechnet man dazu noch Kontostandsabfragen, Protokollabfragen und Transaktionsstatusabfragen für jeden aktiven Nutzer hinzu, können selbst großzügige Ratenbeschränkungen leicht überschritten werden.
WebSocket-Abonnements können ebenfalls Ratenbegrenzungen auslösen. Während die anfängliche Abonnementanfrage als einzelner Aufruf zählt, kann jede vom Server eingehende Nachricht (wie eine Benachrichtigung über einen neuen Block oder eine Warnung bezüglich einer ausstehenden Transaktion) bei einigen Anbietern auf Ihr Nutzungslimit angerechnet werden. Wenn Ihre Anwendung hochfrequente streams mehrere Kontrakte streams abonniert, kann sich das Volumen der eingehenden Nachrichten schnell summieren.
Fehlgeschlagene Anfragen aufgrund von Ratenbegrenzungen lösen einen Dominoeffekt aus. Wenn Ihre App die angeforderten Daten nicht erhält, versucht sie möglicherweise, die Anfrage erneut zu stellen, wodurch die Auslastung weiter steigt. Wenn Wiederholungsversuche nicht mit exponentiellem Backoff implementiert werden, entsteht eine Rückkopplungsschleife, in der ratenbegrenzte Anfragen weitere Anfragen generieren, die wiederum zu einer weiteren Ratenbegrenzung führen. Dieses Muster kann dazu führen, dass Ihre Anwendung effektiv vom endpoint ausgesperrt wird, endpoint das Zeitfenster für die Ratenbegrenzung zurückgesetzt wird.
Strategien zum Umgang mit Ratenbegrenzungen
Die effektivste Strategie besteht darin, die Anzahl der Anfragen zu reduzieren, die Ihre Anwendung stellen muss. Das Caching bildet die Grundlage dieses Ansatzes. Wenn Ihre App ETH-Kurse, Token-Metadaten oder andere sich nur langsam ändernde Daten anzeigt, speichern Sie diese Ergebnisse lokal im Cache und aktualisieren Sie sie in angemessenen Abständen, anstatt bei jedem Laden einer Seite oder jeder Benutzeraktion eine Abfrage an den Node zu senden. Für Daten, die sich mit jedem Block ändern, sollten Sie ein Abonnement über WebSocket nutzen, anstatt per HTTP abzufragen, da ein einziges Abonnement Tausende einzelner Abfrageanfragen ersetzt.
Das Bündeln von Anfragen reduziert den HTTP-Overhead und kann Ihnen helfen, die Ratenbegrenzungen einzuhalten. Anstatt 10 separate Aufrufe für 10 verschiedene Wallet-Guthaben durchzuführen, bündeln Sie diese zu einer einzigen JSON-RPC-Array-Anfrage. Der Knoten verarbeitet jede einzelne davon, aber Sie verwenden nur eine einzige HTTP-Anfrage, um alle zu übermitteln. Beachten Sie, dass einige Anbieter jeden Methodenaufruf innerhalb eines Batches auf Ihre Ratenbegrenzung anrechnen, nicht nur die HTTP-Anfrage selbst.
Die Implementierung einer clientseitigen Ratenbegrenzung ist eine bewährte defensive Vorgehensweise. Anstatt darauf zu warten, dass der Server Ihre Anfragen ablehnt, sollten Sie die Rate Ihrer ausgehenden Anfragen überwachen und Anfragen, die Ihr bekanntes Limit überschreiten würden, in eine Warteschlange stellen oder verzögern. So halten Sie Ihre Anwendung proaktiv innerhalb der Grenzen und vermeiden die durch abgelehnte Anfragen verursachten Latenzverluste. Bibliotheken wie „bottleneck“ (Node.js) oder „ratelimit“ (Python) erleichtern die Umsetzung.
Die Wahl der richtigen Infrastrukturstufe für Ihre Nutzung ist letztendlich die zuverlässigste Lösung. Wenn Ihre Anwendung regelmäßig an die Ratenbegrenzungen stößt, benötigt sie mehr Kapazität und keine weiteren Optimierungstricks. Durch ein Upgrade auf eine höhere Stufe oder den Wechsel zu einer dedizierten Infrastruktur entfällt die Ratenbegrenzung als Problem vollständig.
Was bedeutet ein HTTP-429-Fehler?
Eine HTTP-429-Antwort („Too Many Requests“) bedeutet, dass Sie Ihre zulässige Anfragerate für das aktuelle Zeitfenster überschritten haben. Der Knoten ist nicht defekt und Ihre Anmeldedaten sind in der Regel korrekt; Sie senden lediglich Anfragen schneller, als es Ihr Tarif zulässt. Die Lösung besteht darin, die Antwort zu lesen – diese enthält oft Angaben zur Wartezeit – und den Versuch nach Ablauf dieser Verzögerung mit exponentiellem Backoff erneut zu starten, damit wiederholte Fehler keine zusätzliche Last verursachen. Anhaltende 429-Fehler bedeuten, dass Sie das Anfragevolumen reduzieren oder auf eine Stufe mit höherer Kapazität wechseln sollten, anstatt es mit noch intensiveren Wiederholungsversuchen zu versuchen. Wenn Sie verstehen, wie RPC-Anfragen funktionieren und wie ein endpoint Aufrufe verarbeitet, lässt sich leichter nachvollziehen, warum manche Methoden früher an ihre Grenzen stoßen als andere.
Wie kann man vermeiden, die RPC-Ratenbegrenzungen zu erreichen?
Um Ratenbeschränkungen zu umgehen, geht es vor allem darum, weniger und kostengünstigere Anfragen zu senden und diese zeitlich zu streuen. Die folgende Tabelle fasst die wirkungsvollsten Techniken zusammen und zeigt auf, wann sie jeweils am besten geeignet sind.
Technik
Was es bewirkt
Am besten geeignet für
Zwischenspeicherung
Verwendet Ergebnisse für sich nur langsam ändernde Daten wieder
Preise, Metadaten, Salden
Streaming statt Abfrage
Ersetzt wiederholte Abfragen durch übermittelte Daten
Aktualisierungen und Indizierung pro Block
Chargenverarbeitung
Fasst mehrere Aufrufe zu einer einzigen Anfrage zusammen
Bulk-Lesevorgänge wie viele Salden
Clientseitige Ratenbegrenzung
Stellt Anträge in die Warteschlange, um unter der Obergrenze zu bleiben
Bursty-Verkehr oder benutzergesteuerter Datenverkehr
Höhere Stufe oder dedizierte Infrastruktur
Erhöht oder hebt die Begrenzung auf
Anhaltend hohes Anfrageaufkommen
Der Wechsel von Polling zu Streaming führt oft zur mit Abstand größten Reduzierung der Anfrageanzahl. Wenn eine Optimierung nicht mehr ausreicht, stellt sich die Frage „Selbst entwickeln oder kaufen “ – je nachdem, wie viel Kapazität und Zuverlässigkeit Sie selbst bereitstellen möchten.
Was ist der Unterschied zwischen Ratenbegrenzung und Drosselung?
Die Begriffe werden oft synonym verwendet, beschreiben jedoch unterschiedliche Reaktionen auf eine übermäßige Auslastung. Die Ratenbegrenzung legt eine feste Obergrenze fest: Sobald diese überschritten wird, werden Anfragen sofort abgelehnt, in der Regel mit dem Status 429. Die Drosselung ist weniger streng: Anstatt Anfragen abzulehnen, verlangsamt das System diese oder stellt sie in eine Warteschlange, sodass sie zwar noch ausgeführt werden, jedoch langsamer. Beide Maßnahmen schützen die gemeinsam genutzte Infrastruktur, scheitern jedoch aus Sicht des Clients auf unterschiedliche Weise.
Aspekt
Ratenbegrenzung
Drosselung
Reaktion auf Übermaß
Lehnt Anträge ab
Verzögert oder stellt Anfragen in eine Warteschlange
Typisches Signal
HTTP-Fehler 429
Erhöhte Latenz
Auswirkungen auf den Kunden
Fehlgeschlagene Anrufe, die erneut versucht werden sollen
Verspätete, aber abgeschlossene Anrufe
Ziel
Eine strenge Nutzungsobergrenze durchsetzen
Verkehrsspitzen ausgleichen
Beides kann sich aus Sicht der Anwendung in einer höheren RPC-Latenz äußern, und beides hängt mit den allgemeinen Kompromissen zwischen Durchsatz und Latenz in Ihrer Infrastruktur zusammen.
Häufig gestellte Fragen
Was ist ein akzeptables RPC-Ratenlimit?
Das hängt von Ihrer Auslastung und Ihrer Tarifstufe ab. Bei kostenlosen Tarifen sind etwa 25 Anfragen pro Sekunde zulässig, während bei den Tarifen „Growth“ und „Enterprise“ Hunderte oder Tausende möglich sind. Das richtige Limit ist dasjenige, das Ihre Spitzenanfragerate nach Anwendung von Caching, Batching und Streaming komfortabel übersteigt.
Wie soll ich mit einer 429-Antwort umgehen?
Halten Sie Abstand und versuchen Sie es erneut, anstatt den endpoint zu überlasten. Verwenden Sie einen exponentiellen Backoff mit Jitter, beachten Sie etwaige Hinweise zur Wartezeit vor einem erneuten Versuch in der Antwort und begrenzen Sie die Anzahl der Wiederholungsversuche. Wenn weiterhin 429-Fehler auftreten, reduzieren Sie das Anforderungsvolumen oder erhöhen Sie die Kapazität, anstatt die Wiederholungsversuche zu intensivieren.
Zählen Sammelanfragen als eine einzige Anfrage?
Nicht immer. Der Batch wird als einzelne HTTP-Anfrage übertragen, aber viele Anbieter rechnen jeden Methodenaufruf innerhalb des Batches auf Ihr Ratenlimit an. Durch das Batching wird zwar der Netzwerk-Overhead reduziert, aber die Anzahl der gezählten Aufrufe wird dadurch nicht unbedingt verringert.
Lässt sich durch Streaming die Begrenzung der Datenübertragungsrate umgehen?
Im Großen und Ganzen ja, was die Datenerfassung angeht. Ein Push-basierter Stream liefert neue Blockchain-Daten direkt bei ihrer Erstellung, anstatt Tausende von Polling-Aufrufen zu erfordern. Dadurch entfällt der Großteil des Anfragevolumens, das die Ratenbegrenzung überhaupt erst auslöst.
Rechenintensive Methoden wie die Transaktionsverfolgung oder Abfragen großer Protokolle beanspruchen weitaus mehr Knotenressourcen als ressourcenschonende Aufrufe wie das Abrufen der aktuellen Blocknummer. Um die allgemeine Stabilität des Knotens zu gewährleisten, wenden die Anbieter für diese ressourcenintensiven Aufrufe strengere Grenzwerte pro Methode an.
Wie Quicknode mit Ratenbegrenzungen Quicknode
Quicknode flexible Mechanismen zur Ratenbegrenzung, mit denen Entwickler die Nutzung ihrer endpoint selbst steuern können. Über die RPS-Limits auf Tarifebene hinaus Quicknode eine Ratenbegrenzung auf Methodenebene, mit der Sie präzise Limits für einzelne RPC-Methoden festlegen können. Dies ist besonders nützlich, um Ihren endpoint außer Kontrolle geratenen Skripten oder Integrationen von Drittanbietern zu schützen, die möglicherweise ressourcenintensive Methoden übermäßig oft aufrufen. Sie können Limits pro Sekunde, pro Minute oder pro Tag auf Methodenebene festlegen – entweder über die Benutzeroberfläche des Dashboards oder programmgesteuert über die Console-API.
Quicknode bietet Quicknode eine IP-basierte Ratenbegrenzung zur Steuerung der Gesamtzahl der Anfragen von einzelnen IP-Adressen. Dies ist besonders nützlich, wenn Ihr endpoint für clientseitige Anwendungen zugänglich endpoint , bei denen Sie das Anfragevolumen nicht vollständig kontrollieren können. Die Echtzeit-Analysen im Quicknode zeigen Ihnen das Volumen Ihrer Methodenaufrufe, die Antwortstatus und die Antwortzeiten an. So erhalten Sie einen umfassenden Einblick in Ihre Nutzungsmuster und können Probleme erkennen und beheben, bevor sie zu Ratenbegrenzungsproblemen führen.
Für Teams, die die Ratenbegrenzungen vollständig umgehen müssen, bietet Quicknode Streams das Anfrage-Antwort-Muster durch ein Push-basiertes Datenübermittlungsmodell. Anstatt dass Ihre Anwendung den Knoten tausende Male pro Minute abfragt, Streams Blockchain-Daten direkt an Ihren Webhook, Ihre Datenbank oder Ihr Data Warehouse, sobald neue Blöcke erzeugt werden. Dadurch entfallen RPC-Ratenbegrenzungen bei der Datenerfassung vollständig, während gleichzeitig die Latenz reduziert und Ihre Backend-Architektur vereinfacht wird.
