Introducción y principio de WebSocket
El protocolo WebSocket
es un nuevo protocolo de HTML5. Implementa la comunicación full-duplex entre el navegador y el servidor (full-duplex). El protocolo de enlace inicial debe completarse con la ayuda de solicitudes HTTP.- Enciclopedia de Baidu
Propósito: mensajería instantánea, en lugar de sondeo La
mensajería instantánea en sitios web es muy común, como QQ web, sistema de chat, etc. Según las capacidades técnicas anteriores, las tecnologías de sondeo y Comet se suelen utilizar para resolver el problema.
El protocolo HTTP es un protocolo de red no persistente y unidireccional. Una vez establecida la conexión, solo el navegador puede enviar una solicitud al servidor antes de que el servidor pueda devolver los datos correspondientes. Cuando se requiere comunicación instantánea, el navegador envía una solicitud de solicitud al servidor en un intervalo de tiempo específico (como 1 segundo) a través de un sondeo y luego devuelve los datos más recientes al navegador. La desventaja más obvia de este método es que necesita enviar solicitudes continuamente y, por lo general, el encabezado de la solicitud HTTP es muy largo. Para transmitir una pequeña cantidad de datos, debe pagar un precio enorme, que es muy antieconómico y ocupa mucho ancho de banda.
Desventajas: causará demasiadas solicitudes innecesarias, desperdicio de tráfico y recursos del servidor, cada solicitud y respuesta desperdiciará una cierta cantidad de tráfico en la misma información de encabezado
Sin embargo, la aparición de WebSocket puede compensar esta deficiencia. En WebSocket, solo el servidor y el navegador necesitan realizar una acción de reconocimiento a través del protocolo HTTP, y luego se establece un canal de comunicación TCP separado para la transmisión de datos.
Principio
WebSocket es un protocolo de capa de aplicación como HTTP, pero es un protocolo de comunicación bidireccional basado en TCP.
Proceso de conexión-proceso de negociación
- El navegador y el servidor establecen una conexión TCP y se realiza un protocolo de enlace de tres vías. Esta es la base de la comunicación, la capa de control de transmisión, si falla, no se ejecutará.
- Una vez que la conexión TCP se realiza correctamente, el navegador transmite información como el número de versión compatible con WebSocket al servidor a través del protocolo HTTP. (Protocolo de enlace HTTP antes de comenzar)
- Una vez que el servidor recibe la solicitud de reconocimiento del cliente, también utiliza el protocolo HTTP para devolver datos.
- Después de recibir el mensaje de conexión exitosa, la comunicación se realiza a través del canal TCP.
La relación entre WebSocket y HTTP
Mismo punto
- Todos están basados en TCP y ambos son protocolos de transmisión fiables.
- Ambos son protocolos de capa de aplicación.
diferencia
- WebSocket es un protocolo de comunicación bidireccional que simula el protocolo Socket y puede enviar o recibir información en ambas direcciones. HTTP es unidireccional.
- WebSocket requiere un protocolo de enlace para establecer una conexión.
Cuando se contacta con
WebSocket para establecer un protocolo de enlace, los datos se transmiten a través de HTTP. Pero después del establecimiento, el protocolo HTTP no es necesario para la transmisión real.
[Beneficios del artículo] El editor recomienda mi propio grupo de intercambio de idiomas linuxC / C ++: 832218493. He compilado algunos libros de aprendizaje y materiales de video que creo que son mejores para compartir. ¡Puede agregarlos si los necesita! ~
Más videos excelentes en la cuenta pública
La relación entre WebSocket y Socket
Socket no es en realidad un protocolo, sino una capa abstracta para la conveniencia de usar TCP o UDP, es un conjunto de interfaces entre la capa de aplicación y la capa de control de transmisión.
Socket es la capa de abstracción de middleware para la comunicación entre la capa de aplicación y el conjunto de protocolos TCP / IP. Es un conjunto de interfaces. En el modo de diseño, Socket es en realidad un modo de fachada, que oculta la compleja familia de protocolos TCP / IP detrás de la interfaz de Socket. Para los usuarios, un conjunto de interfaces simples lo es todo, lo que permite a Socket organizar los datos para ajustarse al protocolo especificado.
Cuando dos hosts se comunican, deben estar conectados a través de Socket, y Socket usa TCP / IP para establecer una conexión TCP. La conexión TCP se basa más en el protocolo IP subyacente y la conexión del protocolo IP se basa en niveles más bajos, como la capa de enlace.
WebSocket es un protocolo de capa de aplicación típico.
Difference
Socket es un protocolo de capa de control de transmisión y WebSocket es un protocolo de capa de aplicación.
La relación entre HTML5 y WebSocket
La API de WebSocket es parte del estándar HTML5, pero esto no significa que WebSocket deba usarse en HTML o solo se pueda usar en aplicaciones basadas en navegador.
De hecho, muchos lenguajes, marcos y servidores brindan soporte para WebSocket, como:
- Libwebsocket.org basado en C
- Socket.io basado en Node.js
- Ws4py basado en Python
- WebSocket ++ basado en C ++
- Soporte de Apache para WebSocket: Módulo Apache mod_proxy_wstunnel
- Nginx 对 WebSockets 的 支持 ： NGINX como proxy de WebSockets 、 NGINX anuncia soporte para el protocolo WebSocket 、 Proxy de WebSocket
- soporte lighttpd para WebSocket: mod_websocket
Mecanismo WebSocket
A continuación, se presenta brevemente el principio y el mecanismo operativo de WebSocket.
WebSocket es un nuevo protocolo de HTML5. Implementa la comunicación full-duplex entre el navegador y el servidor, lo que puede ahorrar mejor los recursos del servidor y el ancho de banda y lograr una comunicación en tiempo real. Está construido sobre TCP y transmite datos a través de TCP como HTTP, pero la mayor diferencia entre este y HTTP es :
WebSocket es un protocolo de comunicación bidireccional. Una vez establecida la conexión, tanto el servidor WebSocket como el navegador / agente cliente pueden enviar o recibir datos entre sí de forma activa, al igual que Socket;
WebSocket requiere un cliente y un servidor similares a TCP para conectarse a través de Apretón de manos. Pueden comunicarse entre sí después de una conexión exitosa.
La interacción entre el cliente HTTP tradicional y el servidor en modo no WebSocket se muestra en la siguiente figura:
Figura 1. Diagrama de interacción cliente-servidor de respuesta de solicitud HTTP tradicional
La interacción entre el cliente y el servidor usando el modo WebSocket es la siguiente:
Figura 2. Diagrama de interacción cliente-servidor de respuesta a la solicitud de WebSocket
La comparación de la figura anterior muestra que, en comparación con el modo HTTP tradicional donde cada solicitud-respuesta requiere que el cliente establezca una conexión con el servidor, WebSocket es un modo de comunicación similar a la conexión larga de Socket TCP. Una vez que se establece la conexión WebSocket, los datos subsiguientes serán Transmisión en forma de secuencia de cuadros. Antes de que el cliente desconecte la conexión WebSocket o el servidor se desconecte, no es necesario que el cliente y el servidor inicien una solicitud de conexión nuevamente. En el caso de concurrencia masiva y tráfico de alta carga entre el cliente y el servidor, se ahorra en gran medida el consumo de recursos de ancho de banda de la red y tiene obvias ventajas de rendimiento. El cliente envía y recibe mensajes en la misma conexión persistente. La ventaja sexual es obvia.
Veamos la diferencia entre la comunicación WebSocket y el HTTP tradicional a través de los mensajes intercambiados entre el cliente y el servidor:
En el lado del cliente, el nuevo WebSocket crea una instancia de un nuevo objeto de cliente de WebSocket y se conecta a la URL de WebSocket del servidor similar a ws: // sudominio: puerto / ruta. El objeto de cliente de WebSocket se analizará automáticamente y se reconocerá como una solicitud de WebSocket para conectarse el servidor.Puerto, realice el proceso de protocolo de enlace entre las dos partes, y el formato de datos enviado por el cliente es similar:
Listado 1. Mensaje de conexión del cliente WebSocket
GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: http://localhost:8080
Sec-WebSocket-Version: 13
Se puede ver que el mensaje de conexión de WebSocket iniciado por el cliente es similar al mensaje HTTP tradicional. El valor del parámetro "Upgrade: websocket" indica que se trata de una solicitud de tipo WebSocket, y "Sec-WebSocket-Key" es una base64 -secreto codificado enviado por el cliente WebSocket. Este texto requiere que el servidor devuelva una respuesta cifrada correspondiente "Sec-WebSocket-Accept", de lo contrario el cliente arrojará un error "Error durante el protocolo de enlace WebSocket" y cerrará la conexión.
El formato de datos devuelto por el servidor después de recibir el mensaje es similar:
Listado 2. Mensaje de respuesta del servidor WebSocket
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=
El valor de "Sec-WebSocket-Accept" es calculado por el servidor usando la misma clave que el cliente y luego devuelto al cliente. "HTTP / 1.1 101 Switching Protocols" significa que el servidor acepta la conexión de cliente del protocolo WebSocket, después de dicha solicitud -Después de que se procesa la respuesta, el protocolo de enlace de la conexión WebSocket entre el cliente y el servidor es exitoso y la comunicación TCP se puede llevar a cabo posteriormente.
En términos de desarrollo, la API de WebSocket también es muy simple. Solo necesitamos crear una instancia de WebSocket, crear una conexión, y luego el servidor y el cliente pueden enviarse y responder mensajes entre sí. En la sección de implementación y análisis de casos de WebSocket a continuación, puede ver la implementación detallada del código y la API de WebSocket.
Implementación de WebSocket
Como se mencionó anteriormente, la implementación de WebSocket se divide en dos partes: el cliente y el servidor. El cliente (generalmente un navegador) envía una solicitud de conexión de WebSocket y el servidor responde para lograr una acción de protocolo de enlace TCP, de modo que el cliente del navegador y WebSocket Se forma una conexión larga HTTP rápida entre los servidores. La posterior transferencia directa de datos entre los dos eliminará la necesidad de iniciar una conexión y una respuesta.
A continuación, se describe brevemente la API del servidor y la API del cliente de WebSocket.
API del servidor WebSocket El
servidor WebSocket básicamente ha obtenido el soporte de la API estándar JEE JSR356 entre los principales proveedores de servidores de aplicaciones. A continuación se enumera el soporte de algunos servidores de aplicaciones comerciales y de código abierto comunes en WebSocket Server:
Tabla 1. Compatibilidad con el servidor WebSocket
A continuación, usamos el código de muestra del lado del servidor Tomcat7.0.5 para ilustrar la implementación del servidor WebSocket:
La especificación WebSocket de JSR356 utiliza la API de javax.websocket. *, Y un objeto Java ordinario (POJO) se puede anotar con @ServerEndpoint como el punto final del servidor WebSocket. El ejemplo de código es el siguiente:
Listado 3. Ejemplo de API del servidor WebSocket
@ServerEndpoint("/echo")
public class EchoEndpoint {
@OnOpen
public void onOpen(Session session) throws IOException {
//以下代码省略...
}
@OnMessage
public String onMessage(String message) {
//以下代码省略...
}
@Message(maxMessageSize=6)
public void receiveMessage(String s) {
//以下代码省略...
}
@OnError
public void onError(Throwable t) {
//以下代码省略...
}
@OnClose
public void onClose(Session session, CloseReason reason) {
//以下代码省略...
}
}
Explicación del código:
El código conciso anterior establece un servidor WebSocket. El punto final de la anotación de @ServerEndpoint ("/ echo") indica que el servidor WebSocket se ejecutará en ws: // [IP del servidor o nombre de dominio]: [Puerto del servidor] / Para websockets / echo puntos finales de acceso, el navegador del cliente ya puede iniciar una conexión HTTP persistente a la API del cliente WebSocket.
La clase anotada con ServerEndpoint debe tener un constructor público sin parámetros. El método Java anotado con @onMessage se utiliza para recibir la información entrante de WebSocket. Esta información puede estar en formato de texto o binario.
Se llama a OnOpen cuando se establece una nueva conexión en este punto final. Los parámetros proporcionan más detalles en el otro extremo de la conexión. Session indica el otro extremo de la conexión entre dos puntos finales de WebSocket, que puede entenderse como un concepto similar a HTTPSession.
Se llama a OnClose cuando se termina la conexión. El parámetro closeReason puede encapsular más detalles, como por qué se cierra una conexión WebSocket.
La personalización más avanzada, como la anotación @Message, la propiedad MaxMessageSize se puede utilizar para definir el límite máximo de bytes de mensajes, en el programa de muestra, si se reciben más de 6 bytes de información, se informa un error y se cierra la conexión.
Nota: En los primeros días, diferentes servidores de aplicaciones admitían diferentes métodos de WebSocket. Incluso el mismo fabricante, las diferentes versiones tienen diferencias sutiles. Por ejemplo, el servidor Tomcat 7.0.5 y superior están implementados por la especificación estándar JSR356, mientras que el 7.0.2x Versión /7.0.3X Use API personalizadas (WebSocketServlet y StreamInbound, el primero es un contenedor que se usa para inicializar el entorno WebSocket; el último se usa para procesar solicitudes y respuestas de WebSocket, consulte la sección de análisis de casos para obtener más detalles) y createWebSocketInbound para Tomcat7. 0.3xy 7.0.2x La definición del método es diferente, se agrega un parámetro HttpServletRequest, por lo que se puede obtener más información del cliente WebSocket desde el parámetro de solicitud, como se muestra en el siguiente código:
Listado 4. API de WebSocket de la versión Tomcat7.0.3X
public class EchoServlet extends WebSocketServlet {
@Override
protected StreamInbound createWebSocketInbound(String subProtocol,
HttpServletRequest request) {
//以下代码省略....
return new MessageInbound() {
//以下代码省略....
}
protected void onBinaryMessage(ByteBuffer buffer)
throws IOException {
//以下代码省略...
}
protected void onTextMessage(CharBuffer buffer) throws IOException {
getWsOutbound().writeTextMessage(buffer);
//以下代码省略...
}
};
}
}
Por lo tanto, el lado del servidor que elige WebSocket debe elegir su versión. Normalmente, la versión más nueva es compatible con la API de especificación JSR estándar para WebSocket, pero también se debe considerar la facilidad de desarrollo y la portabilidad de la versión anterior del programa, de la siguiente manera El caso del cliente descrito es la versión Tomcat 7.0.3X de la implementación de WebSocketServlet que se utiliza porque el cliente requiere una versión de servidor de aplicaciones unificada en lugar del punto final de anotación JSR356 @ServerEndpoint.
API de cliente WebSocket
Para los clientes de WebSocket, los navegadores convencionales (incluidos PC y terminales móviles) ahora son compatibles con la API de WebSocket HTML5 estándar, lo que significa que el script WebSocket JavaScirpt del cliente tiene una buena coherencia y características multiplataforma. Las más comunes se enumeran a continuación. Compatibilidad de los proveedores de navegadores con WebSocket:
Tabla 2. Compatibilidad con el cliente de WebSocket
La API de WebSocket del lado del cliente se ha unificado básicamente entre todos los principales proveedores de navegadores. Por lo tanto, es suficiente usar la API de JavaScript del lado del cliente de WebSocket definida en HTML5 estándar. Por supuesto, también puede usar los marcos de código abierto de la industria que cumplen con WebSocket estándares, como Socket.io.
El siguiente es un ejemplo de código para ilustrar la implementación del cliente de WebSocket:
Listado 5. Ejemplo de API de cliente WebSocket
var ws = new WebSocket(“ws://echo.websocket.org”);
ws.onopen = function(){
ws.send(“Test!”); };
ws.onmessage = function(evt){
console.log(evt.data);ws.close();};
ws.onclose = function(evt){
console.log(“WebSocketClosed!”);};
ws.onerror = function(evt){
console.log(“WebSocketError!”);};
La primera línea de código es la solicitud de un objeto WebSocket y el parámetro es la dirección del servidor que debe conectarse. Al igual que el comienzo del protocolo HTTP, la URL del protocolo WebSocket comienza con ws: // y el protocolo seguro WebSocket comienza con wss: //.
La segunda línea a la quinta línea es la función de procesamiento del mensaje de registro del objeto WebSocket. El objeto WebSocket admite cuatro mensajes onopen, onmessage, onclose y onerror. Con estos cuatro eventos, podemos controlar fácilmente WebSocket.
Cuando el navegador y WebSocketServer están conectados correctamente, se activará un mensaje de apertura; si falla la conexión, falla el envío o la recepción de datos, o si hay un error en el procesamiento de datos, el navegador activará un mensaje de error; cuando el navegador reciba los datos enviados por WebSocketServer, activará un mensaje onmessage, el parámetro evt contiene los datos transmitidos por el servidor; cuando el navegador recibe la solicitud de cierre de conexión enviada por WebSocketServer, activará el mensaje onclose. Podemos ver que todas las operaciones se activan mediante devoluciones de llamada asincrónicas, por lo que la interfaz de usuario no se bloqueará y se podrá obtener un tiempo de respuesta más rápido y una mejor experiencia de usuario.