Google stelt Spdy voor als alternatief voor http-protocol

Ontwikkelaars bij Google werken aan een mogelijke opvolger van het Hypertext Transfer Protocol, de standaard om data tussen een server en een client uit te wisselen. De vervanger, Spdy geheten, zou tot 50 procent sneller werken.

Het http-protocol, waarvan 1.1 de meest recente versie is, doet al sinds jaar en dag dienst als het standaardmechanisme waarmee client en server gegevens over het web uitwisselen. Ontwikkelaars bij Google stellen echter dat de efficiëntie kan worden vergroot met een nieuw protocol. Spdy - oftewel Speedy voluit - ligt deels nog op de tekentafel, maar het protocol zou volgens de ontwikkelaars van Google tot 55 procent sneller zijn dan de traditionele http-requests.

Hoewel Google claimt dat Spdy de uitwisseling van data tussen server en client aanzienlijk sneller maakt, is het protocol vooralsnog op beperkte schaal getest. De ontwikkelaars stellen dan ook dat Spdy nog lang niet volwassen genoeg is om op grote schaal toegepast te worden. Google hoopt dat met het vrijgeven van het Spdy-protocol externe ontwikkelaars verbeteringen aandragen en het protocol volwassen maken. Bovendien zou een eventuele overgang van http naar het Spdy-protocol uitsluitend stapsgewijs en over een langere termijn kunnen plaatsvinden, zo benadrukken de ontwikkelaars.

Reacties (158)

[cschutijser]

Volgens Google zelf is het helemaal geen alternatief voor HTTP:

Q: Is SPDY a replacement for HTTP?

A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.

http://sites.google.com/a.../dev/spdy/spdy-whitepaper

[Luukje01]

en hoe lang gaat dat nog duren voor dat het in bedrijf word gezet?

ALS het 50% sneller zou moeten zijn, dan is de HTTP-protocol wel heel erg verouderd lijkt mij...

[Reactie gewijzigd door Luukje01 op 24 juli 2024 00:14]

[DoubleJOnline]

Technologie, dat zo breed in gebruik is als het HTTP-protocol vervang je niet even zomaar. De techniek mag dan wel verouderd zijn, het is een bewezen techniek(betrouwbaar, duurzaam, etc.) en het vervangen ervan kost vermogens.

Mocht dit inderdaad een goede vervanger blijken te zijn, dan duurt het toch enkele jaren voordat het volledig in gebruik genomen is.

Kijk ook maar naar het nieuwe IPv6. Binnenkort is er een grootse noodzaak om dit wereldwijd geimplementeerd te hebben, echter i.v.m. kosten duurt het tijden voordat iedereen gemigreerd is.

[Huppie]

Als je de whitepaper leest dan weet je dat het SPDY protocol niet een vervanger is van het HTTP protocol maar in principe werkt bovenop het HTTP prototcol. Het voordeel van de manier waarop ze SPDY implementeren is juist dat het enige wat gepatcht hoeft te worden de server-software en de client-software zijn.

Zodra de zowel de server-software als de browser het protocol ondersteunt werkt het. In de websites zelf hoeft niet aangepast te worden.

IPv6 is een iets ander verhaal. Zolang er nog geen absolute noodzaak is om de infrastructuur aan te passen zal nietmand het doen. Er komt echter een moment dat we echt op 't randje zitten en dan zal men waarschijnlijk vanzelf de backbone opnieuw gaan bekijken.

Zodra er server-software en browser-software is die het SPDY protocol ondersteunt zullen er webhosts komen die adverteren dat hun webhosting-service gebruik maakt van het nieuwe, 50% snellere protocol.... waardoor er waarschijnlijk heel snel meer webhosts zullen volgen.

[To_Tall]

Waarvoor zou het vermogen kosten?

Als je een client met SPDY en met HTTP uitrust. Dat lijkt mij gewoon een software update.. en servers langzaam laat overgaan naar spdy dan kan het wel een paar jaarduren. maar veel hoeft het niet te kosten!!

[Verwijderd]

Alles, op de hele planeet, wat iets met internetsites doet, moet vervangen worden. Bedrijven moet je overtuigen van updaten, particulieren, voorlichting. Het moet uitvoerig getest worden. Enzovoort.
Denken dat dat zomaar eventjes gaat is ernstig naief.
Er zullen zelfs hele clubs zijn die nee gaan roepen omdat he van google is en hun vinger dan wel heel erg dik word in de pap, krijg je dat getouwtrek ook nog.
Sterker nog ik weet niet of je het wel zou willen.

50% sneller heel leuk, maar het is nou niet waarvan je zegt een probleem dat echt actueel is met het HTTP protocol.
Vind het dus een beetje een raar argument als dat alleen staat.

[Huppie]

Allereerst moet duidelijk zijn dat SPDY absoluut géén vervanger is van HTTP. Het is in principe een implementatie bovenop het HTTP Protocol, zij het dat ze hier en daar wat features licht aangepast hebben om een aantal nieuwe voordelen te bieden.

Er zijn meer voordelen dan alleen snelheid.
- Het standaard onderliggende protocol van SPDY SSL. Waardoor dus alle verbindingen by default beveiligde verbindingen zijn.
- Er komt een mogelijkheid tot het pushen van resources vanaf een server. Zodra een verbinding bestaat tussen client-en-server kan de server de client op de hoogte stellen van wijzigingen in de achterliggende gegeven. Dit lost een heleboel AJAX-Polling problemen op die je ziet in moderne web-applicaties.

Zie ook de whitepaper waarin de achterliggende gedachte duidelijk gemaakt wordt. (Tip: onderin staat een FAQ )

[2playgames]

Het standaard onderliggende protocol van SPDY SSL. Waardoor dus alle verbindingen by default beveiligde verbindingen zijn.

En dus iedere hobbyist een certificaat zal moeten gaan hebben?

[Verwijderd]

Een certificaat is helemaal niet zo speciaal als je impliceert.... Het enige probleem ligt bij M$,

