¿Por qué usar AJAX cuando WebSockets está disponible?

He estado usando WebSockets durante un tiempo, he elegido crear una herramienta de gestión de proyectos ágil para mi proyecto de último año en la Universidad utilizando el servidor Node y WebSockets. Descubrí que el uso de WebSockets proporcionaba un aumento del 624% en la cantidad de solicitudes por segundo que mi aplicación podía procesar.

Sin embargo, desde que comencé el proyecto, he leído sobre las lagunas de seguridad y algunos navegadores que eligen deshabilitar WebSockets de forma predeterminada.

Esto me lleva a la pregunta:

¿Por qué usar AJAX cuando WebSockets parece hacer un gran trabajo al reducir la latencia y la sobrecarga de recursos? ¿Hay algo que AJAX haga mejor que WebSockets?

WebSockets no pretende reemplazar AJAX y ni siquiera es estrictamente un reemplazo para Comet / long-poll (aunque hay muchos casos en los que esto tiene sentido).

El propósito de WebSockets es proporcionar una conexión de baja latencia, bidireccional, full-duplex y de larga duración entre un navegador y un servidor. WebSockets abre nuevos dominios de aplicación a las aplicaciones de navegador que realmente no eran posibles usando HTTP y AJAX (juegos interactivos, flujos de medios dinámicos, puente a protocolos de red existentes, etc.).

Sin embargo, ciertamente hay una superposición de propósitos entre WebSockets y AJAX / Comet. Por ejemplo, cuando el navegador desea recibir notificaciones de eventos del servidor (es decir, push), las técnicas Comet y WebSockets son sin duda ambas opciones viables. Si su aplicación necesita eventos push de baja latencia, este sería un factor a favor de WebSockets. Por otro lado, si necesita coexistir con los marcos existentes y las tecnologías implementadas (OAuth, API RESTful, proxies, equilibradores de carga), este sería un factor a favor de las técnicas Comet (por ahora).

Si no necesita los beneficios específicos que proporciona WebSockets, entonces probablemente sea una mejor idea seguir con las técnicas existentes como AJAX y Comet porque esto le permite reutilizar e integrarse con un enorme ecosistema existente de herramientas, tecnologías y mecanismos de seguridad. , bases de conocimiento (es decir, muchas más personas en stackoverflow conocen HTTP / Ajax / Comet que WebSockets), etc.

Por otro lado, si está creando una nueva aplicación que simplemente no funciona bien dentro de las restricciones de latencia y conexión de HTTP / Ajax / Comet, considere usar WebSockets.

Además, algunas respuestas indican que uno de los inconvenientes de WebSockets es la compatibilidad con servidores y navegadores limitados / mixtos. Permítanme difundir eso un poco. Si bien iOS (iPhone, iPad) aún admite el protocolo anterior (Hixie), la mayoría de los servidores WebSockets son compatibles con Hixie y la versión HyBi / IETF 6455 . La mayoría de las otras plataformas (si aún no tienen soporte incorporado) pueden obtener soporte de WebSockets a través de web-socket-js (Polyfill basado en Flash). Esto cubre a la gran mayoría de los usuarios de la web. Además, si está utilizando Node para el servidor back-end, considere usar Socket.IO que incluye web-socket-js como alternativa y si incluso eso no está disponible (o deshabilitado), recurrirá al uso de cualquier técnica Comet disponible para el navegador dado.

Actualización : iOS 6 ahora es compatible con el estándar actual HyBi / IETF 6455.

Avance rápido hasta diciembre de 2017, Websockets es compatible con (prácticamente) todos los navegadores y su uso es muy común.

Sin embargo, esto no significa que Websockets haya logrado reemplazar AJAX, al menos no por completo, especialmente porque la adaptación HTTP / 2 está en aumento.

La respuesta breve es que AJAX sigue siendo excelente para la mayoría de las aplicaciones REST, incluso cuando se usan Websockets. Pero Dios está en los detalles, así que ...:

AJAX para encuestas?

El uso de AJAX para el sondeo (o el sondeo largo) está desapareciendo (y debería serlo), pero aún permanece en uso por dos buenas razones (principalmente para aplicaciones web más pequeñas):

1. Para muchos desarrolladores, AJAX es más fácil de codificar, especialmente cuando se trata de codificar y diseñar el backend.

2. Con HTTP / 2, se eliminó el costo más alto relacionado con AJAX (el establecimiento de una nueva conexión), lo que permitió que las llamadas AJAX fueran bastante efectivas, especialmente para publicar y cargar datos.

Sin embargo, Websocket push es muy superior a AJAX (no es necesario volver a autenticar o reenviar encabezados, no se necesitan viajes de ida y vuelta "sin datos", etc.). Esto fue discutido varias veces.

AJAX para DESCANSO?

Un mejor uso para AJAX son las llamadas REST API. Este uso simplifica la base del código y evita que la conexión Websocket se bloquee (especialmente en cargas de datos de tamaño mediano).

Hay una serie de razones convincentes para preferir AJAX para llamadas API REST y cargas de datos:

1. La API AJAX fue diseñada prácticamente para llamadas API REST y es una excelente opción.

2. Las llamadas y cargas REST usando AJAX son significativamente más fáciles de codificar, tanto en el cliente como en el backend.

3. A medida que aumenta la carga útil de datos, las conexiones de Websocket pueden bloquearse a menos que se codifique la lógica de multiplexación / fragmentación de mensajes.

   Si se realiza una carga en una sola sendllamada de Websocket , podría bloquear una transmisión de Websocket hasta que la carga haya finalizado. Esto reducirá el rendimiento, especialmente en clientes más lentos.

