Google Chrome gaat overbelaste webservers ontzien

Google Chrome experimenteert met een nieuwe functie die de impact van ddos-aanvallen en overbelasting moet helpen verminderen. Zodra de browser detecteert dat een server problemen heeft, neemt hij een stapje terug.

Om te voorkomen dat webservers die met een overdaad aan verkeer kampen nog zwaarder worden belast, heeft versie 12 van Google Chrome een functie aan boord die overbelaste servers ontziet. Als een webserver vier keer achter elkaar een http-statuscode met een waarde hoger dan 500 teruggeeft, treedt een beschermingsmechanisme in werking. Het gaat daarbij onder meer om 'internal server error'-, 'bad gateway'- en 'service unavailable'-meldingen.

Als het beschermingsmechanisme is geactiveerd, worden de gebruikers ervan verhinderd om al te vaak te refreshen. Aanvankelijk wordt het bezoeken van een getroffen webserver voor 0,7 seconde geblokkeerd, maar als de problemen aanhouden, groeit dit interval exponentieel. Uiteindelijk kunnen verzoeken naar een webserver voor 15 minuten worden geblokkeerd, als deze 48 minuten niet te bereiken is geweest. Daarna neemt het interval weer af.

Op deze manier wordt voorkomen dat webservers met trafficproblemen, bijvoorbeeld door een plotselinge piek in bezoekersaantallen of door een ddos-aanval, nog zwaarder worden belast. ConceivablyTech ontdekte de nieuwe feature, die is geïntegreerd in het canary-channel van Chrome, waar nieuwe features het eerst worden getest. De functie moet nu nog handmatig worden aangezet. Onbekend is of en wanneer deze standaard wordt ingeschakeld.

Reacties (75)

[ari3]

Tja, zolang het maar uit te schakelen is... Lijkt me voor web development en acceptatie testen enorm irritant als je browser gaat bepalen wat je wel/niet mag refreshen.

[Reactie gewijzigd door ari3 op 26 juli 2024 01:46]

[RanDX]

Voor een gemiddelde gebruiker is het wel handig, en zeker ook voor het bedrijf die de website(/server) host.

[com2,1ghz]

Nou liever niet, Stel je voor dat je online applicatie hebt die eruit ligt. Je belt naar de helpdesk en het blijkt dat ze even een service opnieuw op moesten starten. De helpdesk zeg dat het probleem opgelost is.
Wat doe je? F5 en krijg je weer die melding.

Serverside kan je dit makkelijk opvangen. Er is een third-party module voor apache waarmee dit kan opvangen.

[JanvdVeer]

Ook voor consumenten kan deze functie heel vervelend uitpakken. Als je bijvoorbeeld tickets wilt bestellen voor een zeer populair en groot event (noem een Defqon, Sensation White, etc) waarvan de tickets in een aantal minuten uitverkocht zijn, dan is deze functie ook erg onwenselijk omdat je constant moet refreshen om er tussen te komen.

Door te refreshen kom je er vaak sneller in, en maak je nog een kans om tickets te kunnen bestellen. Ben ervaringsdeskundige overigens

[Reactie gewijzigd door JanvdVeer op 26 juli 2024 01:46]

[Mellow Jack]

Lol ik ook... Vaak op maandag ochtend rond een uurtje of 9 refreshen voor het leven om een paar kaartjes te kunnen bestellen... 3 weken geleden ging een maatje van me het doen maar hij kreeg een time out op het moment dat hij wilde bestellen Helemaal in paniek belde hij op of ik het even wilde doen haha

Ik zie dit dus idd ook wel wat nadelen hebben voor de consumenten maar voor sites met een beperkte capaciteit kan het best handig zijn

[Reactie gewijzigd door Mellow Jack op 26 juli 2024 01:46]

[Muta]

