RPC y API>¿Qué es la limitación de velocidad de RPC?
Respuestas>Más información sobre RPC y API>¿Qué es la limitación de velocidad en RPC?
¿Qué es la limitación de velocidad en RPC?
// Tags
Limitación de la tasa de RPCLímites de frecuencia de la API
En resumen: La limitación de tasa de RPC es un mecanismo que restringe el número de solicitudes que tu aplicación puede enviar a un nodo de blockchain en un intervalo de tiempo determinado. Cuando se supera el límite, las solicitudes posteriores se rechazan (normalmente con un error HTTP 429) hasta que se reinicia el intervalo. Los límites de tasa existen para proteger la infraestructura compartida frente a usos indebidos y garantizar un acceso equitativo a todos los usuarios. Comprender y gestionar los límites de tasa es esencial para desarrollar aplicaciones de blockchain fiables que no fallen bajo carga.
La explicación sencilla
Imagina la cocina de un restaurante capaz de preparar 100 comidas por hora. Si 50 clientes piden cada uno 3 platos, la cocina está a pleno rendimiento. Si un cliente intenta pedir 50 platos, la cocina tiene que rechazar su pedido para que el resto pueda seguir comiendo. La limitación de tasa funciona de la misma manera. Un nodo de blockchain tiene una capacidad de procesamiento limitada, y los límites de tasa garantizan que ninguna aplicación monopolice esa capacidad en detrimento del resto de usuarios que utilizan la misma infraestructura.
Cuando tu aplicación envía demasiadas solicitudes RPC en un intervalo de tiempo demasiado corto, el nodo responde con un error en lugar de los datos solicitados. En la mayoría de los proveedores, se trata del código de estado HTTP 429 «Too Many Requests» (Demasiadas solicitudes), que suele ir acompañado de un cuerpo de error JSON-RPC en el que se indica cuántas solicitudes están permitidas, cuántas has intentado y cuánto tiempo debes esperar antes de volver a intentarlo. Si tu aplicación ignora estas señales y sigue enviando solicitudes, el proveedor podría bloquear temporalmente tu IP o tu clave API por completo.
Los límites de tasa suelen expresarse en solicitudes por segundo (RPS), solicitudes por minuto o una combinación de ambos. Un proveedor puede permitir 25 RPS en un nivel gratuito, 300 RPS en un nivel de crecimiento y más de 1.000 RPS en un nivel empresarial. Algunos proveedores también aplican límites por método, lo que significa que ciertos métodos que requieren un gran esfuerzo computacional, como `debug_traceTransaction` o `eth_getLogs` con rangos de bloques amplios, tienen límites individuales más bajos que los métodos ligeros como `eth_blockNumber`.
Por qué existen los límites de frecuencia
Los límites de tasa tienen tres funciones principales. En primer lugar, protegen la estabilidad de la infraestructura. Los nodos de la cadena de bloques son sistemas con estado que mantienen todos los datos de la cadena de bloques y ejecutan operaciones complejas, como llamadas a la EVM y consultas de estado. Un aluvión de solicitudes sin restricciones puede sobrecargar la CPU, la memoria, las E/S de disco o el ancho de banda de red de un nodo, lo que degrada el rendimiento para todos los usuarios o provoca un fallo total del nodo. Los límites de tasa actúan como un cortacircuitos que evita que un solo cliente provoque fallos en cadena.
En segundo lugar, los límites de tasa garantizan una asignación justa de los recursos. En la infraestructura compartida (que es la que utilizan la mayoría de los desarrolladores), cientos o miles de aplicaciones comparten el mismo conjunto de nodos. Sin límites de tasa, una sola aplicación que ejecute un script de indexación agresivo o un bucle de sondeo mal configurado podría consumir la mayor parte de la capacidad disponible, privando a otras aplicaciones de los recursos que necesitan. Los límites de tasa imponen una política de uso justo que garantiza que cada aplicación obtenga una parte razonable.
En tercer lugar, los límites de tasa son una medida de protección contra los abusos. Los ataques de denegación de servicio, ya sean intencionados o accidentales, pueden dejar fuera de servicio la infraestructura de la que dependen muchas aplicaciones. Los límites de tasa evitan tanto que los actores malintencionados utilicen los puntos de acceso públicos como que los desarrolladores bienintencionados provoquen accidentalmente un ataque DDoS en un nodo debido a un script fuera de control.
Cómo afectan los límites de frecuencia a tu aplicación
Si tu aplicación no está diseñada para gestionar los límites de frecuencia, dejará de funcionar en el entorno de producción. El fallo más habitual mode es un bucle de sondeo que consulta la cadena de bloques con demasiada frecuencia. Una aplicación que llama a «eth_blockNumber» cada 100 ms para comprobar si hay nuevos bloques está realizando 600 solicitudes por minuto solo con ese método. Si a esto le sumas las comprobaciones de saldo, las consultas de registro y los sondeos del estado de las transacciones para cada usuario activo, puedes superar fácilmente incluso los límites de frecuencia más generosos.
Las suscripciones a WebSocket también pueden activar límites de frecuencia. Aunque la solicitud de suscripción inicial cuenta como una sola llamada, cada mensaje entrante del servidor (como una notificación de nuevo bloque o una alerta de transacción pendiente) puede contabilizarse en tu consumo con algunos proveedores. Si tu aplicación se suscribe a eventos de alta frecuencia streams en varios contratos, el volumen de mensajes entrantes puede acumularse rápidamente.
Las solicitudes fallidas debido a la limitación de tasa provocan un efecto dominó. Cuando tu aplicación no recibe los datos que ha solicitado, puede volver a intentar la solicitud, lo que aumenta aún más la carga. Si los reintentos no se implementan con retroceso exponencial, se crea un bucle de retroalimentación en el que las solicitudes limitadas por la tasa generan más solicitudes, lo que a su vez genera más limitación de tasa. Este patrón puede bloquear efectivamente el acceso de tu aplicación al endpoint de RPC hasta que se reinicie la ventana de limitación de tasa.
Estrategias para gestionar los límites de frecuencia
La estrategia más eficaz consiste en reducir el número de solicitudes que debe realizar tu aplicación. El almacenamiento en caché es la base de este enfoque. Si tu aplicación muestra precios de ETH, metadatos de tokens u otros datos que cambian lentamente, almacena esos resultados en caché de forma local y actualízalos a intervalos razonables, en lugar de consultar el nodo cada vez que se carga una página o se realiza una acción de usuario. Para los datos que cambian con cada bloque, suscríbete a través de WebSocket en lugar de realizar consultas periódicas mediante HTTP, ya que una sola suscripción sustituye a miles de solicitudes de consulta individuales.
Agrupar las solicitudes reduce la sobrecarga de HTTP y puede ayudarte a no superar los límites de frecuencia. En lugar de realizar 10 llamadas separadas para consultar 10 saldos de monedero diferentes, agrúpalas en una única solicitud JSON-RPC en forma de matriz. El nodo procesa cada una de ellas individualmente, pero tú solo utilizas una solicitud HTTP para enviarlas todas. Ten en cuenta que algunos proveedores contabilizan cada llamada a un método dentro de un lote a la hora de calcular tu límite de frecuencia, y no solo la propia solicitud HTTP.
Implementar la limitación de tasa del lado del cliente es una buena práctica defensiva. En lugar de esperar a que el servidor rechace tus solicitudes, realiza un seguimiento de la tasa de solicitudes salientes y pon en cola o retrasa aquellas que superen el límite establecido. De este modo, mantienes tu aplicación dentro de los límites de forma proactiva y evitas la penalización por latencia que suponen las solicitudes rechazadas. Bibliotecas como «bottleneck» (Node.js) o «ratelimit» (Python) facilitan su implementación.
Elegir el nivel de infraestructura adecuado para tu uso es, en definitiva, la solución más fiable. Si tu aplicación alcanza constantemente los límites de tasa, necesita más capacidad, no más trucos de optimización. Pasar a un nivel superior o cambiar a una infraestructura dedicada elimina por completo la preocupación por los límites de tasa.
¿Qué significa un error HTTP 429?
Una respuesta HTTP 429 «Too Many Requests» significa que has superado la tasa de solicitudes permitida para el intervalo de tiempo actual. El nodo no está averiado y, por lo general, tus credenciales son correctas; simplemente estás enviando solicitudes a un ritmo superior al que permite tu plan. La solución consiste en leer la respuesta, que a menudo incluye el tiempo de espera, y volver a intentarlo tras ese retraso utilizando un retroceso exponencial, para que los fallos repetidos no generen una mayor carga. Si los errores 429 persisten, debes reducir el volumen de solicitudes o pasar a un nivel de mayor capacidad, en lugar de insistir en los intentos. Comprender cómo funcionan las solicitudes RPC y cómo un endpoint RPC procesa las llamadas ayuda a entender por qué algunos métodos alcanzan los límites antes que otros.
¿Cómo se puede evitar alcanzar los límites de frecuencia de las RPC?
Para evitar los límites de frecuencia, lo más importante es enviar menos solicitudes, que sean más baratas, y espaciarlas en el tiempo. La tabla siguiente resume las técnicas más eficaces y en qué casos resulta más adecuado utilizar cada una de ellas.
Técnica
Para qué sirve
Ideal para
Almacenamiento en caché
Reutiliza los resultados para datos que cambian lentamente
Precios, metadatos, saldos
Transmisión en directo frente a sondeos
Sustituye las consultas repetidas por datos enviados
Actualizaciones e indexación por bloques
Dosificación
Agrupa varias llamadas en una sola solicitud
Las lecturas en bloque se asemejan a muchos saldos
Limitación de velocidad del lado del cliente
Pide que se mantengan las solicitudes por debajo del límite máximo
Tráfico intermitente o generado por los usuarios
Infraestructura de nivel superior o dedicada
Aumenta o elimina el límite
Volumen elevado y constante de solicitudes
Pasar del sondeo al streaming suele suponer, por sí solo, la mayor reducción en el número de solicitudes. Cuando la optimización ya no es suficiente, la decisión se convierte en una disyuntiva entre «desarrollar» o «adquirir», en función de la capacidad y la fiabilidad que se desee tener.
¿Cuál es la diferencia entre la limitación de tasa y la regulación de flujo?
Estos términos suelen utilizarse indistintamente, pero describen respuestas diferentes ante una carga excesiva. La limitación de velocidad impone un límite máximo estricto: una vez superado, las solicitudes se rechazan directamente, normalmente con un código 429. La regulación es más suave: en lugar de rechazar las solicitudes, el sistema las ralentiza o las pone en cola para que se completen, aunque sea más lentamente. Ambas protegen la infraestructura compartida, pero fallan de formas diferentes desde la perspectiva del cliente.
Aspecto
Limitación de velocidad
Limitación de velocidad
Respuesta al exceso
Rechaza las solicitudes
Ralentiza o pone en cola las solicitudes
Señal típica
Error HTTP 429
Aumento de la latencia
Repercusión en los clientes
Llamadas fallidas que hay que volver a intentar
Llamadas retrasadas pero completadas
Objetivo
Establecer un límite máximo estricto de uso
Suavizar los picos de tráfico
Ambas situaciones pueden traducirse en una mayor latencia RPC desde el punto de vista de la aplicación, y ambas están relacionadas con las compensaciones entre el rendimiento global y la latencia en tu infraestructura.
Preguntas frecuentes
¿Cuál es un límite de velocidad de RPC aceptable?
Depende de tu volumen de trabajo y del plan que tengas. Los planes gratuitos pueden permitir unas 25 solicitudes por segundo, mientras que los planes «Growth» y «Enterprise» alcanzan cientos o miles. El límite adecuado es aquel que supere holgadamente tu tasa máxima de solicitudes después de haber aplicado el almacenamiento en caché, el procesamiento por lotes y la transmisión continua.
¿Cómo debo gestionar una respuesta 429?
No insistas y vuelve a intentarlo, en lugar de bombardear el endpoint. Utiliza un retroceso exponencial con fluctuación, respeta cualquier indicación de «retry-after» que aparezca en la respuesta y limita el número de reintentos. Si persisten los errores 429, reduce el volumen de solicitudes o amplía la capacidad, en lugar de volver a intentarlo de forma más agresiva.
¿Las solicitudes por lotes cuentan como una sola solicitud?
No siempre. El lote se envía como una única solicitud HTTP, pero muchos proveedores contabilizan cada llamada al método incluida en el lote dentro de tu límite de frecuencia. El envío por lotes sigue reduciendo la sobrecarga de red, pero no reduce necesariamente el número de llamadas contabilizadas.
¿El streaming evita los límites de velocidad?
En gran medida, sí, para la ingesta de datos. Un flujo basado en notificaciones «push» proporciona los nuevos datos de la cadena de bloques a medida que se generan, en lugar de requerir miles de llamadas de sondeo, lo que elimina la mayor parte del volumen de solicitudes que, en primer lugar, activa la limitación de tasa.
¿Por qué se aplica un límite de velocidad más estricto a algunos métodos?
Los métodos que requieren un gran esfuerzo computacional, como el seguimiento de transacciones o las consultas a registros de gran tamaño, consumen muchos más recursos del nodo que las llamadas ligeras, como la obtención del número del último bloque. Los proveedores aplican límites más estrictos por método a esas llamadas pesadas para proteger la estabilidad general del nodo.
Cómo gestiona « Quicknode » los límites de frecuencia
Quicknode Ofrece controles flexibles de limitación de tasa que permiten a los desarrolladores gestionar el uso de su endpoint. Más allá de los límites de RPS a nivel de plan, Quicknode ofrece limitación de tasa a nivel de método, lo que te permite establecer límites precisos para métodos RPC individuales. Esto resulta especialmente útil para proteger tu endpoint frente a scripts fuera de control o integraciones de terceros que puedan llamar en exceso a métodos costosos. Puede configurar límites por segundo, por minuto o por día para cada método, ya sea a través de la interfaz de usuario del panel de control o mediante programación a través de la API de la consola.
Quicknode También ofrece limitación de tasa basada en direcciones IP para controlar el número total de solicitudes procedentes de direcciones IP concretas, lo cual resulta útil cuando tu endpoint está expuesto a aplicaciones del lado del cliente en las que no puedes controlar totalmente el volumen de solicitudes. Los análisis en tiempo real del panel de control de Quicknode muestran el volumen de llamadas a métodos, los estados de las respuestas y los tiempos de respuesta, lo que te proporciona una visibilidad completa de tus patrones de uso para que puedas identificar y resolver los problemas antes de que se conviertan en problemas de limitación de tasa.
Para los equipos que necesitan superar por completo los límites de frecuencia, Quicknode Streams sustituye el patrón de solicitud-respuesta por un modelo de entrega de datos basado en notificaciones push. En lugar de que tu aplicación consulte el nodo miles de veces por minuto, Streams envía los datos de la cadena de bloques directamente a tu webhook, base de datos o almacén de datos a medida que se generan nuevos bloques. Esto elimina por completo los límites de frecuencia de RPC en las cargas de trabajo de ingesta de datos, al tiempo que reduce la latencia y simplifica tu arquitectura de backend.
