Saltar al contenido principal

WebSockets

Un WebSocket es una tecnología que proporciona un canal de comunicación bidireccional y full-duplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y servidores web, pero puede utilizarse por cualquier aplicación cliente/servidor.

Los WebSockets son útiles en una variedad de casos de uso que requieren una comunicación en tiempo real entre el cliente y el servidor.

Los usos más comunes para los WebSockets incluyen:

  • Actualizaciones de eventos en tiempo real, como los feeds de redes sociales, resultados deportivos, noticias o precios del mercado de valores.
  • Notificaciones de usuario, como actualizaciones de software o de contenido.
  • Aplicaciones para chatear.
  • Herramientas de edición colaborativas.
  • Juegos multijugador. (Trackear la posición de un jugador en tiempo real)

La comunicación WebSocket consiste de “frames” (cuadros) de fragmentos de datos, que pueden ser enviados de ambos lados y un frame de WebSocket puede ser de uno de 6 tipos:

  • texto
  • binario
  • ping, pong
  • cierre y continuación

Además, cada frame es o no un frame fin. Los sockets funcionan en función de los eventos. “Event oriented”

https://www.youtube.com/watch?v=1BfCnjr_Vjg

Conceptos​

  • Http vs web sockets

    HTTP y WebSocket son dos protocolos de comunicación utilizados en la comunicación cliente-servidor. HTTP es unidireccional: el cliente envía la solicitud y el servidor la respuesta. Cada solicitud está asociada a su correspondiente respuesta y, tras enviar la respuesta, se cierra la conexión. Cada petición HTTP o HTTPS establece una nueva conexión con el servidor cada vez y después de obtener la respuesta la conexión se termina por sí misma.

    Por otro lado, WebSocket es bidireccional, un protocolo full-duplex que se utiliza en el mismo escenario de comunicación cliente-servidor. Es un protocolo con estado, lo que significa que la conexión entre el cliente y el servidor se mantendrá viva hasta que sea terminada por cualquiera de las partes (cliente o servidor). Tras el cierre de la conexión por cualquiera de los dos, la conexión se termina por ambos extremos.

    A diferencia de HTTP, donde hay que solicitar actualizaciones constantemente, con websockets las actualizaciones se envían inmediatamente cuando están disponibles. WebSockets mantiene abierta una conexión única y persistente, al tiempo que elimina los problemas de latencia que surgen con los métodos HTTP basados en solicitud/respuesta.

  • HTTP Long pulling

    El polling largo es una técnica que emula a un servidor enviando mensajes a un cliente (o navegador) de forma eficiente. Es esencialmente una forma más eficiente de la técnica original de polling. El polling largo es la forma más simple de tener una conexión persistente con un servidor, que no utiliza ningún protocolo específico como WebSocket o Server Sent Events. Siendo muy fácil de implementar, también es lo suficientemente buena en muchos casos 2.

    En el polling largo, el cliente consulta al servidor solicitando nueva información. El servidor mantiene la petición abierta hasta que hay nuevos datos disponibles. Una vez disponibles, el servidor responde y envía la nueva información. Cuando el cliente recibe la nueva información, envía inmediatamente otra petición, y la operación se repite.

  • Transports

    En desarrollo web, un transporte se refiere a un mecanismo para enviar datos entre un cliente y un servidor. Existen varios protocolos de transporte disponibles para su uso en Internet, incluido HTTP/3, utilizado por la API WebTransport para proporcionar una comunicación bidireccional de baja latencia entre un cliente web y un servidor HTTP/312. La API WebTransport admite el envío de datos tanto de forma no fiable a través de sus API de datagramas como fiable a través de sus API de flujos2. Otro protocolo de transporte habitual es TCP, que se basa en la conexión y es fiable.

    Los protocolos de transporte más utilizados en el desarrollo web son el Protocolo de Control de Transmisión (TCP) y el Protocolo de Datagramas de Usuario (UDP) . Estos protocolos ofrecen diferentes funcionalidades para los distintos requisitos de las aplicaciones. TCP es un protocolo basado en conexiones que proporciona una transferencia de datos fiable, mientras que UDP es un protocolo sin conexiones que proporciona una transferencia de datos poco fiable.

  • Handshake

    Para establecer una conexión, el cliente DEBE enviar una petición HTTP GET al servidor.

    Si el servidor acepta la conexión, DEBE responder con un paquete abierto con la siguiente carga útil codificada en JSON:

  {
    "sid": "lv_VI97HAXpY6yYWAAAC",
    "upgrades": ["websocket"],
    "pingInterval": 25000,
    "pingTimeout": 20000,
    "maxPayload": 1000000
  }