onzin, je hoeft niet meer te refreshen, 1x refreshen om bijv. 13.00 om in de rij te komen. refresh je dan, sta je weer achteraan in de rij. dit heeft niks meer te maken met refreshen (en de site blijft het meestal gewoon doen, ondanks de drukte)

[hidden]

als je een piek verwacht kun je er wat aan doen.
10 loadbalancers en met elk 10 webservers om je te laten wachten.

[MindStorm]

Het probleem met een oplossing dmv een third-party module is dat de request dus wel daadwerkelijk door de server moet worden afgehandeld. Wellicht gaat het sneller/met minder resources, maar toch.

Ben het wel eens dat het voor helpdesks erg onhandig zou kunnen zijn...

[Bob]

Da's makkelijk te fiksen door een zinnige melding weer te geven ipv gwn 'niet bereikbaar'.

[latka]

Serverside kun je dit maar deels opvangen: het netwerk verkeer is al gegenereerd, als jij mod_bla op apache gebruikt zijn je firewal en loadbalancer nog wel steeds aan het werk. Het verkeer gewoon niet genereren is dan ook het enige wat echt werkt.

[willyb]

Het is inderdaad te hopen dat iets als SHIFT-f5 ofzo altijd even in iedergeval 1 url checkt.

[Remco Kramer]

Ik weet niet, maar helpdesken hebben meestal een wachttijd van 15 minuten tot een uur, lol.. dan zal die 0,7 seconden dat hij niet refreshed niet uitmaken hoor. Tenzij je loopt te spammen op de refresh knop natuurlijk..... Eén van de eerdere versies van Chrome had al zoiets.. als je op refresh drukte werd de refresh knop "uitgeschakeld" tot je met je muis ervanaf ging zodat je niet kon refresh spammen. Was hinderlijk in beging, maar als je het weet valt het eigenlijk best mee.

[YopY]

Omdat je 0,7 seconden tussen twee refreshes moet wachten? Pas als je een kwartier lang als een gek zit te F5-en van 'HEUHN KOM OP GEEF MIJ MIJN INTERNETS!' zul je langer dan een paar minuten moeten wachten.

En die apache module is leuk, maar de webserver (en tussenliggende hardware) moet nog steeds werk verrichten om jou je antwoord terug te geven, terwijl die het al moeilijk genoeg heeft.

[sygys]

Om nog maar niet te spreken van het feit dat die klootzakken bij anonymous de boel plat leggen en de normale gebruikers worden gekort. dat google hun 60.000 servers maar eens gebruikt om met bots de ddos aanval servers op te sporen en vervolgens die servers eens een een piek belasting te bezorgen. stelletje klojo's.

[Verwijderd]

Beetje frustratie?

Overigens heeft Google wel even meer dan 60.000 servers hoor, vermenigvuldig maar rustig met 10, dan kom je nog niet in de buurt.

Dit heeft er overigens niet echt veel mee te maken; jouw paar requestjes vallen in het niet vergeleken met een (bot) net van Anonymous.

[ritsjoena]

Tja, zolang het maar uit te schakelen is... Lijkt me voor web developement en acceptatie testen enrom irritant als je browser gaat bepalen wat je wel/niet mag refreshen.

Het mechanisme treedt alleen in werking als de server herhaaldelijk de genoemde foutcodes terugggeeft.

Je kan dus heel vaak kort achter elkaar refreshen voordat er problemen optreden. Zeker als er niet veel bezoek is op de gevraagde server.

[Eagle Creek]

Ik vind dit niet de functie van de webbrowser. Sterker nog, (zonder te rellen) vind ik dit bijna een aantasting van netneutraliteit, waarbij de toegang tot websites gefilterd wordt door partijen anders dan de website zelf.

Tevens draagt het bij aan het "iedereen-zijn-eigen-Google-beeld", waar naast andere zoekresultaten per persoon, nu ook sommige sites geblokkeerd worden voor personen terwijl anderen er wel op kunnen.

[vdvleon]

