Google doneert Spdy-plugin aan Apache Software Foundation

Google heeft Mod_spdy, een Apache-plugin die ondersteuning voor het Spdy-protocol biedt, gedoneerd aan de opensourcegemeenschap. De Apache Software Foundation beheert vanaf nu de software en wil de plugin standaard maken in aankomende releases.

Google introduceerde het Spdy-netwerkprotocol in 2009 met tot doel het inladen van websites te versnellen. Daarvoor past het protocol onder andere compressie en flow control toe. Ook worden versleuteling afgedwongen in het http-alternatief. Na Chrome begonnen ook andere grote browsers, zoals Firefox en Internet Explorer, Spdy te ondersteunen.

"Ons doel was toen om de groei en adoptie van Spdy te bevorderen door het voor Apache 2.2-gebruikers eenvoudiger te maken Spdy te installeren en in te schakelen op hun websites", blogt Google-ontwikkelaar Matthew Steele. Volgens hem gebruiken vele populaire sites wereldwijd Spdy tegenwoordig, waaronder Twitter. "Dit lijkt het juiste moment om de ontwikkeling van Mod_spdy als third-party-add-on te staken en in plaats daarvan de plugin een kernonderdeel van de Apache-httpd-server te laten zijn."

Google heeft de code formeel gedoneerd aan de Apache Software Foundation, die het project vanaf nu uitgeeft als onderdeel van de httpd-codebase. De intentie is om Mod_spdy volledig onderdeel van Apache 2.4 te laten zijn, en daarnaast deel van versie 2.6 en 3.0.

De invloed van het Spdy-protocol zal alleen maar toenemen, zodra de Internet Engineering Task Force http 2.0 uitgeeft. De organisatie werkt sinds 2012 aan de nieuwe versie van de http-specificatie en neemt daarbij Spdy van Google als uitgangspunt. De standaard moet dit jaar gereed zijn en wordt uitgerold naast het al bestaande http 1.1, waarvan de standaard begin deze maand werd bijgewerkt.

Reacties (46)

[geertdo]

Internet Explorer (vanaf v 11) ondersteunt het ook. Een tooltip op de adresbar maakt dat zichtbaar als het gaat om een site dat SPDY toepast.

[arthur-m]

IE11 geeft standaard een melding als het via SPDY is geladen.

[geertdo]

Nooit gezien, hoe dan?
Ik zie het alleen als je met de muis over de adresbar hovert...

[arthur-m]

Hmm... Ik heb t ff geprobeerd, en wat je zegt is volgens mij wat ik bedoel. Ik dacht alleen dat als je naar een site gaat die met SPDY geladen wordt, IE11 het standaard via een tooltip laat zien, maar dat is dus alleen als je met je muis over de adresbalk hoovert.

[Sicos]

Ze zijn goed bezig daar bij Google, ben een grote voorstander van Open Source.

[GigaPixels]

Een sneller web komt uiteindelijk iedereen ten goede. Als grote partijen er niet aan werken zoals Google, wie dan wel? Dit soort bedrijven hebben de mankracht en het kapitaal om niet enkel het internet een andere vorm te geven (dmv hun producten), maar ook het web efficiënter te laten functioneren - die inderdaad dan weer de aangeboden producten ten goede komt.

Met een 60% van alle websites die op een Apache server draaien, zal dit echt wel impact hebben op globale schaal.

[Reactie gewijzigd door GigaPixels op 22 juli 2024 21:40]

[Faeron]

Dat valt dus reuze mee. SPDY is alleen interessant voor Google en bedrijven die soort gelijke webdienst aanbieden. Voor het meerendeel van de website-aanbieders biedt SPDY nauwelijks verbetering.

[i-chat]

als je dan vervolgens niet komt met voorbeelden dan is je post natuurlijk ook gewoon nietszeggend...

spdy heeft toch echt behoorlijke voordelen, bijv voor video-sites, maar ook voor andere html5 onderdelen, wil je een irc (achtig systeem) spdy kan het, wil je up of download sites, spdy kan het...

google doet zo enorm veel verschillende dingen ... en op heel veel vlakken zal spdy de overhead minder maken. nu alleen nog hopen dat ip6 snel komt, er zijn maar weinig hosts die sni ondersteunen en gebrek aan encryted comunicatie is toch wel heel jammer ano nu...

[Faeron]

