Comunicaciones en tiempo real en el desarrollo móvil: qué es, qué protocolos y cómo funciona

Comunicaciones en tiempo real: protocolos WebSocket, SSE y Long Polling

Las comunicaciones en tiempo real son tecnologías que permiten el intercambio de datos entre cliente y servidor con latencia mínima. Los protocolos principales: WebSocket, SSE (Server-Sent Events), Long Polling y Short Polling. Cada uno tiene su nicho: WebSocket para comunicación bidireccional, SSE para notificaciones, Long Polling como fallback para navegadores antiguos. El tiempo real en el desarrollo móvil es especialmente importante: los usuarios esperan una entrega instantánea de mensajes y notificaciones. Las comunicaciones en el desarrollo móvil se construyen precisamente sobre estos protocolos.

WebSocket vs SSE

WebSocket es un protocolo full-duplex (cliente ↔ servidor). Tras el handshake (HTTP Upgrade) la conexión permanece abierta. Los encabezados son mínimos (2 bytes frente a encabezados HTTP). Se utiliza en chats (WhatsApp, Telegram), juegos, trading en tiempo real. SSE es un protocolo unidireccional (servidor → cliente). El cliente se suscribe a eventos y los recibe a través de una única conexión HTTP. SSE es más simple, más fácil de escalar (HTTP simple), ideal para feeds de Twitter, tipos de cambio, notificaciones push.

Long Polling es una técnica en la que el cliente realiza una solicitud HTTP y la mantiene abierta hasta que el servidor envía datos o se produce un tiempo de espera (30–60 seg). Tras recibir datos, el cliente abre inmediatamente una nueva solicitud. Long Polling es un fallback para WebSocket. Short Polling — el cliente consulta al servidor cada N segundos. Es el más simple pero ineficiente (la mayoría de las solicitudes devuelven respuestas vacías).

Servidor de señalización

Antes de establecer una conexión P2P, los dispositivos necesitan un Servidor de señalización — un servidor intermediario para intercambiar ofertas SDP y candidatos ICE entre pares. La señalización puede implementarse a través de WebSocket, SSE o cualquier otro protocolo. Una vez establecida la conexión, la señalización ya no participa en la transmisión del tráfico multimedia.

WebRTC: comunicaciones en tiempo real con llamadas de audio y video

WebRTC (Web Real-Time Communication) es una tecnología abierta para audio/video/datos P2P. Funciona en navegadores y aplicaciones nativas (iOS, Android). WebRTC incluye: getUserMedia (acceso a cámara/micrófono), RTCPeerConnection (conexión P2P), RTCDataChannel (transferencia de datos). WebRTC permite comunicaciones en tiempo real en aplicaciones móviles — las comunicaciones en apps móviles funcionan sin complementos adicionales.

Flujo de WebRTC

El Par A crea una RTCPeerConnection y una Offer SDP. Paso 2: La Offer se envía a través del Servidor de señalización al Par B. Paso 3: El Par B recibe la Offer, crea una Answer SDP y la envía de vuelta. Paso 4: Ambos pares recopilan candidatos ICE (direcciones para la conexión) y los intercambian a través de la señalización. Paso 5: El framework ICE selecciona la mejor ruta (P2P o a través de TURN). Tras la conexión — el tráfico multimedia fluye directamente.

SDP (Session Description Protocol) es un protocolo de texto que describe los parámetros de conexión: códecs, direcciones IP, puertos. ICE Candidate es una propuesta de STUN/TURN: "Se me puede encontrar en esta dirección". Cuantos más candidatos, mayor probabilidad de P2P.

Socket.IO es el líder para startups: tú controlas el servidor, sin límites. Pusher y Ably son para productos donde no quieres gestionar infraestructura. PubNub es para IoT y audiencias globales. IT Sectr recomienda Socket.IO para proyectos con backend propio, Pusher para prototipos rápidos, Ably para empresas con requisitos de fiabilidad.