gelukkig gebruiken de meeste webdevelopers dan ook Firefox. maar idd, lijkt me erg irritant.

[Verwijderd]

Een fatsoenlijke webdeveloper gebruikt meerdere browsers om te testen (Webkit, Mozilla, IE, etc), dus jouw comment slaat nergens op en neigt naar een hoog 'fanboy-gehalte'.

[Robtimus]

+1

Een web developer die maar in 1 browser test is IMHO geen goede web developer. Fijn dat je code goed werkt in Firefox, maar als IE (8+), Chrome, Safari of Opera (samen met Fx de "grote 5") niet met je applicatie overweg kunnen ben je niet goed bezig. Daarom heb ik (niet eens pure web developer, meer algemeen) ze ook alle vijf geinstalleerd op mijn development machine.

[Verwijderd]

En het nare is dat er ook nog een groot aantal bezoekers rondzwerft die nog IE 6 en IE 7 gebruiken.
Helaas kun je die versies van Internet Explorer niet naast elkaar op één Windows installatie draaien.

Gelukkig heeft Microsoft al een tijd geleden Virtual Machines beschikbaar gesteld waarmee je je website onder IE 6,7 en 8 kunt testen:
http://www.microsoft.com/...d0a413c8ef&displaylang=en

Ook heeft Firefox met versie 4 een aantal dingen veranderd wat mij nu ook verplicht om de website ook onder versie 3 te testen en eventuele aanpassingen te maken.

Het leven van een web developer wordt er niet makkelijker op

[Verwijderd]

Vanaf IE8 kun je in IE7 simuleren:

In IE8 (of IE9), open de Developer Toolbar (F12). Dan rechtsbovenin de toolbalk die onderin opent staat Browsermodus en Documentmodus, die je kan wisselen tussen IE7 en IE8 (en IE9 als je die gebruikt).

Helaas bevat deze geen IE6, wat in het bedrijfsleven nog steeds aardig veel gebruikt wordt. Alhoewel IE7 wel veelal op IE6 qua rendering en diens 'bugs'.

Anders heb je altijd nog browsershots.org om je website te testen, zolang je geen interactieve javascript hoeft te testen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 01:46]

[psyBSD]

Helaas is de compatibility-mode van IE8 != IE7. Meer een soort IE7.5 - weer een nieuwe versie om tegen te testen.

[Sisko]

Ik ben sowieso tegen het testen in IE6, dat forceert het bedrijfsleven tenminste tot upgraden.

[Pouwiel]

Misschien is dit iets ?:

http://tredosoft.com/Multiple_IE

[YopY]

Helaas kun je die versies van Internet Explorer niet naast elkaar op één Windows installatie draaien.

Welles. Zoals aangegeven, je hebt IE 7 en 8 compatibility mode in de IE 8 / 9 developer console, en met MultipleIEs kun je IE6 (en als je dat echt wilt 3) er ook gewoon bij draaien.

[Batiatus]

Daar heb je zeker gelijk in.
De webdeveloper van mijn school heeft alleen Firefox gebruikt, waardoor Chrome, Safari en IE al niet werkten.
Het leuke was, dat je bij die pagina moet komen om te zien dat er wordt geadviseerd om Firefox te gebruiken. Inmiddels heeft hij het wel weer gefixt, maar het is wel zeer slecht als developer om geen support te bieden voor de andere drie grote browsers.

[RoelRoel]

Het kan principieel zijn. Ik krijg ook steeds meer de neiging om Internet Explorer te verbannen, maar dat is natuurlijk niet economisch verantwoord. Wel goed voor de ontwikkeling van internet, want IE is gekoppeld aan een versie van windows (9 alleen vanaf vista en 10 en alleen vanaf windows 7) vandaar dat Internet Explorer stilstand betekend omdat er altijd mensen zullen zijn die niet upgraden. Zonder dat een consument nadelen ondervind van zijn oude gare browsers zal ie noot updaten. Dus blijven we vast zitten want we willen geen marktaandeel verliezen of belerend overkomen...

