¿En qué situaciones se preferiría el sondeo AJAX largo / corto sobre HTML5 WebSockets?


306

Estoy creando una pequeña aplicación de chat para amigos, pero no estoy seguro de cómo obtener información de manera oportuna que no sea tan manual o tan rudimentaria como forzar una actualización de la página.

Actualmente, estoy implementando esto usando AJAX simple, pero esto tiene la desventaja de golpear regularmente el servidor cuando transcurre un breve temporizador.

Al investigar encuestas largas / cortas, me encontré con HTML5 WebSockets. Esto parece fácil de implementar, pero no estoy seguro si hay algunas desventajas ocultas. Por ejemplo, creo que WebSockets solo es compatible con ciertos navegadores. ¿Hay otras desventajas de WebSockets que debo tener en cuenta?

Dado que parece que ambas tecnologías hacen lo mismo, ¿en qué tipo de escenarios uno preferiría usar uno sobre el otro? Más específicamente, ¿HTML5 WebSockets ha dejado obsoleto el sondeo AJAX largo / corto, o hay razones de peso para preferir AJAX sobre WebSockets?

Respuestas:


508

WebSockets es definitivamente el futuro.

El sondeo largo es una solución sucia para evitar crear conexiones para cada solicitud como lo hace AJAX, pero el sondeo largo se creó cuando WebSockets no existía. Ahora debido a WebSockets, las encuestas largas desaparecen.

WebRTC permite la comunicación entre pares.

Recomiendo aprender WebSockets .

Comparación:

de diferentes técnicas de comunicación en la web

  • AJAX - requestresponse. Crea una conexión con el servidor, envía encabezados de solicitud con datos opcionales, obtiene una respuesta del servidor y cierra la conexión. Compatible con todos los principales navegadores.

  • Encuesta larga - requestwaitresponse. Crea una conexión con el servidor como lo hace AJAX, pero mantiene una conexión de mantenimiento abierto durante algún tiempo (aunque no mucho). Durante la conexión, el cliente abierto puede recibir datos del servidor. El cliente tiene que volver a conectarse periódicamente después de que se cierre la conexión, debido a tiempos de espera o datos de eof. En el lado del servidor, todavía se trata como una solicitud HTTP, igual que AJAX, excepto que la respuesta a la solicitud sucederá ahora o en algún momento en el futuro, definida por la lógica de la aplicación. tabla de soporte (completa) | wikipedia

  • WebSockets - clientserver. Cree una conexión TCP al servidor y manténgala abierta el tiempo que sea necesario. El servidor o el cliente pueden cerrar fácilmente la conexión. El cliente pasa por un proceso de protocolo de enlace compatible con HTTP. Si tiene éxito, el servidor y el cliente pueden intercambiar datos en ambas direcciones en cualquier momento. Es eficiente si la aplicación requiere un intercambio frecuente de datos en ambos sentidos. WebSockets tiene un marco de datos que incluye el enmascaramiento para cada mensaje enviado desde el cliente al servidor, por lo que los datos simplemente se cifran. tabla de soporte (muy buena) | wikipedia

  • WebRTC - peerpeer. Transporte para establecer comunicación entre clientes y es independiente del transporte, por lo que puede usar UDP, TCP o incluso capas más abstractas. Esto generalmente se usa para la transferencia de datos de alto volumen, como la transmisión de video / audio, donde la confiabilidad es secundaria y se pueden sacrificar algunos cuadros o la reducción en la progresión de la calidad a favor del tiempo de respuesta y, al menos, alguna transferencia de datos. Ambas partes (pares) pueden enviar datos entre sí de forma independiente. Si bien se puede usar de manera totalmente independiente de cualquier servidor centralizado, aún requiere alguna forma de intercambio de datos de EndPoints, donde en la mayoría de los casos los desarrolladores aún usan servidores centralizados para "vincular" a sus pares. Esto solo se requiere para intercambiar datos esenciales para establecer una conexión, después de lo cual no se requiere un servidor centralizado. tabla de soporte (medio) | wikipedia

  • Eventos enviados por el servidor - clientserver. El cliente establece una conexión persistente y a largo plazo con el servidor. Solo el servidor puede enviar datos a un cliente. Si el cliente desea enviar datos al servidor, requerirá el uso de otra tecnología / protocolo para hacerlo. Este protocolo es compatible con HTTP y fácil de implementar en la mayoría de las plataformas del lado del servidor. Este es un protocolo preferible para usar en lugar de Long Polling. tabla de soporte (buena, excepto IE) | wikipedia