Juist videowebsites halen er geen voordeel mee. Een lange video stream gaat echt niet sneller met SPDY dan met HTTP/1.1. IRC kan ook met HTTP/1.1, heeft niks met SPDY te maken. Net als up- en downloaden, we doen immers al langer lang niet anders.

Het voordeel van SPDY zou moeten zijn dat in plaats van meerdere connecties (vaak 6) naar een webserver je het nu met 1 af kan. Echter, in de praktijk wordt de content van 1 website niet van 1 server vandaan gehaald. Denk aan de vele reclames die van ad websites komen. Google heeft daar geen last van, omdat ze zelf de ads leveren.

De snelheidswinst is niet meer dan een paar procent, geen tientallen zoals eerder verteld werd. Wil je snelheid verbeteren? Stop je tijd en energie dan in caching. Microcaching bijvoorbeeld versnelt de boel wel aanzienlijk, omdat het de load op je server erorm verlaagt.

SPDY, leuk idee. Maar het is niet meer dan een protocol door Google, voor Google.

[Spykie]

Iedere server beheerder kan SPDY implementeren hoor..

[Tozz]

Dat valt wel een beetje mee. Je hebt namelijk wel voor ieder domein een certificaat nodig. Die kost, goedkoopste oplossing, een tientje. Die moet je dan wel jaarlijks verlengen met alle administratieve handelingen van dien. En zelfs een tientje staat niet in verhouding tot de hedendaagse hostingproviders die hosting aanbieden voor minder dan een tientje per jaar.

Het is dus, zoals Faeron al aangeeft, alleen leuk voor grote partijen. Voor de website van de lokale glazenwasser zal het waarschijnljik niet gebruikt worden.

[Rob Wu]

Voor niet-commericiële doeleinden kan je gratis SSL certificaten halen bij StartCom / StartSSL. En als je een bedrijfje hebt, dan zal dat tientje niet zo zwaar op je jaarlijkse begroting drukken hoor.

Onbeveiligd internet is niet meer van deze tijd, dus het is goed dat het zo benadrukt wordt in SPDY. En het toevoegen aan de core van Apache zal het nog makkelijker maken om het te gebruiken.

[Reactie gewijzigd door Rob Wu op 22 juli 2024 21:40]

[sanderv]

Google open source't wanneer het hen uitkomt (begrijpelijk) en een groeiend percentage van de actieve code voor veelgebruikte, actieve Android-applicaties, die eerder nog open source waren, verdwijnt achter de poorten van Google...

[calvinturbo]

Dat is half juist, veel code blijft nog gewoon in AOSP zitten en wordt apart geupdate.
Kijk bijvoorbeeld naar de ´Phone´ applicatie die speciale Google features heeft die closed-source zijn, maar de rest van de app is open-source.

[Reactie gewijzigd door calvinturbo op 22 juli 2024 21:40]

[sanderv]

Ik heb dit artikel gelezen en was er flink van geschrokken. Er mag best van alles nog wél open source zijn, maar er is blijkbaar voldoende closed source om een mooi stukje vendor lock in te creëren.

[GewoonWatSpulle]

Ik vind het een vervelend geschreven artikel omdat veel van deze dingen weerlegt kunnen worden met: pas het dan aan. De AOSP versie kan worden aangepast, maar vaak zijn er inmiddels betere alternatieven of keuzes om van open source af te stappen. (Music wegens muziekrechten, Search wegens lerende algoritmes)

Voordeel van het lostrekken van veel Google diensten is ook dat je ze niet verplicht meer op je telefoon hebt, ok veel fabrikanten maken ze niet te verwijderen maar hooguit uit te schakelen als je geluk hebt.

En Google Play Services is een mooi voorbeeld van closed source wegens het niet proppen in de core van Android aangezien vele telefoons geen of heel kort updates krijgen en zo toch nieuwe functionaliteit krijgen. Sure iedereen kan zijn eigen notification services maken maar Google maakt het wel makkelijk om op 1 manier alle Google Android gebruikers aan te sturen.

[CAPSLOCK2000]

Voordeel van het lostrekken van veel Google diensten is ook dat je ze niet verplicht meer op je telefoon hebt, ok veel fabrikanten maken ze niet te verwijderen maar hooguit uit te schakelen als je geluk hebt.

