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?

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 - request→ response. 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 - request→ wait→ response. 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 - client↔ server. 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 - peer↔ peer. 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 - client← server. 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.

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.

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.

• 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