IETF begint met opstellen http 2.0-standaard
De IETF is begonnen aan de http 2.0-standaard, die sneller en efficiënter zal zijn dan het huidige http 1.1. Als basis voor de nieuwe standaard dient het door Google bedachte Spdy-protocol. Http 2.0 moet in november 2014 zijn afgerond.
De http-werkgroep van de Internet Engineering Task Force is officieel begonnen met het opstellen van de Hypertext Transfer Protocol 2.0-standaard, zo maakt voorzitter Mark Nottingham bekend op de IETF-mailinglist. Als basis dient versie 3.0 van de Spdy-specificatie die door Google is bedacht. Het internetbedrijf droeg Spdy in februari voor bij de IETF in de hoop dat het protocol omarmd zou worden als internetstandaard. Microsoft had 'http speed+mobility' voorgesteld als mogelijke basis van http 2.0.
Uit het herziene handvest voor de http-werkgroep blijkt dat in november 2014 de http 2.0-specificatie moet zijn afgerond. Het nieuwe protocol moet 'substantieel en meetbaar' sneller zijn dan voorganger http 1.1. Verder moet het niet meer nodig zijn om meer dan één verbinding te openen om verschillende requests uit te voeren. Hoewel tcp het belangrijkste transportmechanisme blijft van http-pakketten, moet het nieuwe standaard ook met andere protocollen overweg kunnen. Een ander onderwerp van discussie binnen de werkgroep is de wijze waarop een client en server overeenkomen welke versie van http wordt gebruikt.
Spdy draagt een aantal aanvullingen op het bestaande http-protocol voor, die binnen de doelstellingen van http 2.0 vallen. Zo wordt standaard datacompressie toegepast op zowel de header als de body van http-pakketten. Met behulp van multiplexing kan een onbeperkt aantal requests over één verbinding worden gemaakt. Ook wordt prioritering uitgevoerd en is het mogelijk om data vanaf een server naar een client te pushen zonder dat de browser een request heeft gestuurd.
De Spdy-specificatie impliceert standaard TLS-encryptie voor verbindingen en in de praktijk gebruiken de meeste implementaties ook versleuteling. Of TLS ook in http 2.0 verplicht wordt, is nog niet zeker. Uit een eerdere discussie op de mailinglist van de IETF http-werkgroep blijkt dat de meningen hierover verdeeld zijn.
Spdy wordt inmiddels ondersteund door de browsers Chrome, Firefox en Opera.
Reacties (41)
Fijn dat er gewerkt word aan opvolging van het HTTP protocol. Vooral meerdere resources over 1 connectie gooien gaat naar mijn idee veel winst opleveren! Ik kan niet wachten tot het 2014 is 
Hoeft ook niet. O.a. Facebook en Google gebruiken SPDY al indien je met Firefox, Chrome of Opera surft. Ik ben wel benieuwd welke delen van SPDY er uiteindelijk in HTTP 2.0 terecht gaan komen.
Valt op zich wel mee. Vrijwel alle servers en browsers ondersteunen al jaren keep-alive waarbij over dezelfde verbinding meerdere requests kunnen worden uitgevoerd..
Daarbij zijn het vaak niet je 'eigen' resources welke voor een vertraging zorgen, maar vaak de externe javascripts (zoals Google Analytics) en images op CDN netwerken. Op dat moment moet gewoon een nieuwe verbinding worden opgebouwd inclusief handshakes en daar zit de grootste vertraging..
Wel hoop ik dat IETF een aantal voorstellen van het speed+mobility voorstel overneemt en laat implementeren in het SPDY protocol. Die heeft ook nog een aantal zeer nuttige toevoegingen voor mobiel gebruik (tablets en smartphones) en mobiele browsers krijgen een steeds groter marktaandeel. Datacompressie kan op een aantal (verouderde) smartphones voor vertraging in de surf ervaring zorgen. Microsoft had voorgesteld om optioneel data compressie uit te kunnen schakelen, waar compressie op HTTP(S) juist optioneel is..
Daarbij zijn het vaak niet je 'eigen' resources welke voor een vertraging zorgen, maar vaak de externe javascripts (zoals Google Analytics) en images op CDN netwerken. Op dat moment moet gewoon een nieuwe verbinding worden opgebouwd inclusief handshakes en daar zit de grootste vertraging..
Wel hoop ik dat IETF een aantal voorstellen van het speed+mobility voorstel overneemt en laat implementeren in het SPDY protocol. Die heeft ook nog een aantal zeer nuttige toevoegingen voor mobiel gebruik (tablets en smartphones) en mobiele browsers krijgen een steeds groter marktaandeel. Datacompressie kan op een aantal (verouderde) smartphones voor vertraging in de surf ervaring zorgen. Microsoft had voorgesteld om optioneel data compressie uit te kunnen schakelen, waar compressie op HTTP(S) juist optioneel is..
Met keep-alive moet je nog steeds synchroon request -reply-request-reply doen. Het nieuwe protocol support dus ook request1-request2-reply1-reply2. Dit maakt het opzetten van meerdere TCP-sessies overbodig en dus het protocol efficienter (zeker voor de TCP stack van de server die het af moet handelen voor x clients).Valt op zich wel mee. Vrijwel alle servers en browsers ondersteunen al jaren keep-alive waarbij over dezelfde verbinding meerdere requests kunnen worden uitgevoerd.
Push zou ook een zeer welkome aanvulling zijn. Het is nu een bijna onmogelijk om dat goed voor elkaar te krijgen. Er is altijd wel een load ballancer of proxy die roet in het eten gooit voor long polls en pollen om de x tijd levert veel overhead op.
Dat ze overwegen andere protocollen dan TCP te omarmen vind ik persoonlijk prima. SCTP is een nieuw protocol die misschien een goede duw krijgt hierdoor.
Zie:
http://www.isoc.org/briefings/017/
Zie:
http://www.isoc.org/briefings/017/
alsjeblieft NIET zeg. SCTP is een protocol louter en alleen ontwikkeld als signalerings protocol. Hierin vervangt het de transportlaag voor C7 signalering. Meestal gaat er dus SIGTRAN en DIAMETER verkeer overheen.
Er is geen enkele toegevoegde waarde van SCTP over TCP voor HTTP.
Daarnaast kent geen een firewall SCTP echt. Dus alle firewalls zullen opnieuw moeten worden ontwikkeld. Dat kost miljarden aan inspanning en levert hoegenaamd niets op.
het enige dat firewalls nu aan SCTP ondersteunen is als IP protocol. Dus source:destination:IP-protocol#132 enable. Nu zet je in je firewall source:dest:TCP-protocol;80,443,8080 en kun je DPI aanzetten om in de TCP pakketjes te kijken of het niet per ongeluk iets anders is dan HTTP. dat valt straks bij jouw voorstel weg.
Er is geen enkele toegevoegde waarde van SCTP over TCP voor HTTP.
Daarnaast kent geen een firewall SCTP echt. Dus alle firewalls zullen opnieuw moeten worden ontwikkeld. Dat kost miljarden aan inspanning en levert hoegenaamd niets op.
het enige dat firewalls nu aan SCTP ondersteunen is als IP protocol. Dus source:destination:IP-protocol#132 enable. Nu zet je in je firewall source:dest:TCP-protocol;80,443,8080 en kun je DPI aanzetten om in de TCP pakketjes te kijken of het niet per ongeluk iets anders is dan HTTP. dat valt straks bij jouw voorstel weg.
SCTP is meer dan dat, het ondersteunt bijvoorbeeld ook multi-homing. Zie http://www.isoc.org/briefings/017/ voor een lijstje.
Bij dit voorstel moet het HTTP protocol het multiplexen gaan regelen. Waarom moet zulks op applicatie niveau worden geregeld? En dus door iedere browser apart worden geïmplementeerd, terwijl dit ook in de transport laag kan, en dus in de netwerk stack van het OS?
...en is het mogelijk om data vanaf een server naar een client te pushen zonder dat de browser een request heeft gestuurd
Waar is dat handig voor? Kan het niet voor beveiligingsproblemen zorgen?
Waar is dat handig voor? Kan het niet voor beveiligingsproblemen zorgen?
Push notificaties of iets dergelijks?
Klopt. Nu moeten webapplicaties met enige regelmaat pollen of er nog iets nieuws is.
Denk aan bijvoorbeeld Omegle, waar die nu de hele tijd moet pollen kan de server dan gewoon eenvoudig nieuwe berichten blijven sturen. Lijkt zo een beetje op het websockets idee (zo ver ik me kan herinneren, anyone?)
Zal inderdaad op websockets lijken. Toevallig (?) ondersteunen Chrome, Firefox en Opera ook al websockets.
Is niet zo heel toevallig, websockets maken namelijk onderdeel uit van HTML5 
IE 10 ondersteund ook websockets.
Alleen is IE10 niet uit, dus totaal niet relevant. Begreep pas op 26 Oktober. (Beta tel ik niet mee!)
Maar goed laten we gewoon software opnoemen die daadwerkelijk zijn uitgebracht.
Maar goed laten we gewoon software opnoemen die daadwerkelijk zijn uitgebracht.
[Reactie gewijzigd door linkkrw op donderdag 4 oktober 2012 11:15]
Klopt, met websockets kan dit inderdaad. Zie bijvoorbeeld deze demo in 2 browser vensters van Chrome of Firefox (Opera niet getest). Dit werkt gewoon op HTTP 1.1, dus waarom hier HTTP 2 voor nodig zou zijn is mij een raadsel.
Omdat
1) De WebSockets standaard nog niet 'final' is.
2) WebSockets geen onderdeel van de HTTP 1.1 standaard is, het is een uitbreiding erop.
1) De WebSockets standaard nog niet 'final' is.
2) WebSockets geen onderdeel van de HTTP 1.1 standaard is, het is een uitbreiding erop.
Ik kan me genoeg mogelijkheden bedenken. HTML based games zonder enige vorm van Flash is bijvoorbeeld al een hele grote.
Mooi vooruitzicht voor 2014!
Mooi vooruitzicht voor 2014!
[Reactie gewijzigd door Alphyraz op woensdag 3 oktober 2012 13:22]
Flash heeft ook websockets. Is ook een onderdeel van de html5 standaard trouwens.
Misschien iets van Websockets al ingebouwd ?
Push notificaties is idd een goed voorbeeld. Ipv dat een client app (bijvoorbeeld gmail) om de zoveel tijd moet controleren of er nieuwe mail is, kan de server nu gewoon een berichtje sturen dat er nieuwe mail is. Dat scheelt een hoop requests. Apps op je telefoon werken nu vaak ook al zo. Als dat straks in de browser kan, zou dat een hoop verkeer kunnen gaan schelen.
Dit gaat waarschijnlijk niet zo gemakkelijk als jij het doet klinken omdat dit namelijk via IMAP gaat (http://en.wikipedia.org/wiki/IMAP_IDLE), wat weer een ander protocol is. Het lijkt mij wel mogelijk, wellicht met een nieuwe versie van IMAP.
Hoewel GMail inderdaad IMAP_IDLE ondersteunt, is dat alleen van toepassing op clients die met IMAP verbinden.
De GMail-website maakt echter gebruik van een client die met JSON data en commando's met de server uitwisselt, en dus niet van IMAP.
De GMail-website maakt echter gebruik van een client die met JSON data en commando's met de server uitwisselt, en dus niet van IMAP.
Je zult dan wel iets moeten bedenken voor dynamische NAT sessies. Zoals NAT keepalives (over UDP) al vaak door SIP stacks gebruikt worden. Je gaat op die manier wel actief heel veel sessies open houden. Dat probleem is natuurlijk opgelost als je IPv6 (zonder NAT) gaat gebruiken.
Juist, naast dat het natuurlijk perfect is om reclames te pushen (en ook malware)..
Onzin, hoezo zou de mogelijkheid om te 'pushen' zorgen voor (meer) reclame en malware?
Hoewel deze comment omlaag gemod wordt, lijkt het mij op het eerste gezicht wel een terechte opmerking. (ja, de zin komt vaag/denigerend over...)
Als een server ongevraagd informatie mag sturen naar een client kan je natuurlijk ongewenste pakketjes krijgen.
Naast de huige lekken komt er nu weer een techniek bij dat te misbruiken gaat worden. (welke software heeft dit niet?!)
Als een server ongevraagd informatie mag sturen naar een client kan je natuurlijk ongewenste pakketjes krijgen.
Naast de huige lekken komt er nu weer een techniek bij dat te misbruiken gaat worden. (welke software heeft dit niet?!)
En als jij een willekeurige pagina op het internet opent heb je wel controle over de data die de server verstuurd?
Als een server ongevraagd informatie mag sturen naar een client kan je natuurlijk ongewenste pakketjes krijgen.
Wie had het over ongevraagd? Het gaat erom dat niet ELK pakket expliciet gevraagd wordt. Dat betekent niet dat alles zomaar ongevraagd de andere kant op gegooid kan worden.
Het bekendste voorbeeld is wel Instant Message of een webmail cliënt, die zijn continu bezig om te kijken of er nog iets is veranderd. Dat kan natuurlijk veel handiger als je 1x vraagt om updates en ze daarna binnenkrijgt.
Wie had het over ongevraagd? Het gaat erom dat niet ELK pakket expliciet gevraagd wordt. Dat betekent niet dat alles zomaar ongevraagd de andere kant op gegooid kan worden.
Het bekendste voorbeeld is wel Instant Message of een webmail cliënt, die zijn continu bezig om te kijken of er nog iets is veranderd. Dat kan natuurlijk veel handiger als je 1x vraagt om updates en ze daarna binnenkrijgt.
De opmerking komt op mij over als "Oh jee, een server die data kan sturen zonder dat de client daar expliciet om vraagt, dat moet wel eng zijn!", oftewel een onderbuikreactie die niet blijkt van enige kennis van zaken. Laat de Tweede Kamer het maar niet lezen, anders komt er straks ook nog een HTTP/2.0-verbod.Hoewel deze comment omlaag gemod wordt, lijkt het mij op het eerste gezicht wel een terechte opmerking.
In principe klopt dit, daarom lijkt bovenstaande reactie ook terecht. Het is dus echter niet zo dat een willekeurige server naar willekeurige clients willekeurige data gaat sturen; dat is pertinent onmogelijk.Als een server ongevraagd informatie mag sturen naar een client kan je natuurlijk ongewenste pakketjes krijgen.
Ook bij HTTP/2.0 komt de allereerste communicatie vanaf de client. Je doet, over een verbinding, een verzoek voor een webpagina naar een server. Deze server, als client en server beide het juiste protocol spreken, kan vervolgens over deze verbinding niet alleen zijn antwoord terugsturen, maar bijvoorbeeld ook alvast de stylesheets, javascript-bestanden en afbeeldingen. Dit scheelt het openen van additionele connecties, wat simpelweg veel tijd kost.
Daarnaast kan de verbinding geopend blijven om updates op dezelfde pagina te pushen, zoals bijvoorbeeld een nieuwstracker die wordt bijgewerkt met nieuwe items, of reacties die live worden geladen. Dit wordt door jouw browser allemaal door een stuk Javascript verwerkt, zodat de getoonde webpagina geüpdatet kan worden.
Tot op heden wordt dit (meestal, maar alternatieven zoals WebSockets en SignalR zijn aan hun opmars bezig) door middel van polling gedaan: er draait continu een stuk Javascript, dat om de X seconden / minuten de vraag aan de server stelt of er al nieuwe data beschikbaar is.
Deze server pushes zijn dus niets nieuws; er wordt alleen maar een definitie in het onderliggende protocol voor vastgelegd, zodat we in de toekomst hopelijk één standaardimplementatie krijgen in plaats van de wildgroei aan technieken die in iedere browser en server weer anders werken.
Dus ja, via de pushes die in HTTP/2.0 gaan worden ingebouwd, kunnen ook reclames en malware gepusht worden. Dit moet echter wel vanaf de server komen waarmee je al verbonden bent, én worden begrepen (en uitgevoerd) door het consumerende stuk Javascript in de browser. Er kan niet simpelweg "cmd.exe format C:" vanaf een server worden gestuurd waarna je browser doodleuk je C:-schijf gaat wissen. Er kan wel worden gestuurd "open een popup met de URL http://xxx" (mits het consumerende stuk JS dat kan interpreteren en uitvoeren, dus die functionaliteit moet door de sitebouwers reeds zijn ingebouwd), maar dat kan met de huidige technieken ook al.
Ergo: er is niets nieuws onder de zon, het wordt alleen geformaliseerd en gestandaardiseerd. Vandaar de downmod: zomaar iets roepen omdat het eng lijkt draagt niet bij aan een leuke discussie. One fool can ask more questions than seven wise men can answer.
[Reactie gewijzigd door CodeCaster op woensdag 3 oktober 2012 15:46]
Niet helemaal. Met het huidige protocol bepaalt mijn browser (en dus ik, al dan niet met behulp van plugins) wat er binnengehaald wordt. Ik kan nu bepaalde URL's of bestandsnamen blokkeren (*ads* bijvoorbeeld), waardoor ik bandbreedte bespaar. Zeker handig als ik tether via mijn mobiele telefoon: goed voor de snelheid en om te kosten te drukken. Vaak schakel ik dan ook het downloaden van afbeeldingen uit.
Als de server nu gaat bepalen wat hij mij toestuurt ben ik die controle dus kwijt, en zal mijn bandwidth consumptie ongetwijfeld gaan stijgen. Niet iets waar ik op zit te wachten.
Als de server nu gaat bepalen wat hij mij toestuurt ben ik die controle dus kwijt, en zal mijn bandwidth consumptie ongetwijfeld gaan stijgen. Niet iets waar ik op zit te wachten.
Als het protocol het werkelijk niet zal toestaan om bestanden te weigeren, dan schakel je toch over naar HTTP 1.1? Servers zullen echt wel backwards compatible blijven en hoe vaak zul je nou helemaal extreem zuinig willen zijn met je bandbreedte?
Ik mag toch aannemen dat je dat nog steeds kan controleren. Leuk voor de inwoners van België met datalimieten. Eén foutief script (of expres, maar laten we uitgaan van het goede van de mens ) en je ramt zo je hele datalimiet vol....
) en je ramt zo je hele datalimiet vol....Het spijt me, maar ik moet mezelf herhalen:
Wat staat er in SPDY?
Het is niet erg dat je het niet weet, niemand kan alles weten en ook ik moest het voor de zekerheid nog even opzoeken, maar je zet het nu al neer als "Het zal wel slecht werken.". Als je de planning erbij pakt en even de specificaties doorleeest, wat je (zelfs zonder achtergrondkennis) in een paar minuten gedaan kunt hebben, zie je dat HTTP/2.0 in eerste instantie op SPDY gebaseerd gaat worden.De opmerking komt op mij over als "Oh jee, een server die data kan sturen zonder dat de client daar expliciet om vraagt, dat moet wel eng zijn!", oftewel een onderbuikreactie die niet blijkt van enige kennis van zaken
Wat staat er in SPDY?
Kortom, de client krijgt eerst een verzoek om een nieuwe stream toe te staan (over de reeds geopende verbinding). In dit verzoek staat ook de URL naar de resource. En verder:When the server intends to push a resource to the user-agent, it opens a new stream by sending a unidirectional SYN_STREAM. [...] The SYN_STREAM MUST include headers for ":scheme", ":host", ":path", which represent the URL for the resource being pushed.
Kortom, een client kan een server push gewoon weigeren als de URL (of de beschikbare bandbreedte) hem niet aanstaan.To cancel individual server push streams, the client can issue a stream error (Section 2.4.2) with error code CANCEL. Upon receipt, the server MUST stop sending on this stream immediately (this is an Abrupt termination).
[Reactie gewijzigd door CodeCaster op donderdag 4 oktober 2012 12:41]
OK, fijn dat het goedgekeurd moet worden. Aan de andere kant, wat is dan nog het voordeel van server push?
Het voordeel was toch juist dat de server al weet welke data de client wil dus niet af hoeft te wachten op een request voor die data maar gelijk kan beginnen met het versturen daarvan. Echter, die vlag gaat niet op want de server moet dus nu alsnog eerst een intentieverklaring tot zenden van de data naar de client sturen. De client moet beoordelen of hij dat wil en daarna zijn goedkeurig terugsturen. Dat zijn dus twee transmissies voor het sturen begint, tegenover één als de client er zelf om vraagt: de client vraagt, en de server kan in reactie daarop beginnen met vertsruren.
Je zou kunnen zeggen dat clients dan maar standaard alles moet accepteren, maar ja, dan ben je bovenstaand voordeel weer kwijt. En hoe kan de client beoordelen of hij iets wil als hij de HTML nog niet geparsed heeft? Als hem afbeelding 'my-awesome-img.jpg' van 3 MB aangeboden wordt zal hij toch op zijn minst eerst moeten checken of de betreffende pagina wel 'my-awesome-img.jpg' gebruikt, bijvoorbeeld.
CANCEL kan daarbij weer helpen natuurlijk, maar dat hadden we ook al bij HTTP 1.1-streams. Dus blijft de vraag: wat is het voordeel van server push?
Het voordeel was toch juist dat de server al weet welke data de client wil dus niet af hoeft te wachten op een request voor die data maar gelijk kan beginnen met het versturen daarvan. Echter, die vlag gaat niet op want de server moet dus nu alsnog eerst een intentieverklaring tot zenden van de data naar de client sturen. De client moet beoordelen of hij dat wil en daarna zijn goedkeurig terugsturen. Dat zijn dus twee transmissies voor het sturen begint, tegenover één als de client er zelf om vraagt: de client vraagt, en de server kan in reactie daarop beginnen met vertsruren.
Je zou kunnen zeggen dat clients dan maar standaard alles moet accepteren, maar ja, dan ben je bovenstaand voordeel weer kwijt. En hoe kan de client beoordelen of hij iets wil als hij de HTML nog niet geparsed heeft? Als hem afbeelding 'my-awesome-img.jpg' van 3 MB aangeboden wordt zal hij toch op zijn minst eerst moeten checken of de betreffende pagina wel 'my-awesome-img.jpg' gebruikt, bijvoorbeeld.
CANCEL kan daarbij weer helpen natuurlijk, maar dat hadden we ook al bij HTTP 1.1-streams. Dus blijft de vraag: wat is het voordeel van server push?
@MadEgg: Het gaat hier om streams over dezelfde TCP-verbinding, dus inderdaad nog wel met een roundtrip, maar een die niet zo traag is als een hele nieuwe TCP-verbinding opbouwen met de bijkomende initiële traagheid door het kleine window.
Als je een webpagina opvraagt, dan moet de browser ook nog alle css en javascript files, alle afbeeldingen, etc opvragen. Nu kan de server die meteen meesturen als je die webpagina opvraagt.
Leuk. En nu had ik deze als client al in mijn cache. Krijg ik dan onzin data binnen over mijn gelimiteerde data abbotje?
Waarom denk je dat de ontwerpers van het protocol daar geen rekening mee houden?
[Reactie gewijzigd door CodeCaster op woensdag 3 oktober 2012 17:01]
Hierdoor kan bijvoorbeeld een server 'alvast' de Javascript en/of images versturen wanneer de client een bepaalde pagina opvraagt.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 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