En Google Play Services is een mooi voorbeeld van closed source wegens het niet proppen in de core van Android aangezien vele telefoons geen of heel kort updates krijgen en zo toch nieuwe functionaliteit krijgen. Sure iedereen kan zijn eigen notification services maken maar Google maakt het wel makkelijk om op 1 manier alle Google Android gebruikers aan te sturen.

Dat heeft niks met Open Source te maken. Google Play Services had ook Open Source (of zelfs Free Software) kunnen zijn, of het nu onderdeel van de Android core is of niet.

[calvinturbo]

Nee, want Google Play Services biedt toegang tot Google API´s en Google diensten. Logisch dat dat beschermd is.

[CAPSLOCK2000]

Ik snap het niet, waarom kan het dan geen Open Source zijn?

[calvinturbo]

Lees ook even deze reactie, het artikel lijkt niet volledig neutraal of juist te zijn in ieder geval. Ook op basis van de realiteit kan je stellen dat het artikel niet klopt. Microsoft, Amazon en vele anderen gebruiken AOSP.

[Reactie gewijzigd door calvinturbo op 22 juli 2024 21:40]

[i-chat]

amzone, en strax ms doen dat toch ook, is het android, strikt gezien ja.. ik denk dat zolang aosp gewoon blijft werken er niets an de hand is...

in htc sence zit ook een custom dialer die de stock vervangt ...
je kunt ook voor go-launcher kiezen die ook een eigen dialor en sms app etc heeft...

en tot nog toe heb ik nog niet 1 stukje van android closed source zien worden wat niet met een eigen laucher te verhelpen is... al zul je idd, wel vaker totaal oplossingen gaan zien.
het al eerder genoemde go-launcher is al ver op weg anderen mischien wat minder

ik had liever gezien dat android veel meer een hardware platform werdt waarin drivers etc standaard 'verplicht' beschikbaar komen, het zij als opensource, het zie als binairies die voor minimaal 5 jaar door de fabrikant naar de laatste android-release worden geport

daar hebben we veel meer aan dan gemikker over wel of geen opensource google+ client mail app of dialer...

[raro007]

er zal altijd wel een vendor lock zijn in android want als jij miljoenen investeerd in iets dan wil je niet dat binnen een jaar verliezen.
daarbij android zelf is opensource maar de bijzaken zijn het niet en hoeft het ook niet.

en trouwens bij elke android google atrikel plaats er iemand wel die link wat een grote bullshit is want anders kon volgens hun amazon en nokia ook geen android toestel maken.

[Reactie gewijzigd door raro007 op 22 juli 2024 21:40]

[gladius1983]

er zal altijd wel een vendor lock zijn in android want als jij miljoenen investeerd in iets dan wil je niet dat binnen een jaar verliezen.
daarbij android zelf is opensource maar de bijzaken zijn het niet en hoeft het ook niet.

Android Telefoons lijken (qua uiterlijk) steeds meer opelkaar. Dit lijkt wel de enige manier om een uniek product neer te zetten.

[Armin]

Google open source't wanneer het hen uitkomt (begrijpelijk) en een groeiend percentage van de actieve code voor veelgebruikte, actieve Android-applicaties, die eerder nog open source waren, verdwijnt achter de poorten van Google...

Geheel waar, maar waarom is dat een probleem?

Open source heeft zijn voor- en nadelen. Het is toch geen religie. het lijkt er soms op dat als je niet 100% puur open source bent, je dan dus opeens 'fout' bent.

[fevenhuis]

Dit klinkt goed, tenzij we er over een paar jaar achter komen hoe de NSA betrokken is bij de ontwikkeling van Spdy.

Het eigenaardige aan Spdy is eigenlijk dat het voornamelijk gericht is op snelheid, in een tijd waarop hogere snelheid van minder belang lijkt te zijn dan de vraag naar grotere veiligheid.

[Reactie gewijzigd door fevenhuis op 22 juli 2024 21:40]

[GewoonWatSpulle]

SPDY en HTTP zelf zijn niet bedoeld voor veiligheid, dat doe je met een laag daar overheen.

Carparison: Zie het als een snelweg waar je minder af/opritten hebt die langer zijn dus meer doorstroming bieden, versus haakse korte invoegstroken. Word niet perse veiliger/onveiliger*, daarom heeft iedere auto die over diezelfde weg gaat nog zijn eigen voorzieningen.
* in een wereld van autonomen voertuigen, korte invoegstroken zijn nu nog wel een stuk onveiliger/gevaarlijker