El cliente DEBE enviar el valor sid en los parámetros de consulta de todas las peticiones posteriores.

  • Upgrade

    Por defecto, el cliente DEBERÍA crear una conexión HTTP long-polling, y luego actualizar a mejores transportes si están disponibles.

    Para actualizar a WebSocket, el cliente DEBE:

    • pausar el transporte HTTP de sondeo largo (no se envían más peticiones HTTP), para garantizar que no se pierde ningún paquete
    • abrir una conexión WebSocket con el mismo identificador de sesión
    • enviar un paquete ping con la cadena probe en el payload

    El servidor DEBE:

    • enviar un paquete noop a cualquier solicitud GET pendiente (si procede) para cerrar limpiamente el transporte HTTP de long-polling
    • responder con un paquete pong con la cadena probe en el payload

  • Heartbeat

    Una vez completado el handshake, se inicia un mecanismo de heartbeat para comprobar la vitalidad de la conexión:

    A un intervalo determinado (el valor pingInterval enviado en el handshake), el servidor envía un paquete ping y el cliente dispone de unos segundos (el valor pingTimeout) para enviar un paquete pong de vuelta.

  • Frames

    Los frames son una cabecera + datos de aplicación. La cabecera contiene información sobre la trama y los datos de la aplicación. Los datos de aplicación son todo lo que envías en el "cuerpo" del frame. En su forma más básica, el protocolo websocket tiene tres frames de no control y tres frames de control.

  • Emitter, send

    socket.send is implemented for compatibility with "vanilla WebSocket" interface. socket.emit is feature of socket.io only. They both do the same, but socket.emit is a bit more convenient in handling messages.

    La API de Socket.io está inspirada en el EventEmitter de Node.js, lo que significa que puedes emitir eventos por un lado y registrar oyentes por el otro:

  // server-side
  io.on("connection", (socket) => {
    socket.emit("hello", "world");
  });

  // client-side
  socket.on("hello", (arg) => {
    console.log(arg); // world
  });

  //This also works in the other direction

  // server-side
  io.on("connection", (socket) => {
    socket.on("hello", (arg) => {
      console.log(arg); // world
    });
  });

  // client-side
  socket.emit("hello", "world");

socket.send envía mensajes que se reciben con el evento 'message'

socket.emit() vs. socket.send()

  • WebRTC

    Comunicación en tiempo real para la Web

    Con WebRTC, puede añadir a su aplicación capacidades de comunicación en tiempo real que funcionan sobre un estándar abierto. Admite el envío de vídeo, voz y datos genéricos entre pares, lo que permite a los desarrolladores crear potentes soluciones de comunicación por voz y vídeo. La tecnología está disponible en todos los navegadores modernos, así como en clientes nativos para las principales plataformas. Las tecnologías detrás de WebRTC se implementan como un estándar web abierto y están disponibles como API de JavaScript normales en los principales navegadores. Para los clientes nativos, como las aplicaciones Android e iOS, existe una biblioteca que ofrece la misma funcionalidad. El proyecto WebRTC es de código abierto y cuenta con el apoyo de Apple, Google, Microsoft y Mozilla, entre otros. Esta página está mantenida por el equipo Google WebRTC.