Hoewel ik er altijd een groot voorstander van ben om MS de schuld van alles te geven is dat in dit geval onzin.
Waar jij op doelt is de lijst met trusted certificates of root certificates, als je MSIE gebruikt wordt die inderdaad standaard door MS gevuld, maar je kunt ook zelf een root certificate importeren.
Het hele certificaat-gebeuren heeft 2 doelen: verificatie en encryptie. De tweede is bij de meeste mensen wel bekend: door middel van de sleutels in de certificaten wordt het https verkeer versleuteld. De eerste is minder bekend, maar minstens net zo belangrijk: daarmee kan je, door middel van een certificaat bewijzen dat je bent wie je zegt dat je bent. Bij de koop van een certificaat controleert de CA (Certificate Authority) of je bent wie je zegt dat je bent en geeft je dan een door de CA ondertekend certificaat. Je browser kan, door middel van de lijst root-certificaten controleren of je certificaat inderdaad getekend is door een "echte" CA.
Je kunt ook zelf een certificaat ondertekenen, maar dan kan je het dus in principe alleen gebruiken voor encryptie.
Daar heeft Microsoft dus echt 0,0 mee te maken. Overigens... een van de grootste CA's van de wereld heeft een aantal jaar geleden Mark Shuttleworth 575 miljoen dollar betaald voor zijn bedrijf Thawte... en Shuttleworth heeft met dat geld Ubuntu uit de grond gestampt... het is dus eigenlijk allemaal de schuld van Linux :-)

[2playgames]

Een certificaat is weinig zinvol als dit niet door een betrouwbare partij is gemaakt. Zo'n partij zal dit nooit gratis doen (dan kunnen ze een goede check van de site niet betalen) en dus blijft de gemiddelde sitemaker zonder of met een zelfgemaakt certificaat zitten.
Ik roep altijd dat SSL zonder certificaat ook moet kunnen werken. Dan heb je alleen de encryptie, niet de identiteitscheck, maar dat is al beter dan niks.

[Verwijderd]

Ik roep altijd dat SSL zonder certificaat ook moet kunnen werken. Dan heb je alleen de encryptie, niet de identiteitscheck, maar dat is al beter dan niks.

Dat kan ook. Je kunt je eigen certificaten ondertekenen.

[2playgames]

Dat kan ook. Je kunt je eigen certificaten ondertekenen.

Ja, en dan krijgt de bezoeker ongeveer dit te zien:

WARNING WARNING THIS CERTIFICATE IS INVALID
IF YOU ENTER THIS SITE YOU DIE!!!

[Daimanta]

Een beetje cru gezegd maar het is wel waar. Certificaten hebben 1 zeer groot mankement, de lease. Je moet zo'n ding namelijk bij een "Trusted CA" registreren om het mooie gele slotje te krijgen naast je URL. En daarvoor moet je geld betalen aan de CA en veel sitebeheerders hebben daar (terecht) lak aan omdat je eenvoudigweg onversleuteld berichten kan versturen en niemand interesseert zich daar voor.

Wat het bericht boven mij op doelt is dat Firefox je een extreme waarschuwing geeft als je je zelf opgezette certificaat gebruikt die wel werkt maar niet te verifiëren is. Als een doorsneegebruiker iets dergelijks ziet dan verlaat hij in angst de site om er vermoedelijk niet weer naar terug te keren.

Mijn mening is dat de koppeling authenticatie/versleuteling te streng gelegd is in SSL waardoor we nu vastzitten aan versleutelde sites met authenticatie en niet versleutelde sites zonder authenticatie die geen versleuteling kunnen krijgen zonder geld te betalen.

[OddesE]

Ze checken de site niet voor zover ik weet. In plaats daarvan moet je betalen voor een certificaat zodat ze kunnen controleren dat je bent wie je zegt dat je bent. Zodat alleen Google maar het certifcaat google.com kan krijgen.

Verder hoeft, net als bij normale verbindingen, alleen de web server maar een certificaat te hebben en niet de computer thuis. Tenzij je bedoelt hobby sites, maar die zijn tegenwoordig toch bijna allemaal onderdeel van een grote website (Facebook, Wordpress, Blogger etc) en je kunt ook op HTTP blijven natuurlijk.

[Herko_ter_Horst]

Hoezo ligt dat probleem bij Microsoft? Als ik Firefox gebruik, heb ik te maken met de lijst die Mozilla standaard in Firefox stopt, niet met de lijst van Microsoft. Dit geldt voor heel veel andere applicaties ook (om nog maar te zwijgen over andere operating systems).

[afterburn]

@Reflian: Ik geloof dat jij je eerst even moet gaan inlezen, voordat je weer begint met Microsoft bashen. Ik snap ook niet dat je hier überhaupt nog een 0 score voor krijgt, ipv een -1.

Microsoft levert met hun browser, net als iedere andere browsermaker, oa de Verisign root certificaten mee. Deze root certificaten zijn noodzakelijk om te kunnen verifiëren of een certificaat welke door een website aangeboden wordt, valid is. En Verisign is niet de enigste; er zijn een aantal trusted root certificaten, en deze roots worden in elke browser en elk systeem meegeleverd. En ja, Microsoft heeft zelf ook een root. Net als Apple. Maar Microsoft heeft op generlei wijze en op geen enkele manier het beheer, controle of monopolie op certificaten. Dat is gewoon regelrechte FUD.

[Verwijderd]

Ik had inderdaad het whitepaper nog niet gelezen, zal dit wel even gaan doen.

Het standaard onderliggende protocol van SPDY SSL. Waardoor dus alle verbindingen by default beveiligde verbindingen zijn.

Dit is dan wel weer mooi. Maar ergens vermoed ik dat zoiets als dat nooit echt veilig, veilig gaat worden. Voornamelijk omdat internets dan niet zonder meer meer af te tappen is en dat vind onze, onze?, de EU regering vast niet zo heel erg leuk.

Als het idd HTTP niet gaat vervangen maar complementeren is het best uit te rollen. Dan heb je, in principe, geen update plicht en kan de tijd zijn werk doen. Ooit word hardware en software immers vervangen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:14]

[Korben]

