Web Sockets hacen ajax / CORS obsoleto?

Question

Will tomas web cuando se utiliza en todos los navegadores web hacen ajax obsoleto?

Porque si podía utilizar sockets de Internet para obtener los datos y actualizar datos en tiempo real, ¿por qué necesitaría ajax? Incluso si uso de AJAX para obtener los datos solo una vez, cuando se inició la aplicación todavía puede ser que desee para ver si estos datos ha cambiado después de un tiempo.

y enchufes web será posible en dominios cruzados o sólo a un mismo origen?

Answer 1

WebSockets no hará AJAX totalmente obsoleta y WebSockets puede hacer entre dominios.

AJAX

mecanismos

AJAX se pueden utilizar con los servidores web de civil. En su nivel más básico, AJAX es sólo una manera para una página web para hacer una petición HTTP. WebSockets es un protocolo mucho nivel inferior y requiere un servidor WebSockets (ya sea integrado en el servidor web, independiente, o proxy del servidor web a un servidor autónomo).

Con WebSockets, el encuadre y la carga útil se determina por la aplicación. Se podría enviar HTML / XML / JSON vuelta y vuelta entre el cliente y el servidor, pero no está obligado a. AJAX es HTTP . WebSockets tiene un amistoso apretón de manos HTTP, pero WebSockets no es HTTP . WebSockets es un protocolo bidireccional que está más cerca de raw sockets (intencionalmente de manera) de lo que es HTTP. Los datos de carga útil es WebSockets UTF-8 codificado en la versión actual de la norma, pero esto es probable que se cambió / extendido en futuras versiones.

Así que probablemente siempre será un lugar para Ajax Tipo de peticiones, incluso en un mundo donde todos los clientes soportan de forma nativa WebSockets. WebSockets está tratando de resolver situaciones en las que AJAX no es capaz o marginalmente capaz (porque WebSockets su bidireccional y mucho menos gastos). Pero WebSockets no reemplazar todo AJAX se utiliza para.

entre dominios

Sí , WebSockets apoyos entre dominios. El apretón de manos inicial para configurar la conexión se comunica información de la política origen. La página de Wikipedia muestra un ejemplo de un apretón de manos típico: http://en.wikipedia.org/wiki/WebSockets

Answer 2

voy a tratar de descomponerlo en preguntas:

  

Will tomas web cuando se utiliza en todos los navegadores web hacen ajax obsoleto?

Por supuesto que no. WebSockets son conexiones de socket primas hasta el servidor. Esto viene con es poseer problemas de seguridad . llamadas AJAX son simplemente asíncrono. peticiones HTTP que pueden seguir los mismos procedimientos de validación que el resto de las páginas.

  

Porque si podía utilizar sockets de Internet para obtener los datos y actualizar datos en tiempo real, ¿por qué necesitaría ajax?

sería utilizar AJAX para simples tareas más manejables. No todo el mundo quiere tener la sobrecarga de asegurar una conexión de socket para permitir simplemente asíncrono solicitudes. Que puede ser manejado simplemente suficiente.

  

Incluso si uso de AJAX para obtener los datos solo una vez, cuando se inició la aplicación todavía puede ser que desee para ver si estos datos ha cambiado después de un tiempo.

Por supuesto, si eso está cambiando los datos . Puede que no tenga los datos de cambiar o actualizar constantemente. Una vez más, esto es código de sobrecarga que hay que contabilizar.

  

y enchufes web será posible en dominios cruzados o sólo a un mismo origen?

Puede tener WebSockets entre dominios, pero hay que codificar su servidor WS para aceptarlos. Usted tiene acceso a la cabecera de dominio (host) que luego se puede utilizar para aceptar / rechazar las solicitudes. Esto puede, sin embargo, ser suplantada por algo tan simple como nc. Con el fin de asegurar realmente la conexión que va a necesitar para autenticar la conexión por otros medios.

Answer 3

