Más información sobre los protocolos HTTP y WebSocket (2)
El artículo anterior presentó el contenido básico del protocolo HTTP1.1. Este artículo continuará analizando el protocolo WebSocket y luego hará una comparación simple entre los dos.
El protocolo WebSocket es todavía muy joven y el documento RFC se publicó por poco tiempo en comparación con HTTP. Nació para crear un protocolo de "comunicación bidireccional" como reemplazo del protocolo HTTP. . Primero, echemos un vistazo a la diferencia entre este y HTTP (o la conexión larga de HTTP).
Como se mencionó en el artículo anterior, el propósito de WebSocket es resolver el problema de la comunicación bidireccional en la transmisión de red. HTTP1.1 utiliza una conexión persistente de forma predeterminada y también se pueden transmitir múltiples solicitudes en una. Conexión TCP.Par de mensajes /Respuesta, pero el modelo básico de HTTP sigue siendo una Solicitud correspondiente a una Respuesta. En la comunicación bidireccional (el cliente necesita transmitir datos al servidor y el servidor también necesita transmitir información al cliente en tiempo real, un sistema de chat es una comunicación bidireccional típica), generalmente se utilizan las siguientes soluciones:
El propósito de WebSocket es reemplazar el uso de HTTP en escenarios de comunicación bidireccional, y algunas de sus implementaciones también se basan en HTTP (los puertos predeterminados de WS son 80 y 443). Todos los entornos de red existentes (clientes, servidores, intermediarios de red, proxies, etc.) tienen un buen soporte para HTTP, por lo que puede hacer un uso completo de la infraestructura HTTP existente y, en cierto modo, es compatible con versiones anteriores.
En pocas palabras, el protocolo WS consta de dos partes: protocolo de enlace y transmisión de datos.
Por razones de compatibilidad, el protocolo de enlace de WS se implementa mediante HTTP (este documento menciona que se pueden usar puertos y métodos dedicados para implementar el protocolo de enlace en el futuro), y el mensaje de protocolo de enlace del cliente es una "solicitud HTTP" "ordinaria". mensaje con encabezado Actualizar". Entonces, la mayor parte del contenido de esta sección proviene de RFC2616, y este es solo uno de sus formularios de aplicación. El siguiente es un ejemplo de un mensaje de reconocimiento de cliente proporcionado en el documento RFC6455:
Como puede ver, los dos primeros La línea es exactamente la misma que la línea inicial de la Solicitud HTTP, y los siguientes campos de encabezado realmente juegan un papel en el proceso de protocolo de enlace de WS.
Si el servidor acepta esta solicitud, puede enviar información de devolución como la siguiente, que es un mensaje de respuesta HTTP estándar. 101 significa que el servidor recibió la solicitud del cliente para cambiar de protocolo y acordó cambiar a este protocolo. RFC2616 estipula que el cambio solo se puede acordar cuando el protocolo que se va a cambiar sea "mejor que HTTP1.1".
El protocolo ws utiliza el puerto 80 de forma predeterminada y el protocolo wss utiliza el puerto 443 de forma predeterminada.
Antes del protocolo de enlace, el cliente primero debe establecer una conexión. Para una misma dirección de destino (generalmente un nombre de dominio o dirección IP, no una dirección de recurso), solo un cliente puede estar en el estado CONECTANDO. mismo tiempo (se está estableciendo la conexión). El proceso desde el establecimiento de una conexión hasta el envío de un mensaje de reconocimiento es más o menos así:
Si el cliente no está en un entorno proxy, primero debe establecer una conexión TCP directa con la dirección de destino.
El servidor se refiere a toda la infraestructura involucrada en el procesamiento de mensajes WebSocket. Por ejemplo, si un servidor usa Nginx (A) para procesar WebSocket y luego pasa el mensaje procesado al servidor que responde (B), entonces. A y B son categorías del lado del servidor que se analizarán aquí.
Si la solicitud es HTTPS, primero se debe utilizar TLS para el protocolo de enlace. Si falla, la conexión se cierra. Si tiene éxito, todos los datos posteriores se enviarán a través de este canal.
Después, el servidor puede realizar algunos pasos de verificación del cliente (incluida la verificación del campo del encabezado del cliente) y, si es necesario, devolver códigos de error de acuerdo con RFC2616.
Si todo es exitoso, se devuelve un mensaje de protocolo de enlace de respuesta exitoso.
Este mensaje de protocolo de enlace es un mensaje de respuesta HTTP estándar y contiene las siguientes partes:
Una vez que se envía este protocolo de enlace, el servidor considera que la conexión WebSocket se ha establecido correctamente. en estado ABIERTO. Puede comenzar a enviar datos.
Ambas partes comunicantes pueden utilizar Sec-WebSocket-Version para admitir más extensiones de protocolo. El valor definido en RFC6455 es 13. El cliente y el servidor WebSocket pueden personalizar más números de versión para admitir más funciones. Su uso es el descrito anteriormente.
Todos los datos enviados en WebSocket se envían en forma de marcos. Las tramas de datos enviadas por el cliente deben estar enmascaradas y todas las tramas de datos enviadas por el servidor no se pueden enmascarar. De lo contrario, la otra parte deberá enviar un marco cercano.
Una trama contiene un identificador de tipo de trama, una longitud de carga útil y una carga útil. La carga útil incluye contenido de extensión y contenido de aplicación.
El tipo de trama está representado por un valor de 4 bits de largo llamado Opcode. Cualquier parte comunicante de WebSocket que reciba un tipo de trama en una ubicación debe desconectar la conexión como una falla de conexión.
Los tipos de trama definidos en RFC6455 son los siguientes:
El significado específico de cada elemento no se detallará aquí.
También como protocolo de capa de aplicación, WebSocket se utiliza cada vez más en el desarrollo de software moderno. Tiene muchas similitudes con HTTP. Aquí simplemente se convierten en un protocolo puramente personal y no autorizado:
Este artículo presenta brevemente el protocolo WebSocket. Es un poco largo y no hay tiempo para dar más detalles sobre el marco de datos. El próximo artículo continuará profundizando en la transmisión de tramas WebSocket y también discutirá algunos problemas en el uso real del protocolo WebSocket a través de ejemplos.
Conozca los protocolos HTTP y WebSocket (1)
La diferencia entre WebSocket y Socket (historia paralela de WebSocket)
Llegue al fondo de HTTP y protocolos WebSocket (3)