Allereerst moet duidelijk zijn dat SPDY absoluut géén vervanger is van HTTP. Het is in principe een implementatie bovenop het HTTP Protocol, zij het dat ze hier en daar wat features licht aangepast hebben om een aantal nieuwe voordelen te bieden.

Licht aangepast... Zo kun je ook wel stellen dat WDDM (het Vista display driver-model) een aangepaste implementatie van WDM (het 'oude' driver-model) is. Toch wens ik je veel succes een WDM-driver onder Vista werkend te krijgen.

Overigens zijn een aantal van die voordelen niet zo rooskleurig als ze lijken. Verplichte SSL bijvoorbeeld lijkt me eerder een nadeel dan een voordeel. Zoals Ars Technica het stelt:

Making SSL mandatory is a strange move that has the potential to increase the number of people who don't bother getting a proper certificate for their server, meaning that users will become even more blasé about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

Daarnaast vereisen ze gzip-compressie, en de combinatie van die twee zorgt ervoor dat pagina's veel zwaarder worden om te verzenden, zeker voor mobiele devices.

[Herko_ter_Horst]

De volledige overgang zou enkele jaren duren? Zeg maar gerust enkele decennia...

Iets dat werkt, wordt niet zo gauw geheel vervangen.

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 00:14]

[i-chat]