websockets tiene un par de grandes desventajas en términos de escalabilidad que evita ajax. Desde ajax envía una petición / respuesta y cierra la conexión (..o poco después) si alguien estancias en la página web no utiliza los recursos del servidor al ralentí. Websockets tienen el propósito de volver flujo de datos al navegador, y que atan los recursos del servidor para hacerlo. Los servidores tienen un límite en el número de conexiones simultáneas que pueden mantener abiertos al mismo tiempo. Por no mencionar dependiendo de su tecnología del lado del servidor, pueden atar un hilo para manejar el zócalo. Así websockets tienen requisitos más intensivas en recursos para ambos lados por conexión. Desde aquí se puede agotar todos sus hilos de servicio a los clientes y luego no hay nuevos clientes podría entrar si muchos usuarios están sentados en la página. Aquí es donde nodejs, VertX, Netty pueden realmente ayudar, pero incluso los que tienen límites superiores también.

También está la cuestión de estado de la toma de corriente subyacente, y escribir el código en ambos lados que llevan a cabo la conversación con estado que no es algo que tiene que ver con ajax estilo porque es sin estado. Websockets requieren crear un protocolo de bajo nivel que se resuelve para usted con el Ajax. Cosas como los latidos del corazón, el cierre de las conexiones inactivas, la reconexión de errores, etc son de vital importancia ahora. Estas son cosas que no tienen que resolver cuando se utiliza AJAX porque era sin estado. Estado es muy importante para la estabilidad de su aplicación y lo más importante la salud de su servidor. No es trivial. Pre-HTTP hemos construido una gran cantidad de protocolos TCP stateful (FTP, Telnet, SSH), y luego pasó HTTP. Y nadie hizo eso mucho más porque incluso con sus limitaciones HTTP fue sorprendentemente fácil y más robusto. Websockets traer de vuelta el bueno y el malo de protocolos con estado. Usted aprenderá muy pronto si no recibió una dosis de esta última todos.

Si necesita una transmisión de datos en tiempo real esta sobrecarga adicional se justifica porque el sondeo del servidor para obtener datos de streaming que es peor, pero si todo lo que está haciendo es usuario interacción-> request-> respuesta-> Actualización de la interfaz de usuario, a continuación, Ajax es más fácil y utilizará menos recursos porque una vez que se envía la respuesta de la conversación ha terminado y no se utilizan recursos adicionales del servidor. Así que creo que es una solución de compromiso y el arquitecto tiene que decidir qué herramienta se adapte a su problema. AJAX tiene su lugar, y websockets tienen su lugar.

Actualizar

Así que la arquitectura de su servidor es lo que importa cuando estamos hablando de hilos. Si está utilizando un servidor tradicionalmente de múltiples hilos (o procesos), donde una conexión cada socket recibe su propio proceso de responder a las solicitudes de continuación websockets importa mucho a usted. Así que para cada conexión que tenemos un enchufe, y, finalmente, el sistema operativo se caiga si tiene demasiados de ellos, y lo mismo pasa con hilos (más para los procesos). Las discusiones son más pesados ??que los zócalos (en términos de recursos) así que tratamos y conservar el número de hilos que se estén ejecutando simultáneamente. Eso significa crear un grupo de subprocesos que es sólo un número fijo de las discusiones que se comparte entre todos los sockets. Pero una vez que se abre un socket el hilo se utiliza para toda la conversación. La longitud de estas conversaciones gobernar lo rápido que puede cambiar la finalidad de esos hilos para las nuevas tomas que vienen. La longitud de sus gobierna conversación cuánto puede escalar. Sin embargo, si está transmitiendo este modelo no funciona bien para el escalado. Usted tiene que romper el diseño de rosca / conector.

HTTP del modelo de solicitud / respuesta hace que sea muy eficiente en la transformación de las discusiones sobre las nuevas tomas. Si sólo se va a una solicitud de uso / uso de respuesta HTTP su ya construido y mucho más fácil que reimplementar algo así en websockets.

