Google draagt Spdy-protocol voor bij IETF
Google heeft Spdy, een protocol dat deels het http-protocol vervangt en beter zou presteren, ingediend bij de Internet Engineering Task Force. De zoekgigant hoopt dat Spdy door de organisatie wordt omarmd als een internetstandaard.
De Spdy-specificatie werd in 2009 door Google gepubliceerd als een opensource-netwerkprotocol. Het protocol is onder andere geïmplementeerd in de Chrome-browser, terwijl Firefox vanaf versie 11 Spdy zal ondersteunen. Spdy heeft tot doel om websites binnen de browser sneller in te laden door aanvullingen op het http-protocol. Zo wordt datacompressie toegepast op de header en met behulp van multiplexing kunnen een onbeperkt aantal requests over één verbinding worden gemaakt. Ook wordt prioritering uitgevoerd en het is mogelijk om data vanaf een server naar een client te pushen zonder dat de browser een request heeft gestuurd.
Google, dat al langer aangaf er naar te streven om van Spdy een internetstandaard te maken, heeft zijn creatie inmiddels voorgedragen aan de IETF. Deze organisatie is al bezig met het http 2.0-protocol en de kans is aanwezig dat Spdy - inmiddels aangekomen bij versie 3.0 - of delen daarvan in deze specificatie worden opgenomen. IETF-leden kunnen tot 4 augustus commentaar indienen op de 'draft-mbelshe-httpbis-spdy-00'-draft.
Reacties (54)
Applaus, SPDY zou het complete 'request' probleem bij websites oplossen, waardoor sites x maal sneller laden!
Als de betreffende webserver niet genoeg resources heeft, zal je nog steeds een request probleem houden.'request' probleem bij websites oplossen
Enige voordeel van alles over 1 verbinding binnen te halen, is dat je de hele handshake maar 1 maal hoeft uit te voeren ipv meerdere keer. Ja hier zit laadtijd winst in.
Ik weet nog niet of als beheerder blij moet worden van een sessie die constant open staat.
Te meer omdat de server software goed geschreven moet zijn, er mogen o.a. geen memory leaks inzitten.
Nu is het vaak zo, dat een child van de parent na een x aantal request afgeschoten wordt om vervangen te worden door een nieuwe, waardoor je o.a. minder snel last hebt van memory leaks.
Door het open houden van een sessie, kan je gemakkelijker er voor zorgen dat andere mensen geen verbinding meer kunnen maken of wel aan de server kant zullen we de sessie wel vaker dicht afschieten.
Betekent dat dan ook dat DoS aanvallen makkelijker worden?
Ik denk het wel. Als je kijkt wat de verplichte onderdelen van de standaard zijn dan zie je bijvoorbeeld dat zlib compressie verplicht is, en 2 contexts per stream vereist. Een spdy-stream is dan al snel een zwaardere belasting dan een TCP connectie. Vervolgens kan je meerdere streams over 1 connectie hebben lopen, en is het nog steeds mogelijk om meerdere TCP connecties naar een server op te zetten.
Natuurlijk kan je als spdy een mainstream protocol wordt dat allemaal weer geen tunen en komen er nieuwe knoppen om aan te draaien in firewalls en webservers, maar het blijft een complexere situatie met een extra multiplicator.
Natuurlijk kan je als spdy een mainstream protocol wordt dat allemaal weer geen tunen en komen er nieuwe knoppen om aan te draaien in firewalls en webservers, maar het blijft een complexere situatie met een extra multiplicator.
De populaire servers gebruiken sowieso al http compressie (welke gebruikmaakt van zlib) om bandbreedte uit te sparen. De hedendaagse CPU's kunnen het wel aan.
Voorbeeld rechtstreeks uit de antwoordheaders die Firebug mij weet te geven van deze pagina waar we ons op het moment op bevinden:
"Content-Encoding gzip"
Voorbeeld rechtstreeks uit de antwoordheaders die Firebug mij weet te geven van deze pagina waar we ons op het moment op bevinden:
"Content-Encoding gzip"
Eigenlijk niet, het wordt zelfs lastiger als ik het zo lees:
Een DoS aanval betekend zoveel aanvragen / verzoeken 1 kant op sturen dat het systeem zoveel resources gebruikt dat het niet meer beschikbaar is. In het geval van een memory leak is het als ik het zo bekijk ook niet eenvoudiger geworden:
Probleem bij het doen van DoS aanvallen met een dergelijke techniek is dat je nog maar 1 verbinding open hebt naar de server, in het HTTP protocol zijn dat er meerdere.
Het is door meerdere verbindingen vanaf 1 plek dus makkelijker meer resources te vragen door heel vaak bepaalde data/ pagina's op te vragen.
Omdat je maar 1 stream open hebt zal je minder snel een hele serie requests tegelijk doen, of is het in elk geval beter te channelen en monitoren. Iemand/ een verbinding die enorme hoeveelheden aan requests doen, kan je eenvoudiger limiteren omdat je dat maar bij 1 verbinding hoeft te doen. Ik denk dat in zoverre de beveiliging ook beter moet kunnen worden.
Een DoS aanval betekend zoveel aanvragen / verzoeken 1 kant op sturen dat het systeem zoveel resources gebruikt dat het niet meer beschikbaar is. In het geval van een memory leak is het als ik het zo bekijk ook niet eenvoudiger geworden:
Probleem bij het doen van DoS aanvallen met een dergelijke techniek is dat je nog maar 1 verbinding open hebt naar de server, in het HTTP protocol zijn dat er meerdere.
Het is door meerdere verbindingen vanaf 1 plek dus makkelijker meer resources te vragen door heel vaak bepaalde data/ pagina's op te vragen.
Omdat je maar 1 stream open hebt zal je minder snel een hele serie requests tegelijk doen, of is het in elk geval beter te channelen en monitoren. Iemand/ een verbinding die enorme hoeveelheden aan requests doen, kan je eenvoudiger limiteren omdat je dat maar bij 1 verbinding hoeft te doen. Ik denk dat in zoverre de beveiliging ook beter moet kunnen worden.
Dat er meerdere requests over een verbinding gedaan kunnen worden betekent natuurlijk niet dat er maar één verbinding gemaakt hoeft te worden; de client kan nog steeds meerdere verbindingen opzetten om zo te DoS'en.
[Reactie gewijzigd door MadEgg op zaterdag 25 februari 2012 18:08]
Als je er vanuit gaat dat clients maar 1 verbinding openen voor alles request, kun je verbindingen per IP limiteren tot 1, desnoods door middel van een firewall, maar zelfs al binnen de webserver, waarmee je dos aanvallen dus voorkomt. Met 1 verbinding kun je immers geen dos aanval uitvoeren.
Dat kan. En wat dan als het een thuisnetwerk is waar meerdere mensen via NAT verbinding met internet hebben? Dan zouden die dus niet dezelfde site kunnen bekijken vanaf hun eigen PC.
Of dezelfde site openen in meerdere browsers, dat lukt dan ook niet meer. Niet echt dingen waar we op zitten te wachten lijkt me.
Of dezelfde site openen in meerdere browsers, dat lukt dan ook niet meer. Niet echt dingen waar we op zitten te wachten lijkt me.
Da's gelukkig alleen een probleem als je slechts een enkele server hebt - in het geval van Google hebben ze honderdduizenden (?) webservers, die elk tienduizenden verbindingen tegelijkertijd aankunnen. Het verdeelt zich daar wel over.Door het open houden van een sessie, kan je gemakkelijker er voor zorgen dat andere mensen geen verbinding meer kunnen maken of wel aan de server kant zullen we de sessie wel vaker dicht afschieten.
Sowieso loopt het max aantal connecties dat een server zoals Node.js aankan in de tienduizenden (vaak is het slechts gelimiteerd aan het max aantal file descriptors in Linux). Doe dat eens over een serverpark van 50 en je kunt sowieso een half miljoen persistente connecties aan.
honderdduizenden (?), google heeft er vermoedelijk meer dat 1.000.000. zie hier.
Het lijkt me vrij veilig om aan te nemen dat dat voornamelijk backend servers zijn. Voor het grootste deel heeft spdy dus totaal geen nut.
gelukkig heeft elke website zoveel servers te beschikking 
Meeste bedrijven hebben idd 1+N applicatie servers achter een LB hangen. Maar het over grote deel heeft echt niet meer dan 2.
Node.js kan misschien wel 1.000.000 request aan.
Dat kan bash hoogs waarschijnlijk ook.
De daad werkelijke applicatie moet zoveel request ook wel aankunnen.
Meeste bedrijven hebben idd 1+N applicatie servers achter een LB hangen. Maar het over grote deel heeft echt niet meer dan 2.
Node.js kan misschien wel 1.000.000 request aan.
Dat kan bash hoogs waarschijnlijk ook.
De daad werkelijke applicatie moet zoveel request ook wel aankunnen.
Http heeft ook al persistent connections, dus wat winnen we hier nu mee?
Ik denk dat google met spdy niet echt als activiteit heeft informatie verzamelen. Maar snelheid. (Als je meer informatie gaat verzamelen wordt het langzamer.)
Dit valt inderdaad net zoals bijvoorbeeld het vrijgeven van de V8 Javascript engine onder het verbeteren van de snelheid van de web. Hoe sneller het is, hoe leuker mensen het vinden met als gevolgd dat ze zich vaker/meer online bevinden. Hoe meer mensen er online zijn hoe groter de winst voor Google is 
.
Google heeft er simpelweg belang bij om het internet zo aantrekkelijk mogelijk te maken, dat hoeft niet direct van invloed te zijn op je eigen privacy.
.Google heeft er simpelweg belang bij om het internet zo aantrekkelijk mogelijk te maken, dat hoeft niet direct van invloed te zijn op je eigen privacy.
gaat dit dan ook nog in je bandbreedte verbruik iets uitmaken ?
In de huidige implementaties is SSL vereist, en dat komt met enige overhead qua CPU cycles. Qua bandbreedte zou er juist voordeel te halen moeten zijn, daar er evenveel in minder pakketjes kan wordem gestopt, door het niet afsluiten van een sessie of verbinding.
Voor de gebruiker: Ja, maar geen gigabytes. Dat headers bijvoorbeeld gecomprimeerd worden en er minder overhead is door bestaande verbindingen te kunnen hergebruiken zal zeker uitmaken. Voor de aanbieder - zoals Google in dit geval - zal het echter nog veel meer uitmaken.
Ik noem maar wat, 100 bytes besparing per header. Gmail openen kost al gauw 70 requests vanuit mijn browser, en zolang hij aanstaat komen er ook langzamaan meer bij. Da's 7 KB voor één bezoek. Doe dat eens maal tien miljoen + de rest.
Ik noem maar wat, 100 bytes besparing per header. Gmail openen kost al gauw 70 requests vanuit mijn browser, en zolang hij aanstaat komen er ook langzamaan meer bij. Da's 7 KB voor één bezoek. Doe dat eens maal tien miljoen + de rest.
Bestaande verbindingen hergebruiken in een non-argument, dat heeft http ook al sinds zijn bestaan in de vorm van persistent connections. Alleen niet gemultiplexed, dus het is de een na de andere ipv een aantal tegelijk. Maar of dat nou een merkbaar verschil gaat geven...
En compressie van de header (compressie van de data kon al) is ook maar een druppel op een gloeiende plaat. Het valt gewoon in het niet bij de te transporteren data.
En compressie van de header (compressie van de data kon al) is ook maar een druppel op een gloeiende plaat. Het valt gewoon in het niet bij de te transporteren data.
Spdy staat dan wel voor Speedy, ik lees toch keer op keer Spy (helemaal icm google...) Ik ben toch op de een of andere manier een beetje wantrouwend bij dit soort zaken..
[Reactie gewijzigd door NitSuA op vrijdag 24 februari 2012 18:55]
Je kan gewoon het hele protocolvoorstel nalezen en zien of er echt iets is om je zorgen over te maken. En denk je echt dat de IETF spy-provisions in een protocol gaat toestaan?
En waarom niet ? Denk je dat ze bij de IETF allemaal heiligen en raket-geleerden zijn of zo ?
Dit is iets waar ik me zorgen over maak. Prioritering gaat niet samen met net-neutraliteit, en pushen zonder dat er een request is gestuurd, zit ik ook niet op te wachten.Ook wordt prioritering uitgevoerd en het is mogelijk om data vanaf een server naar een client te pushen zonder dat de browser een request heeft gestuurd.
tja als je het zo zegt dan is een spamfilter ook tegen de net-neutraliteit?
hogere prio toekennen wordt een zegen voor VOIP
hogere prio toekennen wordt een zegen voor VOIP
Hogere prio wordt een zegen voor file sharing en dus de dood voor VOIP.
Dus gaat er een soort politie (=provider) komen die bepaalde diensten, tegen betaling, voorrang gaat geven. Als je niet betaald wordt jouw product dus takketraag.
Dus gaat er een soort politie (=provider) komen die bepaalde diensten, tegen betaling, voorrang gaat geven. Als je niet betaald wordt jouw product dus takketraag.
[Reactie gewijzigd door Roland684 op zondag 26 februari 2012 12:47]
Dit lijkt mij het einde te betekenen van plugins zoals adblock e.d.
Hierbij worden door de client telkens requests niet uitgevoerd indien deze naar reclame zouden verwijzen.
Als nu de webserver zelf dmv pushing bepaalt wat er op de client getoond moet worden, dan lijkt mij het internet de volgende jaren 1 grote flashy reclameboel te worden.
Knap gezien van Google!
Ik hoop dat ik er grandioos naast zit met mijn toekomstvoorspelling...
Hierbij worden door de client telkens requests niet uitgevoerd indien deze naar reclame zouden verwijzen.
Als nu de webserver zelf dmv pushing bepaalt wat er op de client getoond moet worden, dan lijkt mij het internet de volgende jaren 1 grote flashy reclameboel te worden.
Knap gezien van Google!
Ik hoop dat ik er grandioos naast zit met mijn toekomstvoorspelling...
reclame word geblokkeerd door de servers van de reclamebedrijven te blokkeren. Er zijn maar zeer weinig sites die zelf ook de hosting van de reclame verzorgen. Webservers kunnen dan wel proberen te pushen, als jouw PC zegt dat het geen pakketjes van dat IP wenst te ontvangen dan komt er niks binnen.
Het uiteindelijke renderen gebeurd volledig op je eigen client, dus plugins zullen altijd zulke zaken kunnen blokkeren. Al wordt er gekeken naar de structuur van de inhoud of bepaalde sleutelwoorden, men zal altijd wel een manier vinden om reclame te blokkeren.
Dus ik denk dat het veilig is om te stellen dat je je daar geen zorgen over hoeft te maken, en gelukkig maar!
Dus ik denk dat het veilig is om te stellen dat je je daar geen zorgen over hoeft te maken, en gelukkig maar!
Stel dat normale data en ads van dezelfde server komen, moet je (door pushing) al eerst alle data gaan downloaden, en dan pas filteren. Dan krijg je de ads niet te zien, maar je hebt nog steeds laadtijd verloren door ze te downloaden, wat niet zo is bij HTTP.
[Reactie gewijzigd door lesderid op vrijdag 24 februari 2012 20:44]
En je bent een stuk van je data allowance voor de maand kwijt vanwege adds die je toch niet ziet of wilt zien.
Het ongevraagd pushen van wat voor content dan ook is iets waar ik met wat scheve ogen naar kijk.
Het ongevraagd pushen van wat voor content dan ook is iets waar ik met wat scheve ogen naar kijk.
Mooi gezien... je gaat van pull naar push, dus ja, je kunt niet meer kiezen wat je over je heen duwt krijgt. Interessante kijk. Betwijfel of de techneuten die dit bedachten bij Google ook over de commerciële kansen nagedacht hebben. Maar zeker een mooi bijeffect.
Flashy reclame valt ook wel mee, tweakers.net is nog één van de grootste offenders op dit gebied onder de sites die ik bezoek. Ik bezoek ook een site die zelfs dynamisch algelange je scrolled via JS maar reclame blijft toevoegen aan de zijkant om de ruimte te vullen en daar stoor ik mij geheel niet aan. Het zijn allemaal stilstaande plaatjes van producten en dergelijke, wat je bij tweakers soms ziet als bijvoorbeeld zo een vlag onder in het beeld die groter wordt als je eroverheen hovered vind ik wel iritant.
Maar goed, ik gebruik totaal geen adblocker en het is nog goed vertoeven op het internet. Gebruik op mijn Linux PCs echter wel flashblock. Ik ga niet de CPU flink laten zweten voor de meest iritante vorm van reclame, flash & linux blijft een niet-optimale combinatie.
* Xthemes.us gebruikt geen adblocker omdat hij niet de inkomstenbron van sites wil wegnemen - een bewuste keuze dus
Maar goed, ik gebruik totaal geen adblocker en het is nog goed vertoeven op het internet. Gebruik op mijn Linux PCs echter wel flashblock. Ik ga niet de CPU flink laten zweten voor de meest iritante vorm van reclame, flash & linux blijft een niet-optimale combinatie.
* Xthemes.us gebruikt geen adblocker omdat hij niet de inkomstenbron van sites wil wegnemen - een bewuste keuze dus
Zijn er voorbeelden van dit soort pagina's? Is het dan zoiets als spdy://www.webpagina.nl?
Of zie ik het nu verkeerd?
Of zie ik het nu verkeerd?
http://www.gmail.com en veel (alle?) andere websites van Google.
spdy is een aanvulling op het http-protocol en heeft dus geen eigen protocol-aanroep (of hoe noem je http://, ftp:// eigenlijk?) nodig.
spdy is een aanvulling op het http-protocol en heeft dus geen eigen protocol-aanroep (of hoe noem je http://, ftp:// eigenlijk?) nodig.
Ik vroeg me ook al af hoe de browser weet dat hij SPDY kan gebruiken ipv HTTP. Na een tijdje gezocht te hebben vond ik het: TLS Next Protocol Negotiation (http://technotes.googlecode.com/git/nextprotoneg.html).
In de basis komt het er op neer dat wanneer je een HTTPS pagina als gmail.com benadert er in de TLS communicatie afgesproken wordt of er SPDY of HTTP gebruikt wordt. Dit wordt onder meer gebruikt door de Apache implementatie MOD-SPDY: (http://code.google.com/p/mod-spdy/wiki/GettingStarted).
In de basis komt het er op neer dat wanneer je een HTTPS pagina als gmail.com benadert er in de TLS communicatie afgesproken wordt of er SPDY of HTTP gebruikt wordt. Dit wordt onder meer gebruikt door de Apache implementatie MOD-SPDY: (http://code.google.com/p/mod-spdy/wiki/GettingStarted).
Is snelheid het enige voordeel van Spdy t.o.v http?
SSL is standaard, dus het is veiliger:)
SSL is ook standaard bij https
Hmm, dit lijkt me als eindgebruiker toch niet echt wenselijk?Ook wordt prioritering uitgevoerd en het is mogelijk om data vanaf een server naar een client te pushen zonder dat de browser een request heeft gestuurd.
Of op zijn minst een extra risico ivm security...
Mooi lek in een browser en de benodigde data om het te misbruiken kan zonder request van de browser verstuurd worden.
Hopelijk (waarschijnlijk) hebben de mensen van google hier ook wel aan gedacht...
Ik hoop dat de IETF kritisch kijkt en niet als kip zonder kop de hele spdy overneemt. Ik vertrouw Google niet zo en als Google dan álles wat met http te maken heeft gaat overnemen zit ik daar niet zo op te wachten.
Hoezo paranoia? 
Google heeft een gigantische praktijkervaring met het HTTP protocol en kan dus daar vanuit die verbeteringen aandragen. En dat doen ze dus ook.
Het leunt gewoon op hun motto:
"Don't be evil."
Ik weet dat het bij sommige dingen die ze doen er niet vanaf te grijpen is, maar bij een case als deze doen ze het (mijn inziens..) écht vanuit goodwill en omdat hun een hoop resources zoals CPU cycles en terabytes aan dataverkeer per jaar scheelt.
Google heeft een gigantische praktijkervaring met het HTTP protocol en kan dus daar vanuit die verbeteringen aandragen. En dat doen ze dus ook.
Het leunt gewoon op hun motto:
"Don't be evil."
Ik weet dat het bij sommige dingen die ze doen er niet vanaf te grijpen is, maar bij een case als deze doen ze het (mijn inziens..) écht vanuit goodwill en omdat hun een hoop resources zoals CPU cycles en terabytes aan dataverkeer per jaar scheelt.
Jaja, don't be evil... mijn neus! Net zoals Motorola (nu het al bijna praktisch van Google is) het nu ineens speelt. Als puntje bij paaltje komt blijken ze alles flink gepatenteerd te hebben en willen ze 2,5% van alle opbrengsten. Ja, het is mooi met ze.
Dat zal nooit het geval zijn. Iedere RFC valt binnen een kader waarin staat geschreven dat alle ideeen die in de RFC worden beschreven, door de auteurs aan "de community" worden geschonken. Nooit gedoe met patent-recht.
[Reactie gewijzigd door gryz op zaterdag 25 februari 2012 00:36]
Volgens mij heeft Google nog niet veel te zeggen over Motorola
Ze kunnen wel al plannen maken, maar dat kan nog niet uitgevoerd worden.
+ Ze gaan idd het spelletje meespelen, nadat ze overal aangevallen worden door Microsoft en Apple. Dat kun je hen moeilijk kwalijk nemen, daarvoor hebben ze Motorola (11 miljard) ook gekocht.
Ze kunnen wel al plannen maken, maar dat kan nog niet uitgevoerd worden.
+ Ze gaan idd het spelletje meespelen, nadat ze overal aangevallen worden door Microsoft en Apple. Dat kun je hen moeilijk kwalijk nemen, daarvoor hebben ze Motorola (11 miljard) ook gekocht.
Don't be evil is een slogan van google zefl.
Google is gewoon hartstikke Evil.
Google is gewoon hartstikke Evil.
Mwah, Spdy is toch meer een lapmiddel voor iets wat zogenaamd de gebruikerservaring moet verbeteren door meer snelheid te bieden. In praktijk zal het weinig uitmaken omdat site-beheerders krenterig bandbreedte ter beschikking stellen.
Neem even Tweakers als voorbeeld met hun pagineren van forums. Wanneer ik op "volgende pagina" klik wordt de volgende pagina pas ingeladen. Dat zal met Spdy maar een fractie sneller gaan.
De echte oplossing voor verbeterde gebruikerservaring ligt in het alvast inladen (pre-fetching) van alle mogelijke volgende pagina's, ook als die mogelijk niet bezocht gaan worden. Nagenoeg iedere PC heeft bandbreedte en geheugen om alle te pre-fetchen, alleen zijn sites te beroerd om dit te implementeren omdat het iets meer bandbreedte kost.
Neem even Tweakers als voorbeeld met hun pagineren van forums. Wanneer ik op "volgende pagina" klik wordt de volgende pagina pas ingeladen. Dat zal met Spdy maar een fractie sneller gaan.
De echte oplossing voor verbeterde gebruikerservaring ligt in het alvast inladen (pre-fetching) van alle mogelijke volgende pagina's, ook als die mogelijk niet bezocht gaan worden. Nagenoeg iedere PC heeft bandbreedte en geheugen om alle te pre-fetchen, alleen zijn sites te beroerd om dit te implementeren omdat het iets meer bandbreedte kost.
Niet alleen de bandbreedte is een beperking coor data centers, maar met name het energieverbruik. Als elke pagehit automatisch een aantal paginas prefetch tot gevolg heeft, gaat het dataverbruik bijvoorbeeld 5x omhoog. asl dat nog binnen de bandbreedte past, hoeft dat niet noodzakelijkerwijs een probleem te zijn. Het energieverruik gaat echter ook omhoog, weliswaar met veel minder dan een factor 5, maar dat zijn directe kosten voor het datacentre.
Ik zou een factor 5 meer bandbreedte verbruikt (ongeveer) nou niet 'iets meer' noemen...alleen zijn sites te beroerd om dit te implementeren omdat het iets meer bandbreedte kost.
Sitebeheerder willen het niet implementeren? Niet echt vreemd omdat de voordelen nihil zijn als je server voldoende capaciteit heeft. Of je nu 0.05 of 0.01 seconden moet wachten op de volgende pagina lijkt me niet echt relevant.
En verder lijkt een dergelijke aanpak me meer iets wat in een browser geïmplementeerd dient te worden. In de meest naïeve aanpak zou de browser domweg alle links kunnen inladen bij het openen van een pagina. Een iets slimmere aanpak zou de muiscursor tracken en de links in de richting van het muispijltje gaan preloaden voordat er op de link geklikt is. Dan heb je direct een cross-domain aanpak in plaats van dat het per site geïmplementeerd zou moeten worden, en kan het alleen gebruikt worden voor hen die überhaupt behoefte heeft aan een dergelijke minieme snelheidswinst. Mocht je nu op een dial-up/3G lijntje zitten lijkt het me fijn dat je de mogelijkheid hebt om dergelijke functionaliteit in je browser uit te zetten om dataverkeer binnen de perken te houden.
En verder lijkt een dergelijke aanpak me meer iets wat in een browser geïmplementeerd dient te worden. In de meest naïeve aanpak zou de browser domweg alle links kunnen inladen bij het openen van een pagina. Een iets slimmere aanpak zou de muiscursor tracken en de links in de richting van het muispijltje gaan preloaden voordat er op de link geklikt is. Dan heb je direct een cross-domain aanpak in plaats van dat het per site geïmplementeerd zou moeten worden, en kan het alleen gebruikt worden voor hen die überhaupt behoefte heeft aan een dergelijke minieme snelheidswinst. Mocht je nu op een dial-up/3G lijntje zitten lijkt het me fijn dat je de mogelijkheid hebt om dergelijke functionaliteit in je browser uit te zetten om dataverkeer binnen de perken te houden.
De meeste bezoekers zijn ongetwijfeld ook te beroerd om advertenties te tonen en blokkeren ze. Niet dat het de oorzaak is van 'krenterig' zijn maar vind dat een beetje vreemd verwijt.
Het is ook flink meer dan een "beetje" extra bandbreedte dat je vraagt. Voorbeeldje van de javascript code "document.getElementsByTagName( 'a' ).length;" op de voorpagina van tweakers.net (lang leve Firebug).
383 resultaten.. goed, je zou daar wat logica aan kan toevoegen zoals het er uit filteren van duplicaten en enkel de links uit de huidige viewport. Maar voeg daar dan weer aan toe de CSS/JS bestanden die voor die pagina's nodig zijn.. het zijn en blijven wel een hele hoop extra connecties.
Het is ook flink meer dan een "beetje" extra bandbreedte dat je vraagt. Voorbeeldje van de javascript code "document.getElementsByTagName( 'a' ).length;" op de voorpagina van tweakers.net (lang leve Firebug).
383 resultaten.. goed, je zou daar wat logica aan kan toevoegen zoals het er uit filteren van duplicaten en enkel de links uit de huidige viewport. Maar voeg daar dan weer aan toe de CSS/JS bestanden die voor die pagina's nodig zijn.. het zijn en blijven wel een hele hoop extra connecties.
[Reactie gewijzigd door Xthemes.us op zaterdag 25 februari 2012 16:42]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