waarom zou je het vervangen...
er bestaan al zoveel webprotocollen (torrent, is ook zomaar ineens onstaan), en http / https zijn zomaar ook naast elkaar terweil ze toch verschillend zijn.... (al is het met maar weinig

kortom.... gewoon in inbouwen in apache en de 3 grote browsers (engins) gecko, webkit en hoe heet die van opera ook al weer ??? .... (tja IE zal wel weer niet mee doen)...

want als het echt zo veel sneller is, dan is het leuk voor webapps.. maar meer ook niet...

[ameesters]

wat denk je van de smartphone boom die we nu mee maken, mobiele internet is tegenwoordig niet weg te denken, maar kun je je voorstellen dat je straks echt gigantisch sneller op je mobiel surf? lijkt mij in ieder geval geweldig, ik denk dat dit wat beter te implementeren is dan draadloos fiber verbinding:P

ook de hoeveelheid data die de gemiddelde gebruiker nodig heeft vandaag de dag zal de komende jaren nog alleen maar groeien, en bandbreedte consumptie wordt elk jaar hoger. Op deze manier kan het zo zijn dat over een decennia de rek uit ons huidige http protocol is, en de bandbreedte schaars wordt, en dan kan je 2 dingen doen, of het complete internet vervangen met een technologie die de bandbreedte op kan vangen, of een efficiëntere protocol te gebruiken..
en ik stem voor het laatste

[Verwijderd]

... lijkt mij in ieder geval geweldig, ik denk dat dit wat beter te implementeren is dan draadloos fiber verbinding:P ...

Ok, hier moet ik toch echt even op reageren hoor. Jij moet bij TellSell gaan werken! Briljant! Ik denk dat je gelijk hebt ja, een draadloze draad verbinding kan nog lang op zich laten wachten. Evenals de lange-afstands raket voor de korte afstand en de antimaterie materie

Echt droog dit

[Yakotb]

IPv6 ligt ook al heel lang klaar, maar alleen XS4ALL biedt het van de consumentenproviders in Nederland aan. De rest vindt het allemaal te duur of te veel werk. Alleen als er een absolute noodzaak ontstaat dan zal het ingevoerd worden. Hetzelfde geldt in dit geval voor SPDY denk ik.

[FireDrunk]

Onzin, WIndows (en Linux) werkt ook, maar dat vervangen we ook elke zoveel jaar.

Als webservers (Apache, IIS, LightHTTPD) stapsgewijs een dual-server (HTTP + SPDY) implementeren, en die bijvoegen in hun nieuwe releases, gaat het prima.

Microsoft, Mozilla en Opera maken hun browsers allemaal ook dual-client (of maken 2 versies) en informeren gebruikers dat er een update is...

Het gaat al jaren zo... De leverancier maakt iets wat 2 standaarden ondersteunt, en de gebruiker zorgt dat hij 2 standaarden kan accepteren.

Daarna word stapsgewijs de oude standaard uitgefaseerd...

[tuXzero]

Ik dacht dat dat protocol backwards compatible was. Het is daarom niet vergelijkbaar met IPv6 die dat niet is. Als je geen cent investeert dan werkt het wel alleen niet op top snelheid.

[jbdeiman]

Het ligt op de applicatielaag, dus het is een softwarematige en geen hardware matige oplossing. Of het http gaat vervangen of niet doet er daarbij verder niet toe, het zal helemaal geen hoge kosten met zich meebrengen. De data die naar de cliënt wordt verstuurd wordt op een kleine/ compacte manier verstuurd waarna de cliënt deze data weer uit kan lezen.
De snelheid over de kabel wordt hoger, maar zal (waarschijnlijk, omdat het ook verwerkt moet worden) iets meer rekenkracht kosten. Nu is dat tegenwoordig totaal geen probleem.

[mae-t.net]

Je hoeft helemaal niks te vervangen, de protocollen kunnen naadloos naastelkaar gebruikt worden. Tot in de lengte der jaren zelfs. Dat ik overal SSH gebruik inplaats van Telnet betekent immers ook niet dat Telnet niet meer werkt?

[lesderid]

"Bovendien zou een eventuele overgang van http naar het Spdy-protocol uitsluitend stapsgewijs en over een langere termijn kunnen plaatsvinden, zo benadrukken de ontwikkelaars."

[himlims_]

Ik heb weinig gedetailleerde informatie omtrent HTTP en TCP-IP, maar bij mijn opleidingen enkele jaren terug stond al geschreven dan TCP/HTTP relatief oud/buggy/gammel zijn. Een van de voornaamste min-punten is dat TCP-IP (via HTTP) erg veel (overbodige) informatie herhaaldelijk communiceerde. Een pakket bevat informatie van wie het is en waar het heen moet(label). Iedere keer weer opnieuw. Dit kan er tot leiden dat bij veel (kleine) data, dat het label-kaartje meer data bevat dan het pakketje waar het om gaat.

Natuurlijk kun je zeggen hoezo gammel? Alles (het internet) werkt toch na behoren, en als ik www.tweakers.net tik, krijg ik mijn vaste frontpage. Men krijgt IP-adresjes en communicatie over de gehele wereld is mogelijk. Dat klopt wel maar .. qua communicatie is het relatief fout gevoelig (afhankelijk in welke volgorde en of de pakketjes binnen komen). Mensen die zich wat dieper in communicatie hebben geworpen dan het standaard OSI-model, weten dat TCP en HTTP eigenlijk achterhaald zijn.

Echter zijn deze eerste (beta?) technieken zo hard gegroeid, en over de gehele wereld ingeburgerd, dat updaten/vervangen niet zomaar mogelijk is. Neem nu het IPv6 verhaal. Iedereen weet dat het aantal vrije ip-adressen sterk daalt. Daarvoor zou IPv6 de toekomst veilig stellen.

Vraag me sterk af over HOE men dit standaard zou willen 'upgrade' naar meer hedendaagse technieken. Immers leunt onze halve (digitale)samenleving op deze verouderde technieken. Als de fundering van een gebouw veranderd moet worden, moet het gebouw plat ... toch?

"het protocol vooralsnog op beperkte schaal getest. De ontwikkelaars stellen dan ook dat Spdy nog lang niet volwassen genoeg is om op grote schaal toegepast te worden"

Dat was ook het probleem met HTTP en de manier waarop onze netwerken communiceren. En toch is die techniek uitgegroeid tot ons primaire communicatie tooltje .... time will tell

[Mental]

Als je je dan toch gaat verdiepen in het OSI model dan kom je er ook achter dat TCP en HTTP niet in dezelfde laag voorkomen
HTTP is inderdaad al behoorlijk oud en is aan vervanging toe, tcp/ip daarintegen werkt nog prima en ondergaat zelfs future-ready veranderingen (denk aan ipv6, werkt ook gewoon met TCP.. het is geen vervanging zoals jij suggereert).
Het vervangen van TCP/IP door een ander protocol zou een bijzonder complexe operatie worden waar http relatief eenvoudig coexistent kan zijn / vervangen kan worden.

Opzich een aardig verhaaltje wat je typt maar er klopt werkelijk bijzonder weinig van.

[Verwijderd]

Misschien een beetje offtopic, maar relevant denk ik.

Nu kan TCP wel ge-update worden maar daar ligt het probleem echter niet, denk ik.

Alle verbindingen worden tegenwoordig opgezet met het Ethernet-Protocol.
En daar ligt juist het probleem. Als we met zijn alle in 1x IPv6 gaan gebruiken. Dan hebben we in één keer heel veel meer data verkeer nodig. Omdat het IP-adres een veel groter gedeelte van het pakket opneemt.

Met betrekking to Google's Spdy protocool, denk ik, dat ze zo die extra data willen beperken.

Meer off-topic @ Afraca:

Als je de film Babylon A.D. heb gezien dan zie je daar dat Google de "enige" Flow of info is... want alle schermen waar wat op te zien is mbt tot nieuws staat een Google logo op. Dus zo "kan" het worden.

[Myrdhin]

Het ethernet protocol werkt niet met IP adressen, daar zorgt de netwerk laag voor die bovenop de ethernet laag ligt (TCP/IP architectuur werkt met een 4 laags model en is later vertaald naar het 7 laags OSI model, zie: Internet Protocol Suite: Layers). Ethernet werkt met MAC adressen.

En als je dan toch over het ethernet protocol praat, daarbij is het juist helemaal niet zo erg dat de pakketjes wat groter worden door de extra data die het IP protocol nodig heeft voor IPv6, want naarmate de snelheid omhoog gaat moet de pakket lengte groter worden, zie: Ethernet: 1000Mbps or more, het stukje over "Effect on network size". Hetzelfde probleem trad ook op bij de overgang van 10Mbps naar 100Mbps.

Conclusie: sneller betekent niet dat je data wilt beperken. Het is zo, dat om het efficienter te maken je juist het tegenovergestelde wilt: zo weinig mogelijk pakketjes van het liefst zoveel mogelijk data (Jumbo Frames bij Gbit netwerken...).

Ik denk dat het SPDY protocol juist zoveel mogelijk data probeert samen te vatten in een enkel pakket. HTTP 1.1 had niet voor niets al Persistent connections om het aantal pakketjes te verkleinen (o.a. opbouwen nieuwe verbinding).

[Reactie gewijzigd door Myrdhin op 24 juli 2024 00:14]

[Verwijderd]

Volgens mij heeft HTTP niets van doen met de packet size op TCP/IP. En labels met van wie het komt en waar het heen moet heeft ook niets met HTTP te maken.. Ik begrijp dus niet waarom je het TCP protocol er bij betrekt.. Als je het OSI model zo goed hebt bestudeerd dan weet je dat HTTP op een heel andere laag opereert namelijk de Applicatie laag. TCP is transport ofwel waar het bericht in stukjes geknipt wordt en verpakt wordt. Dan gaat je pakketje naar de Netwerk laag, hier krijgt het adres labels. Daarna gaat het naar de Datalink laag waar het via Ethernet verzonden wordt.. Als je wilt voorkomen dat pakketen opnieuw verzonden worden gebruik je UDP in plaats van TCP. Dit wordt bijvoorbeeld voor streaming video veel toegepast, waar het geen zin heeft om een pakket met informatie over het beeld te versturen dat je 2 seconden geleden al hebt bekeken. Lees anders deze even: http://nl.wikipedia.org/wiki/TCP/IP met name het stukje "Lagen".

[Klaus_1250]

Dat is niet correct natuurlijk. HTTP word over TCP verstuurd, dus er is wel degelijk een relatie. Vroeger hield je als webdesigner rekening met de grootte van pagina's, stylesheets, images, etc zodat ze in zo min mogelijk TCP/IP packetjes gingen. Zorgde voor betere performance en minder bandbreedte-verbruik/kosten.

Zeker bij modem-verbindingen kon je de performance van pagina's enorm verbeteren. Nu is dat niet meer echt van toepassing (tenzij je een perfectionist bent) omdat iedereen breedband en snelle computers heeft en het er allemaal niet meer zo toe doet.

Maar voor bedrijven als Google zijn dit soort zaken wel interessant aangezien ze miljarden pagina's per dag serveren en inefficientie door nutteloze HTTP-headers of TCP packets die worden verzonden omdat er net 1 byte niet meer in de vorige packets paste zijn dan de moeite om onder de loep te nemen.

[engibenchi]

Ik kan mij voorstellen dat het voor de cliënt minder belangrijk is. Maar aan de kant van de server kan ik mij voorstellen dat het nog wel uitmaakt.
En als er daar efficiënter gewerkt wordt merk je dat als klant toch ook?

[gizmostudios]

Hoe staat het vandaag de dag met het (in het verleden) veelbesproken Comet protocol? Dit zou ook veel sneller werken dan het huidige HTTP, waar het ook non-lineaire communicatie kon verzorgen tussen client en server. Daar hoor je nu helemaal niks meer van.. en nu zo out of the blue komt Google met Spdy.

[OddesE]

Web Sockets uit HTML 5 zouden een cross-browser alternatief moeten gaan vormen voor Comet.

[afraca]

Bij mijn weten (en wat ik even kan vinden), is Comet geen nieuw protocol, maar een "web application model", waar iets anders met http requests wordt omgegaan.

Daar komt uiteraard bij dat het hier Google betreft...... En Google is zeker een interessant onderwerp, als je ziet wat voor gigant het aan het worden is. Ik laat mij hier niet uit of ik dit echt geweldig vind (ok, eigenlijk wel, ik ben zo'n iemand die Google beetje creepy gaat vinden.....). Het innoveert op vele terreinen, en met z'n naamsbekendheid weet het een enorm publiek aan te trekken. Chrome, maps, video's, gmail, Go (nieuwe programmeertaal), google docs, google news, google blogs, google earth, google translator, Chrome OS en uiteraard nog de zoekmachine

[Verwijderd]

Comet is een Ajax achtige manier van werken waarbij je Javascript laat wachten op een server event. Dat bestaat al lang, en is niets nieuws, het is gewoon een manier van werken. Comet had je sinds het bestaan van (i)frames al toe kunnen passen, maar natuurlijk met de xmlhttprequest is het wat simpeler geworden.

[chaos.be]

Ik vind het gek dat wibra naar omlaag wordt gemod, maar misschien was zijn reactie iets te agressief?

Anyhow, himlims... TCP-IP wordt helemaal niet vervangen, enkel HTTP. Een een HTTP-response uitvoeren via een ander kanaal dan TCP-IP zie ik niet direct gebeuren.

Als je een HTTP-request-response analyseert kan het waarschijnlijk wel zijn dat deze veel te bulky zijn. Dit is waarschijnlijk waar het protocol van Google tussenspringt. Maar wat ik meer verwacht is modernisatie zoals bvb een Push-systeem want dit is werkelijk een heikel punt bij HTTP, de browser moet alle aanvragen regelen bij een HTTP-protocol.

Er bestaat wel zoiets als het Comet-pattern om een push-systeem te emuleren, dit zie je bvb aan het werk bij een facebook chat. Maar de truuk die daar wordt uitgehaald is een ongelofelijke mis-manipulatie van waarvoor het HTTP-protocol origineel voor ontwikkeld is.

[OddesE]

Check out HTML 5 en dan vooral Web Sockets

[Toolskyn]

Wat een onzin allemaal. Ten eerste is het precies andersom, het HTTP protocol gaat over het TCP/IP protocol. HTTP heeft totaal geen weet van het TCP protocol. Al stuur je een HTTP request via de post. Waarom je die twee bij elkaar pakt is me sowieso onduidelijk. Verder zie ik niet in waarom TCP gammel is. Als ik een gigantisch bestand van 4 GB overstuur via internet heb ik bijna nooit aan het einde een corrupt bestand. Dat je zo'n groot bestand de hele wereld over kan krijgen zonder een foutje is nou niet bepaald gammel te noemen. Dat is overigens ook het enige en enkele doel van TCP, informatie zonder fouten van de ene naar de andere computer brengen. Het IP protocol zorgt ervoor dat het ook nog eens naar de goeie computer gaat.

Verder kan er prima een extra protocol naast HTTP leven. Er is geen enkele reden waarom een browser niet twee protocollen zou kunnen ondersteunen. Als de gemiddelde browser een klein beetje modulair is opgebouwd (en dat zijn ze echt wel) dan is het eigenlijk zelfs relatief eenvoudig om zo'n nieuw protocol toe te voegen, zonder dat iedereen opeens moet stoppen het HTTP protocol te gebruiken.

[Reactie gewijzigd door Toolskyn op 24 juli 2024 00:14]

[mae-t.net]

Loopt spdy dan niet meer over TCP?

In het artikel staat daar in elk geval niets over.

[Verwijderd]

ALS het 50% sneller zou moeten zijn, dan is de HTTP-protocol wel heel erg verouderd lijkt mij...

Het is ook al behoorlijk gedateerd, maar het werkt nog steeds.

De "traagheid" zit vooral in de vragen van de client c.q. het is client gedreven.
1) Vraagt pagina x
2) De wordt gestuurd
3) Als de text van de pagina binnen is ziet deze dat content 1 tm n (plaatjes, flash wat dan ook) nog is en vraagt dit weer op.
4) Deze contect wordt gestuurd.

