WebRTC vs WebSocket: entre pares o con un servidor
WebRTC vs WebSocket
WebRTC vs WebSocket (y webhooks, y HTTP) | We.Inc
WebRTC vs WebSocket: medios y canales de datos entre pares frente a un socket cliente-servidor, por qué WebRTC sigue necesitando señalización, además de webhook vs WebSocket y HTTP vs WebSocket.
WebSocket mantiene una conexión bidireccional entre un navegador y tu servidor, y cada mensaje pasa por ese servidor. WebRTC conecta los navegadores directamente entre sí para audio, vídeo y datos arbitrarios, cifrados con DTLS y SRTP. A menudo se usan juntos: un WebSocket transporta los mensajes de señalización que configuran la llamada WebRTC.
WebRTC y WebSocket comparados
Pregunta
WebRTC
WebSocket
Quién habla con quién
De navegador a navegador (entre pares)
De navegador a servidor
Pensado para
Audio, vídeo, compartir pantalla, datos entre pares
Mensajes entre la app y el servidor
Configuración
Oferta, respuesta y candidatos ICE mediante tu propia señalización
Un único handshake HTTP Upgrade
Opciones de entrega
Los canales de datos pueden ser ordenados o no, fiables o no
Ordenada y fiable
Cifrado
Siempre activo (DTLS, SRTP)
Solo con wss://
Necesita un servidor
Para la señalización, y relés TURN cuando los pares no pueden conectarse directamente
Sí, es el otro extremo
Elige lo que estás construyendo en el asistente de abajo y te dirá qué tecnología encaja y por qué. También responde a las dos preguntas que la gente suele mezclar con esta: los webhooks, que van de servidor a servidor, y las peticiones HTTP normales.
Elige la función más parecida a la tuya.
Lee qué tecnología encaja y por qué.
Baja hasta las secciones de código para ver un esbozo de señalización y un ejemplo de canal de datos.
Usa las dos tablas del final para las comparaciones con webhooks y con HTTP.
No recurras a WebRTC para enviar actualizaciones desde tu servidor. Ahí el servidor no es un par, y un WebSocket o un flujo de eventos es mucho más sencillo.
Reserva presupuesto para un relé TURN antes de lanzar las llamadas. Algunas redes bloquean las conexiones directas entre pares, y entonces todos los medios pasan por el relé que tú pagas.
Mantén el servidor de señalización tonto: solo reenvía ofertas, respuestas y candidatos. MDN describe el contenido como una caja negra que el servidor no necesita entender.
Para un juego o un flujo de cursores en vivo entre pares, abre el canal de datos con ordered en false y maxRetransmits en 0 para que un paquete tardío nunca bloquee a los más nuevos.
Preguntas frecuentes
¿WebRTC sustituye a los WebSockets?
No. WebRTC no incluye ninguna forma de que dos navegadores se encuentren, así que sigues necesitando un canal para intercambiar los mensajes de configuración. Lo habitual es un WebSocket, aunque MDN señala que sirve cualquier transporte.
¿Puede WebRTC enviar datos simples, no solo vídeo?
Sí. RTCPeerConnection.createDataChannel() abre un canal para datos de texto o binarios entre pares, y su API se parece a propósito a la de WebSocket, con send() y un evento message.
¿Qué diferencia hay entre un webhook y un WebSocket?
Un webhook es una petición HTTP que un servidor envía a una URL de otro servidor cuando ocurre un evento, y después la conexión termina. Un WebSocket es una conexión que permanece abierta para que un navegador y un servidor sigan hablando.
¿Es un WebSocket más rápido que HTTP?
Para muchos mensajes pequeños, normalmente sí, porque el handshake ocurre una sola vez y cada mensaje posterior se ahorra las cabeceras de la petición. Para cargar una página o un archivo, el HTTP de siempre es la herramienta correcta y se beneficia de la caché.
¿WebRTC sigue siendo entre pares con mucha gente en una llamada?
Cada conexión es entre dos pares, así que una malla completa crece rápido a medida que entra gente. Muchos productos de llamadas más grandes enrutan los medios a través de un servidor que reenvía los flujos, algo que queda fuera de la propia API de WebRTC del navegador.
Por qué WebRTC sigue necesitando un servidor
Antes de que dos navegadores puedan conectarse, cada uno debe conocer la descripción de sesión del otro, una oferta y una respuesta SDP, y una lista de posibles direcciones de red llamadas candidatos ICE. WebRTC deja en tus manos la entrega de esos mensajes.
Una vez intercambiados, ICE prueba los candidatos, con STUN ayudando a cada lado a descubrir su dirección pública. Si ninguna ruta directa funciona, el tráfico pasa a un servidor TURN que lo retransmite. A partir de ahí los medios fluyen entre los pares, no a través de tu servidor de señalización.
Webhook vs WebSocket
Resuelven problemas distintos. Un webhook permite que un servicio, como un proveedor de pagos o un alojamiento de código, avise a tu backend de que algo ha pasado, enviando una petición HTTP a una URL que registraste. Nada queda abierto y no interviene ningún navegador.
Un WebSocket mantiene una línea en directo con el navegador del usuario. Un patrón habitual usa ambos: un webhook avisa a tu servidor de que se pagó un pedido, y tu servidor envía entonces esa noticia a la página abierta del cliente por un WebSocket.
HTTP vs WebSocket
El HTTP normal es petición y respuesta: el cliente pregunta, el servidor contesta, y los navegadores y las CDN pueden cachear las respuestas GET. Es la opción por defecto adecuada para páginas, archivos y la mayoría de llamadas a API.
Un WebSocket empieza como una petición HTTP, luego cambia de protocolo con una respuesta 101 y permanece abierto. Recurre a él solo cuando el servidor deba enviar datos que el cliente no pidió, o cuando los mensajes vayan y vengan con tanta frecuencia que el coste por petición importe.
Configurar WebRTC sobre un WebSocket
Quien inicia la llamada: crea una oferta y un canal de datos
El WebSocket solo reenvía los mensajes de configuración. La URL de STUN es un marcador para el servidor que elijas.
Quien recibe: responde y recibe el canal
El otro lado obtiene el canal mediante el evento datachannel en lugar de crearlo.
Un canal sin orden y sin reintentos para el estado del juego
maxRetransmits y maxPacketLifeTime no pueden definirse a la vez; elige uno.
Webhook vs WebSocket de un vistazo
Webhook vs WebSocket
Pregunta
Webhook
WebSocket
Quién se conecta
Un servidor invoca a otro servidor
Un cliente mantiene una línea abierta con un servidor
Duración
Una petición HTTP por evento
Abierto hasta que uno de los dos lados lo cierra
Dirección
Del emisor al receptor
En ambos sentidos
Uso típico
Eventos de pagos, repositorios o formularios
Chat en vivo, paneles, presencia
HTTP vs WebSocket de un vistazo
HTTP vs WebSocket
Pregunta
Petición HTTP
WebSocket
Quién inicia un mensaje
Siempre el cliente
Cualquiera de los dos lados
Conexión
Petición, luego respuesta
Se actualiza con 101 y queda abierta
Caché
Las respuestas GET y HEAD se pueden cachear
Ninguna
Esquemas de URL
ws:// (puerto 80), wss:// (puerto 443)
Videollamada entre dos personas
WebRTC, con un WebSocket para la señalización
El audio y el vídeo deben ir directamente entre quienes hablan, con poco retraso. Un pequeño servidor WebSocket solo transmite la oferta, la respuesta y los candidatos durante la configuración.
Sala de chat en grupo en una app web
WebSocket
Los mensajes deben guardarse, moderarse y enviarse a todos los de la sala, así que de todas formas deben pasar por tu servidor. Un socket por usuario es la solución sencilla.
Enviar un archivo grande al navegador de un amigo
Canal de datos WebRTC
Un canal de datos fiable y ordenado mueve los bytes entre pares, así que tu servidor nunca guarda ni retransmite el archivo salvo que haga falta TURN.
Movimientos rápidos en un juego de dos jugadores
Canal de datos WebRTC, sin orden
Sin orden y sin retransmisiones, una actualización de posición perdida se descarta en lugar de retener a las más nuevas. Si necesitas un servidor árbitro, usa mejor un WebSocket hacia él.
Un proveedor de pagos confirma un pedido
Webhook
El servidor del proveedor invoca una URL de tu servidor cuando el pago se completa. No interviene ningún navegador y nada tiene que quedar abierto.
Cargar una página de producto y sus datos
HTTP normal
Petición y respuesta es todo lo que necesitas, y las respuestas GET se pueden cachear. Una conexión persistente añadiría coste sin ningún beneficio.