Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 54, views: 18.499 •

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!
'request' probleem bij websites oplossen
Als de betreffende webserver niet genoeg resources heeft, zal je nog steeds een request probleem houden.
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.
Ik denk dat google met spdy niet echt als activiteit heeft informatie verzamelen. Maar snelheid. (Als je meer informatie gaat verzamelen wordt het langzamer.)
gaat dit dan ook nog in je bandbreedte verbruik iets uitmaken ?
Betekent dat dan ook dat DoS aanvallen makkelijker worden?
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.
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.
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.

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.
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 24 februari 2012 18:55]

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 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.
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...
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! :)
Zijn er voorbeelden van dit soort pagina's? Is het dan zoiets als spdy://www.webpagina.nl?

Of zie ik het nu verkeerd?
Is snelheid het enige voordeel van Spdy t.o.v http?
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.
honderdduizenden (?), google heeft er vermoedelijk meer dat 1.000.000. zie hier.
SSL is standaard, dus het is veiliger:)

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013