javascript - ejemplo - websocket php y html5

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

Question

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

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

En la investigación de sondeo largo / corto, me encontré con HTML5 WebSockets. Esto parece fácil de implementar, pero no estoy seguro de 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 preferiría uno usar uno sobre el otro? Más específicamente, ¿HTML5 WebSockets ha dejado obsoleto AJAX a largo / corto de la encuesta, o hay razones de peso para preferir AJAX sobre WebSockets?

Answer 1

Para las aplicaciones de chat o cualquier otra aplicación que esté en constante conversación con el servidor, WebSockets es la mejor opción. Sin embargo, solo puede usar WebSockets con un servidor que los admita, por lo que puede limitar su capacidad para usarlos si no puede instalar las bibliotecas necesarias. En cuyo caso, necesitaría utilizar Long Polling para obtener una funcionalidad similar.

Answer 2

Una tecnología rival que ha omitido es el evento enviado por el servidor / el origen del evento. ¿Qué son los sondeos largos, websockets, eventos enviados por el servidor (SSE) y cometas? 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.

Answer 3

WebSockets es definitivamente el futuro.

El sondeo largo es una solución sucia para evitar la creación de conexiones para cada solicitud como lo hace AJAX, pero el sondeo largo se creó cuando no existía WebSockets. Ahora debido a WebSockets, el sondeo largo va a desaparecer.

WebRTC permite la comunicación de igual a igual.

Recomiendo aprender WebSockets .

Comparación:

de las 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 mantener viva 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 los tiempos de espera o datos eof. En el lado del servidor, todavía se trata como una solicitud HTTP, igual que AJAX, excepto que la respuesta a solicitud ocurrirá ahora o en algún momento en el futuro, definido por la lógica de la aplicación. gráfico de soporte (completo) | wikipedia

• WebSockets - client ↔ server . Cree una conexión TCP con el servidor y manténgala abierta todo el tiempo que sea necesario. El servidor o cliente puede cerrar fácilmente la conexión. El cliente pasa por un proceso de protocolo de enlace compatible con HTTP. Si tiene éxito, entonces el servidor y el cliente pueden intercambiar datos en ambas direcciones en cualquier momento. Es eficiente si la aplicación requiere el intercambio frecuente de datos de ambas maneras. Los WebSockets tienen marcos de datos que incluyen el enmascaramiento de cada mensaje enviado desde el cliente al servidor, por lo que los datos simplemente se cifran. WebSockets | wikipedia

• WebRTC - peer ↔ peer . El transporte para establecer comunicación entre clientes es agnóstico al transporte, por lo que puede utilizar UDP, TCP o incluso capas más abstractas. Esto se usa generalmente para la transferencia de datos de gran volumen, como la transmisión de video / audio, donde la confiabilidad es secundaria y se pueden sacrificar algunos cuadros o la reducción de la calidad en favor del tiempo de respuesta y, al menos, cierta transferencia de datos. Ambos lados (pares) pueden empujar los datos entre sí de forma independiente. Si bien se puede usar de forma totalmente independiente de cualquier servidor centralizado, aún requiere alguna forma de intercambiar datos de puntos finales, donde en la mayoría de los casos los desarrolladores todavía usan servidores centralizados para "vincular" a sus compañeros. Esto es necesario solo para intercambiar datos esenciales para establecer una conexión, después de lo cual no se requiere un servidor centralizado. gráfico de soporte (medio) | wikipedia

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

Ventajas:

La principal ventaja de WebSockets del lado del servidor es que no es una solicitud HTTP (después del protocolo de enlace), sino un protocolo de comunicación basado en mensajes 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 una pueda acceder a las variables compartidas. Por lo tanto, no necesita utilizar 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 la RAM, o incluso volver a publicar entre sockets de inmediato.

Consideraciones de Seguridad

La gente suele estar preocupada por la seguridad de WebSockets. La realidad es que hace poca diferencia o incluso pone a WebSockets como una mejor opción. En primer lugar, con AJAX, existe 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 entre sí, con un enmascaramiento de marco adicional cuando se transmiten los datos del cliente al servidor, así como una compresión adicional, que requiere más esfuerzo para sondear los datos. Todos los protocolos modernos soportan ambos: HTTP y HTTPS (encriptados).

PD

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