html5 - metatags - meta tags seo

Eventos enviados por el servidor frente al sondeo

Question

¿Existe una gran diferencia (en términos de rendimiento, disponibilidad de implementación del navegador, carga del servidor, etc.) entre las SSEs HTML5 y las encuestas Ajax directas? Desde el lado del servidor, parece que EventSource está llegando a la página especificada cada ~ 3 segundos más o menos (aunque entiendo que el tiempo es flexible).

Por supuesto, es más fácil configurarlo en el lado del cliente que configurar un temporizador y tener $.get cada cierto tiempo, pero ¿hay algo más? ¿Envía menos encabezados o hace alguna otra magia que me falta?

Answer 1

El sondeo Ajax agrega una gran cantidad de sobrecarga HTTP, ya que constantemente establece y destruye las conexiones HTTP. Como HTML5 Rocks lo define como "Eventos enviados por el servidor", se han diseñado desde cero para que sean eficientes ".

Los eventos enviados por el servidor abren una única conexión HTTP de larga duración. Luego, el servidor envía datos de manera unidireccional cuando lo tiene, no hay necesidad de que el cliente lo solicite ni haga nada más que esperar por los mensajes.

Una desventaja de los eventos enviados por el servidor es que, dado que crean una conexión persistente con el servidor, es posible que tenga muchas conexiones abiertas a su servidor. Algunos servidores manejan cantidades masivas de conexiones simultáneas mejor que otros. Dicho esto, usted tendría problemas similares con las encuestas además de la sobrecarga de restablecer constantemente esas conexiones.

Los eventos enviados por el servidor son bastante compatibles en la mayoría de los navegadores , la excepción notable es, por supuesto, IE. Pero hay un par de polyfills (y un plugin jQuery ) que solucionará eso.

Si está haciendo algo que solo necesita una comunicación unidireccional, definitivamente iría con los eventos enviados por el servidor. Como mencionó Los eventos enviados por el servidor tienden a ser más simples y más limpios para implementar en el lado del cliente. Solo necesita configurar oyentes para mensajes y eventos y el navegador se ocupa de cosas de bajo nivel como reconectar si está desconectado, etc. En el lado del servidor también es bastante fácil de implementar ya que solo usa texto simple. Si envía objetos codificados JSON, puede convertirlos fácilmente en objetos JavaScript en el cliente a través de JSON.parse() .

Si está utilizando PHP en el servidor, puede usar json_encode() para convertir cadenas, números, matrices y objetos en JSON correctamente codificado. Otros lenguajes de back-end también pueden proporcionar funciones similares.

Answer 2

Solo agregaría una perspectiva más alta a lo que se ha dicho, y es que SSE es un modelo de publicación y suscripción en lugar de un sondeo constante en caso de AJAX.

Generalmente, ambas formas (sondeo y publicación-suscripción) intentan resolver el problema de cómo mantener un estado actualizado en el cliente.

1) Modelo de sondeo

Es simple. El cliente (navegador) primero obtiene un estado inicial (página) y para que se actualice, necesita solicitar periódicamente el estado (página o su parte) y procesar el resultado en el estado actual (actualizar toda la página o procesarla inteligentemente en su parte en caso de AJAX).

Naturalmente, un inconveniente es que si no ocurre nada con el estado del servidor, los recursos (CPU, red, ...) se utilizan innecesariamente. Otra es que incluso si el estado cambia, los clientes lo obtienen solo en el siguiente período de encuesta, no lo antes posible. A menudo se necesita evaluar un buen compromiso de tiempo entre las dos cosas.

Otro ejemplo de sondeo es un spinwait en subprocesamiento.

2) Modelo de publicación y suscripción

Funciona de la siguiente manera:

• (el cliente primero solicita y muestra algún estado inicial)
• el cliente se suscribe al servidor (envía una solicitud, posiblemente con algún contexto como fuente de evento)
• servidor marca la referencia al cliente a algunos de sus repositorios de referencia de clientes
• en caso de una actualización del estado, el servidor envía una notificación al cliente en función de la referencia al cliente que posee; es decir, no es una respuesta a una solicitud sino un mensaje iniciado por el servidor
• los buenos clientes se dan de baja cuando ya no están interesados ​​en las notificaciones

Esto es SSE, o dentro de un evento waitable, como otro ejemplo. Un inconveniente natural, como se indica, es que el servidor debe conocer todos sus clientes suscritos, lo que, dependiendo de una implementación, puede ser un problema.