[schaduw]

De iBood Hunt is getest met en geschikt bevonden voor:
Internet Explorer, Firefox, Opera.

U kunt helaas geen bezoek brengen aan de iBood Hunt met Chrome

[Verwijderd]

Dus als ik het goed begrijp: Wanneer een webserver het zwaar heeft zegt chrome tegen zijn gebruiker "Je mag er nu even niet op de server heeft het zwaar"? Maar waarom zou je dat als gebruiker willen?

[Roland684]

Ik denk dat het meer bedoeld is voor plugins, virussen en dergelijken die dan niet ongemerkt servers blijven overbelasten via chrome

[Verwijderd]

Het is bedoeld om ervoor te zorgen dat je niet perongeluk meehelpt een site naar de mallemoeren te helpen.

Virussen trekken zich hier noppes van aan, bovendien zijn er niet/nauwelijks (ik heb ze nog niet gezien) die Chrome gebruiken om iets vervelends te gaan doen. Het is verspilling van resources, dus je zou jezelf verraden.

Plugins zou in princiepe nog kunnen, maar de meeste plugins die zo slecht geschreven zijn verwijder je toch binne no-time. Het is vooral voor de F5'ertjes onder ons.

[com2,1ghz]

Ik begrijp dit niet. Je bedoelt dus dat als je pc geinfecteerd zou zijn met een virus dat chrome de verzoeken zou verhinderen?

[Verwijderd]

Om dezelfde reden dat Windows het maximale aantal half-open verbindingen beperkt (bij de Home versie tot maximaal 2, dacht ik).

Het gevolg hiervan is dat virussen minder snel kunnen voortplanten. Iets soortgelijks kun je stellen met deze techniek, die overbelaste servers niet eindeloos requests krijgen van normale browsers, als toch duidelijk is dat de server niet (goed) beschikbaar is. De vele requests ofwel F5's kunnen dan de situatie juist verslechteren. Het beste in zo'n geval is rustig wachten tot de server uit zijn piekbelasting komt en normale requests weer binnen redelijke tijd kan verwerken.

Alleen sommige power users zouden er last van kunnen hebben, voor alle andere gebruikers geldt dat ze er geen last van hebben, en de site-eigenaren wel veel profijt door ze te beschreven tegen agressieve browsers die enorm veel verkeer veroorzaken op het moment dat de server overbelast is.

[vinsterdamus]

omdat de kan dat je normaal op die server kan browsen dan veel groter wordt. Je wil niet een website bezoeken met 0 performance daar erger je jezelf alleen maar aan, een bericht met deze website is tijdelijk niet berijkbaar probeer het over een X aantal minuten nog eens is dan beter lijkt mij. Wanneer de server niet meer extra requests krijgt kan hij natuurlijk sneller weer recoveren dus een win win voor beide partijen.

[Niemand_Anders]

Dus als gebruiker zie je liever HTTP 500 error meldingen op je scherm?! Zolang de webserver geen fouten terug geeft, gaat het 'overload' bescherming ook niet aan.

Wat mij betreft mag het ook zonder meer in andere browsers worden geïmplementeerd.

[SinergyX]

Waarom wordt een internal 500 nu direct gelijk gezet aan een 'zware aanval' of erger? Een simpele scripterror kan zo'n 500 error ook gewoon geven, zonder dat er maar iets overbelast is.

Een DDOS of zware aanval zal niet per definitie zo'n 500 of gateway fout geven, beetje nutteloze feature zou het dan worden.

[SPee]

Zo'n Internal 5xx melding, geeft aan dat de server problemen heeft. De kans dat het vaker voorkomt is dan vrij groot.
Als die fout komt door een tijdelijke te grote belasting, dan kan het aantal verzoeken verlagen helpen om het totale te bereik publiek te vergroten. De spreiding wordt dan groter, waardoor de server meer 'lucht' krijgt om de aanvragen af te handelen.

