Los WebSockets son un protocolo de la capa de aplicación de la pila de protocolos TCP/IP y del modelo de interconexión de sistemas abiertos (modelo OSI). Se encuentra en el mismo lugar que el protocolo HTTP. La capa de transporte utiliza el protocolo TCP para transmitir los datos en paquetes.
A diferencia de los sockets de la capa de transporte, que son una interfaz a través de la cual los protocolos de la capa de aplicación acceden a los servicios de la capa de transporte, un WebSocket es un protocolo que describe las reglas de comunicación entre diferentes hosts de la capa de aplicación.
Tabla de Contenido
Protocolo HTTP
El protocolo HTTP se utiliza para la web, que es un protocolo muy popular, ¿por qué necesitamos otro? El protocolo HTTP funciona en modo solicitud-respuesta. Un cliente envía una solicitud a un servidor, el servidor responde con una página web y la muestra en un navegador, por ejemplo.
Este modelo proporciona un protocolo muy sencillo, pero el inconveniente es que el servidor no puede enviar nada al cliente por voluntad propia, tiene que esperar a que el cliente envíe una petición/solicitud e incluir esos datos en la respuesta. Y si la web solía ser muy sencilla y se utilizaba para navegar por ella, entonces este modelo era suficiente.
Necesidades en Chat
La web es ahora más compleja y se utiliza para muchas otras tareas, como los mensajeros y las salas de chat. En este caso tenemos varios clientes de chat que están conectados al mismo servidor. Uno de los clientes envía un mensaje al servidor y, a continuación, el servidor envía este mensaje a todos los demás clientes del chat para que puedan verlo.
Sin embargo, si utilizamos el protocolo HTTP, el servidor no puede enviar el mensaje a todos los clientes nada más recibirlo, sino que tiene que esperar a que cada cliente envíe su petición HTTP. Este problema también puede resolverse dentro del protocolo HTTP, por ejemplo, enviando peticiones a pequeños intervalos para recibir el mensaje rápidamente. Sin embargo, el problema es que esto crea una gran carga en la red y funciona de manera ineficiente.
WebSockets: Concepto y Uso
Los WebSockets están diseñados para hacer precisamente eso. A diferencia de HTTP, los WebSockets establecen una conexión bidireccional persistente entre el cliente y el servidor. A través de esta conexión, el cliente puede enviar datos al servidor en cualquier momento, y el servidor puede enviar datos al cliente por iniciativa propia en cualquier momento.
Asimismo, cualquier parte que reciba una solicitud podrá responder a ella inmediatamente o después de un tiempo, según lo considere oportuno y con la mayor eficacia posible. Por lo tanto, los websocket son mucho más adecuados para desarrollar aplicaciones en tiempo real que el protocolo HTTP.
Los Web sockets son un protocolo estándar definido en el RFC 6455 en 2011 y es soportado por todos los navegadores modernos. Los websockets establecen una conexión bidireccional persistente entre el cliente y el servidor en la capa de aplicación. También se utiliza una conexión TCP persistente en la capa de transporte.
Los websockets, así como el HTTP, funcionan en los puertos 80 y 443 si se utiliza la encriptación. Para los web sockets hay un prefijo especial en la URL ws/ que significa web sockets o wss/ si los sockets se utilizan junto con SSL TLS para el cifrado. La URL de los web sockets es la siguiente: ws://www/ccnadesdecero.es/chat).
Establecimiento de una Conexión: Solicitud del Cliente
En los web sockets, la solicitud de conexión de un cliente se parece a una solicitud HTTP GET. Especifica la opción de actualización y el protocolo al que se debe actualizar el websocket. La cabecera también contiene la clave del websocket, que son 16 bytes generados aleatoriamente y representados en codificación base 64.
GET /chat HTTP/1.1
Host: ccnadesdecero.es
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
Origin: https://ccnadesdecero.es
Sec-WebSocket.Version: 13La clave se utiliza para proteger contra las solicitudes falsas para establecer una conexión con los web sockets. La cabecera también indica la versión de los web sockets, la versión actual 13.
Establecimiento de una Conexión: Respuesta del Servidor
La respuesta del servidor para establecer una conexión de web socket también se parece a la respuesta HTTP. Código de respuesta 101, Switching Protocols.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTXaQK9THzzhRSjJ+xOo=La cabecera Upgrade también especifica el protocolo al que se cambian los web sockets y especifica la clave de seguridad, que se deriva de la clave enviada a los clientes utilizando un algoritmo especial descrito en el RFC 6455. A continuación, se establece una conexión TCP directa entre el cliente y el servidor, donde se transmiten los datos sin utilizar el protocolo HTTP.
Transferencia de Datos
En los web sockets los datos se transfieren en forma de tramas mientras que los desarrolladores del protocolo trataron de reducir el coste de la transferencia de datos, por lo que la cabecera de los web sockets es una forma binaria en contraste con HTTP, donde la cabecera en forma de texto es muy grande. Como resultado, la sobrecarga de la transferencia de datos a través de web sockets es mucho menor que a través de HTTP.
Fragmentación
Los datos que quieres enviar a través de los web sockets no tienen por qué caber en una sola trama, y los web sockets admiten la fragmentación. Un mensaje grande puede dividirse en varias partes y transmitirse en varias tramas.
Tipos de Tramas
Hay tres tipos de tramas en los web sockets:
- tramas que transmiten información de texto en codificación utf-8;
- tramas que transmiten datos en forma binaria;
- las tramas de control que se utilizan para mantener o cerrar una conexión.
Solicitud de Ping
Las solicitudes ping/pong se utilizan para establecer una conexión, el servidor envía una trama de control ping al cliente a intervalos regulares y después de que el cliente haya recibido la solicitud, responde con una trama de control pong.
Esto tiene dos propósitos: el primero es asegurar que el otro lado de la conexión sigue funcionando, y el segundo es mantener las conexiones TCP abiertas en caso de que el cliente y el servidor no estén conectados directamente sino a través de un servidor proxy o un equilibrador de carga, por ejemplo.
Cerrar la Conexión
Una conexión se termina con una trama de control especial del tipo de cierre. Cualquiera de las partes puede terminar una conexión por iniciativa propia. Por ejemplo, si un cliente envía un mensaje de cierre (close) a un servidor, éste responde con una trama de control de cierre (close) y termina la conexión.
Formato de la Cabecera de la Trama del WebSocket
La cabecera de la trama en los web sockets tiene el siguiente aspecto. Esta imagen es del documento RFC.
Los principales campos aquí son el código de operación (opcode), que le indica qué tipo de trama es. Puede ser una trama que transmita datos de texto, datos binarios, trama ping, trama pong, trama close y otros tipos de trama.
La sección Payload Data contiene los datos útiles que se van a transmitir. Los web sockets utilizan un esquema inteligente para especificar la cantidad de datos que se van a transferir, con el fin de reducir la sobrecarga. Si el volumen de datos es pequeño, sólo se utilizan 7 bits para el campo de longitud de datos, pero si el volumen de datos es grande, se pueden utilizar bits de cabecera adicionales y el tamaño del campo de longitud de datos puede ser de 16 o 64 bits.
La primera parte de la trama contiene banderas. El primer tipo de bandera FIN se utiliza para indicar fragmentación, si esta bandera es uno. Entonces la trama actual es la última. Al mismo tiempo si los datos caben en una trama en su totalidad y no hay fragmentación, entonces la bandera FIN se pone a uno.
Y si los datos han sido fragmentados y se transmiten en múltiples tramas, entonces en todas las tramas, excepto en la última, la bandera FIN se pone a 0. Las siguientes tres banderas, están reservadas y se utilizan para ampliar el protocolo. El cliente y el servidor deben decidir, durante el proceso de establecimiento de la conexión, si se utilizarán las extensiones y cuáles.
En los web sockets, los datos en tránsito pueden ser enmascarados y en la práctica esto se hace casi siempre, si los datos son enmascarados la bandera MASK se pone a uno, en caso contrario 0. Si se utiliza el enmascaramiento de datos, la trama debe incluir una clave de enmascaramiento, la Masking-key.
La clave de enmascaramiento es generada aleatoriamente por el emisor y esta clave debe ser diferente para cada trama, si se utiliza el enmascaramiento entonces la parte de Payload Data contiene los datos que se obtienen como resultado de la operación xor de la clave de enmascaramiento y los datos originales.
Conclusión
Hemos estudiado el protocolo web socket, que permite la transferencia de datos asíncrona bidireccional. Los web sockets son muy útiles para desarrollar aplicaciones web en tiempo real.
El funcionamiento de los web sockets consta de dos partes, la primera etapa es el establecimiento de la conexión, ahora las cabeceras del protocolo HTTP se utilizan para este propósito, pero el protocolo de los web sockets implica una extensión y si después de algún tiempo en la web será popular otro protocolo que HTTP, entonces el procedimiento de establecimiento de la conexión en los web sockets puede ser reemplazado por otro protocolo. La segunda fase de los web sockets, la transferencia de datos, se realiza a través de una conexión TCP directa entre el cliente y el servidor utilizando tramas en formato web socket.
La ventaja de los web sockets es que este protocolo es compatible con toda la infraestructura web que está diseñada para el funcionamiento del protocolo HTTP. De modo que, si quieres sustituir HTTP por Web sockets en tu aplicación en la infraestructura existente, no hay necesidad de cambiar nada.
Además, los web sockets proporcionan un mejor rendimiento debido a la baja sobrecarga de transferencia de datos que supone el uso de cabeceras de trama binaria de web socket en lugar de las grandes cabeceras HTTP en texto plano.
