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 , , 54 reacties, 18.594 views •

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)

Reactiefilter:-154052+132+28+30
Moderatie-faq Wijzig weergave
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 ?
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.
Hmm, dit lijkt me als eindgebruiker toch niet echt wenselijk?
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...
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.
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 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? 8)7

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.
Is snelheid het enige voordeel van Spdy t.o.v http?
SSL is standaard, dus het is veiliger:)
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.
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.
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.
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.
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.
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"
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.
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 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.
Zijn er voorbeelden van dit soort pagina's? Is het dan zoiets als spdy://www.webpagina.nl?

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.
gaat dit dan ook nog in je bandbreedte verbruik iets uitmaken ?
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.
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.

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True