ajax - usar - tutorial socket io node js
¿Cuál es la desventaja de usar websocket/socket.io donde ajax hará? (8)
Se hicieron preguntas similares antes y todos llegaron a la conclusión de que AJAX no se volverá obsoleto. Pero, ¿de qué manera es ajax mejor que websockets?
Con socket.io, es fácil recurrir al flash o al sondeo largo, por lo que la compatibilidad del navegador parece no ser un problema.
Websockets son bidireccionales. Donde ajax haría una solicitud asincrónica, el cliente de websocket enviaría un mensaje al servidor. Los parámetros POST / GET se pueden codificar en JSON.
Entonces, ¿qué hay de malo con el uso de 100% websockets? Si cada visitante mantiene una conexión persistente de websocket con el servidor, ¿sería más desperdicio que hacer algunas solicitudes de ajax durante la sesión de visita?
Como dijeron otras personas, mantener abierta la conexión puede ser excesiva en algunos casos en los que no se necesitan notificaciones de servidor a cliente, o la solicitud de cliente a servidor ocurre con poca frecuencia.
Pero otra desventaja es que websockets es un protocolo de bajo nivel que no ofrece características adicionales a TCP una vez que se realiza el saludo inicial. Por lo tanto, al implementar un paradigma de solicitud-respuesta sobre websockets, probablemente omita características que HTTP (una familia de protocolos muy madura y extensa) ofrece , como el almacenamiento en caché (cachés compartidos y del cliente), validación (solicitudes condicionales), seguridad e idempotencia (con implicaciones sobre cómo se comporta el agente), solicitudes de rango, tipos de contenido, códigos de estado, ...
Es decir, reduce el tamaño de los mensajes a un costo.
Así que mi elección es AJAX para solicitud-respuesta, websockets para empujar servidores y mensajería de baja latencia de alta frecuencia
Creo que sería más derrochador. Para cada cliente conectado necesita algún tipo de objeto / función / código / lo que sea en el servidor emparejado con ese único cliente. Un manejador de socket, o un descriptor de archivo, o como sea que su servidor esté configurado para manejar las conexiones.
Con AJAX no necesita una asignación 1: 1 del recurso del lado del servidor al cliente. Su número de clientes puede escalar menos dependientemente que sus recursos del lado del servidor. Incluso node.js tiene sus limitaciones a la cantidad de conexiones que puede manejar y mantener abiertas.
La otra cosa a considerar es que ciertas respuestas AJAX también se pueden almacenar en caché. A medida que escala, puede agregar un caché HTTP para ayudar a reducir la carga de las frecuentes solicitudes AJAX.
Creo que tarde o temprano los frameworks basados en websocket comenzarán a aparecer no solo para escribir chat en tiempo real como partes de aplicaciones web, sino también como frameworks web independientes. Una vez que se crea la conexión permanente, se puede utilizar para recibir todo tipo de cosas, incluidas las partes de la interfaz de usuario de la aplicación web, que ahora se sirven, por ejemplo, a través de solicitudes de AJAX. Este enfoque puede dañar el SEO de alguna manera, aunque puede reducir la cantidad de tráfico y la carga generada por las solicitudes asincrónicas, que incluye encabezados HTTP redundantes.
Sin embargo, dudo que los websockets reemplacen o pongan en peligro a AJAX porque existen numerosos escenarios donde las conexiones permanentes son innecesarias o no deseadas. Por ejemplo, aplicaciones de mashup que utilizan (una vez) servicios basados en REST de propósito único que no necesitan estar permanentemente conectados con los clientes.
Las conexiones WS: // tienen mucha menos sobrecarga que las solicitudes "AJAX".
No hay nada "malo" al respecto.
La única diferencia es principalmente la legibilidad. La principal ventaja de Ajax es que le permite un desarrollo rápido porque la mayoría de la funcionalidad está escrita para usted.
Existe una gran ventaja al no tener que volver a inventar la rueda cada vez que desea abrir un zócalo.
Personalmente, creo que los websockets se usarán cada vez más en aplicaciones web en lugar de AJAX. No se adaptan bien a los sitios web donde el almacenamiento en caché y el SEO son de mayor preocupación, pero harán maravillas para webapps.
Los proyectos como DNode y socketstream ayudan a eliminar la complejidad y permiten la codificación simple de estilo RPC. Esto significa que su código de cliente solo llama a una función en el servidor, pasando cualquier información a la función que desee. Y el servidor puede invocar una función en el cliente y pasarle datos también. No necesita preocuparse por los detalles de TCP.
Además, hay muchas sobrecargas con llamadas AJAX. Por ejemplo, se debe establecer una conexión y los encabezados HTTP (cookies, etc.) se pasan con cada solicitud. Websockets elimina mucho de eso. Algunos dicen que los websockets son más derrochadores, y quizás tienen razón. Pero no estoy convencido de que la diferencia sea realmente tan importante.
Respondí otra pregunta relacionada en detalle, incluidos muchos enlaces a recursos relacionados. Deberías revisarlo:
Si desea que la conexión con el servidor esté abierta y si el sondeo continuo al servidor estará allí, entonces vaya a los enchufes, de lo contrario, puede usar ajax.
Analogía simple: Ajax hace preguntas (solicitudes) al servidor y el servidor da respuestas (respuestas) a estas preguntas. Ahora, si desea hacer preguntas continuas, ajax no funcionará, tiene una gran sobrecarga que requerirá recursos en ambos extremos.
Respuesta corta
Mantener activo un websocket tiene un costo, tanto para el cliente como para el servidor, si Ajax tendrá un costo solo una vez, dependiendo de lo que esté haciendo con él.
Respuesta larga
Los websockets a menudo son malentendidos debido a todo este "Oye, usa Ajax, ¡eso servirá!". No, Websockets no reemplazan a Ajax. Pueden aplicarse potencialmente a los mismos campos, pero hay casos en los que usar Websocket es absurdo.
Tomemos un ejemplo simple: una página dinámica que carga datos después de que la página se carga en el lado del cliente. Es simple, haz una llamada Ajax. Solo necesitamos una dirección, del servidor al cliente. El cliente pedirá estos datos, el servidor los enviará al cliente, listo. ¿Por qué implementaría websockets para tal tarea? No necesita que su conexión esté abierta todo el tiempo, no necesita que el cliente pregunte constantemente al servidor, no necesita que el servidor notifique al cliente. La conexión permanecerá abierta, desperdiciará recursos, porque para mantener una conexión abierta, debe verificarla constantemente.
Ahora, para una aplicación de chat, las cosas son totalmente diferentes. Necesita que su cliente sea notificado por el servidor en lugar de forzar al cliente a preguntarle al servidor cada x segundos o milisegundos si algo es nuevo. No tendría sentido.
Para entender mejor, vea eso como dos personas. Uno de los dos es el servidor, el final es el cliente. Ajax es como enviar una carta. El cliente envía una carta, el servidor responde con otra letra. El hecho es que, para una aplicación de chat, la conversación sería así:
"Hola servidor, ¿tienes algo para mí?
- No.
- Hola servidor, ¿tienes algo para mí?
- No.
- Hola servidor, ¿tienes algo para mí?
- Sí, aquí está."
El servidor no puede enviar una carta al cliente, si el cliente nunca solicitó una respuesta. Es una gran pérdida de recursos. Porque por cada solicitud de Ajax, incluso si está almacenada en caché, debe realizar una operación en el lado del servidor.
Ahora el caso que discutí anteriormente con los datos cargados con Ajax. Imagine que el cliente está hablando por teléfono con el servidor. Mantener la conexión activa tiene un costo. Cuesta electricidad y tienes que pagarle a tu operador. Ahora, ¿por qué necesitarías llamar a alguien y mantenerlo en el teléfono durante una hora, si solo quieres que esa persona te diga 3 palabras? Envía una maldita carta.
En conclusión, ¡Websockets no es un reemplazo total para Ajax!
A veces necesitarás Ajax, donde el uso de Websocket es absurdo.
Editar: El caso de SSE
Esa tecnología no se usa mucho, pero puede ser útil. Como su nombre lo indica, los eventos enviados por el servidor son un envío de un solo sentido desde el servidor al cliente. El cliente no solicita nada, el servidor simplemente envía los datos.
En breve :
- Unidireccional desde el cliente: Ajax
- Unidireccional desde el servidor: SSE
- Bidireccional: Websockets