Als de server dit in de eerste request al aan zou kunnen bieden zou je tijd willen. Zeker bij verbindingen met hoge latency.

[Naatan]

Dit is onzin, dat je meerdere HTTP requests moet uitvoeren om de plaatjes in een pagina te laden heeft niks met het protocol te maken. Je kunt niet verwachten dat een protocol je pagina code gaat analyseren, dat heeft niks met de werking van een protocol te maken.

Verder lijkt me dit protocol wel een mooie vooruitgang, ik kan me vaak dood ergeren aan de sloomheid van het HTTP protocol, zeker als je in apps gebaseerd op een single thread language (zoals php) gebruik moet maken van op http gebaseerde web services zoals SOAP of REST.

[McCloud]

Zou dat niet gewoon liggen aan de sloomheid van de service logica achter die SOAP of REST interface? De traagheid bij ditsoort apps zit eerder in de traagheid van de SOAP stack, de XML parsers en unmarshallers en de service logica dan in het HTTP protocol. Maar alles moet tegenwoordig in XML anders is het niet sexy. XML = data dressed up as a hooker.

[Naatan]

Natuurlijk zal het parsen van XML wat tijd kosten maar het is absoluut niet vergelijkbaar met de vertraging van het HTTP protocol.

Stel ik parse een XML string vanuit een lokaal bestand ter vergelijking met een XML string die dmv een http link ingeladen wordt. Ik garandeer je dat het gross (gros?) van de laadtijd bij de http request ligt.

