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.
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.
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.
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 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]
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.
Is snelheid het enige voordeel van Spdy t.o.v http?
SSL is standaard, dus het is veiliger:)
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.
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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 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
