¿Qué es una desconexión?
Establecer una conexión a las APIs de streaming implica hacer una solicitud HTTPS de muy larga duración y parsear la respuesta de forma incremental. Al conectarse a un endpoint de streaming, debes formar una solicitud HTTPS y consumir el stream resultante durante el tiempo que sea práctico. Los servidores de X mantendrán la conexión abierta indefinidamente, salvo:- Errores del lado del servidor
- Retraso excesivo del lado del cliente
- Problemas de red
- Mantenimiento rutinario del servidor
- Inicios de sesión duplicados
Por qué las conexiones se desconectan
Posibles razones de desconexiones:Errores comunes de desconexión
Operational disconnect
Demasiadas conexiones
Detectar desconexiones
Los endpoints de streaming proporcionan un keep-alive heartbeat de 20 segundos (un carácter de nueva línea). Usa esta señal para detectar desconexiones:- Tu código debe detectar cuándo dejan de llegar contenidos nuevos y el heartbeat
- Si no se recibe ningún dato durante 20 segundos, activa la lógica de reconexión
- Algunos clientes HTTP te permiten especificar un timeout de lectura — configura esto en 20 segundos
Estrategia de reconexión
Una vez que una conexión establecida se pierde, intenta reconectarte inmediatamente. Si la reconexión falla, usa estrategias de backoff basadas en el tipo de error:Errores de red TCP/IP
Backoff lineal. Estos problemas son generalmente temporales.- Aumenta el retraso en 250 ms en cada intento
- Retraso máximo: 16 segundos
Errores HTTP
Backoff exponencial para errores HTTP en los que reconectarse sea apropiado.- Comienza con una espera de 5 segundos
- Duplica en cada intento
- Retraso máximo: 320 segundos
Errores de rate limit (HTTP 429)
Backoff exponencial con una espera inicial más larga.- Comienza con una espera de 1 minuto
- Duplica en cada intento
- Cada 429 recibido aumenta el tiempo de espera hasta que expire el rate limiting
Rate limits y uso
Las respuestas de conexión de streaming devuelven tres cabeceras para ayudarte a comprender los límites:
Para rastrear cuántos Posts se han entregado, implementa lógica de medición en el lado del cliente para que se pueda medir y pausar el consumo si es necesario.
Buenas prácticas de reconexión
Usa una arquitectura de cola FIFO
Tu cliente de stream debe insertar los Posts entrantes en una cola FIFO (first-in, first-out) o una estructura en memoria similar. Un proceso/hilo separado debe consumir los Posts de esa cola para su parseo y almacenamiento. Este diseño escala eficientemente cuando los volúmenes de Posts cambian drásticamente.Prueba las estrategias de backoff
Prueba tu implementación de backoff usando credenciales de autorización inválidas y examina los intentos de reconexión. Una buena implementación no debe recibir ninguna respuesta 429.Emite alertas para múltiples reconexiones
Si tu cliente alcanza su umbral superior de tiempo entre reconexiones, envía notificaciones para que puedas clasificar los problemas de conexión.Gestiona cambios de DNS
Asegúrate de que tu proceso cliente respete el Time To Live (TTL) del DNS. Algunas pilas almacenan en caché las direcciones resueltas durante la duración del proceso y no captarán los cambios de DNS dentro del TTL. El almacenamiento en caché agresivo conduce a interrupciones del servicio a medida que X redistribuye la carga entre direcciones IP.Configura la cabecera User-Agent
Incluye la versión de tu cliente en la cabecera HTTPUser-Agent. Esto es fundamental para diagnosticar problemas del lado de X. Si tu entorno impide configurar User-Agent, usa la cabecera x-user-agent en su lugar.
Próximos pasos
Recuperación y redundancia
Recupera los datos perdidos después de desconexiones
Consumo de datos de streaming
Construye clientes de streaming robustos
Capacidad de alto volumen
Maneja streams de alto rendimiento