Natuurlijk heeft afstand er ook wat mee te maken maar wanneer je het vergelijkt met een protocol zoals TCP of SSH heb ik altijd toch het gevoel dat HTTP wat langer op zich laat wachten.

[OddesE]

Toch honderd keer liever XML dan terug aar iedereen zijn eigen formaatjes verzinnen en voor elk formaatje een nieuwe parser schrijven.

[zeemeerman2]

Dan krijg je wat bij IE een lange tijd zo was. (mss nu nog? ik weet het niet)

Je krijgt een witte pagina totdat alles geladen is.

Nu kun je tenminste al de tekst van een site lezen vooraleer extra opmaak (randen, arcering, ...) en afbeeldingen, video, etc... is geladen.

Je kunt de lijn ook doortrekken:
Beeld je eens in om een witte pagina te krijgen bij een YouTube-filmpje in HD totdat het hele filmpje is geladen. Dan ben je toch blij dat YouTube maar een 10 min. limiet heeft.
Of een Youtube Full HD filmpje...

Wil je intussentijd niet even de comments lezen terwijl je wacht op je filmpje?

Dat is de reden waarom vele browsers dit in stukken laden in plaats van ineens.

[Joolee]

De server kan natuurlijk ook de HTML pagina als eerste aanbieden Wat worldcitizen bedoeld is dat er geen extra request voor de extra content nodig zou hoeven zijn. Al die nieuwe request kosten een hoop overhead waarbij nogmaals bijv. je cookies en alle http headers verzonden worden.

[Pinkys Brain]

Als er eenmaal een IETF RFC is zal het snel gaan denk ik (zeg een half jaar voordat support en een paar websites opduiken). Toevoegen van het protocol aan Firefox/Apache is niet zo heel veel werk, en goede webdevelopers zullen met de push/hint opties ook niet zo veel moeite hebben.

[mrlammers]

Yup, het protocol stamt uit 1999. Een 'ouwe taaie' dus.

[Verwijderd]

Hoeveel overhead heeft het HTTP protocol dan precies? Stel op een gemiddelde site van 50kb heeft HTTP 10% overhead, dan is dat SPDY 50% sneller, dus zou maar 5% overhead hebben. De totale site is dan 5% sneller, wat denk ik niet het invoeren van een heel nieuw protocol rechtvaardigt... Helemaal met de steeds sneller wordende internetverbindingen waar het HTTP verkeer steeds minder voorstelt in vegelijking met de 1080p youtube streams, P2P verkeer, online games etc.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:14]

[metaal]

In de eerste plaats heeft HTTP last van latency. Je kan maar 1 resource per keer opvragen (is wel wat verbeterd met keep-alive, maar dat is meer een workaround). Bovendien kan de content van een pagina wel gecompressed worden, maar de headers niet. Dan beginnen de headers opeens toch wel een groot deel uit te maken van de request. Veel headers zijn daarnaast dubbelop, bijvoorbeeld de user-agent header, die hoef je niet elke keer te versturen.
Verder worden steeds meer webapps AJAX achtig, en willen data op verzoek van de server ophalen. Dit is niet mogelijk met HTTP, en er moeten trucks worden uitgehaald om dit toch te kunnen. Spdy zal hier waarschijnlijk ook wel een oplossing voor bieden.

[elmuerte]

HTTP is een stateless protocol, dus je moet alle headers die van belang zijn elke keer opnieuw sturen. Dit zal je ook bij SPDY moeten doen, tenzij je er een stateful protocol van maken, wat enorm onhandig zou zijn.

In ieder geval is het niet HTTP die het internet traag maakt, maar de websites zelf en alle troep die ze in de HTML verstoppen.

[Romke]

Er wordt juist steeds meer gebruik gemaakt van HTTP als protocol voor dataoverdracht, omdat de HTTP poorten praktisch overal open staan.

[i-chat]

dan moet je toch nog eens verder gaan lezen..

sorry dat ik het zo stel, - mare, omdat men probeerd te zorgen dat je niet kunt msnen op je werk (door poorten dicht te gooien krijg je hacks om over http te werken). en vervolgens post je hier vrolijk 'dat spdy wel niet zal slagen omdat http zo populair is?

als http een concurent krijgt, (en dat is zeer wel mogelijk) - gaat de msn over http hacks natuurlijk nog geen cent meetellen in de overweging. - en als port 80 vervolgens wordt vervangen voor port 666 - dan heeft de hele it-sector binnen dag 666 default open staan (als dat zou moeten).

kortom....

[Myrdhin]

Dat zeg je verkeerd: er wordt steeds meer (mis)gebruik gemaakt van de poort die aan het HTTP protocol is toegewezen..

[BlueLed]

Dus dan kunnen alle websites als spdy.alsikinje.com of spdy.google.nl worden gevonden?

[jvo]

Nee, spdy:\\google.com waarschijnlijk.

En een browser kan eventueel zelf checken of er een spdy:\\ alternatief is bij het intikken van google.com.

[Reactie gewijzigd door jvo op 24 juli 2024 00:14]

[lesderid]

waarom backslashes?
spdy://www.google.com/spdy/

[Umbrah]