[SinergyX]

Lucht van wat? De DDOS aanval stopt niet als er 'reguliere' bezoekers niet meer naar de website gaan, je houd niets tegen en je lost niets op. Het gros van de servers kan tijdens een DDOS aanval niet eens een bad gateway/500 meer terug sturen, je krijgt uiteindelijk gewoon een timeout.

Het zou pas nut hebben als de DDOS zou gedaan worden vanuit die Chrome browsers, dan wordt de DDOS zelf minder en heeft de server 'echt lucht'.

[Asteryz]

Veel DDOS aanvallen zijn niet sterk genoeg om een site down te kirjgen.

[Verwijderd]

De 500 error code geeft aan dat het probleem bij de server ligt, dus dat de server om wat voor reden dan ook de pagina op dat moment niet kan weergeven.
De kans is dus groot dat de server dus diezelfde pagina een paar seconde later ook niet kan weergeven.

Maar goed in eerste instantie wordt er maar 0,7 seconden lang een blokkade gebruikt:

Aanvankelijk wordt het bezoeken van een getroffen webserver voor 0,7 seconde geblokkeerd, maar als de problemen aanhouden, groeit deze interval exponentieel. Uiteindelijk kunnen verzoeken naar een webserver voor 15 minuten worden geblokkeerd, als deze 48 minuten niet te bereiken is geweest. Daarna neemt de interval weer af.

Dit zul je alleen merken als je al aan het F5'en bent, bij een normaal surfend mens zal het zeker langer duren dan 0,7 seconden om te bedenken dat je de pagina wilt herladen en daarna op F5 te drukken.

Dit is dus eigenlijk een goede functie om de gebruiker tegen zichzelf te beschermen.
Stel je belt een klantenservice en het is daar zo druk dat je de melding krijgt: "momenteel kampen wij met enorme drukte, wij verzoeken u op een later moment terug te bellen. de verbinding wordt nu verbroken".
Dan bel je ook niet 10 seconden later weer terug, dan wacht je eerst even.

In dit geval doet Chrome dat ook voor je.

[ACM]

Er staat natuurlijk dat er meerdere 500's moeten komen. Maar het is idd niet heel zinvol om het dan onder de noemer van een DDoS te scharen, want iig bij de DDoS-aanvallen die wij ontvingen werden onze webservers of loadbalancers zelden in staat gesteld daadwerkelijk iets van een 500 terug te sturen

[Scotix]

Ik denk dat de load die word veroorzaakt door F5-ende bezoekers minimaal is tijdens een DDOS aanval. Want dat zijn toch meestal botnets? En die maken neem ik aan geen gebruik van deze feature

Maar alle kleine beetjes helpen.

[DRaakje]

Niet altijd botnets of DDOS.

http://en.wikipedia.org/wiki/Slashdot_effect

Je wilt het nu ook nog wel eens zien bij sites die op tweakers.net/nu.nl/slashdot staan dat die vervolgens onderuit gaan.

Paar jaar terug was er de allereerste preview van 1 of andere CPU en er was zelfs een posting op tweakers hoe ze lieten zien welk effect het had, en dat ze trots waren dat alles soepel was blijven lopen.

[BartOtten]

Als webmasters/systeembeheerders betere cache-mogelijkheden zouden gebruiken dan is een website bijna niet te Slashdotten volgens mij. Hield een jaar of 7 geleden nog Releases4U.com in de lucht op een shared hosting-account en als die internationaal in het nieuws kwam dan werd het ook ernstig druk. Kwestie van iets meer static presenteren. De kans dat het zelfs met een 'simpele' pagina de mist in gaat is vrij klein volgens mij.

[hackerhater]