Plataformas: Socket.IO, Pusher, Ably, PubNub

Las plataformas en tiempo real proporcionan infraestructura de servidor lista para WebSocket y SSE. Eliminan la necesidad de escribir tu propio servidor en tiempo real, balancear conexiones WebSocket y escalarlas. La elección de la plataforma depende del presupuesto, los requisitos de fiabilidad y la disposición a gestionar un servidor. Para el tiempo real en el desarrollo móvil, las plataformas ofrecen SDKs de cliente e infraestructura listos para usar.

Socket.IO

Socket.IO es una biblioteca para Node.js y clientes (iOS, Android, web). Basada en WebSocket, pero utiliza HTTP polling como fallback. Soporta salas, espacios de nombres, confirmaciones ACK. Para desarrollo — socket.io-client-java (Android) y socket.io-client-swift (iOS). Las comunicaciones en aplicaciones móviles con Socket.IO se manejan de forma fiable gracias a la reconexión automática.

Pusher y Ably

Pusher es una plataforma SaaS en tiempo real. Integración simple: crea un canal y suscríbete a eventos. Pusher Channels para notificaciones, Pusher Beams para notificaciones push. Ably es de nivel empresarial con replicación global en 7 centros de datos. Garantiza entrega exactly-once. Soporta SSE, WebSocket, MQTT para IoT. Ambas plataformas resuelven tareas de comunicación en el desarrollo móvil sin escribir código de servidor.

Infraestructura en tiempo real: STUN, TURN, Signaling en WebRTC

STUN (Session Traversal Utilities for NAT) es un servidor que ayuda a un dispositivo a descubrir su IP y puerto externos detrás de NAT. El dispositivo envía una solicitud STUN, el servidor responde: "Eres visible como 203.0.113.5:45678". STUN se usa de forma gratuita (Google STUN: stun.l.google.com:19302). En el contexto de la infraestructura en tiempo real, STUN es el primer paso para establecer un canal P2P.

STUN vs TURN

TURN (Traversal Using Relays around NAT) es un servidor de retransmisión que retransmite el tráfico multimedia si la conexión P2P es imposible (por ejemplo, ambos dispositivos están detrás de NAT simétrico). TURN consume ancho de banda del servidor, por lo que es caro. En WebRTC, el framework ICE primero prueba P2P, luego TURN como último recurso. El tiempo real en el desarrollo requiere TURN para comunicaciones en aplicaciones móviles al conectarse a través de redes corporativas.

ICE (Interactive Connectivity Establishment) es un framework que recopila todas las rutas de conexión posibles (IP local, IP externa a través de STUN, relays TURN) y selecciona la mejor. ICE Candidate es cada ruta posible. Cuantos más candidatos, mayor probabilidad de P2P exitoso.

Peer-to-Peer

P2P es una conexión directa entre dos dispositivos sin un servidor intermediario para el tráfico multimedia. P2P reduce la latencia (< 100 ms) y los costes de servidor. Desventajas: protección débil contra NAT, necesidad de STUN/TURN. WebRTC usa P2P por defecto.

P2P e ICE

Peer-to-Peer (P2P) es una arquitectura donde los datos se transfieren directamente entre dispositivos. En el contexto de las comunicaciones en tiempo real, P2P se utiliza en WebRTC para minimizar la latencia. ICE (Interactive Connectivity Establishment) es el mecanismo que encuentra la mejor ruta para una conexión P2P. Para el desarrollo, P2P es la forma óptima de organizar comunicaciones en aplicaciones móviles en tiempo real.

Cómo funciona ICE

ICE recopila ICE Candidate de tres tipos: 1) host (IP local), 2) srflx (a través de STUN), 3) relay (a través de TURN). Todos los candidatos se ordenan, e ICE intenta conectarse con cada uno en orden de prioridad. La primera conexión exitosa se utiliza. Si P2P no es posible, se usa TURN (pero es caro).