Un diseño común utiliza pequeños mensajes bidireccionales transferidos a través de Websockets mientras que REST y las cargas de datos (cliente a servidor) aprovechan la facilidad de uso de AJAX para evitar que el Websocket se bloquee.

Sin embargo, en proyectos más grandes, la flexibilidad que ofrece Websockets y el equilibrio entre la complejidad del código y la gestión de recursos inclinarán la balanza a favor de Websockets.

Por ejemplo, las cargas basadas en Websocket podrían ofrecer la posibilidad de reanudar cargas grandes después de que se desconecte y restablezca una conexión (¿recuerda la película de 5GB que quería cargar?).

Al codificar la lógica de fragmentación de carga, es fácil reanudar una carga interrumpida (la parte difícil fue codificar la cosa).

¿Qué pasa con HTTP / 2 push?

Probablemente debería agregar que la función de inserción HTTP / 2 no reemplaza (y probablemente no puede) a Websockets.

Esto se discutió aquí anteriormente, pero es suficiente mencionar que una sola conexión HTTP / 2 sirve a todo el navegador (todas las pestañas / ventanas), por lo que los datos que HTTP / 2 envía no saben a qué pestaña / ventana pertenece, eliminando su capacidad para reemplazar la capacidad de Websocket de enviar datos directamente a una pestaña / ventana específica del navegador.

Si bien los Websockets son excelentes para la comunicación de datos bidireccional pequeña, AJAX aún tiene una serie de ventajas, especialmente cuando se consideran cargas útiles más grandes (cargas, etc.).

¿Y seguridad?

Bueno, en general, cuanto más confianza y control se ofrece a un programador, más poderosa es la herramienta ... y más preocupaciones de seguridad surgen.

AJAX por naturaleza tendría la ventaja, ya que su seguridad está integrada en el código del navegador (que a veces es cuestionable, pero todavía está allí).

Por otro lado, las llamadas AJAX son más susceptibles a los ataques de "hombre en el medio", mientras que los problemas de seguridad de Websockets generalmente son errores en el código de la aplicación que introdujo una falla de seguridad (por lo general, la lógica de autenticación de back-end es donde los encontrará).

Personalmente, no creo que esto sea una gran diferencia, en todo caso creo que los Websockets están un poco mejor, especialmente cuando sabes lo que estás haciendo.

Mi humilde opinión

En mi humilde opinión, usaría Websockets para todo excepto las llamadas a la API REST. Cargas de Big Data que fragmentaría y enviaría a través de Websockets cuando sea posible.

Las encuestas, en mi humilde opinión, deberían prohibirse, el costo en el tráfico de red es horrible y el empuje de Websocket es lo suficientemente fácil de administrar incluso para los nuevos desarrolladores.

Además de los problemas con los navegadores más antiguos (incluido IE9, ya que WebSockets será compatible a partir de IE10), todavía hay grandes problemas con los intermediarios de red que aún no admiten WebSockets, incluidos los proxies transparentes, los proxies inversos y los equilibradores de carga. Hay algunos operadores móviles que bloquean completamente el tráfico de WebSocket (es decir, después del comando HTTP UPGRADE).

Con el paso de los años, WebSockets será cada vez más compatible, pero mientras tanto, siempre debe tener un método alternativo basado en HTTP para enviar datos a los navegadores.

La mayoría de las quejas que he leído sobre los sockets web y la seguridad provienen de proveedores de seguridad de herramientas de seguridad del navegador web y firewall. El problema es que no saben cómo hacer un análisis de seguridad del tráfico de websockets, porque una vez que ha realizado la actualización de HTTP al protocolo binario de websocket, el contenido del paquete y su significado es específico de la aplicación (según lo que programe). Obviamente, esta es una pesadilla logística para estas empresas cuyo sustento se basa en analizar y clasificar todo su tráfico de Internet. :)

Los WebSockets no funcionan en navegadores web más antiguos, y los que lo admiten a menudo tienen implementaciones diferentes. Esa es prácticamente la única buena razón por la que no se usan todo el tiempo en lugar de AJAX.

No creo que podamos hacer una comparación clara de Websockets y HTTP, ya que no son rivales ni resuelven los mismos problemas.

Los Websockets son una excelente opción para manejar la transmisión de datos bidireccional de larga duración casi en tiempo real, mientras que REST es ideal para comunicaciones ocasionales. El uso de websockets es una inversión considerable, por lo tanto, es una exageración para las conexiones ocasionales.

Puede encontrar que Websockets funciona mejor cuando hay grandes cargas, HTTP es un poco más rápido en algunos casos porque puede utilizar el almacenamiento en caché. Comparar REST con Websockets es como comparar manzanas con naranjas.

Deberíamos verificar cuál proporciona la mejor solución para nuestra aplicación, cuál se adapta mejor en nuestro caso de uso gana.

Un ejemplo de las diferencias entre HTTP y Websockets en forma de una biblioteca de tamaño de cliente que puede manejar el punto final de Websocket como las API REST y los puntos finales RESTful como Websockets en el cliente. https://github.com/mikedeshazer/sockrest También, para aquellos que están tratando de consumir una API websocket en el cliente o viceversa de la forma en que están acostumbrados. Libs / sockrest.js deja bastante en claro las diferencias (o más bien se supone que debe hacerlo).