javascript - validacion - Eventos enviados por el servidor y límites del navegador

validar formulario jquery

Question

Tengo una aplicación web que escucha los eventos enviados por el servidor. Mientras estaba trabajando y probando con varias ventanas abiertas, las cosas no funcionaban y me golpeé la cabeza varias veces mirando en la dirección incorrecta: finalmente, me di cuenta de que el problema eran las conexiones simultáneas.

Sin embargo, estaba probando un número muy limitado e incluso si estoy ejecutando la prueba en Apache (lo sé, debería usar el nodo).

Luego, cambié el navegador y noté algo realmente interesante: aparentemente Chrome limita las conexiones de los eventos enviados al servidor a 4-5, mientras que Opera no lo hace. Firefox, por otro lado, después de 4-5 conexiones simultáneas, se niega a cargar cualquier otra página.

Cuál es la razón detrás de esto? ¿El límite solo se aplica a las conexiones SSE de la misma fuente, o sería lo mismo si probara abrirlos desde un dominio diferente? ¿Hay alguna posibilidad de que esté haciendo un uso indebido de SSE y esto realmente está bloqueando los navegadores, o se trata de un comportamiento conocido? ¿Hay alguna manera de evitarlo?

Answer 1

Tiene razón sobre la cantidad de conexiones simultáneas.

Puede consultar esta lista para conocer los valores máximos: http://www.browserscope.org/?category=network

Y desafortunadamente, nunca encontré ningún trabajo, excepto la multiplexación y / o el uso de diferentes nombres de host.

Answer 2

La forma en que esto funciona en todos los navegadores es que cada dominio obtiene una cantidad limitada de conexiones y los límites son globales para toda la aplicación. Eso significa que si tiene una conexión abierta para comunicación en tiempo real, tiene una menos para cargar imágenes, css y otras páginas. Además de eso, no obtienes nuevas conexiones para pestañas o ventanas nuevas, todas necesitan compartir la misma cantidad de conexiones. Esto es muy frustrante, pero hay buenas razones para limitar las conexiones. Hace unos años, este límite era 2 en todos los navegadores (según las reglas en ( http://www.ietf.org/rfc/rfc2616.txt ) especificación HTTP1.1) pero ahora la mayoría de los navegadores usan 4-10 conexiones en general. Los navegadores móviles, por otro lado, aún deben limitar la cantidad de conexiones para ahorrar batería.

Estos trucos están disponibles:

1. Use más nombres de host. Al asignar ex. www1.domain.com, www2.domain.com, obtienes nuevas conexiones para cada nombre de host. Este truco funciona en todos los navegadores. No olvides cambiar el dominio de cookies para incluir todo el dominio (domain.com, no www.domain.com)
2. Use enchufes web. Los sockets web no están limitados por estas restricciones y, lo que es más importante, no compiten con el resto del contenido de su sitio web.

3. Reutiliza la misma conexión cuando abres nuevas pestañas / ventanas. Si ha reunido toda la lógica de comunicación en tiempo real en un concentrador de llamadas a objetos, puede recuperar ese objeto en todas las ventanas abiertas como esta:

   window.hub = window.opener ? window.opener.hub || new Hub()

4. o use el flash, no es el mejor consejo hoy en día, pero podría ser una opción si los websockets no son una opción.
5. Recuerde agregar unos segundos de tiempo entre cada solicitud de SSE para permitir que las solicitudes en cola se borren antes de comenzar una nueva. También agregue un poco más de tiempo de espera por cada segundo que el usuario esté inactivo, de esa manera usted puede concentrar los recursos de su servidor en aquellos usuarios que estén activos. También agregue un número aleatorio de retraso para evitar el problema del rebaño que truena

Otra cosa que debe recordar al usar un lenguaje multiproceso y de bloqueo como Java o C #, arriesga el uso de recursos en su larga solicitud de sondeo que son necesarios para el resto de su aplicación. Por ejemplo, en C #, cada solicitud bloquea el objeto Session, lo que significa que la aplicación completa no responde durante el tiempo en que se activa una solicitud SSE.

NodeJs es ideal para estas cosas por muchas razones, como ya has descubierto, y si utilizaras NodeJS, habrías utilizado socket.io o engine.io que se ocupa de todos estos problemas utilizando websockets, sockets y XHR-polling y también porque no es bloqueante y tiene un solo subproceso, lo que significa que consumirá muy pocos recursos en el servidor cuando está esperando que se envíen cosas. La aplicación AC # consume un hilo por solicitud de espera, lo que requiere al menos 2 MB de memoria solo para el hilo.