[fevenhuis]

Snelwegen zijn ook beter beveiligt en worden nauwkundiger beheerd dan gewone wegen.

Ik begrijp dat HTTP er niet voor bedoelt was, maar inmiddels is de cyberwereld veranderd.

Ook met het oog op DDoS aanvallen lijkt mij een protocol met betere beveiliging een veel beter idee.

[Verwijderd]

Blijft vreemd om van een protocol dat veelgebruikt gaat worden/wordt geen IETF RFC te kunnen vinden en te moeten constateren dat 'SPDY' (tm) een trademark is van Google.

http://www.rfc-editor.org...%5D=Any&pub_date_type=any

Er wordt hier weer gemeningmod, dit is geen -1 -.-

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:40]

[SupaHotFire]

Gebruikt Tweakers.net ook Spdy?

[AmbroosV]

SPDY heeft als vereiste dat de site HTTPS gebruikt. Is bij Tweakers ook nog niet het geval (en ook nauwelijks nodig aangezien het niet echt om belangrijke informatie gaat).

[SupaHotFire]

Dat is waar.

In ieder geval wel goed en waarschijnlijk ook beter van Google dat ze het doneren aan een ''Groot website-beheerder/maker'', Om maar weer even on-topic te komen

[Armin]

Klopt, al maakt het de inlog-cookies van Tweakers wel meer vatbaar voor SSL-stripping.

[Nactive]

De reden dat tweakers geen Spdy ondersteund heeft ACM een jaar geleden beantwoord (Let wel op antwoord is deels out of date ):

ACM in 'nieuws: Internet Explorer 11 krijgt ondersteuning voor WebGL en Spdy'

ACM schreef op donderdag 26 juni 2013 @ 19:59:
Wat ons betreft is het nog te vaag/ongespecificeerd/ongestandaardiseerd:
- Vziw is er geen ondersteuning in Varnish en wij gebruiken Varnish vollop als reverse proxy. Dus dat gaan we niet zomaar eventjes tussendoor vervangen door "iets" anders dat wel SPDY ondersteund.
- SPDY vereist SSL. Ook SSL wordt niet in Varnish ondersteund en aangezien onze loadbalancers heel goed SSL kunnen "terminaten", maken we dankbaar gebruik van de kracht van Varnish (enorm goede reverse proxy) met die van onze loadbalancers (o.a. ssl-offloading/termination)
- SPDY vereist SSL deel 2. SSL en banners gaan momenteel niet zo best samen, browsers hebben de neiging om content van niet-ssl-domeinen te blokkeren of er waarschuwingen over te geven... En Tweakers heeft nou eenmaal banners nodig om voldoende inkomsten te genereren om uberhaupt servers te kunnen draaien (die bijvoorbeeld weer SPDY kunnen serveren) en mensen aan het werk te houden (die er SPDY op kunnen installeren) En nee, banners en SSL... dat is ook nog een toekomstdroom dat "bannerboeren" daaraan helemaal perfect meewerken.
- De SPDY-ondersteuningen voor o.a. apache lijkt nog niet erg uitgewerkt, de mod_spdy werkt bijvoorbeeld niet zo lekker samen met onze - en de de facto standaard - manier van PHP (aka, pre-fork en niet multi-threaded).

Sowieso zijn er nog meer kandidaten voor HTTP 2.0, dus het is ook nog een beetje afwachten of dit de uiteindelijk "winnaar" van die race wordt, of dat we over een paar jaar de SPDY-support dan weer zouden moeten verwijderen...

We gaan in ieder geval niet "zomaar" even onze Varnish vervangen (bijvoorbeeld door Nginx) en zien het al helemaal niet zitten om onze Apache te vervangen (ook door bijvoorbeeld Nginx).

Ik ben dan ook bang dat het antwoord op "of zie ik dat verkeerd", helaas "ja, dat zie je verkeerd" is

Dus vooralsnog blijven we de kat uit de boom kijken.

[Reactie gewijzigd door Nactive op 22 juli 2024 21:40]

[Armin]

En Tweakers heeft nou eenmaal banners nodig om voldoende inkomsten te genereren om uberhaupt servers te kunnen draaien

Veel advertentie-sites ondersteunen anno 2014 ook HTTPS, dus dat is inmiddels minder een argument.

