Mozilla implementeert Googles Spdy-protocol in testversie Firefox

In een testbuild van Firefox heeft Mozilla het Spdy-protocol deels geïntegreerd. Spdy is afkomstig van Google en het protocol zou een sneller alternatief vormen voor http. In Chrome is Spdy al verwerkt en werkt het samen met Google-diensten.

Google introduceerde Spdy in 2009 als een opensource-project en heeft het protocol sindsdien verder verfijnd. Volgens de zoekgigant is Spdy tot 60 procent sneller dan http bij het laden van webpagina's, omdat het aantal dataverzoeken bij een webserver wordt gereduceerd en de headers worden gecomprimeerd. Het http-alternatief is in Google Chrome geïntegreerd en wordt toegepast als een Chrome-gebruiker diensten als Gmail en Chrome Sync benadert.

Inmiddels hebben Mozilla-ontwikkelaars die aan Firefox werken het http-alternatief deels verwerkt in een testbuild van de opensource-browser. Enkele belangrijke onderdelen van Spdy als alternate protocol, waarbij clients vanaf de webserver automatisch worden doorgestuurd naar een Spdy-verbinding, ontbreken nog.

Volgens Patrick McManus, network engineer bij Mozilla, dalen in deze testbuild echter al de laadtijden als een browser websites bezoekt die Spdy ondersteunen. Vooral het beperken van het aantal benodigde requests aan de webserver zou een belangrijke bijdrage leveren aan de snelheidswinst. Of Spdy definitief in toekomstige Firefox-versies wordt opgenomen, is echter nog niet duidelijk.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (51)

Google gaat de microsoft kant op? In plaats van met de standaarden te werken, en de standaarden organisaties (IETF in deze situatie) maken ze maar een eigen protocol verzinnen? Het enige positieve is dan nog dat het een open protocol is, en niet propietary, maar dat is dan ook het enige. Je wil geen protocol-versnippering op internet.

Hoezo? Ze werken toch nog steeds met de standaarden? Daarnaast werken ze aan een performance verbeterende techniek, die ze vervolgens openbaar maken voor iedereen om te gebruiken.
Wat MS deed (ik spreek hier over hun praktijken tijdens de browserwars) was een standaard pakken, die verbasteren (incompatible maken zonder al te veel toevoegingen) en zorgen dat alleen hun clients ermee overweg kunnen. Daar is hier geen sprake van.

Over protocol versnippering gesproken; Het internet hangt aan elkaar van 'versnipperde' protocollen. Om te chatten heb je het msn protocol, xmpp, yahoo, en ga zo maar door. Zolang deze standaarden maar open zijn voor iedereen om te implementeren zie ik het probleem niet.

OT: Leuk dat deze twee browsers het ondersteunen, maar hoeveel webservers kunnen dit protocol aanbieden?

[Reactie gewijzigd door sab op 21 september 2011 10:46]

Google gaat de microsoft kant op? In plaats van met de standaarden te werken, en de standaarden organisaties (IETF in deze situatie) maken ze maar een eigen protocol verzinnen?

Het is behoorlijk sneller als ik het zo lees dus ik snap het probleem niet, ze tonen gewoon aan dat het sneller kan, en blijkbaar gaat mozilla er al gebruik van maken, nu IE nog en Safari (enne Apple doet trouwens precies hetzelfde met hun DLNA variant die nergens behalve bij Apple werkt, DAT Is versnippering en nog bewust ook).

Daarbij merkt de gebruiker hier weinig van, dus voor wie is eventueel de versnippering dan zo erg?!?

enne Apple doet trouwens precies hetzelfde met hun DLNA variant die nergens behalve bij Apple werkt, DAT Is versnippering en nog bewust ook

DLNA en Airplay hebben overlap, maar ze doen toch echt andere dingen. Airplay is meer breedspectrum.

Daar is Google al een tijdje mee bezig. Kijk maar naar hun implementatie van ics kalenders bij Gmail, net niet de standaard. Net als de imap overigens (wat natuurlijk komt voor de tags, want dan kent imap niet, maar goed).

Ik snap je bezwaren niet. Wat heb je liever dat ze doen? Als niemand dit soort dingen zou doen, dan hadden we nog met z'n allen gopher://tweakers.net in onze browsers staan.

