WebSocket es un producto (protocolo) de HTML5, lo que significa que el protocolo HTTP no ha cambiado, o no importa, pero HTTP no admite conexiones persistentes (las conexiones largas y las conexiones cíclicas no se cuentan)
En primer lugar, HTTP tiene 1.1 y 1.0, que también se denominan keep-alive, que fusionan múltiples solicitudes HTTP en una sola. Sin embargo, Websocket es en realidad un protocolo nuevo y básicamente no tiene nada que ver con HTTP. protocolo Es solo por compatibilidad con el protocolo HTTP existente. Es solo la especificación de protocolo de enlace del navegador, lo que significa que es un complemento del protocolo HTTP.
Tienen intersecciones, pero no todas.
Además, Html5 hace referencia a una serie de nuevas API, o nuevas especificaciones y nuevas tecnologías. El protocolo Http en sí solo tiene 1.0 y 1.1, y no tiene relación directa con el propio Html. . En términos sencillos, puede utilizar el protocolo HTTP para transmitir datos que no sean HTML, eso es todo =. =
En pocas palabras, los niveles son diferentes.
En primer lugar, Websocket es un protocolo persistente, en comparación con protocolos no persistentes como HTTP. Pongamos un ejemplo simple y usemos el ciclo de vida de PHP que se usa ampliamente actualmente para explicarlo.
El ciclo de vida de HTTP está definido por Solicitud, es decir, una Solicitud y una Respuesta. En HTTP1.0, esta solicitud HTTP finaliza.
Se realizaron mejoras en HTTP 1.1 para que haya un mantenimiento, es decir, en una conexión HTTP, se pueden enviar múltiples solicitudes y se pueden recibir múltiples respuestas. Pero recuerde que Solicitud = Respuesta siempre es el caso en HTTP, lo que significa que una solicitud solo puede tener una respuesta. Además, esta respuesta también es pasiva y no puede iniciarse activamente.
Entrenador, ha hecho tantas cosas, ¿qué tiene que ver con Websocket? (:з ∠) Bien, estaba a punto de hablar sobre Websocket. .
En primer lugar, Websocket se basa en el protocolo HTTP, o toma prestado el protocolo HTTP para completar parte del protocolo de enlace.
Primero, echemos un vistazo a un protocolo de enlace típico de Websocket (tomado de Wikipedia...)
Los zapatos para niños que están familiarizados con HTTP pueden haber descubierto que esta solicitud de protocolo de enlace es similar a la El protocolo HTTP tiene más varias cosas. Por cierto, explicaré la función.
Este es el núcleo de Websocket. Dígale a Apache, Nginx y otros servidores: Atención, inicié el protocolo Websocket. Ayúdenme a encontrar el asistente de procesamiento correspondiente, no el antiguo HTTP.
En primer lugar, Sec-WebSocket-Key es un valor de codificación Base64, que el navegador genera aleatoriamente y le dice al servidor: Peat, no me engañes, quiero verificar si lo eres. Realmente el Asistente de Websocket.
Entonces, Sec_WebSocket-Protocol es una cadena definida por el usuario que se utiliza para distinguir los protocolos requeridos por diferentes servicios bajo la misma URL. Comprensión simple: quiero servir A esta noche, no se equivoque ~
Finalmente, Sec-WebSocket-Version le dice al servidor el Websocket Draft (versión del protocolo) utilizado Al principio, el protocolo Websocket todavía estaba en. En la etapa de borrador, hay todo tipo de protocolos extraños, y también hay muchas cosas extrañas y diferentes. Firefox y Chrome usan versiones diferentes. Al principio, había demasiados protocolos Websocket, lo cual fue un gran problema. .
Pero está bien ahora, se ha decidido sobre algo que todos usan para la deshidratación: Camarero, quiero un niño de 13 años →_→
Luego, el servidor devolverá las siguientes cosas, indicando que la solicitud Ha sido aceptado, ¡Websocket se estableció con éxito!
Esta es la última área de la que HTTP es responsable. Dígale al cliente que he cambiado el protocolo correctamente~
Actualización: websocket
Conexión: Actualización<. /p >
Todavía está solucionado, diciéndole al cliente que la próxima actualización es el protocolo Websocket, no mozillasocket, lurnarsocket o shitsocket.
Entonces, Sec-WebSocket-Accept es la Sec-WebSocket-Key que ha sido confirmada por el servidor y cifrada. Servidor: Está bien, está bien, lo entiendo. Déjame mostrarte mi cédula de identidad para comprobarlo. .
Lo que sigue es Sec-WebSocket-Protocol que indica el protocolo final utilizado.
En este punto, HTTP ha completado todo su trabajo y el siguiente paso es proceder completamente de acuerdo con el protocolo Websocket. El acuerdo específico no se explica aquí.
——————La parte de análisis técnico está completa——————
Has estado haciendo BBB durante tanto tiempo, entonces, ¿para qué sirve Websocket, encuesta larga http? ¿O el sondeo ajax no puede realizar la transmisión de información en tiempo real?
Bien, jóvenes, hablemos del uso de Websocket. Déjame darte algunas zanahorias (rojas)
Antes de hablar sobre Websocket, hablaré sobre los principios de la encuesta larga y la encuesta ajax.
sondeo ajax
El principio del sondeo ajax es muy simple: permite al navegador enviar una solicitud cada pocos segundos para preguntar al servidor si hay información nueva.
Reproducción de escena:
encuesta larga
la encuesta larga es en principio similar al sondeo ajax. Ambos usan sondeo, pero adoptan un modelo de bloqueo (Keep. llamando y no cuelgue si no recibe la llamada). En otras palabras, después de que el cliente inicia la conexión, si no hay ningún mensaje, la respuesta no se devolverá al cliente. No regresa hasta que hay un mensaje. Después de regresar, el cliente vuelve a establecer la conexión y el ciclo comienza de nuevo.
Reproducción de escena:
Como se puede ver en lo anterior, de hecho, estos dos métodos establecen constantemente conexiones HTTP y luego esperan el procesamiento del servidor, lo que puede reflejar otro aspecto de la Protocolo HTTP. Características, pasividad.
¿Qué es la pasividad? De hecho, el servidor no puede contactar activamente al cliente, solo puede ser iniciado por el cliente.
En pocas palabras, el servidor es un refrigerador muy vago (esto es una broma) (no puede, no puede iniciar activamente una conexión), pero el jefe tiene un pedido. Si viene un cliente, no importa. que cansado estés, debes hacerlo bien.
Dicho esto, hablemos de los defectos anteriores (perdóname por decir tantas tonterías, OAQ)
Es fácil ver por lo anterior que pase lo que pase, lo anterior 2. Todos consumen muchos recursos.
El sondeo Ajax requiere que el servidor tenga una velocidad de procesamiento y recursos rápidos. (Velocidad) La encuesta larga requiere una alta concurrencia, lo que significa la capacidad de recibir clientes al mismo tiempo. (Tamaño del sitio)
Entonces, esto puede suceder tanto con el sondeo ajax como con el sondeo largo.
Volvamos al tema, hablemos de Websocket
A través del ejemplo anterior, podemos ver que ninguno de estos dos métodos es el mejor método y requiere muchos recursos.
Se necesitan velocidades más rápidas, se necesitan más 'teléfonos'.
Ambos conducirán a una creciente demanda de "teléfonos".
Ah, por cierto, olvidé mencionar que HTTP sigue siendo un protocolo con estado.
En términos sencillos, debido a que el servidor tiene que recibir demasiados clientes todos los días, es un fantasma olvidadizo. Tan pronto como cuelgues el teléfono, olvidará todas tus cosas y las tirará a la basura. . Tienes que decírselo al servidor nuevamente la segunda vez.
Así que en este caso apareció Websocket. Resolvió estos problemas de HTTP. Primero, pasividad Una vez que el servidor completa la actualización del protocolo (HTTP->Websocket), el servidor puede enviar información activamente al cliente. Entonces el escenario anterior se puede modificar de la siguiente manera.
Se vuelve así: solo se necesita una solicitud HTTP para lograr un flujo constante de transmisión de información. (En programación, este diseño se llama devolución de llamada, es decir: notifícame cuando tengas información, en lugar de que yo corra estúpidamente para preguntarte cada vez)
Este protocolo resuelve el retraso de sincronización anterior y También consume muchos recursos. Entonces, ¿por qué resuelve el problema del consumo de recursos en el servidor?
De hecho, el programa que utilizamos tiene que pasar por dos capas de proxies, es decir, el protocolo HTTP es analizado por servidores como Nginx, y luego transmitido al Handler correspondiente (PHP, etc.) para su procesamiento. En pocas palabras, tenemos un operador muy rápido (Nginx) que se encarga de trasladar el problema al servicio de atención al cliente correspondiente (Handler).
La velocidad del operador en sí es básicamente suficiente, pero cada vez que me quedo atascado en el servicio al cliente (Handler), la velocidad de procesamiento del servicio al cliente siempre es demasiado lenta. , lo que resulta en un servicio al cliente insuficiente. Websocket resuelve este problema. Una vez establecido, puede establecer directamente una conexión persistente con el operador. Cuando hay información, el servicio al cliente encontrará una manera de notificar al operador y luego el operador la transferirá al cliente.
Esto puede resolver el problema de la lentitud de procesamiento del servicio de atención al cliente.
Al mismo tiempo, de la manera tradicional, el protocolo HTTP debe establecerse y cerrarse continuamente. Dado que HTTP no tiene estado, la información de identidad (información de identificación) debe retransmitirse cada vez para informarle al servidor. tu eres quien.
Aunque el operador es muy rápido, la eficiencia se verá reducida si tiene que escuchar tanto cada vez y al mismo tiempo tiene que trasladar constantemente esta información al servicio de atención al cliente, lo que no sólo supone un desperdicio. El tiempo de procesamiento del servicio al cliente, pero también consumirá demasiado tráfico/tiempo en la transmisión de la red.
Sin embargo, Websocket solo requiere un protocolo de enlace HTTP, por lo que todo el proceso de comunicación se establece en una conexión/estado, lo que evita la naturaleza sin estado de HTTP. El servidor siempre conocerá su información hasta que cierre la solicitud. lo que resuelve el problema de que el operador tiene que analizar repetidamente el protocolo HTTP y verificar la información de identidad.
Al mismo tiempo, el cliente toma la iniciativa de preguntar y el servidor (push) lo envía cuando hay información (por supuesto, el cliente todavía espera a que la información se envíe activamente ... ), y cuando no hay información se entrega al operador (Nginx), no hay necesidad de ocupar el servicio de atención al cliente (Handler) que es inherentemente lento
—————–
En cuanto a cómo usar Websocket en un cliente que no es compatible con Websocket. . La respuesta es: No
Pero puedes simular un efecto similar a través del sondeo largo y el sondeo ajax mencionados anteriormente