zelfs dan kan het gebeuren. Je hebt maar zoveel serverkracht en zoveel bandbreedte tot je beschikking.

Krijg je meer traffic dan dat gaat je site neer. Wel is het uiteraard zo dat je een stuk meer aan kan met statische pagina's dan met dynamische

[Goderic]

Bij een DDOS aanval zal het inderdaad minimaal zijn, maar bij het slashdot effect kan het wel nuttig zijn.

[ieperlingetje]

Voor extensies en eventueel AJAX calls lijkt het me een handige functie (het is nutteloos dataverkeer) maar de gebruiker moeten ze er niet mee gaan lastigvallen.

[Verwijderd]

Heel handig, als ze het gaan combineren met 'in cache'.
Stel me zo voor dat je Tweakers probeert te bezoeken, je een berichtje krijgt:

Deze website lijkt op dit moment overbelast. Bekijk hier een momentopname van hoe deze website eruitzag op 19 april 2011 11:20:44 GMT.

Heerlijk!

[Reactie gewijzigd door Verwijderd op 26 juli 2024 01:46]

[Finraziel]

Dit werkt natuurlijk alleen als ALLE browsers dit gaan doen... Anders ben je als chrome gebruiker gewoon de zak die er niet op mag terwijl de mensen met andere browsers lekker door rammen.

edit: Typo...

[Reactie gewijzigd door Finraziel op 26 juli 2024 01:46]

[zeezuiper]

Kansloos verhaal als je een concert ticket wilt boeken van een populaire band.

[themole]

Idd, dan moet je soms door een haperende server heenbeuken. Dan is deze functie zeer irritant. Als ie maar uit te zetten is.

[RocketKoen]

Maar als voldoende mensen deze functie hebben, raakt de webserver niet overbelast en kun je gewoon in 1 keer je kaartje bestellen.

Die haperende webserver wordt veroorzaakt door mensen die F5 aan het spammen zijn rond de tijd dat de verkoop zal starten omdat ze het eerste een kaartje willen bestellen. Gevolg is dat iedereen die daarna komt ook op F5 moet spammen omdat de website slecht laad. En hierdoor blijft de website overbelast.

[Verwijderd]

Nou nee hoor. Ticketsites houden over het algemeen gewoon geen rekening met bezoekerspieken als populaire evenementen aantreden.
De serveromgeving waar dat hele apparaat op loopt is er domweg niet op berekend.

Daar gaan mensen van F5en, het is dus een gevolg geen oorzaak.

[Mellow Jack]

Maar dat zorgt dr wel weer voor dat je niet om 9 uur je kaartje kan kopen maar pas om 9:30 Toch weer een mogelijkheid waarbij de kaartjes uitverkocht kunnen raken

[Verwijderd]

Geeft wel de tweaker (de persoon die wel weet van deze functie en het nut hem uit te zetten) meer kans op kaarten(Y)

[The Jester]

Leuk als je website ge-SlashDot wordt...

[sygys]

Kan een webserver van een desbetreffende website niet zelf bepalen wanneer het te veel is en bijvoorbeeld bepaalde spammers herkennen en weren? dit is toch veel efficienter dan een te omzeilen browser functie?

[ACM]

De mate van rekenwerk die je moet besteden aan het herkennen en weren van zware bezoekers is nou niet bepaald een triviale hoeveelheid... Dus het kan zomaar zijn dat je herkenning zelf een deel van je bottleneck gaat vormen

[flabber]

Kan een webserver van een desbetreffende website niet zelf bepalen wanneer het te veel is

Dat doet de webserver al: hij stuurt namelijk een duidelijke (...) foutcode terug.
De webbrowser helpt je nu alleen een handje om daar op de juiste methiode mee om te gaan!

[Alpha89]

Shit, geen f5en meer om bijvoorbeeld de iPad op launch te bestellen :((

[Asteryz]

Zolang de servers van apple het blijven doen is er niks aan de hand.