Desde websockets no tienen que ser de petición / respuesta HTTP y pueden transmitir datos si el servidor dispone de un número fijo de hilos en su grupo de subprocesos y tiene el mismo número de websockets tying seguridad de todos los hilos con las conversaciones activas, no se puede dar servicio a nuevos clientes que entra! Que haya alcanzado su capacidad máxima. Ahí es donde el diseño del protocolo es importante también con websockets e hilos. Su protocolo te podría ayudar a aflojar el hilo por socket para cada modelo conversación que forma la gente allí sentado no utilizan un hilo en su servidor.

Es donde los servidores de hilos individuales asíncronos entran en juego. En Java a menudo llaman a este NIO de no bloqueo IO. Eso significa que es una API diferente para enchufes donde enviar y recibir datos no bloquea el hilo que realiza la llamada.

Así tradicional en el bloqueo de tomas cuando se llama socket.read () o socket.write () esperan a que los datos son recibidos o enviados antes de devolver el control a su programa. Esto significa que su programa está esperando pegado para los datos de sockets para entrar o salir hasta que se pueda hacer otra cosa. Es por eso que tenemos hilos para que podamos hacer el trabajo simultáneamente (al mismo tiempo). Enviar estos datos al cliente X mientras espero en datos de cliente Y. concurrencias es el nombre del juego cuando hablamos de servidores.

En un servidor NIO se utiliza un solo hilo para manejar todos los clientes y registrar las devoluciones de llamada a ser notificado cuando los datos llegan. Por ejemplo

socket.read( function( data ) {
   // data is here! Now you can process it very quickly without waiting!
});

El socket.read () devolverá inmediatamente sin lectura de los datos, pero nuestra función que siempre se llamará cuando se trata de. Este diseño cambia radicalmente la forma de construir y arquitecto de su código, porque si se colgó la espera de algo que no puede recibir nuevos clientes. Usted tiene un solo hilo que realmente no puede hacer dos cosas a la vez! Usted tiene que mantener un hilo que se mueve.

NIO, S asíncrona, programa basado en eventos como todo esto se le conoce como, es un diseño de sistema mucho más complicado, y yo no sugeriría que tratar de escribir esto si usted está comenzando. Incluso los programadores de muy alto nivel resulta muy difícil construir un sistema robusto. Dado que usted es asíncrona no se puede llamar a las API de ese bloque. Al igual que la lectura de los datos de la base de datos o el envío de mensajes a otros servidores tiene que realizarse de forma asíncrona. Incluso la lectura / escritura desde el sistema de archivos puede ralentizar su único hilo por la reducción de su capacidad de ampliación. Una vez que pasan asíncrono todo es asíncrona todo el tiempo si se quiere mantener en marcha el solo hilo. Que es donde se pone un reto porque con el tiempo se encontrará con una API, como DB, que no es asíncrona y hay que adoptar más hilos en algún nivel. Por lo que una enfoques híbridos son comunes incluso en el mundo asíncrona.

La buena noticia es que hay otras soluciones que utilizan esta API de nivel inferior ya construida que puede utilizar. NodeJS, VertX, Netty, Apache Mina, Jugar Marco, Twisted Python, sin apilado Python, etc. Puede haber alguna biblioteca oscura para C ++, pero sinceramente no me molestaría. la tecnología de servidor no requiere los idiomas muy rápido porque es obligado IO más de CPU obligado. Si usted es un uso tuerca rendimiento de morir duro de Java. Tiene una gran comunidad de código para tirar desde y su velocidad está muy cerca (y, a veces mejor) de C ++. Si odias ir con el Nodo o Python.

Answer 4

Sí, sí lo hace. : D

Las respuestas anteriores carecen de imaginación. No veo ninguna razón más para utilizar AJAX si websockets están disponibles para usted.