ajax - websockets - websocket php mysql
¿Por qué usar AJAX cuando WebSockets está disponible? (6)
He estado usando WebSockets desde hace un tiempo, he elegido crear una herramienta de gestión de proyectos Agile para mi proyecto de último año en la Universidad utilizando el servidor Node y WebSockets. Descubrí que usar WebSockets proporcionaba un aumento del 624% en el número de solicitudes por segundo que mi aplicación podía procesar.
Sin embargo, desde que comencé el proyecto, he leído sobre lagunas de seguridad, y algunos navegadores 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 hace mejor que WebSockets?
No creo que podamos hacer una comparación clara de Websockets y HTTP ya que no son rivales ni resolver los mismos problemas.
Websockets es una gran opción para manejar la transmisión bidireccional de datos de larga duración casi en tiempo real, mientras que REST es ideal para comunicaciones ocasionales. Usar websockets es una inversión considerable, por lo tanto, es un exceso de conexiones ocasionales.
Puede encontrar que Websockets mejora cuando hay altas cargas, HTTP es ligeramente 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 comprobar cuál proporciona una mejor solución para nuestra aplicación, cuál se ajusta mejor a las victorias de nuestro caso de uso.
Además de los problemas con los navegadores más antiguos (incluido IE9, ya que WebSockets será compatible a partir de IE10), todavía existen grandes problemas con los intermediarios de red que aún no soportan WebSockets, incluidos los proxies transparentes, los proxies inversos y los balanceadores de carga. Hay algunos operadores de telefonía móvil que bloquean por completo 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 websockets y seguridad provienen de proveedores de seguridad de seguridad de navegador web y herramientas de seguridad de firewall. El problema es que no saben cómo hacer 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). Esto es obviamente 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 antiguos, y los que sí lo admiten suelen tener diferentes implementaciones. Esa es prácticamente la única buena razón por la que no se usan todo el tiempo en lugar de AJAX.
Un 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 logró reemplazar AJAX, al menos no del todo, especialmente a medida que la adaptación HTTP / 2 va en aumento.
La respuesta corta 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, entonces ...
AJAX para sondeo?
El uso de AJAX para el sondeo (o el sondeo largo) está desapareciendo (y debería ser así), pero aún permanece en uso por dos buenas razones (principalmente para aplicaciones web más pequeñas):
Para muchos desarrolladores, AJAX es más fácil de codificar, especialmente cuando se trata de codificar y diseñar el back-end.
Con HTTP / 2, se eliminó el costo más alto relacionado con AJAX (el establecimiento de una nueva conexión), lo que permite que las llamadas AJAX sean 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 es necesario "ida y vuelta sin datos", etc.). Esto fue discutido varias veces.
AJAX para REST?
Un mejor uso para AJAX son las llamadas a la API REST. 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 las llamadas a la API REST y las cargas de datos:
La API de AJAX se diseñó prácticamente para llamadas a la API REST y encaja perfectamente.
Las llamadas y cargas REST usando AJAX son significativamente más fáciles de codificar, tanto en el cliente como en el back-end.
A medida que aumenta la carga de datos, las conexiones de Websocket pueden bloquearse a menos que se codifique la lógica de fragmentación / multiplexión de mensajes.
Si se realiza una carga en una sola llamada de
sendWebsocket, podría bloquear una transmisión de Websocket hasta que finalice la carga. Esto reducirá el rendimiento, especialmente en clientes más lentos.
Un diseño común utiliza pequeños mensajes bidi transferidos a través de Websockets mientras que REST y la carga de datos (cliente a servidor) aprovechan la facilidad de uso de AJAX para evitar que 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 haya eliminado y restablecido una conexión (¿recuerdas esa película de 5GB que querías subir?).
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 empuje HTTP / 2 no reemplaza (y probablemente no puede) Websockets.
Esto ya se discutió anteriormente, pero basta con mencionar que una única conexión HTTP / 2 sirve para todo el navegador (todas las pestañas / ventanas), por lo que los datos que HTTP / 2 empujan 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 geniales para la comunicación de datos bidireccional pequeña, AJAX todavía tiene una serie de ventajas, especialmente cuando se consideran cargas útiles más grandes (cargas, etc. '').
¿Y seguridad?
Bueno, en general, mientras más confianza y control se le ofrecen 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 aún 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 suelen ser errores en el código de la aplicación que introdujo una falla de seguridad (generalmente la lógica de autenticación de back-end es donde los encontrará).
Personalmente, no creo que esto sea tan importante, en todo caso creo que Websockets está 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 menos para las llamadas a API REST. Cargas grandes de datos fragmentaré y enviaré 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 la red es horrible y Websocket push es lo suficientemente fácil de administrar incluso para los nuevos desarrolladores.
WebSockets no pretende reemplazar a AJAX y no es estrictamente ni siquiera un reemplazo para Comet / long-poll (aunque hay muchos casos en los que esto tiene sentido).
El objetivo de WebSockets es proporcionar una conexión de baja latencia, bidireccional, dúplex completo y de larga duración entre un navegador y un servidor. WebSockets abre nuevos dominios de aplicaciones para las aplicaciones del navegador que no eran realmente posibles usando HTTP y AJAX (juegos interactivos, flujos de medios dinámicos, puentes a protocolos de red existentes, etc.).
Sin embargo, ciertamente existe una superposición en el propósito entre WebSockets y AJAX / Comet. Por ejemplo, cuando el navegador quiere ser notificado de los eventos del servidor (es decir, push), entonces las técnicas Comet y WebSockets son ciertamente opciones viables. Si su aplicación necesita eventos de baja latencia, esto 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, balanceadores de carga), esto sería un factor a favor de las técnicas de Comet (por ahora).
Si no necesita los beneficios específicos que proporciona WebSockets, entonces probablemente sea una mejor idea quedarse con las técnicas existentes, como AJAX y Comet, porque esto le permite reutilizar e integrar con un gran ecosistema existente de herramientas, tecnologías y mecanismos de seguridad. , bases de conocimiento (es decir, muchas más personas en conocen HTTP / Ajax / Comet que WebSockets), etc.
Por otro lado, si está creando una nueva aplicación que simplemente no funciona bien dentro de la latencia y las restricciones de conexión de HTTP / Ajax / Comet, entonces considere usar WebSockets.
Además, algunas respuestas indican que uno de los inconvenientes de WebSockets es el servidor limitado / mixto y el soporte del navegador. Déjame difuminar un poco. Si bien iOS (iPhone, iPad) aún es compatible con el protocolo anterior (Hixie), la mayoría de los servidores WebSockets son compatibles tanto con Hixie como con la versión HyBi / IETF 6455 . La mayoría de las otras plataformas (si aún no tienen soporte integrado) pueden obtener compatibilidad con WebSockets a través de web-socket-js (Flashfill based polyfill). Esto cubre la gran mayoría de los usuarios de la web. Además, si está utilizando Node para el backend del servidor, entonces considere usar Socket.IO que incluye web-socket-js como una alternativa y si incluso eso no está disponible (o deshabilitado), entonces recurrirá a usar cualquier técnica de Comet. disponible para el navegador dado.
Actualización : iOS 6 ahora es compatible con el estándar actual HyBi / IETF 6455.