¿Cuál es la desventaja de usar websocket/socket.io donde hará ajax?

Question

Se han hecho 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 volver al flash o al sondeo largo, por lo que la compatibilidad del navegador no parece 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?

Answer 1

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.

Hay una gran ventaja en no tener que volver a inventar la rueda cada vez que quiera abrir una toma de corriente.

Answer 2

Creo que tarde o temprano los marcos basados ​​en websocket comenzarán a aparecer no solo para escribir chat en tiempo real como partes de aplicaciones web, sino también como marcos 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 hay 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.

Answer 3

Creo que sería más desperdicio. 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 tener en cuenta 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.

Answer 4

Personalmente, creo que los websockets se usarán cada vez más en aplicaciones web en lugar de AJAX. No son adecuados para sitios web donde el almacenamiento en caché y 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 una gran sobrecarga con las 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, incluyendo muchos enlaces a recursos relacionados. Es posible comprobar que funciona:

websocket api to replace rest api?

Answer 5

WS: // conexiones tienen mucho menos espacio que los pedidos "Ajax".

Answer 6

respuesta Corto
Mantener un WebSocket activo tiene un costo, tanto para el cliente y el servidor, ya sea Ajax tendrá un costo de una sola vez, dependiendo de lo que estás haciendo con él.

Respuesta larga
websockets están a menudo mal entendido debido a este conjunto "Hey, utilizar Ajax, que va a hacer!". 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 de la conversación sería así:
"Hey Server, tiene algo para mí
- No.
- Hey Server, tiene algo para mí
- No.
?? - Hola servidor, ¿tengo 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 lo hará necesita Ajax, donde el uso de Websocket es absurdo.

Editar: El caso SSE
que la tecnología no se utiliza muy ampliamente, 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 resumen:
- unidireccional desde el cliente: Ajax
- unidireccional desde el servidor: SSE
- Bidireccional: websockets

Answer 7

Como se ha dicho otras personas, manteniendo la conexión abierta puede ser excesiva en algunos escenarios donde no necesita notificaciones de servidor a cliente, o la solicitud de cliente a servidor ocurre con baja 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 handshake inicial. Por lo tanto, al implementar un paradigma de solicitud-respuesta en 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 de petición-respuesta, WebSockets para el servidor de empuje y de alta frecuencia de mensajería de baja latencia

Answer 8

Si desea que la conexión con el servidor abierto y si interrogación continua con el servidor estará allí y luego ir por los zócalos de lo contrario, eres bueno para ir con 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.