Hmmm, was het niet een van de eerste ontwikkelaars van het HTTP protocol die zei dat hij spijt heeft van die eigenlijk nutteloze slashes? Hij had ooit eens gekeken hoeveel inkt/papier/gigabyte/elektriciteit die 3 nutteloze tekens (://) gekost hebben, en vooral aan toner is dat een schokkende openbaring.

Verder denk ik dat het eerder iets zou zijn als:

www.google.com

waar de browser éérst kijkt of er op het spdy-protocol er een server draait, vervolgens op http, daarna op udp, daarna op FTP? Handmatig aangeven kan, maar door 'defaults' en priorities te gebruiken is het voor de 50-plussers ook te doen.

[Herko_ter_Horst]

Het is best mogelijk dat user-agents gebruikersinput zonder scheme op die manier gaan interpreteren, maar qua standaard komt er vrijwel zeker iets met spdy://.

Dit heeft dus niets met het spdy protocol zelf te maken, maar wel met de geldende URL syntax standaard.

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 00:14]

[mae-t.net]

En wat nu als al die protocollen in gebruik zijn en je wil kiezen?

[Verwijderd]

Nee, spdy:\\google.com waarschijnlijk.

De uitvinder van http heeft zich onlangs verontschuligd voor de twee streepjes, dus die zullen wel weggelaten worden zeker.

[Herko_ter_Horst]

Die twee streepjes zijn gewoon onderdeel van de URI/URL standaarden, dus die zie ik niet zo gauw verdwijnen.

[jip_86]

Jaha, dat klopt. Alleen heeft Tim Berners Lee zich verontschuldigt voor het feit dat dit een foutje was. Oorspronkelijk was dit niet de bedoeling.
http://www.dailymail.co.u...-web-address-mistake.html

[Herko_ter_Horst]

Ik krijg meer de indruk dat TBL's reactie humoristisch bedoeld is, zo van "waar maakt iedereen zich in hemelsnaam druk om".

[2playgames]

Die indruk krijg ik niet. Hij heeft gewoon gelijk, die slashes zijn nutteloos

[Toolskyn]

Ach beetje relativeren. Op het moment dat hij bedacht hoe een URL eruit moest zien wist hij ook niet dat die dingen zo massaal gebruikt zouden gaan worden. Je kan je natuurlijk net zo goed gaan afvragen waarom je in C++ dingen als -> hebt (2 karakters). Het zou ook miljoenen toetsaanslagen schelen als dat niet zo was geweest. Maar waar praten we dan over De meeste mensen typen toch geen http:// in, dat laten ze de browser aanvullen. Daarbij is die extra inkt ook wel te verwaarlozen in vergelijking met wat er in totaal aan inkt gebruikt wordt.

[Blokker_1999]

waarom niet? Wat is er mis met bijv http:tweakers.net/nieuws ?

[Herko_ter_Horst]

Op zich niks, maar die URL voldoet niet aan de syntax voor hierarchische URLs. En die standaard gelijk ook even vervangen, is een iets grotere uitdaging.

[Ultraman]

Denk eerder als: "spdy:google.com" ipv "http://www.google.com".
Maar dat is even een gokje, heb er namelijk nog niets over kunnen lezen. Nu eens gaan doen

Dit ligt er namelijk totaal aan hoe ook browsers dit gaan implementeren.
Interessant: http://dev.chromium.org/spdy/spdy-protocol

[Reactie gewijzigd door Ultraman op 24 juli 2024 00:14]

[Verwijderd]

Of we happen uberhaupt me dat lamlendige gedrag in de browser.
Dat is iets wat ik me al tijden afvraag. Waarom staat er tegenwoordig nog http in de adresbalk en niet gewoon www.blablabla. Behalve als je gericht wat doet met protocollen is het voor de meeste mensen lekker boeiend welk protocol ze gebruiken.

[2playgames]

Omdat het wel degelijk uitmaakt welk protocol je gebruikt. Als je de http:// vervangt door ftp:// krijg je een heel andere pagina.

[Joolee]

Wat ik me eerder afvraag, waarom gebruiken zoveel mensen www.google.com terwijl je er met gewoon google.com ook komt?

[Reactie gewijzigd door Joolee op 24 juli 2024 00:14]

[jbdeiman]

@2playgames
Maar als jij: ftp.domein.nl intikt lijkt me het ook dat dat voor ftp is. Je typt normaal gesproken toch niet ftp://www.domein.nl in?
Op zich maken die protocollen niet zoveel uit. Net als bij een bank bijvoorbeeld. Als iets https is wordt je automatisch doorgestuurd meestal, ook geen probleem voor wat betreft de protocollen. Dit kan prima op de server worden teruggegeven middels een header ofzo.

@Jolee
Omdat er ook veel websites zijn waarbij (is iets met instellingen ofzo) waarbij je niet op de website komt als je geen www. ervoor zet.

[Moonsurfer_1]

Op dat eerste: Toch wel. Dat heeft te maken met hoe het subdomein ftp in de dns-server ingesteld staat. als in de dns ftp:// niet gespecificeerd is, zal ftp.domein.nl ook niet werken. Daarom is het belangrijk dat deze notatie blijft bestaan, of alleszins het gedeelte ftp:

Op dat laatste: ja, ook dat heeft te maken met subdomeinen. Als het domein en het subdomein www in de dns staan ingesteld om naar hetzelfde te verwijzen, dan maakt dat inderdaad niet uit. Als dit niet zo is, dan zal www weglaten niet werken.

[mae-t.net]

Omdat anders niet direct duidelijk is dat het om een URL gaat. Dan zou je weer moeten schrijven http://google.com

[Verwijderd]

Ik denk dan eerder als spdy://www.google.nl

[Verwijderd]

of "s:google.com"

[Bigs]

Het protocol is te enthousiast om succesvol te worden. Een grote verandering als dit gaat er nooit doorkomen. Het standaard SSL gebruiken is leuk, maar als je ziet hoeveel mensen nu al verzuimen om een certificaat te kopen voor hun SSL site zal dit het browsen erg onplezierig maken.

Een aantal van de voordelen worden reeds geboden door HTTP-over-SCTP en de ontwikkeling van SCTP is al een stuk verder (alhoewel het wel wat meer low-level support vraagt). Ik zou m'n energie dus liever daarop richten.

[2playgames]

