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.
