De maximumaantal verbindingen per server van Google Chrome tot meer dan 6 verhogen

Voor zover ik weet, op het huidige moment, eind 2011 blijft de maximumlimiet per serverlimiet 6. Corrigeer me als ik het mis heb. Dit is erg dat we dit niet gemakkelijk kunnen oplossen zoals in Firefox. Voor zover ik weet, is deze waarde hard gecodeerd.

Een van de oplossingen is om de Chromium-bronnen te downloaden en opnieuw te bouwen. Is er een eenvoudigere oplossing?

Is er een lastige manier om dit te hacken zonder een dozijn mirror-domeinen te maken?

Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The JavaScript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the JavaScript app will take days.

Offtopic: kent u nog andere dingen die kunnen worden aangepast in mijn concrete situatie?

39
Hier is een link naar een chrome dev die WAAROM 6 verbindingen uitlegt: bugs .chromium.org/p/chroom/issues/detail? id = 85323 # c7
toegevoegd de auteur Michael Cole, de bron
Je kunt ook enkele van de afbeeldingen op een andere server plaatsen voor statische inhoud en geen enkel blokkeerpunt hebben.
toegevoegd de auteur Dean J, de bron
Als we de "willekeurige modus" aan de add-ons van SwitchySharp zouden kunnen toevoegen, kunnen we 25 aanvragen tegelijkertijd in 25 proxypoortverbindingen scheiden. Het zou rond de max-connections-per-server limiet moeten werken.
toegevoegd de auteur diyism, de bron
Nou, je kunt firefox gebruiken en in about: config de network.http.max-persistent-connections-per-server config configureren
toegevoegd de auteur joecks, de bron
dit lijkt het open verbeteringsverzoek te zijn, maar helaas kijken ze er niet naar uit om de configuratieoptie code.google.com/p/chromium/issues/detail?id=85323
toegevoegd de auteur jamshid, de bron
Sommige links in deze vraag-en-antwoord discussie zijn verouderd. Hier is een archiefkoppeling van waarom browsers/klanten dwingen max. Verbindingen per server af: web.archive.org/web/20101228053711/http://… Let ook op: HTTP 2 multiplexen kan dit veel helpen en wordt breder ondersteund sinds deze vraag voor het eerst werd gesteld.
toegevoegd de auteur groovecoder, de bron

5 antwoord

IE is nog erger met 2 verbindingen per domeinlimiet. Maar ik zou niet vertrouwen op het herstellen van clientbrowsers. Zelfs als u de controle over hen hebt, worden browsers zoals Chrome automatisch bijgewerkt en kan een toekomstige versie zich anders gedragen dan u verwacht. Ik zou me concentreren op het oplossen van het probleem in uw systeemontwerp.

Jouw keuzes zijn om:

  1. Laad de afbeeldingen opeenvolgend zodat slechts 1 of 2 XHR-oproepen tegelijk actief zijn (gebruik de succesgebeurtenis van de vorige afbeelding om te controleren of er meer afbeeldingen zijn om te downloaden en de volgende aanvraag te starten).

  2. Gebruik subdomeinen zoals serverA.myphotoserver.com en serverB.myphotoserver.com. Elk subdomein heeft zijn eigen pool voor verbindingslimieten. Dit betekent dat je 2 verzoeken zou kunnen hebben om naar 5 verschillende subdomeinen te gaan als je dat zou willen. Het nadeel is dat de foto's in de cache worden opgeslagen op basis van deze subdomeinen. Tussen haakjes, dit hoeven geen "mirror" -domeinen te zijn, je kunt gewoon extra DNS-verwijzingen naar exact dezelfde website/server maken. Dit betekent dat u geen hoofdpijn hebt bij het beheer van veel servers, slechts één server met veel DNS-records.

25
toegevoegd
Wat ik ga doen: 1) verhoog TTL, 2) controleer afbeeldingen in een reeks met img.complete, 3) plaats urgente feeds in een apart domein
toegevoegd de auteur Dan, de bron
3) En tel het aantal open verbindingen in mijn bibliotheek (dat is eenvoudig!). Afbeeldingen hebben honger en kunnen tot 20 seconden downloaden, dus liet ik er slechts 4 tegelijk over (gelijktijdig een ketting plaatsen), waardoor er 2 kanalen voor feeds overblijven.
toegevoegd de auteur Dan, de bron

BTW, HTTP 1/1 specificatie (RFC2616) suggereert niet meer dan 2 verbindingen per server.

Clients die permanente verbindingen gebruiken MOET het aantal gelijktijdige verbindingen beperken dat ze onderhouden naar een bepaalde server. Een client voor één gebruiker MOET NIET meer dan 2 verbindingen onderhouden met een server of proxy. Een proxy MOET maximaal 2 * N verbindingen gebruiken met een andere server of proxy, waarbij N het aantal gelijktijdig actieve gebruikers is. Deze richtlijnen zijn bedoeld om HTTP-reactietijden te verbeteren en congestie te voorkomen.