Standaard SSL kan wel, maar dan moet de certificaateis voor SSL vervallen. SSL dient twee doelen:
- Encryptie
- De identiteit van de server bevestigen

Dit zouden eigenlijk twee aparte onderdelen moeten zijn. Het eerste kan dan wel degelijk standaard aan staan.

[CyberSnooP]

Meestal versleutel je dingen omdat je wil dat alleen diegene waar het voor bedoeld is het kan lezen en de rest niet. Als je de identiteit niet kunt vaststellen van diegene die het kan lezen, hoe weet je dan dat het niet iemand willekeurigs is?

Als je niet weet wie je gegevens kan ontsleutelen, waarom dan versleutelen?

[Pinkys Brain]

Als Google meteen een officiele standaard voor zelf gegenereerde certificates bij SPDY in de RFC stopt zie ik niet in waarom het een problem moet zijn. Zelf gecertificeerde sites kunnen dan gewoon in de browser worden weer gegeven zonder het klassieke slotje.

CERT RR zou een goede zijn, aangezien DNSSEC er aan zit te komen.

[Icekiller2k6]

spdy://www.google.be lijkt me eerder ... het staat namelijk voor de url niet http://spdy.google.be want dan zou de browser het nog steeds als "html" proberen te renderen

[Reactie gewijzigd door Icekiller2k6 op 24 juli 2024 00:14]

[lesderid]

Niemand heeft gezegt dat ze html gaan vervangen, maar het protocol, HTTP.

[a153957]

Hoezo wil je pagina's niet meer als html renderen? alleen het transfer protocol, de data overdracht van server naar client, wordt anders, niet het html/css/java taaltje..

[ari3]

SPDY is geen oplossing. De oplossing ligt in goed ontwerp. Je hebt pas last van latency als je een request doet. De oplossing is dus het aantal request te minimaliseren door goed ontwerp. Tweakers zou bijvoorbeeld beter niet kunnen pagineren (click-through) zodat het doorklikken naar de volgende pagina niet nodig meer is en je dus ook geen last van latency hebt.

[the_stickie]

Je kunt de defecten van een archaïsch protocol niet afvangen door je webdevvers te leren leven met de beperkingen.
Google timmert hier (nog maar eens) serieus aan de innovatie van het internet. Innovatie is het verbeteren van wat bestaat. En om te kunnen innoveren, moet je vaak grondige conceptswijzigingen doorvoeren. Zover ik weet is Google het enige bedrijf dat dat soort innovaties durft aangaan.
Het lijkt er bijna op dat ze spotten met de onkunde van "de rest". Het begon met de zoekmachine, beter dan de rest, toen gmail, beter en meer dan de rest, dan google maps/google earth, beter dan de rest, dan een browser, sneller dan de rest, etc etc...
en nu stellen ze de grondbeginselen van het www (terecht) in vraag.


/disclaimer: ja ik weet ook dat je elders tegenwoordig nog meer space, nog betere kaarten en nog betere zoekmachines vindt.....

[mae-t.net]

En dat er ook voordat Chrome uitkwam al betere, snellere en stabielere browsers bestonden.

[Herko_ter_Horst]

Of nog beter: laten we het hele internet in één grote pagina weergeven. Duurt even voor je hem binnen hebt, maar daarna heb je gegarandeerd geen last meer van latency...

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 00:14]

[Verwijderd]

Het http protocol vervangen

Hoe ging het ook alweer? Hoogmoed komt voor de val?

[Herko_ter_Horst]

Nee, het juiste spreekwoord is: "de geschiedenis herhaalt zich". HTTP is ook ooit klein begonnen en heeft toen een groot aantal andere protocollen geheel of gedeeltelijk vervangen.

Als er genoeg voordeel in zit, zal dat met spdy op termijn niet anders zijn.

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 00:14]

[Verwijderd]

Niet echt een eerlijke vergelijken mijns inziens.
Internet was toen nog heel wat anders dan de gemeengoed dat het nu is.
Het is nu ook vele malen moeilijker dergelijke truucs uit te halen, tenzij je echt met iets innovatief komt. Wat me in dit geval niet echt van toepassing lijkt.

[Herko_ter_Horst]

We hebben het met Gopher en bulletinboards gezien (vervangen door Internet/HTTP), we hebben het met browsers gezien(Netscape=>IE=>Firefox?/Chromium?/Opera?), we hebben het met zoekmachines gezien (Altavista=>Yahoo=>Google). Zodra er iets beters komt, danwel zodra het gemak van iets nieuws het eventuele voordeel van iets anders overstijgt, zal het oude geleidelijk vervangen worden, ongeacht het succes c.q. de verspreidingsgraad van het voorgaande.

[mae-t.net]

Even een beetje op de details letten: http is inderdaad een opvolger van gopher, maar bulletinboards werden opgevolgd door het news-protocol. Dat nog steeds in gebruik is, en niet alleen voor binaries.

[Verwijderd]

Ze zitten in ieder geval niet op hun luie reet, maar timmeren met allerlei tools aardig aan de weg. Ben benieuwd of het ooit HTTP gaat vervangen, waarom niet als het een stuk efficienter is.

[Pyronick]

Als ze het open-source maken, adverteren en bepaalde diensten (YouTube, Gmail, Google Maps, Google Search, etc) bevoordelen met het SPDY protocol dan zal het vanzelf aan slaan.

Ze kunnen het ook zo maken dat als ze via de user agent (of wat er dan beschikbaar is) je browser automatisch doorverwijzen naar een SPDY link zodra men een HTTP link invult.

[RHochstenbach]

Dus Google stelt dat voor. Als spdy een feit wordt, dan moet dadelijk zeker iedereen licentiekosten aan Google betalen om het te gebruiken...

[Herko_ter_Horst]

Anders doe je even een klein beetje onderzoek voordat je begint te blaten...

De draft spec is vrijgegeven onder de Creative Commons - Attribution license, de voorbeeldimplementatie onder de BSD. Niemand hoeft Google dus ook maar een cent te betalen hiervoor.

[jegelie]

Lang leve Creative Commons! Zij maken het internet weer tot wat het vroeger was toen nog niet iedereen erop zat.