Microsoft wil in protocolvoorstel voor http 2.0 websocket benutten

Microsoft heeft onder de naam Http speed+mobility een eigen protocol ontwikkeld dat de opvolger van http 1.1 sneller moet maken. Het protocol zou met name de internetcommunicatie op mobiele apparaten versnellen dankzij websockets.

De IETF werkt al enige tijd aan 'http 2.0' in een poging om de beperkingen van het huidige http 1.1 op met name netwerkprestaties weg te nemen. Google heeft zijn spdy-protocol voorgelegd als een mogelijk onderdeel van http 2.0 en spdy zou een goede kans maken om in een uiteindelijke standaard te worden opgenomen.

Inmiddels heeft Microsoft op zijn interoperability-blog het Http speed+mobility-protocol aangekondigd. Daarbij zou websocket, een api die snelle uitwisseling van data tussen server en browser mogelijk maakt, een belangrijke rol moeten spelen. Daarnaast zou Http speed+mobility met name effect moeten hebben op mobiele apparaten, waaronder een verbeterde accuduur door efficiëntere communicatie.

Microsoft, die het nieuwe protocol wil voorleggen bij de IETF, belooft de technische details binnenkort openbaar te zullen maken. Het zou dienen als een aanvulling op spdy, het door Google ontwikkelde protocol dat volgens Microsoft het probleem van het verouderde http-protocol goed op de kaart heeft gezet. Microsoft hoopt echter dat zijn inbreng een 'energieke en open discussie' zal opleveren bij de IETF.

Mike Belshe, voormalig spdy-ontwikkelaar bij Google, laat op Google+ in een reactie weten dat hij benieuwd is naar Microsofts voorstel en de bijbehorende metingen om de geclaimde snelheidswinst te onderbouwen. Belshe ontkent echter dat spdy, waar inmiddels drie jaar aan is gewerkt, niet is geoptimaliseerd voor mobiele apparaten. Zijn eigen startup, Twist geheten, zou al profiteren van spdy op mobiele apparaten. Desondanks zou de inbreng van Microsoft waardevol kunnen zijn om op basis van meerdere voorstellen een uiteindelijk http 2.0-protocol te ontwikkelen, zo stelt Belshe.

Reacties (40)

[SinergyX]

Vraag me af, heeft het 'optimaliseren' nog wel nut, als gros van websites geen aparte mobiele versie hebben en dus gewoon de 'echte' site laten, daar wordt imho 90% aan de data verbruikt voor reclame-banners en flashzut (waar van toepassing), en die laatste 10% is dan de daadwerkelijke tekst van een site.

Snap best dat ze ook aan mobiele versies geld moeten verdienen met websites, maar is het niet een beetje overkill dat het gros van data voor site totaal niet meer site-gerelateerd is? (zie het verschil met tweakers.mobi en tweakers.net maar eens).

Lomp voorbeeld:
Total HTTP Requests: 3
Total Size: 9504 bytes
tegen
Total HTTP Requests: 28
Total Size: 237513 bytes

Natuurlijk staat er op de .net site veel meer informatie, maar als er vanuit de website zelf geen ondersteuning is voor de api (spdy werkt dacht ik ook zo?), wat is dan je winst?

Of zit ik er nu compleet naast?

[ytterx]

Al kan je maar 1% optimaliseren..
Voor grote datacenters kan het enorm nuttig zijn want dat betekend 1% meer bezoekers kunnen afhandelen in de zelfde tijd zonder al te veel moeite, immers zal het protocol uiteindelijk in apache en andere webservers ingebouwd worden.

[siepeltjuh]