Ventajas:

La principal ventaja del lado del servidor WebSockets es que no es una solicitud HTTP (después del protocolo de enlace), sino un protocolo de comunicación basado en un mensaje adecuado. Esto le permite lograr enormes ventajas de rendimiento y arquitectura . Por ejemplo, en node.js, puede compartir la misma memoria para diferentes conexiones de socket, para que cada uno pueda acceder a las variables compartidas. Por lo tanto, no necesita usar una base de datos como punto de intercambio en el medio (como con AJAX o Long Polling con un lenguaje como PHP). Puede almacenar datos en RAM o incluso volver a publicarlos entre sockets de inmediato.

Consideraciones de Seguridad

Las personas a menudo están preocupadas por la seguridad de WebSockets. La realidad es que hace poca diferencia o incluso pone WebSockets como una mejor opción. En primer lugar, con AJAX, hay una mayor probabilidad de MITM , ya que cada solicitud es una nueva conexión TCP que atraviesa la infraestructura de Internet. Con WebSockets, una vez que está conectado, es mucho más difícil interceptar en el medio, con enmascaramiento de trama adicionalmente aplicado cuando los datos se transmiten desde el cliente al servidor, así como la compresión adicional, que requiere más esfuerzo para sondear datos. Todos los protocolos modernos admiten ambos: HTTP y HTTPS (encriptados).

PD

Recuerde que los WebSockets generalmente tienen un enfoque lógico muy diferente para las redes , más parecido a los juegos en tiempo real que tuvieron todo este tiempo, y no como http.


15
No se trata de compatibilidad en sí mismo. Lo más importante es que está a punto de repensar completamente la forma en que se produce la comunicación. Como las API RESTful funcionan con el patrón Solicitud> Respuesta, la comunicación bidireccional aquí no tendría sentido. Por lo tanto, intentar usar WebSockets para consultar la API RESTful es un intento un poco extraño, y no puedo ver ningún beneficio en absoluto. Si necesita datos de la API RESTful pero en tiempo real, entonces crea una API de WebSockets para enviar datos que funcionarán con la comunicación bidireccional como WebSockets. Estás tratando de comparar cosas en ángulo que no son comparables :)
moka

2
Hola @pithhelmet, todo depende del software del lado del servidor (idioma / tecnología). WebSocket es capa sobre TCP, y hay muchas formas de hacer implementaciones de flujo TCP. Los servidores web modernos utilizan una arquitectura basada en eventos y son muy eficientes con los grupos de subprocesos. ¿Qué tecnología estás usando? Node.js usa eventos detrás de escena para IO y eventos con un solo hilo en contexto de ejecución, por lo que es increíblemente eficiente. El uso de subprocesos para cada conexión es muy ineficiente en términos de RAM (1mb + por subproceso) y de CPU, ya que esos subprocesos simplemente estarán inactivos o peor, bucle infinito de verificación de datos.
moka

44
Las encuestas largas no son una solución sucia, y son diferentes de webSocket. Estos dos están destinados a ser utilizados en diferentes escenarios.
bagz_man

55
@bagz_man Long Polling es un uso "hacky" de la tecnología para lograr resultados que la tecnología no permitía por definición y que no estaba disponible una alternativa estándar. La razón por la que existe Long Polling es exactamente el hecho de que WS no, Period.
moka

44
@moka: el nivel libre de Cloudflare absorberá un ataque sostenido de más de 400 Gbps. ¿Puede su billetera absorber la factura de AWS? También AWS y Cloudflare tienen puntos de vista opuestos cuando se trata de manejar quejas contra su origen. Es algo a tener en cuenta siempre que estemos discutiendo las compensaciones. :)
danneu

11

Una tecnología contendiente que ha omitido es Eventos enviados por el servidor / Origen del evento. ¿Qué son Long-Polling, Websockets, Server-Sent Events (SSE) y Comet? tiene una buena discusión de todos estos. Tenga en cuenta que algunos de estos son más fáciles de integrar que otros en el lado del servidor.


