Mozilla brengt Firefox 36 met http/2-ondersteuning uit

Mozilla heeft dinsdag een nieuwe Firefox-versie uitgebracht die standaard ondersteuning biedt voor de onlangs goedgekeurde http/2-standaard. Die is voor een groot deel gebaseerd op het door Google ontwikkelde spdy-protocol.

Mozilla rolt de versie, Firefox 36, momenteel uit. Het gaat om één van de eerste browsers die standaard over de http/2-standaard beschikt. Die volgde onlangs de http 1.1-specificatie op en moet onder andere het sneller inladen van webpagina's mogelijk maken. Zo brengt http/2 de multiplexing-mogelijkheid, waarbij meerdere http-requests vanuit de browser gebundeld naar een webserver kunnen worden gestuurd. Hierdoor wordt het totale aantal actieve connecties flink verminderd.

Behalve Firefox biedt ook Internet Explorer 11 out-of-the-box de http/2-standaard aan in Windows 10. Chrome beschikt ook over de ondersteuning, maar biedt die voorlopig niet standaard aan. In toekomstige versies zal dit wel gebeuren. Het spdy-protocol, dat door Google is ontwikkeld als aanvulling van het http 1.1-protocol en waarop http/2 grotendeels is gebaseerd, zal dan langzaamaan komen te vervallen. Begin volgend jaar wil de internetgigant ondersteuning voor het spdy-protocol helemaal laten vallen.

Met de recente afronding van de http/2-standaard kwam er na zestien jaar een vervanger voor het http 1.1-protocol, één van de populairste toepassingen voor het huidige internet. Het zal nog enige tijd gaan duren voordat http/2 de dominante standaard wordt. Software moet namelijk nog worden aangepast om met de nieuwe standaard te kunnen werken.

De Firefox-update die Mozilla dinsdag uit heeft gebracht, komt ten slotte met nog enkele kleine wijzingen. Zo ondersteunt de browser voortaan niet langer 1024bit-rsa-encryptie voor ssl-verbindingen. Die biedt al langer onvoldoende sterke encryptie. Ook kan Firefox 36 voortaan zogeheten pinned tiles in een nieuwe tab syncen.

Reacties (95)

Wat is er mis met HTTP?
https://www.usenix.org/le...9/invited_talks/mogul.pdf

NIks eigenlijk dus...
(over een paar extra tcp-request gaan we niet moeilijk doen, node.js gaat alles oplossen hihi)

Het kon destijds wel een valide mening zijn, nu is dat minder denk ik. Dit vooral door mobile toegang waarbij het openen van connecties vrij kostbaar is. Tevens is de toepassing van HTTP traffic natuurlijk enorm ontwikkeld.

Waar HTTP 2.0 ook aardig wat terrein wint is in upload snelheid. In de jaren 90 was het veelal downloaden maar tegenwoordig met facebook, twitter etc is upload belangrijker.

