2011-12-06 24 views
35

Hasta donde sé, en el momento actual, a fines de 2011, el límite máximo de conexiones por servidor permanece en 6. Corrígeme si me equivoco . Esto es malo, no podemos arreglarlo tan fácilmente como en Firefox. Por lo que sé, este valor está codificado.Incrementando el límite máximo de conexiones de Google Chrome por servidor a más de 6

Una de las soluciones es descargar las fuentes de Chromium y reconstruirlas. ¿Hay una solución más fácil?

¿Hay alguna forma complicada de hackear esto sin crear una docena de dominios espejo?

Por qué hago la pregunta: Mi tarea es crear una presentación de diapositivas html-javascript que se ejecutará dentro de un navegador completamente apantallado, y un enorme monitor colgado en la pared. El javascript es realmente complicado, precarga fotos y realiza muchas llamadas ajax a mis servicios web. Si la conexión WIFI es lenta, si se cargan 6 fotos, las llamadas AJAX fallan, la aplicación se ejecuta mal. Quiero una solución rápida basada en http, navegador o ubuntu modificar otra cosa, porque la reconstrucción de la aplicación javascript tomará días.

Offtopic: ¿conoces alguna otra cosa que pueda modificarse en mi situación concreta?

+2

esto parece ser la solicitud de mejora abierta, pero lamentablemente no parecen ansiosos por agregar la opción de configuración https://code.google.com/p/chromium/issues/detail?id=85323 – jamshid

+2

If podríamos agregar "modo aleatorio" al complemento SwitchySharp, podemos separar 25 solicitudes en 25 conexiones de puerto proxy simultáneamente. Debería funcionar alrededor del límite máximo de conexiones por servidor. – diyism

+2

Bueno, puedes usar firefox y configurar en '' 'about: config''' the' '' network.http.max-persistent-connections-per-server '' 'config – joecks

Respuesta

24

IE es aún peor con 2 conexiones por límite de dominio. Pero no confiaría en arreglar navegadores de clientes. Incluso si tiene control sobre ellos, los navegadores como Chrome se actualizarán automáticamente y una versión futura podría comportarse de manera diferente a lo esperado. Me concentraría en resolver el problema dentro del diseño de tu sistema.

Sus opciones son:

  1. Cargar las imágenes en secuencia de manera que sólo 1 o 2 llamadas XHR están activos a la vez (utilice el caso de éxito de la imagen anterior para comprobar si hay más imágenes para descargar e iniciar la siguiente solicitud).

  2. Utilice subdominios como serverA.myphotoserver.com y serverB.myphotoserver.com. Cada subdominio tendrá su propio grupo para los límites de conexión. Esto significa que podría tener 2 solicitudes yendo a 5 subdominios diferentes si así lo desea. La caída es que las fotos se almacenarán en caché según estos subdominios. Por cierto, estos no necesitan ser dominios "espejo", solo puede hacer punteros DNS adicionales al mismo sitio web/servidor. Esto significa que no tiene el dolor de cabeza de administrar muchos servidores, solo un servidor con muchos registros DNS.

+0

Lo que haré: 1) aumentar TTL, 2) controlar imágenes en una secuencia usando img.complete, 3) poner feeds urgentes para separar el dominio – Dan

+0

3) Y contar el número de conexiones abiertas dentro de mi biblioteca (¡eso es simple!) Las imágenes están hambrientas y pueden descargarse hasta 20 segundos, por lo que dejé solo 4 de ellas para descargarlas simultáneamente (ponerlas en una cadena), dejando 2 canales para las transmisiones. – Dan

0

No parece haber una forma externa de piratear el comportamiento de los ejecutables.

Puede modificar los ejecutables de Chrome (ium) ya que esta información es obviamente compilada. Este enfoque trae muchos problemas con el soporte y las actualizaciones automáticas, por lo que probablemente desee evitar hacerlo. También debe comprender how to make the changes en los binarios, que la gente no puede recoger en pocos días.

Si compila su propio navegador, está creando un problema de soporte para usted, ya que está atascado con una revisión específica. Si desea obtener nuevas características y correcciones de errores, deberá volver a compilar. Todo esto implica rastrear el desarrollo de Chrome para detectar errores y generar fallas, algo que un desarrollador web no debería hacer.

Seguiría el consejo de @ BenSwayne por ahora, pero podría valer la pena pensar en hacer parte del trabajo fuera del cliente (el navegador web) y ponerlo en un proceso en segundo plano que se ejecute en las mismas o diferentes máquinas.Este proceso puede manejar muchas más conexiones y usted es el único responsable de recuperar los datos. Como es local (ish), obtendrá resultados rápidamente incluso con conexiones mínimas.

+1

Recomiendo esta respuesta. Debe hacer un tutorial sobre cómo editar el binario para este efecto o incluso cómo usar un editor de memoria para ello. Libera a un entrenador en un sitio de trucos para que Chrome haga cosas como esta. Los desarrolladores de Chrome se quejan de las personas que hacen configuraciones no compatibles, así que vamos a hacer que las cosas sean un infierno para ellos. – jgmjgm

1

No sé si puedes hacerlo en Chrome fuera de Windows: algunos googlean muestran que Chrome (y por lo tanto posiblemente Chromium) podrían responder bien a un cierto hack de registro.

Sin embargo, si solo está buscando una solución simple sin modificar su código base, ¿ha considerado Firefox? En about: config puedes buscar "network.http.max" y hay algunos valores que definitivamente vale la pena mirar.

Además, para un dispositivo que no se moverá (es decir, está montado en una ubicación fija), debería considerar no usar Wi-Fi (incluso un Home-Plug sería un paso adelante en cuanto a latencia/estabilidad/conexiones caídas van).

4

Por cierto, HTTP 1/1 especificación (RFC2616) sugiere no más de 2 conexiones por servidor.

Los clientes que utilizan conexiones persistentes DEBEN limitar el número de conexiones simultáneas que mantienen a un servidor determinado. Un cliente de usuario único NO DEBE mantener más de 2 conexiones con ningún servidor o proxy. Un proxy DEBE usar conexiones de hasta 2 * N a otro servidor o proxy, donde N es el número de usuarios activos simultáneamente. Estas pautas están destinadas a mejorar los tiempos de respuesta de HTTP y evitar la congestión.

+7

Sí, pero el RFC2616 tiene 18 años, por lo que sus recomendaciones deben tomarse con un grano de sal. – Davio

+2

RFC2616 ha estado muerto desde 2014. No se debe confiar en él como guía. Fue reemplazado, en su totalidad por 6 RFCs: 7230, 7231, 7232, 7233, 7234 y 7235. Elimine RFC 2616 de su cerebro. Solo existe como un artefacto histórico. –

Cuestiones relacionadas