3
toegevoegd
Ja, maar RFC2616 is 18 jaar oud, dus zijn aanbevelingen moeten met een korrel zout worden genomen.
toegevoegd de auteur Davio, de bron
RFC2616 is sinds 2014 dood. Er moet niet op worden vertrouwd als leidraad. Het werd in zijn geheel vervangen door 6 RFC's: 7230, 7231,7232,7233,7234 en 7235. Verwijder RFC 2616 uit je hersenen. Het bestaat alleen als een historisch artefact.
toegevoegd de auteur K. Alan Bates, de bron

just adding this for the reference. I came across this article of how to increase the max downloads per domain in Google chrome http://www.ehow.com/how_12169537_change-number-simultaneous-downloads-chrome.html

2
toegevoegd

Er lijkt geen externe manier te zijn om het gedrag van de uitvoerbare bestanden te hacken.

U zou de Chrome (ium) -uitvoerbare bestanden kunnen wijzigen, omdat deze informatie duidelijk is gecompileerd. Die aanpak brengt veel problemen met ondersteuning en automatische upgrades met zich mee, dus u wilt waarschijnlijk voorkomen dat u dat doet. U moet ook begrijpen hoe u de wijzigingen kunt aanbrengen naar de binaire bestanden, wat niet de meeste mensen zijn kan over een paar dagen weer ophalen.

Als u uw eigen browser compileert, creëert u een ondersteuningsprobleem voor uzelf omdat u vastzit aan een specifieke revisie. Als u nieuwe functies en bugfixes wilt ontvangen, moet u deze opnieuw compileren. Dit alles houdt in dat Chrome-ontwikkeling wordt gevolgd voor fouten en breuken worden opgebouwd - niet iets dat een webontwikkelaar zou moeten doen.

Ik zou voorlopig het advies van @ BenSwayne volgen, maar het is misschien de moeite waard om na te denken over het doen van een deel van het werk buiten de client (de webbrowser) en het in een achtergrondproces te plaatsen dat op dezelfde of verschillende machines draait. Dit proces kan veel meer verbindingen verwerken en u bent alleen verantwoordelijk voor het terughalen van de gegevens. Omdat het lokaal (ish) is, krijg je snel resultaten, zelfs met minimale verbindingen.

1
toegevoegd
Dit antwoord is niet nuttig. Uitvoerbare bestanden kunnen altijd worden bewerkt.
toegevoegd de auteur Michael Cole, de bron
Ik beveel dit antwoord aan. U moet een howto maken over hoe u de binary van dit effect kunt bewerken of zelfs hoe u er een geheugeneditor voor gebruikt. Laat een trainer op een cheats-site vrijgeven voor Chrome om dit soort dingen te doen. Chrome-ontwikkelaars janken over mensen die niet-ondersteunde configuraties maken, zodat dingen een absolute hel voor hen kunnen maken.
toegevoegd de auteur jgmjgm, de bron
Ik denk dat ik misschien een grapje gemaakt heb, maar ik heb het een tijdje terug gelukt om dit met kanarie te omzeilen. Ik denk dat ik cross-domeinebeveiliging uitschakelde of zoiets en dan maar duizend subdomeinen aan dezelfde host creëerde.
toegevoegd de auteur jgmjgm, de bron
@jgmjgm: Ik wilde al heel lang dit soort dingen doen in Chrom {e, ium}, om niet-verwante redenen. Ik weet helaas vrijwel niets over assembly-taal, C ++ demontage, enz. Ik weet wel dat dit meer dan symbolen zou vereisen, ik zou in staat moeten zijn om setting/optie-data te vinden in officiële + distro-gecompileerde + door de gebruiker gecompileerde binaries op Linux, dan zijn er nog 2 andere platformen waar rekening mee gehouden moet worden. (Ik zou alleen Linux testen.) Waar/hoe zou je aanbevelen dat ik mijn hoofd tegen deze muur begin te hameren? : P
toegevoegd de auteur i336_, de bron

Ik weet niet dat je het buiten Chrome in Windows kunt doen in Chrome - op sommige Google-sites is te zien dat Chrome (en dus mogelijk Chromium) mogelijk goed reageert op een bepaalde registerhack.

Als u echter op zoek bent naar een eenvoudige oplossing zonder uw codebasis aan te passen, hebt u dan rekening gehouden met Firefox? In de about: config kunt u zoeken naar "network.http.max" en er zijn enkele waarden die zeker de moeite van het bekijken waard zijn.

Ook voor een apparaat dat niet beweegt (dat wil zeggen dat het op een vaste locatie is gemonteerd), zou je moeten overwegen om geen Wi-Fi te gebruiken (zelfs een Home-plug zou een stapje hoger zijn voor zover latency/stabiliteit/gedropte verbindingen gaan) .

0
toegevoegd
about: config :: netwerk.http.max-persistent-connections-per-se & zwnj; rver zag er veelbelovend uit, maar leek geen effect te hebben voor mijn gelijktijdige uploadtest.
toegevoegd de auteur nobar, de bron