Het is geen kwestie van protocolversnippering (zolang niet elke partij met een eigen protocol gaat komen, uiteraard, maar Mozilla lijkt er al niet aan te beginnen en Microsoft heeft het er ook nog nooit over gehad - maar da's ook echt "internetbedrijf", Google wel) , het is een kwestie van een partij die een betere manier heeft verzonnen waar snelheidswinsten mee geboekt worden. HTTP is oud, alles is anders tegenwoordig (op alle vlakken), het internet is niet meer wat het was, en om daar helemaal geen gebruik van te maken en rekening mee te houden is doodzonde.
Zie het als een evolutie, niet als ongewenste versnippering.

Het protocol is nog niet gestandaardiseerd... mocht het goed blijken te functioneren kan dit natuurlijk altijd nog gebeuren, en zoals het artikel aantoont is dit proces inmiddels ook gebeurt. Ook ondersteund google het standaard alternatief dus ik zie dit niet als negatief.

het http protocol is 30 jaar oud.
Het heeft ons veel websites laten zien, maar als er een beter protocol is dat veel sneller is ben ik blij dat te kunnen gebruiken.
Ik verwacht ook geen protocol versnippering, spdy word al op google sites gebruikt, deze kun je echter ook gewooon via http benaderen.
Ik verwacht dat elke webserver dat spdy zal ondersteunen ook http zal ondersteunen.

Vanaf het begin hebben ze het protocol openbaar gemaakt. Zowel hun servers als hun browsers ondersteunen het nieuwe en het oude protocool. Ik zie echt niet hoe ze hier iets verkeerd doen. Zodra ze tevreden zijn over SPDY laten ze het waarschijnlijk goedkeuren door een of andere standaardenorganisatie. Deze manier is echt veel sneller dan via bureaucratische standaardenorganisatie. Vergelijk maar eens de manier waarop XHTML 2.0 en HTML 5 tot stand zijn gekomen (als in: niet en wel, bureacratisch en door bedrijven). Het belangrijkste verschil is dat HTML 5 een samenwerking van browsermakers is, maar ik heb Google nog geen verzoek tot samenwerking op het gebied van SPDY zien weigeren.

Het SPDY protocol is NIET bedoeld als een vervanging van het HTTP protocol! Het is slechts een ALTERNATIEF protocol en zal dus nooit een bedreiging vormen voor het HTTP protocol. Er wordt hier dus niets versnipperd...

Op een markt een alternatief bieden leid natuurlijk wel tot versnippering. Eerst alleen http, nu spdy als alternatief.Zodra iedereen spdy kan gaat men het snellere alternatief gebruiken en dan gaat http uitsterven. Als niet iedereen spdy kan of wil blijven ze naast elkaar bestaan. Hoe het ook loopt, als spdy ook maar 1% pakt is dat meer versnipperd dan het was.

Maar de implementatie ervan is vrijwillig. Als een overgrote meerderheid van de browsers en servers dus spdy gaat ondersteunen is dat omdat het blijkbaar als een verbetering wordt ervaren. Dan is er sprake van evolutie en kan de nieuwe methode tot standaard worden verheven. Het is niet anders dan bijvoorbeeld de ontwikkeling van SATA terwijl er al een andere standaard (PATA) bestond.

tuurlijk wel

Alleen zit er nog een groot verschil tussen toen en nu. spdy is meer een aanvulling op http waarbij de tekortkomingen worden weggewerkt en alles sneller werkt. Voor de eindgebruiker geen echt verschil. Gopher en http hadden wel een totaal andere gebruikerservaring voor de eindgebruiker.

Google gaat de microsoft kant op

Precies mijn gedachte. En natuurlijk zullen vele Google fans het hier niet mee eens zijn. Maar Google lijkt net als Microsoft destijds zijn 'gewicht' in de markt te misbruiken om protocollen in te voeren en te door drukken. Zo ook destijds WebM. Persoonlijk vind ik het dan ook een slechte zaak dat Mozilla hier aan meewerkt. Liever had ik gezien dat ze gewacht hadden totdat het een daadwerkelijke standaard was. Als Microsoft dit had gedaan dan had de wereld op zijn kop gestaan.

Natuurlijk is het zo dat Google toestaat dat Mozilla en anderen het ook invoeren ... maar door het gewicht van Google is het 'volgen of sterven'.

Slechte zaak.

[Reactie gewijzigd door HerrPino op 21 september 2011 11:03]

Google levert deze technieken als open-source/spec.
Ja ze hebben er een eigen belang bij, en ja Google is groot.

Maar is het dan nodig om alles dat door een groot bedrijf word gemaakt gelijk als slecht te bestempelen? Zij werken hier dagelijks mee en hebben dus ook de meeste kennis.

Ze delen met andere, juist om het populairder te maken.
En om het verder te verbeteren.

Je kan zeggen wat je wilt over Google.

Zonder hun harde werk en vrijgevigheid hebben we misschien nooit de V8 JavaScript engine die Node.JS gebruikt, WebM (open en niet patent gevoelig), PageSpeed en ga zomaar door.

Het is OPEN, het niet zoals met Apple of MS dat ze alleen hun eigen software/dingen willen doordrukken zoals mp4 wat volstaat van de patenten.

[...]
Natuurlijk is het zo dat Google toestaat dat Mozilla en anderen het ook invoeren ... maar door het gewicht van Google is het 'volgen of sterven'.

Daar zit een fout in je redenering, volgens mij. Chrome heeft geen dominante positie in de browsermarkt en Google heeft ook geen manier waarop ze sterke druk kunnen uitoefenen op webhosts en het protocol waarmee ze hun content serveren. Het protocol wordt nu alleen nog maar geserveerd door sites van Google zelf. Hoe zie jij dit naar andere sites verspreiden?

Google komt tenminste met een alternatief??

En waarom een alternatief? Waarom geen uitbreiding of vernieuwing van de bestaande standaard?

Bij microsoft deed men dat om consumenten en concurrenten het lastig te maken, google heeft ook nog lang niet dezelfde positie als microsoft nog steeds heeft, de enige die hier deze vergelijking trekken zijn "microsoft-fans"

Je wil geen protocol-versnippering op internet.

Ze ondersteunen toch (ook) gewoon HTTP?

Hoezo? als ze de microsoft kant op zouden zijn gegaan dan zou mozilla het niet hebben kunnen implementeren, bovendien heeft google geen lock-in waarmee ze pseudo standaarden door de gebruikers' strot kunnen drukken...

Zien die links er dan uit als spdy://google.nl ipv http://google.nl?

Aangezien de verbindingen gewoon over port 80 en 443 gaan lijkt het dat je gewoon http:// en https:// kan blijven gebruiken. Ik ben wel benieuwd hoe servers en clients dit af gaan handelen en hoe de keuze tussen normaal http en spdy gemaakt word. Hier kan ik zo snel even niets over vinden.

Leukigheidje voor de nieuwschierige: Details over de huidige spdy verbindingen in chrome. Als je gmail even open zet kan je zien dat hij hier al gebruik van maakt over ssl op port 443.

Edit: directe link werkt dus niet, even dit in je omnibox plakken: chrome://net-internals/#spdy

[Reactie gewijzigd door Sleepkever op 21 september 2011 10:45]

Bij Chrome lijkt dit niet het geval te zijn. Ik heb daar namelijk nog nooit Spdy zien staan bij het gebruik van gmail.

Bij recente versies van Chrome wordt het protocol sowieso al helemaal weggelaten in de adresbalk.

Nee gebeurd op achtergrond op dit moment.
De gebruiker ziet er niets van.

Nope, gelukkig niet.

[Reactie gewijzigd door Olaf van der Spek op 21 september 2011 10:35]

Volgens de zoekgigant is Spdy tot 60 procent sneller dan http bij het laden van webpagina's

Werkt dit ook met https?

Nvm, staat in de link, werkt met SSL

[Reactie gewijzigd door Bartjeh op 21 september 2011 10:33]

Ja, er is geen enkele reden waarom het niet zou werken met HTTPS. Het enige echte verschil is dat de headers ook gecomprimeerd worden niet alleen de data en dat veel data samengevoegd wordt in een download. Dat maakt voor HTTPS geen verschil het aantal bestanden of het format van de bestanden, de versleuteling gebeurt buiten de te downloaden bestanden en data om.

Probeer voor de grap maar eens een directory met 100.000 tekst bestanden van 1k te copieren en probeer daarna maar eens alles samen te voegen in een zip (zonder of als je dat wil met compressie) en het resulterende bestand te kopieren en je zult zien wat Google bedoelt met de snelheids winst. Nu is er natuurlijk wel een beetje verschil tussen acties op de harde schijf en een netwerk maar het concept en de rede voor de vertraging is redelijk te vergelijken.
Als je bijvoorbeeld de Google Web Toolkit bekijkt dan doet Google iets vergelijkbaars door bijvoorbeeld alle images samen te voegen in een bestand en deze pas aan de client side weer uit elkaar te trekken en als losse images weer te geven kun je de download flink reduceren. Het zelfde geldt voor includes zo als CSS en Javascript, het geheel laad een stuk sneller als je het voor zo ver mogelijk allemaal in 1 bestand dumpt en dat in 1x laad. zeker bij een "lichte site" zo als de meeste Google sites is het grootste deel van de tijd van het openen van een pagina nodig om de verschillende bestanden op te vragen en duurt het downloaden van de bestanden zelf vaak veel minder lang.

Ik hoop dat Mozilla dit protocol ook in de gewone builds gaat gebruiken en dat bijvoorbeeld de grote servers IIS/Apache/J2EE compiant meuk dit als optie gaan mee leveren. Het zou een heleboel schelen voor de snelheid van het internet.

Het scenario wat je schetst over die 100.000 tekstbestanden is natuurlijk alleen maar geldig als je dit meer dan eens uitvoert. Mocht je dit een enkele keer gebruiken raakt de tijdswinst verloren door het comprimeren of samenvoegen van de bestanden.

@Vaal: Natuurlijk niet. Dat comprimeren kan betrekkelijk snel gebeuren, in veel minder tijd dan dat het kost om 100.000 verbindingen te maken.

dat zou dan toch spdys zijn?

ik zie op de spdy website geen melding over beveiligde verbindingen dus is er nog geen alternatief voor https denk ik.

http://www.chromium.org/spdy

Er word op die paginas meerdere malen SSL vermeld wat dus HTTPS is.

Hier kan je duidelijk zien welke websites het protocol gebruiken

chrome://net-internals/#spdy (Alleen in chrome)

Dit lijkt mij van wel, tenminste bij Chrome. Het gebruik van gmail gaat namelijk over https.

Op de pagina achter de link in het artikel vind je onder andere dit:

We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.

Het lijkt er dus wel op.

Sterker nog, er staat op die pagina ook het volgende:

SPDY design and features

SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.

Of het met de genoemde testversie van Firefox werkt weet ik niet, maar aan het protocol zal het niet liggen.

Ik hoop dat Microsoft snel SPDY toevoegt als extra binding in IIS, gratis performance boosts zijn altijd mooi meegenomen als eind-hoster/developer

Als ze nu lekker investeren in het mod_spdy project dan wordt de kans wel groot dat dit gaat aanslaan in de webwereld.

Ik vind het persoonlijk een goede ontwikkeling dat SPDY opgepakt wordt. Ik hoop alleen wel dat de desbetreffende personen SPDY ook als IETF RFC gaan indienen. Google is immers groot geworden dankzij open formaten en protocollen, dus lijkt me niet meer dan normaal dan dat ze dezelfde weg volgen om verbeterde protocollen gestandaardiseerd te krijgen.

Mooie praatjes allemaal, maar wat zijn de gebruikerservaringen van de mensen hier?

Het zou fijn zijn als het een meer generieke naam zou krijgen. Zo iets als cctp://.....
Waar de 'c' zou staan voor 'compressed' of 'consolidated' gevolgd door 'content transfer protocol'. Voor zover ik kan checken bestaat er nog geen CCTP protocol.

Edit: visual markup added.

[Reactie gewijzigd door perlboy op 21 september 2011 12:18]

SPDY staat voor speedy; daarom heet het ook SPDY en niet CCTP

[Reactie gewijzigd door onox op 21 september 2011 15:53]

Het voordeel van een afkorting als CCTP ten opzichte van een naam als SPDY is dat als een verbeterde versie uitkomt het niet omgedoopt te worden to SPDR (Speedier). Dan wordt het gewoon CCTP v2 maar blijft in essentie CCTP.

Creeer je met SSL geen issue dat de controles die normaal sequentieel achter elkaar plaatsvinden nu tegelijk plaatsvinden en daardoor potentieel een ruimte laten voor een lek ivm met timings.

Lijkt me dat ze daar wel rekening mee gehouden hebben...

SSL kan sowieso naast de cypher zelf de compressie regelen. En dat zou ook daar moeten gebeuren om de entropy van het te encoden bericht zo hoog mogelijk te krijgen. Dat proberen op te lossen buiten de SSL library zorgt buiten legacy problemen ook gewoon voor een zwakkere encryptie.

Het probleem is alleen dat het aantal datagrammen gebruikt om de boel over te sturen... vrijwel gelijk is met gewoon gzip/deflate gebruik. Daarnaast zorgt het ervoor dat veel transparante http proxies niet meer werken...