Al is het nog steeds wel een probleem, want LinkedIn kampt bijvoorbeeld momenteel bij de overschakeling naar HTTPS met o.a. exact dat probleem. Maar als LinkedIn het kan (nota bene hun pilot was in Nederland!) moet het ook kunnen voor Tweakers.

Sterker nog, het maakt een site minder kwestbaar voor malware, want als een advertentie-site gehacked wordt, wordt de eigenlijk malware content - die immers van een 3e domein komt - in non-SSL aangeboden en dus automatisch geblokeerd (door een goede browser).

Een geldig SSL-certifciaat verkrijgen ('jatten') is een extra drempel voor die malware aanbieders. Een aangezien die weer gekoppeld zijn aan of een domain of IP adres, is daarna server-hoppen om de opsporingsdensten te ontwijken ook niet snel mogelijk.

( Wel kan ik Tweakers dan aanraden hun Appache servers te upgraden, want ze gebruiken nog oude die enkel 1024 bits DH exchange ondersteunen. Dat kan eigenlijk anno 2014 niet meer ... )

[GigaPixels]

Blijkbaar gebruikt tweakers.net nog niet het SPDY protocol. Al zijn er natuurlijk andere zaken die worden toegepast om een website sneller te doen laden.

[SupaHotFire]

Ah, owke. Mooie site!

Tweakers reageert namelijk wel snel op mijn acties dus had ik dat in gedachte

[WhatsappHack]

Neen.

[WhatsappHack]

Kijk, dat is goed nieuws. Heb de module een paar keer ingezet, en werkt ook gewoon lekker, mits de software meewerkt. Kan enkel toejuichen dat Apache dit zelf gaat beheren en onderdeel maakt van de standaard release. Kan niet snel genoeg gebeuren.
Andere http software, zoals nginx, volgen dan hopelijk vanzelf.

[pBook]

Safari zal vanaf de herfst SPDY gaan ondersteunen (vanaf versie 8 in OS X 10.10).

[tellavist]

Ik ben geen programmeur.
Kan iemand mij vertellen wat hier precies gebeurd is?

[WhatsappHack]

Google heeft software gedoneerd aan Apache Foundation, de makers van Apache httpd (populairste opensource http-server software), die er nu eigenaar van is en t doorontwikkeld... Iets dat volgens mij behoorlijk helder in t artikel staat

[tellavist]

"Google heeft Mod_spdy, een Apache-plugin die ondersteuning voor het Spdy-protocol"
Hier was ik hem al kwijt hoor
Niet mijn piece of cake dit, ik hou me stil oke?

[Permutor]

Lees anders dit artikel even:
http://nl.m.wikipedia.org/wiki/SPDY

[Verwijderd]

Normaal gesproken zou ik je voor een open standaard internet protocol naar een IETF RFC document verwijzen, maar helaas is dit voor SPDY(tm Google Inc.) niet mogelijk. Ik heb ook het idee dat er gewoon een versie van SPDY open source gemaakt is en dat de controle nog steeds bij Google ligt (vergelijk Android).

[bop]

Zolang Apache alleen hun eigen open-source versie implementeert die iedereen in kan kijken lijkt het me dat er niks aan de hand is en dat Google hier geen controle over heeft.
Android is totaal niet te vergelijken hiermee, daar heeft Google namelijk allemaal eigen applicaties aan hangen (als je voor de Google variant kiest en niet voor AOSP), die inderdaad wel closed-source zijn (en ze suggereren ook niet anders).
De Android versies waar Amazon en Nokia op draaien staan compleet los van Google invloed.

Google heeft ook zo zijn dingen waar je wel twijfels bij kan hebben, maar als Google zoiets als dit doet snap ik niet dat mensen altijd weer de negatieve dingen erbij moeten betrekken. Deze gift en dit soort ontwikkelingen (ook webp!) zijn gewoon goed voor het internet en ook als je een iPhone of Windows Phone hebt.

[Reactie gewijzigd door bop op 22 juli 2024 21:40]

[Dannydekr]

Ik gebruik SPDY 1.3 in combinatie met Nginx en OCSP Stapling. Veel sneller zul je de HTTPS verbinding niet kunnen maken denk ik. First contact blijft trager dan een simpele HTTP request, maar met caching etc kom je in de buurt en soms haal je zelfs snellere resultaten dan standaard HTTP.

Mijn webshop draait in ieder geval volledig op HTTPS.