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)
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...
ALS het 50% sneller zou moeten zijn, dan is de HTTP-protocol wel heel erg verouderd lijkt mij...
[Reactie gewijzigd door Luukje01 op vrijdag 13 november 2009 17:37]
"Bovendien zou een eventuele overgang van http naar het Spdy-protocol uitsluitend stapsgewijs en over een langere termijn kunnen plaatsvinden, zo benadrukken de ontwikkelaars."
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?
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?
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"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"
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". 
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.
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.
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?
En als er daar efficiënter gewerkt wordt merk je dat als klant toch ook?
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.
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
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
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.
Web Sockets uit HTML 5 zouden een cross-browser alternatief moeten gaan vormen voor Comet.
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.
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.
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.
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.
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).
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 zaterdag 14 november 2009 10:05]
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.
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 zaterdag 14 november 2009 09:34]
Loopt spdy dan niet meer over TCP?
In het artikel staat daar in elk geval niets over.
In het artikel staat daar in elk geval niets over.
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.
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.
Check out HTML 5 en dan vooral Web Sockets
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.
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.
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!!
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!!
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.
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.
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)
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
)Ik had inderdaad het whitepaper nog niet gelezen, zal dit wel even gaan doen.
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.
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.Het standaard onderliggende protocol van SPDY SSL. Waardoor dus alle verbindingen by default beveiligde verbindingen zijn.
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 Alpha Bootis op vrijdag 13 november 2009 19:16]
En dus iedere hobbyist een certificaat zal moeten gaan hebben?Het standaard onderliggende protocol van SPDY SSL. Waardoor dus alle verbindingen by default beveiligde verbindingen zijn.
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).
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.
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.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.
Ja, en dan krijgt de bezoeker ongeveer dit te zien:Dat kan ook. Je kunt je eigen certificaten ondertekenen.
WARNING WARNING THIS CERTIFICATE IS INVALID
IF YOU ENTER THIS SITE YOU DIE!!!
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.
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.
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.
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.
Hoewel ik er altijd een groot voorstander van ben om MS de schuld van alles te geven is dat in dit geval onzin.Een certificaat is helemaal niet zo speciaal als je impliceert.... Het enige probleem ligt bij M$,
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 :-)
@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.
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.
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.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.
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:
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.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.
De volledige overgang zou enkele jaren duren? Zeg maar gerust enkele decennia...
Iets dat werkt, wordt niet zo gauw geheel vervangen.
Iets dat werkt, wordt niet zo gauw geheel vervangen.
[Reactie gewijzigd door Herko_ter_Horst op vrijdag 13 november 2009 18:20]
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...
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...
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
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
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... lijkt mij in ieder geval geweldig, ik denk dat dit wat beter te implementeren is dan draadloos fiber verbinding:P ...
Echt droog dit
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.
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...
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...
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.
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.
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.
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.
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.
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?
Het is ook al behoorlijk gedateerd, maar het werkt nog steeds.ALS het 50% sneller zou moeten zijn, dan is de HTTP-protocol wel heel erg verouderd lijkt mij...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Toch honderd keer liever XML dan terug aar iedereen zijn eigen formaatjes verzinnen en voor elk formaatje een nieuwe parser schrijven.
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.
Yup, het protocol stamt uit 1999. Een 'ouwe taaie' dus.
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.
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.
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.
Dus dan kunnen alle websites als spdy.alsikinje.com of spdy.google.nl worden gevonden?
Nee, spdy:\\google.com waarschijnlijk.
En een browser kan eventueel zelf checken of er een spdy:\\ alternatief is bij het intikken van google.com.
En een browser kan eventueel zelf checken of er een spdy:\\ alternatief is bij het intikken van google.com.
[Reactie gewijzigd door jvo op vrijdag 13 november 2009 17:40]
waarom backslashes?
spdy://www.google.com/spdy/
spdy://www.google.com/spdy/
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.
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.
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.
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 vrijdag 13 november 2009 18:30]
En wat nu als al die protocollen in gebruik zijn en je wil kiezen?
De uitvinder van http heeft zich onlangs verontschuligd voor de twee streepjes, dus die zullen wel weggelaten worden zeker.Nee, spdy:\\google.com waarschijnlijk.
waarom niet? Wat is er mis met bijv http:tweakers.net/nieuws ?
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.
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
http://www.dailymail.co.u...-web-address-mistake.html
Ik krijg meer de indruk dat TBL's reactie humoristisch bedoeld is, zo van "waar maakt iedereen zich in hemelsnaam druk om".
Die indruk krijg ik niet. Hij heeft gewoon gelijk, die slashes zijn nutteloos
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.
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.
Ik denk dan eerder als spdy://www.google.nl
of "s:google.com"
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
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 vrijdag 13 november 2009 17:41]
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.
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.
Omdat het wel degelijk uitmaakt welk protocol je gebruikt. Als je de http:// vervangt door ftp:// krijg je een heel andere pagina.
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 zaterdag 14 november 2009 00:14]
@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.
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.
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.
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.
Omdat anders niet direct duidelijk is dat het om een URL gaat. Dan zou je weer moeten schrijven http://google.com
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 vrijdag 13 november 2009 17:40]
Niemand heeft gezegt dat ze html gaan vervangen, maar het protocol, HTTP.
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..
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 Shadow op vrijdag 13 november 2009 17:44]
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.
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.
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.
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.
Er wordt juist steeds meer gebruik gemaakt van HTTP als protocol voor dataoverdracht, omdat de HTTP poorten praktisch overal open staan.
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....
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....
Dat zeg je verkeerd: er wordt steeds meer (mis)gebruik gemaakt van de poort die aan het HTTP protocol is toegewezen..
Kunnen we dan ook niet gelijk de dubbele slash weghalen in het nieuwe protocol? Aangezien het aardig nutteloos is en de bedenker van het net (kan even niet op zijn naam kome) dit ook toegegeven heeft dat het niet geheel handig is.
Sir Tim Berners Lee
Die dubbele slash is géén onderdeel van het protocol, maar van de URL/URI standaarden. Die gaat dus niet verdwijnen.
Waarom niet? Standaarden kunnen toch ook aangepast worden?
Het is toch best wel handig als je als ontwikkelaar er vanuit kan gaan dat een bestaande standaard niet zomaar even veranderd wordt. Dat er een nieuwe versie komt, ok. Maar als een standaard er eenmaal is veranderd die niet zomaar opeens.
Er zijn anders ook URL's zonder die slashes, bijvoorbeeld mailto:ex@mple.com
Ja, maar dat zijn geen hierarchische URLs.
Er is natuurlijk best iets te bedenken zonder die slashes, maar niet binnen de bestaande URL syntax. En die is nog iets wijdverbreider dan HTTP...
Er is natuurlijk best iets te bedenken zonder die slashes, maar niet binnen de bestaande URL syntax. En die is nog iets wijdverbreider dan HTTP...
spdy:google.com lijkt meer plausibel, aangezien de uitvinder van Http onlangs heeft vermeld dat de // onnodig waren
Kan een nieuw protocol er niet voor zorgen dat spdy, http:// en www overbodig worden in urls?
Dus gewoon google.com of google.be......
Dus gewoon google.com of google.be......
Dat is een implementatie van een URL en zal dus altijd gebruikt worden. Subdomeinen (zoals www) zijn eigenlijk bedoeld voor meerdere locaties/servers/clusters aan te geven in plaats van waar ze nu gebruikt voor worden.
Als je http weglaat, zal de server eerst aan moeten geven welk protocol de client moet gaan gebruiken, zodat websites nog trager laden.
Als je http weglaat, zal de server eerst aan moeten geven welk protocol de client moet gaan gebruiken, zodat websites nog trager laden.
klopt, mijn sites werken over het algemeen ook zonder www.
Er is geen betekenis toegekend aan een bepaald niveau in een domeinnaam, alles onder een TLD (Top Level Domain, zoals com of nl) is een subdomein. Het hele ding, ongeacht het aantal "subdomeinen", heet een domeinnaam.
Dus example.com is een domeinnaam, www.example.com is óók een domeinnaam. example.com is een subdomein van com, www.example.com is een subdomein van example.com.
Zodra er aan een domeinnaam een IP adres is gekoppeld, is het tevens een hostnaam. Dat veel websites gebruik maken van de hostnaam www.domein.ext, is een kwestie van conventie/historie, niet van standaarden. Dat veel domeineigenaren er voor kiezen om domein.ext en www.domein.ext naar dezelfde host te laten wijzen, is een kwestie van klantvriendelijkheid.
Noch HTTP, noch SPDY hebben hier enige invloed op. Hoe domeinnamen en URLs zich gedragen, is namelijk gedefinieerd in andere standaarden (DNS en URL/URI).
Hoe user-agents (client-software, zoals een browser) hier mee omgaan, is aan elke afzonderlijke user-agent.
Dus example.com is een domeinnaam, www.example.com is óók een domeinnaam. example.com is een subdomein van com, www.example.com is een subdomein van example.com.
Zodra er aan een domeinnaam een IP adres is gekoppeld, is het tevens een hostnaam. Dat veel websites gebruik maken van de hostnaam www.domein.ext, is een kwestie van conventie/historie, niet van standaarden. Dat veel domeineigenaren er voor kiezen om domein.ext en www.domein.ext naar dezelfde host te laten wijzen, is een kwestie van klantvriendelijkheid.
Noch HTTP, noch SPDY hebben hier enige invloed op. Hoe domeinnamen en URLs zich gedragen, is namelijk gedefinieerd in andere standaarden (DNS en URL/URI).
Hoe user-agents (client-software, zoals een browser) hier mee omgaan, is aan elke afzonderlijke user-agent.
[Reactie gewijzigd door Herko_ter_Horst op vrijdag 13 november 2009 20:33]
Protocollen moeten geen deel uit maken van de naam van een host!
Een goed concept zou eigenlijk zijn dat je aan de hand van het SRV record in DNS weet met welke server je moet connecten. Op die manier heb je geen http://www.domeinnaam.nl meer nodig omdat je via de browser al zegt dat je het HTTP protocol wilt gebruiken en via een SRV record opzoekt welke server je daarvoor moet hebben.
http://domein.nl zou dan voldoende moeten zijn omdat de browser via DNS opzoekt welke server hij moet pakken en de DNS server dan webserver.domein.nl teruggeeft. SIP en XMPP werken bijvoorbeeld al zo. Je kan gewoon verbinding maken met het hoofddomein in je SIP client en de client weet dan met welke server hij echt verbinding moet gaan maken.
Zelfde geld dan ook voor FTP, dus: ftp://domein.nl i.p.v. ftp://ftp.domein.nl.
Dit geld overigens alleen voor diensten. SSH zou een beetje moeilijk gaan omdat je daarbij toch wel per server verbinding wilt kunnen maken en je niet 1 server hebt die de dienst SSH afhandelt. Ook als je meerdere diensten lever op basis van de domeinnaam gaat dit niet meer op, maar dan zit de naam van de dienst in de domeinnaam verwerkt en niet het protocol (zoals bij www... en ftp...)
Een goed concept zou eigenlijk zijn dat je aan de hand van het SRV record in DNS weet met welke server je moet connecten. Op die manier heb je geen http://www.domeinnaam.nl meer nodig omdat je via de browser al zegt dat je het HTTP protocol wilt gebruiken en via een SRV record opzoekt welke server je daarvoor moet hebben.
http://domein.nl zou dan voldoende moeten zijn omdat de browser via DNS opzoekt welke server hij moet pakken en de DNS server dan webserver.domein.nl teruggeeft. SIP en XMPP werken bijvoorbeeld al zo. Je kan gewoon verbinding maken met het hoofddomein in je SIP client en de client weet dan met welke server hij echt verbinding moet gaan maken.
Zelfde geld dan ook voor FTP, dus: ftp://domein.nl i.p.v. ftp://ftp.domein.nl.
Dit geld overigens alleen voor diensten. SSH zou een beetje moeilijk gaan omdat je daarbij toch wel per server verbinding wilt kunnen maken en je niet 1 server hebt die de dienst SSH afhandelt. Ook als je meerdere diensten lever op basis van de domeinnaam gaat dit niet meer op, maar dan zit de naam van de dienst in de domeinnaam verwerkt en niet het protocol (zoals bij www... en ftp...)
[Reactie gewijzigd door Myrdhin op zaterdag 14 november 2009 10:22]
Volgens Google zelf is het helemaal geen alternatief voor HTTP:
http://sites.google.com/a.../dev/spdy/spdy-whitepaperQ: 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.
Leg eens uit wat je in vredesnaam bedoeld!?! Denk je dat ze via dit protocol al het webverkeer kunnen gaan afluisteren ofzo?
Misschien bedoet hij dat Google zo (nog) een vinger in de pap krijgt omdat Spdy van Google is...
Maar het is open source, dus die vlieger gaat niet op. Als SPDY straks overal gebruikt wordt en goed werkt maakt het geen bal meer uit wat er met Google gebeurt, SPDY overleeft het wel.
Eerder dat Google naar een monopolie streeft, en buiten dat om hebben ze natuurlijk niet zo'n heel goede reputatie wat betreft privacy. Iets waarbij een monopolypositie wel kan meehelpen.
Er staat Spdy (speedy) maar ik lees eerder Spy (hetgeen ook maar 1 letter scheelt)
en ik kan mij niet aan de gedachte onttrekken dat hier ook een andere gedachte achter zit, namelijk beter kunnen loggen van user requests..
en ik kan mij niet aan de gedachte onttrekken dat hier ook een andere gedachte achter zit, namelijk beter kunnen loggen van user requests..
Er is daarin geen verschil tussen HTTP en SPDY.
Heb je de technische documentatie bestudeerd en geconcludeerd dat er meer mogelijkheden inzitten om requests te kunnen loggen, of is dit niet meer dan een wilde speculatie die eigenlijk nergens op gebaseerd is?
Ik vermoed het laatste (heb de docs zelf ook nog niet gelezen).
Ik vermoed het laatste (heb de docs zelf ook nog niet gelezen).
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