De todo esto, ¿qué sugerencia sugerirías que estudies?
Somdow

He tenido éxito con los sondeos largos, el único truco (para ello y otras tecnologías) es no atar un hilo del servidor. Si no utiliza el código de servidor asíncrono, no se escalará.
bmm6o

1
@somdow Maksims-Mihejevs respondió su pregunta muy bien en los primeros dos párrafos de su respuesta. Usa websockets.
Jeff Sheffield

7

Para las aplicaciones de chat o cualquier otra aplicación que esté en constante conversación con el servidor, WebSocketsson la mejor opción. Sin embargo, solo puede usar WebSocketscon un servidor que los admita, por lo que puede limitar su capacidad de usarlos si no puede instalar las bibliotecas necesarias. En ese caso, deberá usarlo Long Pollingpara obtener una funcionalidad similar.


55
Todos los servidores admiten WebSockets ... Solo necesita instalar node.js o algo similar.
noob

99
Ajustado un poco para explicar que sí, cualquier servidor admitirá WebSockets. Sin embargo, si está utilizando el servicio de alojamiento, es posible que no pueda utilizarlos.
Brant Olsen

Me doy cuenta de que este hilo es un poco viejo pero ... WebSockets puede no ser la mejor respuesta para toda comunicación bidireccional. Hace poco noté que la documentación para el soporte de socket web de Spring 4 sugiere que los WebSockets son más adecuados para mover grandes cantidades de datos o baja latencia. Si esos no son aplicables o no son una prioridad, entonces creo que sugieren usar encuestas largas. No sé la justificación completa de esta opinión, me imaginé que la gente de Spring sabe de lo que están hablando en general.
Stoney

1
@Stoney, aparte del hecho de que necesitaría configurar websocket en el servidor (controladores, etc.) Simplemente no hay razón para usar Long sondeo sobre websocket. Websocket es mucho más rápido (baja latencia) y permite al servidor "hablar" con el cliente sin que el cliente se lo pida. Hoy en día utilizo signalr (una de las mejores implementaciones de websocket que se haya hecho en mi opinión, se ejecuta en el cliente y el servidor y permite que el cliente llame a métodos en el servidor y al servidor en el cliente como si no hubiera diferencia) en cada sitio web que hago - carga de contenido dinámico, páginas sin fondo, etc.
DividedByZero

0

Sondeo XHR vs SSE vs WebSockets

  • Sondeo XHR Una solicitud se responde cuando se produce el evento (podría ser inmediatamente o después de un retraso). Se deberán realizar solicitudes posteriores para recibir más eventos.

    El navegador realiza una solicitud asincrónica del servidor, que puede esperar a que los datos estén disponibles antes de responder. La respuesta puede contener datos codificados (generalmente XML o JSON) o Javascript para que el cliente los ejecute. Al final del procesamiento de la respuesta, el navegador crea y envía otro XHR para esperar el próximo evento. Así, el navegador siempre mantiene una solicitud pendiente con el servidor, para ser respondida a medida que ocurre cada evento. Wikipedia

  • El servidor envía eventos El cliente envía una solicitud al servidor. El servidor envía nuevos datos a la página web en cualquier momento.

    Tradicionalmente, una página web tiene que enviar una solicitud al servidor para recibir nuevos datos; es decir, la página solicita datos del servidor. Con los eventos enviados por el servidor, es posible que un servidor envíe nuevos datos a una página web en cualquier momento, enviando mensajes a la página web. Estos mensajes entrantes pueden tratarse como eventos + datos dentro de la página web. Mozilla

  • WebSockets Después del apretón de manos inicial (a través del protocolo HTTP). La comunicación se realiza bidireccionalmente utilizando el protocolo WebSocket.

    El protocolo de enlace comienza con una solicitud / respuesta HTTP, lo que permite a los servidores manejar conexiones HTTP, así como conexiones WebSocket en el mismo puerto. Una vez que se establece la conexión, la comunicación cambia a un protocolo binario bidireccional que no se ajusta al protocolo HTTP. Wikipedia

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.