Als je echt de perceptie wilt hebben van een enorme snelle site dan moet je richten op 60fps (zie bv http://jankfree.org/ )

Dat betekent dat je 16ms hebt voor het doen van het verzoek aan de server, server dingen, download en browser redeneren. Dan tellen de miliseconden wel en maakt een HTTP 1 .1of HTTP 2.0 wel degelijk uit.

Bandbreedte maakt voor HTTP bezoek boven de 10Mbit (meen ik me te herinneren) niet zoveel meer uit, het probleem verschuift dan naar latency. https://www.igvita.com/20...b-performance-bottleneck/ en zaken zoals head of line blocking waardoor site onderdelen niet worden geladen totdat bijvoorbeeld een CSS file binnen is. Dit is bij HTTP 2.0 veranderd naar multiplexing.

Jankfree is een mooi streven maar heeft vrijwel niks te maken met je connecties naar wat dan ook. De 60fps refereert naar wat er op het scherm gebeurd zodra iets beweegt: scrollen, animaties, user input, etcetera. 16ms is nu ongeveer hoe lang een DNS-lookup duurt, zeker met mobiel duurt het nog wel even voordat connecties binnen 16 seconden geopend, afgehandeld en gesloten worden. Zelfs als dit mogelijk is heeft het niks te maken met de 60 beeldframes per seconde waarin iets met de data kan gebeuren, het is niet alsof je 60 keer per seconde een update maakt. Uitzonderingen zijn realtime multiplayer games en mogelijk chat, maar daar gebruik je connecties die open blijven (net als veel sites nu al doen, ook met http 1.1).

Als je op Jankfree naar de onderwerpen kijkt zie je dan ook: Touch and Input, Paint (pixels renderen), Layout & Styles (compositie), en Animations. Allemaal in relatie tot optische feedback.

Om de laadsnelheid te testen moet je kijken naar http://www.webpagetest.org, die laadt je website vanaf verschillende devices, locaties als je dat wilt en maakt een visuele map van de voortgang. Over het algemeen wil je dat een pagina binnen een seconden klaar is om input te ontvangen (meestal scrollen). Dit betekent dat je momenteel goed moet nadenken over de hoeveelheid assets (losse bestanden, momenteel 1 tegelijk per connectie), de bestandsgrootte en zeer belangrijk, de ‘waterval’. Met http2 kan er meer over een lijntje, en SSL zou sneller moeten gaan, wat nu nog komt met een relatief forse snelheidspenalty.

De waterval is verantwoordelijk voor een belangrijk deel van de snelheidsperceptie van het laden. Dit is een onderdeel dat relevant blijft, ook met de komst van http2. Hoewel er meer bestanden tegelijk geladen kunnen worden ligt het gemiddelde momenteel rond de 100, wat totaal goed is voor bijna 2MB aan data. Op dit niveau vraag ik me af in hoeverre http2 nog gaat helpen, zeker het aantal connecties is absurd te noemen*. Bestandsgrootte: http://www.webperformance...00-web-page-1795-kb-size/
Connecties/waterval: http://www.webperformance...agnose-performance-pains/

Om meer te lezen over snelheid zoals het er nu voor staat: http://www.webperformancetoday.com (je moet wel een beetje door de infographics heen kijken). Om meer te lezen over optimalisatie hebben Google en Yahoo beide uitgebreide documenten opgesteld. Google: https://developers.google.com/speed/ (zie best practice)
en Yahoo: https://developer.yahoo.com/performance/ (lijkt er nu uit te liggen). Vrij zorgelijk is dat ongeveer een 0,5MB! van alle data op een webpagina uit tekst bestaat. Het weergeven van een ‘simpel document’, daar kan je een boek** mee vullen.

Zowel Google als Yahoo hebben ook een browser extensie om snel op ususal suspects betreft performance te testen. Pagespeed: https://developers.google...speed/insights_extensions (bestaat ook voor andere browsers dan Chrome) en ySlow: http://yslow.org

Laatste edit artikel dat simpel uitlegt hoe http2 bestanden sluist: http://moz.com/blog/http2...ock-for-the-future-of-seo

* Deze pagina komt hier met een leeg cache uit op 85 connecties, 1,68MB, en laadt in 2,26 seconden: http://cl.ly/ZvmK
** https://answers.yahoo.com...qid=20110602142446AAbeLae

[Reactie gewijzigd door n8n op 25 februari 2015 12:57]

Dat is een verhaal uit 1999, een eeuwigheid geleden in computerland.

In 1999 hadden we allemaal nog een 486 of een Pentium, hadden de meeste mensen nog geen Internet thuis, en als je het had dan had je nog een oud piepend modem of misschien wel ADSL en vonden we 1 Mbit/s al razendsnel. Je browser was IE 4.0 of 5.0 of Netscape Navigator.

De wereld ziet er nu natuurlijk heel anders uit, dus die presentatie is niet meer volledig relevant.

Één van de nadelen van HTTP/1.0 en 1.1 die wordt genoemd in de presentatie is "no multiplexing". Dit is nu juist één van de dingen die HTTP/2.0 mogelijk maakt.

[Reactie gewijzigd door jj71 op 25 februari 2015 08:56]

In 1999 hadden we allemaal nog een 486 of een Pentium

Klein beetje off-topic, maar ik moet corrigeren door te zeggen dat toen de Athlon, AthlonXP, Pentium3 en Pentium4 gangbaar waren met kloksnelheden van rond en voorbij de GigaHertz. Niet direct een gemiddelde, stoffige 486 dus.

Ik denk dat php aan de serverkant net zo snel kan. Als je serverside goed cached kun je Mb aan data responsen om de framerate hoog te houden

Met de recente afronding van de http/2-standaard kwam er na zestien jaar een vervanger voor het http 1.1-protocol, één van de bouwstenen van het huidige internet

Dat het gros van de bevolking het internet als synoniem voor het web gebruikt is tot daar aan toe, maar van tweakers verwacht ik beter . HTTP is niet een bouwsteen van het internet, protocollen zoals TCP en UDP zijn dat. HTTP is gewoonweg een toepassing zoals zovele anderen. Wel een van de populairste, maar geen fundamentele.

In dat opzicht zijn TCP en UDP ook "toepassingen" die boven IP zijn gebouwd...

Als je een protocol als "Internet" wil aanduiden, dan hoort die eer IMHO aan IP toe.

In dat opzicht zijn TCP en UDP ook "toepassingen" die boven IP zijn gebouwd...

Toch niet. Je kunt niet zomaar een nieuw protocol verzinnen dat layert op het IP protocol, want in een IP packet staat een protocol nummer, en de invulling daarvan staat gedefinieerd in de specificatie van het IP protocol. Voor verschillende OSI layer 4 protocollen zijn gewoon nummers reserveerd.

Dit in tegenstelling tot application layer protocols. Als je een willekeurig TCP-packet ziet waar menig protocol zoals HTTP gebruik van maakt, dan kun je aan de metadata alleen niet zien wat voor protocol er daadwerkelijk overheen gaat. Zelfs poortnummer zegt in werkelijkheid vrij weinig.

[Reactie gewijzigd door .oisyn op 24 februari 2015 20:49]

Toch niet. Je kunt niet zomaar een nieuw protocol verzinnen dat layert op het IP protocol, want in een IP packet staat een protocol nummer, en de invulling daarvan staat gedefinieerd in de specificatie van het IP protocol. Voor verschillende OSI layer 4 protocollen zijn gewoon nummers reserveerd.

Dat is niet anders voor TCP-poorten en dergelijke, daar is ook een registry van die ze naar protocollen mapt. Maar ondanks dat kun je gerust een ander protocol dan http over poort 80 versturen, net als je een willekeurig IP-protocol over internet kunt versturen, of het nummer nou geregistreerd is of niet.

Alleen als je onderweg firewalls tegenkomt zullen die jouw eigen protocol wellicht tegenhouden, maar dat is niet anders dan met het gebruik van willekeurige TCP-poorten.

Het zijn verschillende laagjes, maar ze zijn prima vergelijkbaar.

Daarnaast lijk vooral jij http hier synoniem te stellen aan het web, maar tegenwoordig gebruiken zo enorm veel verschillende toepassingen allemaal http als onderliggend protocol, dat de opmerking dat het op dit moment één van de bouwstenen van het huidige internet is me volledig gerechtvaardigd lijkt.

Je hebt wel gelijk, maar in de praktijk is er toch een groot verschil. Zo zal de gemiddelde huis-tuin-en-keuken-router alle TCP en UDP verkeer prima routeren, ook als er "foute" protocollen worden gebruikt. Bijvoorbeeld IMAP over port 443.

Dat ligt anders bij de protocollen boven op IP. Als jij UDP gaat uitwisselen maar het protocol nummer op TCP zet zal vrijwel elke router daarvan in de war raken. De router zal voor NAT of SPI doeleinden de boel proberen te interpreteren en dat gaat dan mis.

Bovendien zullen de meeste routers alleen TCP, UDP en ICMP goed doorlaten. Iets als ESP, UDP-Lite of GRE levert bij menig router al problemen op, om over exotischere protocollen nog maar te zwijgen en dan ben je ze nog niet eens aan het wisselen of customisen.

Dat is niet anders voor TCP-poorten en dergelijke, daar is ook een registry van die ze naar protocollen mapt

Dat er een registry is wil niet zeggen dat het ook verplichtingen opwerpt. Nergens staat dat poort 80 voor HTTP gebruikt moet worden, noch dat HTTP alleen over poort 80 gebruikt mag worden. En hoewel je inderdaad willekeurige IP packets over het net kan sturen, staat toch redelijk vast dat protocol nummer 6 gebruikt dient te worden voor TCP, en dat TCP verkeer alleen protocol nummer 6 gebruikt. Nogal een verschil.

Daarnaast lijk vooral jij http hier synoniem te stellen aan het web

Dat is nogal een boude statement. Nergens beweer ik dat HTTP louter voor het web gebruikt wordt - je moet me geen woorden in de mond leggen.

[Reactie gewijzigd door .oisyn op 25 februari 2015 10:05]

Het Internet Assigned Numbers Authority heeft poort 80 aan http toegewezen. Dus het staat wel vast.

http://nl.m.wikipedia.org/wiki/TCP-_en_UDP-poorten

[Reactie gewijzigd door Anoniem: 604167 op 24 februari 2015 21:30]

Ik kan met gemak m'n SSHD op port 80 zetten, en mijn HTTPD op port 25 en hier (bijna) overal gebruik van maken zonder problemen. Er komt geen IANA politie langs om mij te arresteren.
Een TCP pakketje waarbij in de IP header protocol 2 (IGMP), ipv 6 (TCP), bevat gaat waarschijnlijk niet heel ver komen.

Je kunt het zeker doen en http (net als ander protocol) op een andere poort gebruiken. Echter staat vast dat poort 80 officieel voor HTTP gebruikt word.

Niet, of ik nou poort 80 gebruik of een ander poort het zal blijven werken en de politie komt niet langs om het te controleren.

Zover ik weet wordt poort 80 standaard gebruikt en standaard gereserveerd voor http-verkeer, maar je bent tot niets verplicht
Anders is het testen met bijv. IIS Express (standaard poorttoewijzigen boven de 1024 voor http, 44300-44399 voor HTTPS) bijvoorbeeld niet mogelijk dan wel handig

Het is meer dat, om zaken makkelijker te maken en enigszins standaard te krijgen, er is afgesproken dat poort 80 wordt gebruikt voor de http-daemon. Maar dat heeft volgens mij meer met dns-entries te maken dan strikt met http... Een standaardpoort is immers makkelijker te vinden.

En om dit soort inhoudelijke discussies lees ik nou altijd de comment sectie op Tweakers. Typisch voorbeeld van: "Ter lering ende vermaak."

Wat ik in mijn post zei is dat er nergens staat dat poort 80 voor HTTP gebruikt moet worden. Er staat ook nergens dat poort 80 alléén voor HTTP gebruikt mág worden. Er staat alleen vast dat poort 80 de standaard poort is voor HTTP. Het is handig om dat vast te leggen, zodat verschillende standaard services niet conflicteren. Maar het is verder vooral een richtlijn - zowel de server als de client (browser) zal niet moelijk doen als er een ander poort gebruikt wordt, noch de tussenliggende routers (dingen als transparent proxies uitgezonderd uiteraard).

Die situatie is nogal anders voor de verschillende IP protocollen. Jouw TCP verkeer zal alleen goed over het internet werken als je daar IP-protocol 6 voor gebruikt. Het protocol-nummer in een IP packet heeft daardoor veel vastere betekenis dan het poort nummer in een TCP packet.

@ .oisyn

IP staat voor Internet Protocol en niet IP Protocol

[Reactie gewijzigd door Anoniem: 114278 op 24 februari 2015 21:42]

IP is een protocol en daarom kun je zeggen "Het IP-protocol". Dat is inderdaad dubbelop, net als pincode, bommoeder, apk-keuring, etc. Niet vreemd dus. Leesvoer.

[Reactie gewijzigd door .oisyn op 25 februari 2015 10:03]

http://nl.wikipedia.org/wiki/Internetprotocol

IP is een afkorting van Internet Protocol

waarom een onjuist stelling + 1 gemodereerd wordt en een juiste stelling met 0 is mij een raadsel

[Reactie gewijzigd door Anoniem: 114278 op 25 februari 2015 15:35]

Misschien moet je de aanname dat ik niet weet waar IP voor staat even laten vallen en dan opnieuw lezen wat ik zeg.

Ik zag deze laatst op Twitter: https://twitter.com/xme/status/515071679761223681

Denk dat je HTTP zeker wel een bouwsteen kan noemen.

De definitie bouwsteen is gevaarlijk. Met een bouwsteen wordt een onderdeel bedoeld dat veelal cruciaal is. Ofwel, zonder dat onderdeel valt de boel om. Dat iets als http (of voor mijn part html) veel gebruikt wordt maakt het nog niet cruciaal.

Dus? Als http wereldwijd zou 'omvallen', dan valt het hele web toch ook om?

Even buitengelaten dat HTTP nooit kan omvallen

Dus? Als http wereldwijd zou 'omvallen', dan valt het hele web toch ook om?

Het web ja, maar het ging om het internet , inclusief de stelling dat het internet geen synoniem is voor het web.

[Reactie gewijzigd door .oisyn op 25 februari 2015 10:26]

Het was nog vroeg

Nooit omvallen en IT.... dat je dat durft te zeggen

Maar nee, het internet valt niet om. Als een browser met een marktaandeel van 75% een bug heeft waardoor de pagina niet gerenderd wordt is het internet dan stuk?

HTTP is absoluut belangrijk maar ik denk niet dat het de aanduiding "bouwsteen van het internet" verdiend.

Och, lijkt me toch zeker waardig om het een 'bouwsteen' van het web te noemen... ook al staat 'internet' en 'web' niet voor hetzelfde; wordt in de volksmond wel vaak zo gebruikt.

Dit is dan ook een semantische discussie van het caliber mierencopuleren. Technisch en hierarchisch zijn IP en tcp/ip de bouwstenen, correct. Of moeten we arp en csma/cd er ook bij betrekken... ? U snapt mijn punt? Http is de bekendste en voor de consument een van de meest gebruikte en oudste toepassingsprotocollen. Indien je het internet niet hierarchisch bekijkt klopt dat prima... Een dakpan is ook een "bouwsteen". Afbranden van "http" argument beetje overdreven imho.

Ik ben het volledig eens met je stelling dat http een bouwsteen van het Internet is. Het is echter allesbehalve een der oudsten: als ik me niet vergis, bestaat het sinds 1992... E-mail en ftp zijn een stuk ouder.

Dus als iedereen van de Eifeltoren springt, die jij het ook??? Het klopt niet. Het heet ook een webbrowser.

Mooi om te zien dat het zo snel wordt opgepikt door alle grote browsermakers, als Google het eens niet zolang gaat laten naslepen zoals ze anders doen, hebben we met een beetje geluk tegen het eind van het jaar een landschap waar HTTP2 al wijd wordt ondersteund door de gebruikte browsers (naar marktaandeel).

Begin volgend jaar wil de internetgigant ondersteuning voor het spdy-protocol helemaal laten vallen.

Waarom is Google dan nu bezig aan SPDY4?

Google doet altijd vanalles. De beste manier om te zien of iets werkt is het op grote schaal testen, en dat kunnen ze dankzij al hun online services en Chrome. Er is ook nog QUIC, dat over UDP in plaats van TCP gaat, bijvoorbeeld.

Chrome heeft ondersteuning voor heel veel protocollen, ze staan gewoon standaard niet aan. Surf even naar chrome://flags en je kan HTTP/2, QUIC en een hoop andere dingen nu al aanzetten.

Dat ze het standaard niet aanzetten zolang het geen goedgekeurde standaard is net goed. Anders beginnen programmeurs niet-gefinaliseerde versies soms te gebruiken en krijg je, basically, chaos.

(Redelijk wat sites hebben al ondersteuning voor SPDY, en een aantal Google-sites zijn ook al klaar voor een draft van HTTP/2. Ik YouTube al een paar maanden over HTTP/2, en de eerste helft van 2014 over QUIC.)

Ze laten SPDY 4.0 meer op HTTP/2 lijken. Misschien doen ze dit om te zorgen dat de overstap naar HTTP/2 makkelijker word voor servers en dergelijke.

Ideaal dat deze standaard nu ook geadopteerd door Firefox wordt. Het zorgt ervoor dat SSL sites 'sneller' worden. Zodat ook voor gewone sites, het opzetten van een veilige verbinding geen vertraagde weergave meer geeft. Veilig internet met Spdy of http/2 geeft gewoon de snelheid die je gewend bent, maar dan met zekerheid, dat de site die je bezoekt, ook de site is waar je wilt wezen.

Veilig internet met Spdy of http/2 geeft gewoon de snelheid die je gewend bent, maar dan met zekerheid, dat de site die je bezoekt, ook de site is waar je wilt wezen.

ja, blijf maar lekker zo naief.. ook bij SSL zul je goed moeten opletten, het is al lang geen 100% zekerheid meer..

Het is nooit 100% veilig geweest, echter kan je het risico tot een minimum beperken. Daarnaast spelen nog zo veel externe invloeden mee die er voor zorgen dat een systeem nooit 100% veilig kan zijn.

Sinds de update naar FF36 is er nu ook Firefox Hello toegevoegd.. een beetje whatsapp-achtig en verwerkt in je browser, ben benieuwd of 't aanslaat bij 't gros van de mensen... mij lijkt 't eigenlijk niet echt bijzonder iig.

Firefox Hello zat zelfs al in FF35, echter lijkt het nu inderdaad standaard aan te staan voor iedereen. Ik merkte het nu ook pas op in ieder geval.

Wil je er vanaf? Type dan "about:config" in je adresbalk, zoek vervolgens naar "loop.enabled", dubbelklikken naar false en Firefox herstarten. Poef weg is de rommel.
Echt verwijderen doet het niet en lijkt niet eens mogelijk, maar het is nu tenminste uitgeschakeld.

[Reactie gewijzigd door Postman op 24 februari 2015 21:18]

Ben je verder wel tevreden over Firefox, of zijn er langzaamaan steeds meer dingen waar je niet blij mee bent? Als de Firefox van een jaar ofzo geleden je beter beviel dan de huidige (maar je wel up-to-date wil blijven) dan zou je eens naar Palemoon kunnen kijken; oorspronkelijk begonnen als een "optimised build", maar inmiddels uitgegroeid tot een echte fork. Ze zijn tegenwoordig erg snel in het overnemen van wijzigingen die ze goed vinden (HTTP/2 is een mooie testcase om eens te kijken hoe snel precies ).

Bedankt voor de tip, Palemoon bevalt mij opzich wel.
Kan ook naast Firefox open staan.

Persoonlijk bevalt Hello mij wel. Het is zonder plugins en andere rotzooi te gebruiken. Vooral voor mensen die weinig snappen van dat soort installatie dingetjes is het een uitkomst omdat je alleen de link hoeft te sturen (en deze in firefox moet laten openen)

Dank

Ik heb het uitgezet.

De beta van Firefox 36 had ook een eerste implementatie van Media Source Extensions, wat DASH playback op Youtube mogelijk maakte. Daardoor kon je via HTML 5 1080p 60 fps YouTube videos bekijken. Zie ook de releasenotes van de beta:
Implemented a subset of the Media Source Extensions (MSE) API to allow native HTML5 playback on YouTube.
https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/

In de final versie van Firefox 36 staan deze Media Source Extensions helaas standaard weer uit. Je kunt ze via about:config aanzetten, maar ik had gehoop dat ze standaard aan zouden staan. Weet iemand misschien waarom het nog steeds niet standaard aan staat?

Te veel crashes, vooral OOM (Out-Of-Memory) crashes. Mede omdat in deze versie ook standaard Direct2D 1.1 hardwarematige versnelling gebruikt wordt op Windows, en ze niet twee nieuwe bronnen van crashes op Windows wilden hebben. Het is wel jammer, want er is behoorlijk wat werk in gegaan om MSE ook in 36 werkende te krijgen (terwijl de code werd ontwikkeld voor 37 en 38).

Bedankt voor de info. Begrijpelijke keuze dan. Ik vind het jammer dat ik langer moet wachten, maar als het nog crashes veroorzaakt dan heb ik liever dat ze het eerst perfectioneren. Wanneer kunnen we de MSE voor YouTube nu verwachten? Firefox 37? Of 38?

Hoe kom je aan deze info trouwens? Wordt dit ergens op een forum besproken ofzo? Want ik kon het zelf niet vinden.

Ik krijg veel bugmail over een aantal componenten (en volg een aantal ontwikkelaars), dus is het niet moeilijk om een beeld op te bouwen. Daarnaast zijn er ook nieuwsgroepen zoals mozilla.dev.planning, mozilla.dev.platform en firefox-dev, en worden nota bijgehouden op de Platform wiki. Die gebruik ik minder, maar het zal daar waarschijnlijk langsgekomen zijn.

MSE-ondersteuning voor Youtube wordt nu gepland voor Firefox 37. Ik weet niet zeker of MSE-ondersteuning in het algemeen aan zal staan, of alleen een whitelist voor Youtube. Met Firefox 37 zal ook de 64-bit versie voor Windows beschikbaar worden als ik me niet vergis, dus dat zal ook tegen dit soort crashes helpen! Natuurlijk kunnen ze er niet vanuit gaan dat iedereen die versie ook meteen zal gebruiken.

Bij mij werkt het nu op YouTube (zie hier onder) maar werkt deze demo bijvoorbeeld ook. Dat suggereert dat het niet alleen een whitelist is voor YouTube.

Heb je het over dat filmpje van 6 seconden op die site? Dat speelt hier in Firefox 36 ook af. Zal in oudere versies van Firefox ook afspelen. Dat is gewoon een HTML 5 video, iets dat Firefox al heel lang ondersteund.

Wat nieuw is in de beta is Media Source Extensions, wat nodig is voor DASH playback van HTML 5 video. Non-DASH playback wordt al jaren ondersteund, daar zijn geen MSE voor nodig.

DASH playback houdt in dat niet de gehele video wordt gebufferd, maar steeds maar een klein stukje. Voor 1080p en 480p gebruikt YouTube DASH. 720p is non-DASH en werkt dus ook al tijden in Firefox met HTML 5.

Je hebt helemaal gelijk, dat filmpje blijkt geen MSE nodig te hebben dus het bewijst inderdaad niets. Weet jij, behalve YouTube, sites die MSE en h.264 nodig hebben om te testen?

Ik ken één testsite van de BBC. Kijk maar even naar deze link:
http://rdmedia.bbc.co.uk/radio3/index.html

(Lees ook het achtergrondartikel hier: http://www.bbc.co.uk/rd/blog/2014/03/media-source-extensions)

In een browser die geen MSE ondersteunt (of alleen ondersteunt op YouTube) zul je het volgende bericht krijgen:
Your browser does not appear to support Media Source Extensions.

Please see the FAQs for guidance..

In een browser die wel MSE ondersteunt zul je dit bericht krijgen:
The stream appears to have ended. If the concert hadn't finished, please try refreshing the page.

Je kunt dus helaas niet het concert beluisteren om te kijken hoe goed MSE werkt. Maar het is een snelle check om te zien of je browser überhaupt MSE ondersteunt.

Edit: hier heb je nog een testsite:
http://www.jwplayer.com/html5/mediasource/
Deze site laat in detail zien wat je browser ondersteunt. Er zijn nogal wat verschillen tussen IE11 en Chrome.

Edit: en hier een testsite die daadwerkelijk een video laat zien als je browser MSE ondersteunt:
http://html5-demos.appspot.com/static/media-source.html
Tenminste, in Chrome zie ik een video. In IE11 gaat er een balkje lopen en zie ik geen video helaas. In Firefox krijg ik een melding dat de API niet wordt ondersteund.

[Reactie gewijzigd door dusty-2011 op 27 februari 2015 01:01]

Hmm... zowel de BBC als de jwplayer test suggereren dat Firefox 37 beta 1 geen MSE ondersteunt. Bij de appspot test zie ik inderdaad ook die API melding. HTML5test.com zegt ook dat MSE niet ondersteunt wordt.

Dat zou kunnen betekenen dat ze inderdaad een whitelist gebruiken zodat het werkt op YouTube maar niet op alle andere sites (wie weet staat er wel meer dan alleen YT op de whitelist).

Het is niet ondenkbaar, gezien het crashes verhaal van Mitsuko, dat ze het in beta 1 voorzichtig aan hebben gezet maar wel met een whitelist. Hopelijk is er later in de beta-fase voldoende gefixt of voldoende vertrouwen om de whitelist op te heffen.

[Reactie gewijzigd door Maurits van Baerle op 27 februari 2015 14:08]

Hopelijk is er later in de beta-fase voldoende gefixt of voldoende vertrouwen om de whitelist op te heffen.
Voor zover ik begrepen heb gaan ze eerst alles perfectioneren voor YouTube. In latere versies komt dan pas MSE voor andere sites. Om MSE op alle sites werkzaam te krijgen is nog flink wat werk nodig. Ik durf geen inschatting te geven hoe lang het gaat duren. Maar het zou me niets verbazen als MSE voor alle sites pas in Firefox 40 beschikbaar komt.

Ik heb met deze werkwijze geen problemen. MSE voor YouTube volledig werkend krijgen moet de hoogste prioriteit hebben. YouTube is ook de enige echte grote site die ik ken die vol inzet op MSE. Om andere sites te vinden die MSE gebruiken moet je nog echt goed zoeken.

Ik zit op het Firefox betakanaal en heb vanochtend Firefox 37 beta 1 gekregen. Daar ziet het overzicht op www.youtube.com/html5 er ineens zo uit: http://i62.tinypic.com/j6r4sk.jpg Dit is op OS X 10.9.5.

Kortom, ondersteuning voor MSE, MSE & H.264 is nu toegevoegd, beide waren rood in Firefox 36. En YouTube doet het prima met de standaard HTML5 player. Een stuk soepeler dan de oude flash player.

Is MSE in combinatie met VP9 dan nóg niet af? Hoe zit dat dan nu? Zijn er YouTube video's die alleen in VP9 beschikbaar zijn of zijn die ook in H.264 beschikbaar? Als ze alleen in VP9 beschikbaar zijn dan krijg je dus alsnog de Flash Player?

Ik had gehoopt dat MSE en VP9 ook af zou zijn. Dan kan ik eindelijk 60 fps video's kijken.

Kennelijk niet. Ik geloof dat Firefox VP9 wel ondersteunt maar misschien nog niet in combinatie met MSE.

Overigens hoeft dat volgens mij geen probleem te zijn. Voor zover ik weet is YouTube volledig h.264 en hebben ze alleen een deel ook als VP9 beschikbaar gemaakt. In principe zouden alle video's op YT dus gewoon moeten werken.

Aangezien de HTML5 player en de Flash player allebei gewoon h.264 gebruiken hoefde YouTube dus niet al hun materiaal opnieuw te encoden om over te stappen van de Flash player naar de HTML5 player. Voor het afspelen van VP8/VP9 moeten ze natuurlijk wel opnieuw coderen dus is het niet vreemd als je daar minder van tegen komt.

[Reactie gewijzigd door Maurits van Baerle op 26 februari 2015 14:44]

Ok, in dat geval missen we niets. Want als ik zo naar bijv. dit artikel kijk http://iphome.hhi.de/marp...264_PCS_2013_preprint.pdf dan maakt VP9 haar claims van een hogere efficiëntie niet waar. HEVC (ook wel H.265 genoemd) biedt wél een flink hogere efficiëntie dan H.264 (waar wel absurd hoge encoding times tegenover staan). Maar VP9 komt in dit artikel niet als efficiënter dan H.264 uit de bus. De VP9 encoder had 100 keer zo veel tijd nodig om de video's te encoden (in vergelijking met de H.264 encoder), maar was ongeveer 8.4% minder efficiënt dan de H.264 encoder.

Firefox heeft al een hele tijd VP9 support, zie bijv. https://gigaom.com/2013/1...eration-open-video-codec/ Maar op VP9 in samenwerking met MSE moeten we dus nog wat langer wachten.

Bedankt yotube werkt nu weer met 1080p hier. Al 2 weken lopen klooien met plug ins die niet werkten.

Nu werkt het weer als van ouds.

Het is maar de vraag of we echt zo blij moeten zijn met de huidige HTTP/2, er is een kleine groep, maar wel met kennis van zaken, die zeggen dat de huidige HTTP/2 een compromis is van slechte beslissing die voornamelijk gebaseerd zijn op politieke beslissingen van bedrijven, en belanghebbende.

En vooral privacy is de grote verliezer in het HTTP/2 protocol, daar er niks is gedaan om gebruikers te beschermen tegen bedrijven en overheden, die willen weten wat gebruikers doen.

En maar zeer beperkte prestatie verbeteringen met zich mee brengt in de praktijk.

The team also noted that SPDY took a heavier performance hit than HTTPS when packet loss was higher and that the protocol was intrinsically more likely to suffer packet loss than the protocol it ostensibly replaces. Whether these issues were fundamentally corrected in HTTP/2 is unclear — no one seems to have addressed the issue one way or another.

ExtremeTech: Prominent developer criticizes HTTP/2 protocol, claims politics drove adoption process
ACM: HTTP/2.0 - The IETF is Phoning It In, interessante reacties en discussie op het artikel op Hacker News

Correct me if I'm wrong maar is het juist niet de taak van een protocol als HTTP/HTTP2 om voor privacy e.d te zorgen? Dat lijkt me een taak voor een hoger liggende laag, HTTP is puur data over en weer brengen en niks meer.

Je hebt de artikelen niet gelezen. Cookies maken ook deel uit van HTTP en Poul-Henning Kamp had graag willen zien dat deze vervangen werd voor een ander mechanisme wat meer controle over het volgen van gebruikers zou opleveren. Maar zijn punt is dat de grote bedrijven zoals Google en facebook dat niet willen omdat dat juist hun core business is.

Dat komt omdat HTTP per definitie stateless is, iets wat eigelijk nu niet meer werkt, maar toen HTTP bedacht werd prima was.

Vandaar ook dat HTTP met 1.1 is uitgebreid tot het bieden van cookies: http://tools.ietf.org/html/rfc6265

Ter info en aanvulling; de server-zijde moet het natuurlijk ook ondersteunen. Windows 10 Technical Preview ondersteunt het ook server-zijde. http://blogs.msdn.com/b/i...-long-awaited-sequel.aspx
Ben wel benieuwd hoe snel dit beschikbaar is in cloud web services zoals Azure.

[Reactie gewijzigd door geertdo op 24 februari 2015 20:19]

"Behalve Firefox biedt ook Internet Explorer 11 out-of-the-box de http/2-standaard aan in Windows 10."

Euh ik bedoelde server-zijde Je kunt dus Visual Studio erop zetten en het http/2 protocol volgen.

[Reactie gewijzigd door geertdo op 24 februari 2015 20:31]

Lezen blijft lastig

Da's waar ook begrijpend lezen

Internet Explorer is natuurlijk ook echt een webserver

Ik kon het bijna niet vinden in de tekst en dacht dat je je vergist had en dat het alleen om internet explorer ging op windows 10. Windows phone 8.1 heeft nu spdy 3.0 maar zal dan met windows 10 voor phone ook wel http/2 krijgen en/of spdy 4.0

Maar goed de IIS webserver heeft dus support in windows 10 tech prev alleen encrypted (wat wel fijn is)

The Technical Preview has HTTP/2 server support also. This means you can create sites in IIS and test your content end to end. Note: in the Technical Preview versions of both IE and IIS, non-secure connections (i.e. HTTP) are not supported on HTTP/2; only secure connections (i.e. HTTPS) are supported on HTTP/2.

Hoe kan je herkennen of een website http/2 ondersteund?

Daarnaast hoe weet ik of mijn browser (chrome) hier ook gebruik van maakt? Ik heb dat namelijk aangezet in chrome://flags.

Many thnx

http://spdycheck.org/#tweakers.net

Tweakers.net ondersteunt het dus niet.

Is die test ook valide voor HTTP/2? Immers SPDY != HTTP/2 (al lijkt het er wel sterk op)

Ja, min of meer. Bij ondersteunde protocollen van google.nl bijvoorbeeld, zie er 'h2-15' tussen staan. Wat 'HTTP/2 draft 15' is

Net de update binnen gekregen, viel wel op dat hij ondertussen na 5 minuten 2x niet reageerde, pas toen ik ad-block uit deed...

Voor mij is het nu nog even wachten tot nginx ook HTTP/2 ondersteunt. Volgens ServerWatch.com zijn er - aldus Owen Garrett - al wel plannen om aan het einde van dit jaar die ondersteuning ook uit te rollen.

[Reactie gewijzigd door Zeg op 24 februari 2015 20:19]