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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 54 reacties

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
Don't be evil is een slogan van google zefl.

Google is gewoon hartstikke Evil.
SSL is ook standaard bij https
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.

[Reactie gewijzigd door Roland684 op 26 februari 2012 12:47]

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.
Http heeft ook al persistent connections, dus wat winnen we hier nu mee?
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.
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.

[Reactie gewijzigd door Xthemes.us op 25 februari 2012 16:42]

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.
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.
tja als je het zo zegt dan is een spamfilter ook tegen de net-neutraliteit?
hogere prio toekennen wordt een zegen voor VOIP
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).
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.
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.
alleen zijn sites te beroerd om dit te implementeren omdat het iets meer bandbreedte kost.
Ik zou een factor 5 meer bandbreedte verbruikt (ongeveer) nou niet 'iets meer' noemen...
Het lijkt me dat de belangrijkste reden dat Google moeite doet voor dit protocol is dat daarmee content (spam blurb) gepushed ca worden naar je browser. Straks kun je dan geen browser openen zonder meteen into-you-face adds te krijgen.

De efficiŽntieverbetering ten opzichte van http: is naturrlijk erg welkom voor datacenters, dat spaart veel energie in internetverkeer en energie is hun belangrijkste kostenpost. (power=money). Voor Google Search zal dit niet helpen, dat zijn toch voornamelijk kortere pakketjes. (geen streams of heftig parallelle zaken)

just my $0.02, feel free to comment
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.
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.
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 25 februari 2012 00:36]

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.

Op dit item kan niet meer gereageerd worden.



Microsoft Windows 10 Home Apple iPhone 6s Star Wars: Battlefront (2015) Samsung Galaxy S6 Edge Apple Watch Project CARS Nest Learning Thermostat Websites en communities

© 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