Het gaat niet alleen om internetpagina`s. Er zijn veel meer systemen die het HTTP protocol (mis) bruiken.

Wat ik begrijp is dat er niet meer per file/request een TCP sessie wordt opgebouwd, maar dat alle data door min of meer 1 sessie wordt afgehandeld. Daarnaast lijkt er op dat GZIP en SSL ook verplicht gaan worden.

[Anoniem: 294759]

Laten we hopen dat GZIP niet overal verplicht wordt want het is niet altijd ten voordele om het te gebruiken. Noem als voorbeeld van zover gecomprimeerde plaatjes dat de door de extra metadata wat gegenereerd wordt het bestand groter wordt i.p.v kleiner.

En waarom zou je voor alles SSL willen gebruiken? Het zorg dan nog steeds voor vertraging van verkeer wat voor bepaalde pagina's helemaal niet nodig is. Waarom zou je SSL willen afdwingen voor bijvoorbeeld een campagne pagina? Dat zou helemaal niet logisch zijn. SSL moet gebruikt worden waarvoor het gebruikt dient te worden: het mogelijk maken van veilig http verkeer voor bepaalde onderdelen van een website ipv alle onderdelen.

[MSalters]

"GZIP verplicht" betekent dat de client het moet ondersteunen. Dat wil zeggen dat je als HTTP2.0 server niet hoeft te checken of de client het ondersteunt. Op dezelfde manier mag je als webdeveloper er vanuit gaan dat je een redirect naar https: kunt doen, en hoef je geen error handling voor domme clients te bouwen.

[totaalgeenhard]

Welke browsers (naast Lynx) hebben geen ZIP support?


update: Lynx ondersteund gzip sinds versie 2.6 lees ik zojuist.

[Reactie gewijzigd door totaalgeenhard op 22 juli 2024 19:49]

[totaalgeenhard]

Je ziet een veel belangrijker argument over het hoofd, ZIP gebruikt onnodig CPU resources bij plaatjes.

Verder wil GOOGLE alles SSL omdat ze dan PC kunnen identificeren.
Daar hoor je niemand over, terwijl er destijds een grote discussie over CPU-ID was.

[J.J.J. Bokma]

gzip wordt alleen met bestanden gedaan waar dat zin voor heeft, natuurlijk. Nu geeft de browser aan (want dat was vroeger de tekortkoming) dat het gzip aan kan, en de server stuurt dan HTML gzipped terug. Dat kan on-the-fly gebeuren (belast server), of er kan gewoon al een gzipped versie klaar staan.

[Anoniem: 80466]

als gros van websites geen aparte mobiele versie hebben en dus gewoon de 'echte' site laten, daar wordt imho 90% aan de data verbruikt voor reclame-banners en flashzut (waar van toepassing), en die laatste 10% is dan de daadwerkelijke tekst van een site.

Ik denk dat de verwachting is dat het merendeel van de 'mobile' data door apps gebruikt zullen worden die dan dit protocol zullen gebruiken.
Niet door websites.
Zeker als straks op windows 8 ook veel meer apps zullen verschijnen

[Cybergamer]

Een goeie vraag! Ik bedacht me hetzelfde en zou daar ook graag een antwoord op willen zien.

[SoloH]

Bij websockets zet je gewoon 1 verbinding op, die intact blijft. Web apps hoeven dan niet telkens via een cookie opnieuw in te loggen voor elk request. Huge improvement en voor html5 apps zeer wenselijk.

[codebeat]

Hahaha, de enige browser die websocket niet ondersteund is, jawel, de geweldige browser die Internet Explorer heet. Ben er laatst nog bezig geweest en uiteraard is er voor IE weer een uitzondering nodig. Laten ze nu eens voort maken met dat project IE, zorgen dat als basis alles het goed doet en ondersteund wordt.

[Anoniem: 80466]

IE10 preview bevat wel websockets
http://blogs.msdn.com/b/i...ows-consumer-preview.aspx

[eXtink]

Ik wil niet veel zeggen, maar standaard worden firefox en webkit browser ook niet door dezelfde code ondersteund, ze hebben beide hun eigen code nodig.
-webkit- ...
-moz- ...

Het is wel zo dat IE meerdere functies in zijn geheel niet onersteunen, IE is dus een erger geval.

[Anoniem: 146163]

En daarom vind ik IE juist beter op dat vlak. Geen proprietaire voorvoegsels en dergelijke, dat zorgt er JUIST voor dat er versplintering optreedt. Nu moet ik voor webkit en mozilla EN IE aparte code schrijven. Als iedereen nou hard werkt aan de standaard en er voor zorgt dat die eerder stabiel wordt, kan iedereen de functionaliteit implementeren zoals ie afgesproken is waardoor het wat eenvoudiger wordt voor ons als simpele developers.
Persoonlijk zou ik het liefst een browser optie zien die standaard uit staat, die je via een setting in je browser kan aanzetten. Developer mode ofzo. Alleen dan werken de -moz en -webkit experimentele implementaties. Zo kan je wel uitproberen hoe 't werkt, maar niet in je live website gebruiken waardoor dit soort rommel van het web blijft...

[arjankoole]

En daarom vind ik IE juist beter op dat vlak. Geen proprietaire voorvoegsels en dergelijke, dat zorgt er JUIST voor dat er versplintering optreedt.

daar vergis je je ernstig in. De meeste webbouwers lopen namelijk nog altijd ernstig te klagen over de IE specifieke hacks die ze er in moeten proppen om überhaupt iets te laten werken.

[bakakaizoku]

Dan heb je die webdevelopers lang geleden voor het laatst gesproken of je hebt dingen uit 2008 zitten lezen op internet. Met de komst van IE8 en vooral IE9 zijn hacks nauwelijks tot niet meer nodig.

[hackerhater]

betreffende CSS 1 en 2 inderdaad
maar met CSS 3 en HTML 5 begint het gezeur opnieuw

[Bauknecht]

Het is waar dat IE8/9 ivm IE6/7 een aanvaardbare feature set heeft, en deze correct implementeert. Maar als een grafische dienst hebt die snelle, flexibele, state of the art pagina's wil met gradients, animaties, rounded corners, schaduwen, ... en die mensen willen niet verstaan dat je in oude browsers geen moderne, state of the art pagina's kunt maken, dan heb je nog altijd twee keuzes: PIE-achtige hacks en prutsoplossingen, of overal images gebruiken. Pest, cholera, you know...

[Bauknecht]

Het grote voordeel van die prefixes is dat je een syntax al kan gebruiken, en dat de definitieve implementatie en de legacy syntax perfect naast elkaar kunnen bestaan. Kijk bv. naar de oude webkit-syntax: je kan die nog perfect gebruiken naast de nieuwe bijna-standaard. Oude browsers gebruiken die, nieuwe browser gebruiken de oude. Geen interferentie of misverstanden of wat dan ook. Liever dat dan de troep en hacks die je moet gebruiken om rond de foutieve implementaties van IE7 rond te werken.

Ik heb trouwens geen probleem met die dubbele code waar jij het over hebt, zolang je een proper, voorspelbaar systeem hebt waar je bleeding edge en fallbacks naast elkaar kan gebruiken, desnoods met een modernizr erachter om te weten te komen wat een browser ondersteund. Die dubbele code zal sowieso de toekomst zijn, omdat HTML5 een evoluerende standaard is. Je gaat de komende 20 jaar geen moment hebben dat alle browsers in omloop alle features ondersteunen. Je zal altijd moet rekening houden met verschillende featuresets.

Die extra code valt trouwens mee. In feite komt het erop neer dat je bv. voor een gradient een lijn background: linear-gradient(blablabla) voorziet, en die copy-paste naar een -webkit-, -moz-, -ms- en -o-lijn. En dan voorzie je nog één lijntje met een effen background. Als jij op die tijd Photoshop kan openen, een image kan maken en kan saven, of een SVG kan schrijven, chapeau. Om nog maar te zwijgen over de beperkte onderhoudbaarheid, grotere bestanden, tragere performantie, ...

PS: zoals je kan zien, gaat IE in de toekomst ook met de -ms-prefix beginnen werken

[latka]

Dat zou een redelijke breuk met het verleden zijn: MS nut over het algemeen open standaarden alleen vlot uit als ze er een competetief voordeel aan beleven. Alle browser-hypes achterna hollen kost veel geld zonder direkt geld op te leveren.

[Ramon]

So? Dit gaat over een standaarden-overleg voor HTTP 2.0. Dat is toekomst. En zoals je hierboven leest kan IE10 het wel.

[Reactie gewijzigd door Ramon op 22 juli 2024 19:49]

[judgewooden]

Opera ondersteunt ook geen websockets. Ze hebben een (lange) tijd geleden wel aanstalten gemaakt en boden toen ook als opt-in ondersteuning voor een vroege draft (7 volgens mij) aan. Verder dan dat is het helaas niet gekomen.

[Juris LLM.]

http://xkcd.com/927/

Moest hier gelijk weer aan denken.

[Reactie gewijzigd door Juris LLM. op 22 juli 2024 19:49]

[EAM666]

In veel gevallen is deze comic van toepassing. Hier lijkt het mij echter een goed idee om een efficiënter protocol af te spreken. Zaken als statefull i.p.v. stateless en volledige compressie zouden al een berg resources kunnen besparen.

Zelfs als er een enkele procent (of zelfs tienden/honderdsten) aan dataverkeer bespaard wordt, dan heb je het al over gigantische hoeveelheden.

Het is ook niet meer dan logisch dat de grote namen binnen de IT wereld zich hiermee bemoeien.

[latka]

Statefull en scaleable gaat zelden of nooit samen: de efficiente per connectie kan wellicht omhoog maar omdat de server nu ineens veel meer data vast moet houden (nml. de state) zal het geheugenverbruik omhoog schieten. Je ziet het al als je session-cookies gaat gebruiken om per-user state bij te gaan houden: de session data moet dan niet te groot worden anders loopt je server uit de resources, of, als je fail-over constructies hebt, de performance achteruit holt door de overhead van session replicatie. Het aardige van stateless is juist dat het linear schaalt met de hoeveelheid hardware die je er tegenaan smijt.

[MSalters]

Dat is typisch een gevolg van slecht programmeren. Met 1KB state kun je al bijzonder veel; dat is bijvoorbeeld genoeg voor 200 database keys van 40 bits elk; een server die daar 1GB voor reserveert kan de state van een miljoen parallele gebruikers (en dus 200 miljoen keys) onthouden.

Maar waar gaat het dan fout? Tja, excessieve overhead. Gebruik een GUID in plaats van een 40 bits key, sla 'm op als Unicode string, en je hebt opeens 512+ bits nodig.

Nu kun je je afvragen of dit schaalbaar is. Servers gaan momenteel tot zo'n 2048 GB. Zeg dat je daar 50% voor user state reserveert, dus 1024 GB. Dat is genoeg voor een miljard sessies, dat is 1/3 van alle internetgebruikers in de wereld. Geen hardware grenzen, dat is schaalbaar in mijn definitie.

[xAn52]

Goed om te zien dat ze elkaar willen aanvullen en niet aanvallen. Daar zijn we allen bij gebaat. Ik snap de terughoudende instelling van Belshe wel maar applaudiseer de "open" staande instelling, ondanks de wat stellende Microsoft. Wie weet!

[arjankoole]

Goed om te zien dat ze elkaar willen aanvullen en niet aanvallen. Daar zijn we allen bij gebaat. Ik snap de terughoudende instelling van Belshe wel maar applaudiseer de "open" staande instelling, ondanks de wat stellende Microsoft. Wie weet!

ik ben voorzichtig, en snap ook waarom Belshe dat is. Microsoft heeft een weinig florissante geschiedenis met 'Embrace, extend, extinguish'. Dat gedrag heeft als direct resultaat dat Microsoft vaak niet als een betrouwbare partner wordt gezien.

[Neko Koneko]

Die methode werkt echter alleen als ze een monopolie hebben en juist op dat vlak zijn ze terrein aan het verliezen. Op de mobiele markt hebben ze sowieso maar een klein voetje aan de grond. Leuk als MS probeert een eigen standaard door te duwen maar Apple en Google hoeven deze maar te negeren op de mobiele markt en MS is nergens meer

[thegve]

Microsoft heeft een te verwaarlozen marktaandeel op websites in het algemeen, en al helemaal op de "grotere" sites, al word het langzaamaan groter. Willen ze hun standaard populair maken, dan moeten ze er voor zorgen dat het ook geïmplementeerd word in open source software, en hiermee dus dat het een open standaard word.
Ze hebben uiteraard wel een groot marktaandeel op de desktop, dus hier hebben ze wel wat macht, maar op mobiel is het ook maar klein, dus MS is wel geforceerd tot een open houding op dit moment.

[StiGMaTa]

En waar komt die wijsheid vandaan?
IIS heeft een marktaandeel van ongeveer 20% (voor publieke websites). Dat noem ik niet te verwaarlozen (Bron)
Om nog maar te zwijgen over het niet meetbare aandeel (intern + owa).

[totaalgeenhard]

Welke partij is wel betrouwbaar?

Het feit dat alleen Amerikaanse (commerciële) partijen hun standaarden proberen door te drukken zegt al genoeg.

Uiteindelijk houden ze er allemaal hun eigen agenda erop na.

Verder is Microsoft verleden tijd, maar ten opzichte van Google kun je stellen dat Microsoft tenminste de privacy van mensen respecteerde.

[arthur-m]

Je bedoelt respecteerT? ;-) je kan van MS zeggen wat je wilt, maar vergelijk eens een willekeurige privacy statement van MS tov Google, Apple, paypal, etc etc...

[J.J.J. Bokma]

Google doet daar niet voor onder, helaas.

[SXForce]

Ik vind het helemaal niet erg dat Microsoft met dit protocolvoorstel komt, maar ik hoop dan wel dat dit protocol bij de tijd gaat blijven.

Als je ziet hoe ver Internet Explorer achter loopt op sommige vlakken en de snelheid waarop ze vooruit gaan, zie ik toch meer in Google die iets onderhoud.

Ik weet niet waarom, maar bij Microsoft zie ik trage updates voor me. Maargoed, toch leuk dat ze zulke innovatieve dingen toch wel uitproberen. We will see...

[Ramon]

Ik heb liever dat een standaarden-organisatie een standaard onderhoudt. Of wil je graag een nieuwe IE6 in de vorm van Chrome? (aka alles werkt alleen met Chrome)

[Reactie gewijzigd door Ramon op 22 juli 2024 19:49]

[NicoJuicy]

Mooi dat Microsoft ook eens moeite doet om het web sneller te maken! Google was hier al lang mee bezig, hopelijk kunnen beide bedrijven eens samen werken op bepaalde (overlappende) vlakken.

Uiteindelijk hebben ze er allemaal baat bij!

[arthur-m]

Dat doen ze al jaren...

[Anoniem: 440278]

Ga door met dit soort dingen en stop de nuttelose "patenten war"