Standaardenorganisatie keurt http/2-standaard goed

De IETF HTTP Working Group heeft de http/2-specificatie goedgekeurd. De nieuwe specificatie volgt na zestien jaar de http 1.1-specificatie op en moet onder andere het sneller inladen van webpagina's mogelijk maken.

Nu de HTTP Working Group klaar is met de http/2-specificatie, zal de draft de status van 'request-for-comments' voor editors krijgen, zo schrijft Mark Nottingham, voorzitter van de werkgroep, op zijn blog. Tijdens deze fase kan er nog enige input gegeven worden. Vervolgens zal de standaard officieel door de IETF gepubliceerd worden.

Een van de verbeteringen die http/2 brengt is de multiplexing-mogelijkheid, waarbij meerdere http-requests vanuit de browser gebundeld naar een webserver gestuurd kunnen worden. Hierdoor wordt het totale aantal actieve connecties flink verminderd ten opzichte van http 1.1 met snelheidswinst tot gevolg. Ook het gebruik van encryptie via het tls-protocol wordt met http/2 efficiënter. Tevens is er http-headercompressie mogelijk.

De http/2-standaard is voor een groot deel gebaseerd op het door Google ontwikkelde spdy-protocol. In tegenstelling tot het spdy-protocol is het in de http/2-standaard niet langer verplicht om tls-encryptie in te schakelen, maar Mozilla en Google hebben aangekondigd dat Firefox en Chrome http/2-verbindingen zonder tls niet zullen accepteren.

Met de afronding van de http/2-standaard komt er na zestien jaar een vervanger voor het http 1.1-protocol, een van de bouwstenen van het huidige internet. Het zal nog enige tijd gaan duren voordat http/2 de dominante standaard wordt, omdat nog veel software aangepast zal moeten worden om met de nieuwe http-standaard overweg te kunnen.

Reacties (85)

Als auteur van een open source webserver ben ik niet echt blij met HTTP/2. Het brengt een boel extra complexiteit met zich mee voor een server om te implementeren. Daarnaast zijn er allerlei lelijke en vieze dingen in HTTP/1.x die niet aangepakt zijn (te lang verhaal om dat hier te gaan intikken).

Daarnaast is mijn ervaring dat SPDY (en dus ook HTTP/2) alleen voordeel gaat bieden als je Google of een vergelijkbare organisatie bent. Het multiplexen biedt niet zoveel snelheidswinst als men wil laten geloven. Vaak staat de content van een website op verschillende plekken (plaatjes, advertenties) waardoor het gebruiken van slechts 1 connectie helemaal niet kan. Daarnaast heeft HTTP/1 al request pipelining, waarbij een browser meerdere requests kan sturen zonder eerst het antwoord van een vorige te hoeven afwachten. Alleen staat dit op de meeste browsers standaard uit. Wat je ook ziet is dat de eerste request (vaak een CGI script) lang duurt en de vervolg requests (voor de plaatjes, JS, CSS, etc) uitblijven vanwege browser caching. Dus dat multiplexen vraagt een hoop complexiteit en biedt weinig voordeel.

Waarom hebben we dan toch HTTP/2? Nou, omdat het voor Google wel interessant is. Zij hebben alle content op hun eigen server staan. En omdat IETF verzaakt heeft om met HTTP/2 te beginnen, is een commerciele partij (Google dus) daar op in gesprongen en de boel naar eigen hand weten te zetten. HTTP/2 is in feite een protocol door Google, voor Google.

Mijn ervaring is dat je met slim cachen op de server een veel grotere snelheidswinst behaalt dan HTTP/2 je ooit zal bieden. Zeker op het moment dat er een slimme samenwerking is tussen het framework van je CGI applicatie en de webserver (wat ik heb gedaan met mijn framework in combinatie met mijn webserver). Je haalt dan honderden tot duizenden requests per seconde in plaats van enkele tientallen. Dat is een snelheidswinst die HTTP/2 je nooit gaat bieden.

[Reactie gewijzigd door Faeron op 18 februari 2015 10:51]

Het doel van HTTP/2 is niet om de efficiëntie bij de server te verbeteren, maar juist bij de client. Met HTTP/2 is het mogelijk in dezelfde tijd een groter deel van de resources die nodig zijn voor het renderen van een pagina te ontvangen dan met HTTP/1.1. Daardoor renderen pagina's sneller, wat fijn is voor de (menselijke) eindgebruiker.

Voor de server heeft het verder weinig voordelen; die moet nog steeds dezelfde hoeveelheid data versturen en latency doet er voor de server niet echt toe.

HTTP/2 realiseert die lagere latency vooral door multiplexing van verschillende datastromen over een enkele TCP-connectie. Dat heeft twee voordelen. Ten eerste kunnen grote/trage resources de ontvangst van kleine/snelle resources niet meer blokkeren. Ten tweede werkt transmission control het best wanneer alle requests over een enkele verbinding gaan (want TCP optimaliseert bandbreedte per connectie, niet per host-paar).

Daarnaast heeft HTTP/1 al request pipelining, waarbij een browser meerdere requests kan sturen zonder eerst het antwoord van een vorige te hoeven afwachten.

HTTP pipelining is geen alternatief voor multiplexing. Het gaat er niet om dat de client meerdere requests kan versturen, maar dat de client resources kan ontvangen zodra ze beschikbaar zijn, en niet gedwongen is om ze af te wachten in de volgorde waarin ze toevallig opgevraagd zijn.

Dat probleem wordt helemaal niet opgelost door HTTP pipelining. In plaats daarvan openen browsers nu uit wanhoop maar meerdere TCP-verbindingen met dezelfde server zodat ze tenminste een stuk of vier requests parallel kunnen uitvoeren. Met HTTP/2 hoeft dat niet meer.

Mijn ervaring is dat je met slim cachen op de server een veel grotere snelheidswinst behaalt dan HTTP/2 je ooit zal bieden.

Het is niet of/of. Als een groot deel van de resources gecachet wordt, zijn de verschillen in latency tussen gecachete en niet-gecachte resources juist groot, en heeft de eindgebruiker dus baat bij HTTP/2.

[Reactie gewijzigd door Soultaker op 18 februari 2015 12:55]

Kleine toevoeging: de server(beheerder) heeft wel baat bij HTTP/2 te deployen aangezien een HTTP/2 server meer clients kan bedienen dan een HTTP1.1 server voor eenzelfde load. Cfr. http://www.neotys.com/blo...spdy-enabled-web-servers/

[Reactie gewijzigd door logion op 18 februari 2015 14:50]

Wanneer je SSL gebruikt is SPDY (3) wel degelijk een grote snelheidswinst. De TTFB neemt enorm af in combinatie met OCSP-stapling en goede caching. Aangezien men stimuleert om iedereen SSL te laten gebruiken is HTTP/2 een hele goede aanvulling en zal het argument dat SSL snelheidsverlies met zich meeneemt veel minder waarde krijgen.

TLS (SSL is dood) is optioneel in HTTP/2

In mijn optiek zou SSL niet optioneel moeten zijn, maar zou het kiezen voor geen SSL optioneel moeten zijn. Een volledig encrypted web voorkomt massale ongerichte data-mining door overheidsinstanties als de NSA. Voor statische HTML pagina's is het overbodig, maar die websites zijn in principe in de minderheid.

Ligt volgens mij aan de implementatie van de encryption en je kan er dan donder op zeggen dat de NSA (of welke inlichtingen dienst dan ook) hard z'n best doet hier backdoors in te krijgen.

Ja, maar dan nog kan men dan niet zo massaal als nu data vergaren. Doelgerichte acties kun je niet tegengaan (men heeft wellicht meerdere backdoors/manieren), maar die massale datavergaring is juist hetgeen dat zo gevaarlijk is (het digitale vissersnet).

Wanneer iedereen zijn cloudgegevens encrypt en alle websites via het SSL protocol verlopen kan de NSA zijn gigantische datacenters sluiten omdat die massale datavergaring dan compleet nutteloos is.

Het moet wel optioneel zijn, want anders zou elke website in de wereld een certificaat moeten aanvragen. Dat brengt nogal wat kosten met zich mee, en is voor de website van de slager of de bakker om de hoek daarnaast volledig zinloos.

Echter kom je dan nergens als je Chrome of Firefox gebruikt.

Ben het hier niet echt mee eens.
1) Het brengt complexiteit met zich mee voor de webserver.
Akkoord, maar dat zou geen argument mogen zijn. Er zijn slechts een handvol veelgebruikte webservers. Dat zijn er slechts een handvol die nu wat werk hebben om zowat het hele WWW te kunnen bedienen.

2) Grote sites hebben er het meeste voordeel van:
Google's sites zijn al zodanig geoptimaliseerd dat static content (js, css, icons als spritesheets, ...) gecombineerd wordt en vanaf een CDN wordt geladen die zijn caching goed op orde heeft. Veel JS en CSS wordt ook geinlined. Het zijn net de amateursites die tientallen verschillende JS/CSS/images laden (de meeste staan niet op een CDN, maar op 1 shared server, vaak niet met de nodige http headers voor caching goed te laten werken).
De meeste browsers beperken het aantal simultane connecties tot 4 a 6. Dus multiplexen is zeker intressant voor die kleine sites, zeker als je ze vanaf een mobiele verbinding bezoekt, waar de latency nog veel groter is.

[Reactie gewijzigd door seba op 18 februari 2015 11:35]

Vooral content management systems (denk aan Joomla, Wordpress etc) zijn hier goed zijn. Elke plugin voegt veelal zijn eigen spreadsheet en javascript toe. Met gebruik van meerdere plugins weten sommige sites een tiental CSS bestanden naast een tiental javascript bestanden in te laden.
Zeker een kijkje waard of er niet juist een plugin is die dit aanpakt, zoals Seba hierboven aangeeft valt hier grote snelheidswinst mee te behalen .

Elke plugin voegt veelal zijn eigen spreadsheet en javascript toe.

Stylesheet bedoel je, hoop ik? :-)

Op vlak van caching scoort HTTP/2 minstens gelijk als HTTP1.1. Caching aanhalen als een argument tegen HTTP/2, slaat dus nergens op. HTTP/2 focust voornamelijk op de framing van HTTP berichten binnenin TCP (of TLS), aan de mechanismen in HTTP zelf is (zoals je zegt) weinig tot niets veranderd.

Omtrent de snelheidswinst van HTTP/2 is er nog niet zoveel geweten iirc, als je echter kijkt naar de winst die een SPDY webserver haalt dan zou ik zeker zeggen dat er een substantieel verschil is: http://www.neotys.com/blo...spdy-enabled-web-servers/. SPDY (en dus ook HTTP/2) kan een veel groter aantal simultane gebruikers aan voor eenzelfde load.

Request pipelining is inderdaad iets wat bestaat in HTTP 1.1 maar je kunt nog altijd tegen head of line blocking aanlopen. En zoals je zegt staat dit inderdaad af in meeste HTTP 1.1 clients/browsers. Multiplexing in HTTP/2 daarentegen zorgt wel voor aanzienlijke latency reductie zonder dat je 4-8 HTTP(S) connecties dient te openen. Verder komt HTTP/2 ook met server PUSH, waardoor de server proactief Web resources kan doorsturen naar de client zodat deze reeds in de client cache aanwezig zijn wanneer nodig => lagere latency.

Vergeet ook niet dat HTTP headers nu gecomprimeerd en binair worden doorgestuurd, hiermee wordt de netwerkoverhead van de vaak heel grote headers aanzienlijk minder.

Je hebt wel gelijk dat dit protocol voornamelijk organisaties met grote deployments en veel users ten goede komt, dit is dan ook het grootste deel van het HTTP verkeer vandaag. Het complexiteit argument valt imo wel mee, de http2 draft telt slechts 97 pagina's: https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

Nu is het nog wachten tot de draft wordt gepubliceerd als RFC. Maar technische wijzigingen zitten er niet meer aan te komen. Developers - die relevant willen blijven - kunnen dus starten met het implementatiewerk .

edit: voor zij die meer over HTTP/2 willen leren kan ik trouwens volgende resources aanraden:
http://http2.github.io/
http://daniel.haxx.se/http2/

[Reactie gewijzigd door logion op 18 februari 2015 12:42]

Wie zit er te wachten op zoveel requests per user. Het gaat om simultaan binnenhalen van bv source files daar heb je er in de tientallen voor nodig. Waar jij over praat werkt allang dat is multi-user. Nu zit je vast op 2 simultaan

Gelukkig gebruikt juist daarom iedereen apache

Eindelijk, ik ben heel benieuwd hoe lang de 'request-for-comments' status blijft voordat ontwikkelaars het nieuwe protocol gaan implementeren en of de snelheidswinst daadwerkelijk zichtbaar is tijdens het surfen.

Eindelijk, ik ben heel benieuwd hoe lang de 'request-for-comments' status blijft

Een RFC *is* de standaard.

Beetje verwarrende naam misschien. Maar een het is niet de bedoeling dat je commentaar gaat hebben op RFCs, zelfs als de naam Request For Comment is. De ontwikkeling van een nieuwe standaard wordt gedaan in "drafts". Draft proposals of Draft RFCs genaamd. Kortweg draft. Die worden constant aangepast, en dan opnieuw gepubliceerd met een nieuw versie nummer. De meeste drafts hebben 3-4 versies, sommige meer dan 10. Pas als iedereen tevreden is, wordt het document een standaard. Btw, lang niet alle drafts worden een standaard.

Als iedereen tevreden is, gaat de draft naar de RFC-editor. Dat zijn 1 of 2 professionals die betaald worden door de Internet Society. Die bewerkt het document op een niet-inhoudelijke zodat het aan de richtlijnen voldoet. Spelling, stijl, indeling, etc. Als dat klaar is, krijgt het document een rfc-nummer. En wordt het een standaard. Daarna kan het document helemaal nooit never niet aangepast worden.

RFCs met een protocol-specificatie krijgen eerst het label "informational". Het gekke is, die specificatie is helemaal geen vrijblijvend voorstel. Het is *de* standaard. Iedere implementatie van het protocol zal zich er aan moeten houden.

Na een aantal jaren wordt gekeken hoe het is gegaan met het protocol. Hebben meerdere bedrijven/individueen het geimplementeerd ? Wordt het gebruikt ? Is het populair ? Heeft het toekomst ? Is het relevant voor het Internet ? Zo ja, dan kan de RFC van "informational standard" naar "proposed standard". Dat is het stempel dat het protocol belangrijk is. Tijdens deze laatste stap kunnen er nog kleine veranderingen (qua stijl maar ook technisch) worden aan gebracht. Bugfixes, zeg maar. Als je daarna het protocol echt wilt veranderen of uitbreiden, zal je weer opnieuw moeten beginnen met het schrijven van draft.

Voorbeeld.
In 1998 wilden cisco en Juniper het IS-IS routing protocol uitbreiden.
De eerste draft werd geschreven in 1998. Code werd geschreven.
In Februari 1999 werd de eerste draft gepubliceerd.
https://tools.ietf.org/html/draft-ietf-isis-traffic-00
Gebruikers (ISPs) gingen de feature gebruiken in hun netwerk. In 1999 al.
Er kwamen in totaal 5 drafts. De laatste draft kwam uit in Augustus 2003.
De draft werd uiteindelijk een RFC in Juni 2004. RFC 3784.
https://tools.ietf.org/html/rfc3784
RFC 3784 was een Informational RFC. Terwijl talloze ISPs de techniek gebruikten in hun netwerken.
In Oktober 2008 werd de RFC opnieuw gepubliceerd. Met wat kleine aanpassingen.
De status was dat het nu een echte standaard was.
https://tools.ietf.org/html/rfc5305

Zo zie je, het kan 10 jaar duren voor een idee eindelijk een officiele standaard wordt.
Burocratische rompslomp. Maar het zal wel ergens goed voor hebben.

TL;DR
Een idee wordt eerst een draft-RFC.
Als het protocol en de tekst uitgekristalliseerd is, wordt het een Informational RFC.
Als het protocol goed is, wordt het uiteindelijk een Proposed Standards RFC.

Veel browsers en servers als Apache en Nginx ondersteunen deze draft al jaren...

http/2 wordt nog niet ondersteunt door zowel Apache als Nginx voor zover ik weet. Spdy wel, maar hoewel http/2 gebaseerd is op spdy is het niet hetzelfde.

Ik heb weinig ervaring met Apache maar ik dacht begrepen te hebben dat het op dit moment een aparte module is voor Apache. De verwachting was dat het na het uitkomen van de definitieve standaard zou kunnen verhuizen naar het core product.

Er is een spdy module, maar een http/2 module is nergens te vinden.

Ik ben heel erg benieuwd hoe lang het duurt voor alle grote webservers (Nginx, Apache, IIS etc) hier mee om kunnen gaan Dan kan het vrij snel gaan natuurlijk!

Ik ben heel erg benieuwd hoe lang het duurt voor alle grote webservers (Nginx, Apache, IIS etc) hier mee om kunnen gaan Dan kan het vrij snel gaan natuurlijk!

Alstu. Nog niet veel software heeft ondersteuning voor ware HTTP/2, maar dat komt wel. Tot die tijd hebben wij SPDY, zeg maar de experimentele voorganger/het prototype waarnaar gekeken is voor de ontwikkeling van HTTP/2. Ondersteuning voor die laatste zal wel snel volgen, aangezien SPDY vaak al ondersteund wordt. Zie bijvoorbeeld ook deze discussie.

Over de verplichting om SSL/TLS te gebruiken voor Chrome en Firefox gebruikers: YES! Dat was één van de voordelen van SPDY en ik vind het jammer dat deze verplichting uit de standaard is gehaald. Gelukkig dat Google en Mozilla het touw voortrekken door met hun populaire browsers alleen beveiligde verbindingen te ondersteunen.

Volgende stap: het PKI model op de schop, zodat niet een enkele vertrouwde CA voor veel schade kan zorgen? We can only hope.

[Reactie gewijzigd door The Zep Man op 18 februari 2015 10:39]

"Gelukkig dat Google en Mozilla het touw voortrekken door met hun populaire browsers alleen beveiligde verbindingen te ondersteunen."

Eigenlijk zeggen ze dat ze zich niet aan de nieuwe standaard gaan houden. En daar ben je blij me?

Eigenlijk zeggen ze dat ze zich niet aan de nieuwe standaard gaan houden. En daar ben je blij me?

Ik ben ervan overtuigd dat Google HTTP/2 volledig en correct gaat ondersteunen. Dat zij besluiten om het niet te ondersteunen over onbeveiligde verbindingen heeft niets met die standaard te maken, maar met de implementatie. De verplichting komt daarom vanuit de implementatie, niet vanuit de standaard.

De grote drie (Google, Microsoft, Mozilla) beperken het gebruik van onveilige protocollen al jaren, bijvoorbeeld SSL 2.0 en straks SSL 3.0. Dat unencrypted verbindingen niet meer ondersteund worden zie ik als iets dat al vele jaren eerder had moeten gebeuren. Zo weet je dat er onderweg tussen server en client niets veranderd wordt aan de verstuurde data, wat naar mijn mening gewenst is. ISP's worden daarmee verplicht om alleen te doen wat zij moeten doen (=pakketten schuiven) en overheden hebben zo minder mogelijkheden tot bedoelingen die als kwaadaardig bestempeld kunnen worden.

Altijd en overal encryptie had jaren geleden al ingevoerd moeten worden. Dat zou veel ellende gescheeld hebben.

[Reactie gewijzigd door The Zep Man op 18 februari 2015 11:38]

Dat zij besluiten om het niet te ondersteunen over onbeveiligde verbindingen heeft niets met die standaard te maken, maar met de implementatie.

Juist, ze implementeren de standaard dus niet volledig...

Ja en ik ook. Het zou fijn zijn als er geen ssl-loze sites meer zijn. En met http/2 is tls een stuk sneller ten opzichte van http/1.1. Dus het feit dat tls erdoor gedrukt wordt door chrome en mozilla stemt me blij. Erg jammer dat het in de standaard niet verplicht is. Zo blijft het internet veel onveiliger dan nodig.

Ken je toevallig ook 'client'-software om het eens uit te testen?
Als in: een soort Fiddler met ondersteuning voor HTTP/2 waar ik de complete request kan bekijken/aanpassen/...?
Ik ben eigenlijk vooral benieuwd hoe die verschillende requests in één stuk opgevraagd kunnen worden.

Een sniffer als wireshark er tussen zetten als de server geen TSL gebruikt?

Wireshark + curl.

"We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. "
Bron: http://blog.chromium.org/...odbye-spdy-http-is_9.html

Interessant stuk die eigenlijk de hele RFC onderuit haalt: http://queue.acm.org/detail.cfm?id=2716278
Veel afwegingen zijn gebaseerd op commercie.

Het is treurig dat een nieuw http protocol inderdaad slechter is voor het milieu en effectief voor de meeste sites langzamer zal zijn dan huidige http protocollen en bovendien niks toevoegt op privacygebied voor mensen die meer privacy voor zich willen tov huidige protocollen.

Je kunt hier niet beiden willen, privacy en het milieu. Concreet: het "milieu" probleem in deze context is de voorgestelde verplichting om TLS te gebruiken, wat rekenintensief is en dus energie gebruikt. Het "privacy" probleem van HTTP/2 is het omgekeerde hiervan, het niet verplicht zijn van TLS.

En in de praktijk lijkt TLS in HTTP/2 uit te lopen op een rommeltje. Niet officieel verplicht, officieus wel.

Zonder alle verwijzingen naar andere op en aanmerkingen gelezen te hebben hier nog wat punten die ook van toepassing zijn.

Extra rekenkracht valt ook wel mee, vele cpu's hebben instructie set die dit helpen.

Verder hoeft imagespriting niet meer, wat geheugen en cpu scheelt omdat het voor clients makkelijker weer te geven is.

Tevens kunnen meer gebruikers over een NAT device omdat er poorten per gebruiker nodig zijn. Dan moet het NAT device misschien meer CPU en ram krijgen maar dat is altijd nog efficienter dan een extra device simpelweg omdat er geen nieuwe sessies mogelijk zijn.

Of het beter is of niet voor het milieu is moeilijk te zeggen, ik denk zelf dat de belasting gelijk blijft echter het verbruik wordt verplaatst.

Zie ook https://istlsfastyet.com/

Hij zegt eigenlijk maar 2 dingen:
- HTTP/2 verbetert privacy niet.
- Het kost meer CPU.

Daar heeft hij gelijk in maar deze 2 zaken wegen imho niet op tegen de potentiële snelheidsverbeteringen.

Het wordt juist langzamer

Dat hangt van de usecase af.
Dit is 1 van de vele mogelijkheden om de snelheid te vergelijken:
http://blog.httpwatch.com...-of-https-spdy-and-http2/
Je kunt echter makkelijk een test schrijven waarin http/2 langzamer is.

Het artikel eerder in de thread war je op reageerde zij echter ook:

You may perceive webpages as loading faster with HTTP/2.0, but probably only if the content provider has a global network of servers. The individual computers involved, including your own, will have to do more work, in particular for high-speed and large objects like music, TV, movies etc. Nobody has demonstrated a HTTP/2.0 implementation that approached contemporary wire speeds. Faster? Not really.

Dus hij zegt 3 dingen.
Hij zegt eigenlijk maar 2 dingen:
- HTTP/2 verbetert privacy niet.
- Het kost meer CPU.
EN
- HTTP/2 is trager

Hij kan dat gemakkelijk zeggen maar het is beter als hij het hard maakt.
De gemiddelde opinie lijkt te zijn dat http/2 sneller is dan voorgaande versies:
http://www.neotys.com/blo...spdy-enabled-web-servers/
http://research.microsoft...%20HTTP%20performance.pdf
http://blog.httpwatch.com...-of-https-spdy-and-http2/
http://www.httpvshttps.com/

Veel leesplezier

[Reactie gewijzigd door Jaaap op 19 februari 2015 18:27]

Er zijn al testen gebeurd die wijzen op grote snelheidsverbeteringen hoor.

Check deze maar eens: https://thethemefoundry.c...-dont-use-a-cdn-spdy-ssl/

En weer genoeg reacties hier die dat stuk van Kamp onderuit halen: https://news.ycombinator.com/item?id=8850059

HTTP/2 lost niet alle problemen op, maar als ik deze uitleg van de maker van (lib)curl lees lijkt het wel het een en het andere te verbeteren. Vaak genoemde dingen die als nadelig worden gezien (bedacht door Google, alleen nuttig voor grote sites bijv.) komen daar ook aan bod.

[Reactie gewijzigd door Rafe op 18 februari 2015 10:59]

Verandert er voor de ontwikkelaars ook iets dan? Of is dit enkel een aanpassing op serverniveau?

Ja, sommige workarounds (bijv. CSS sprites) zouden niet meer nodig zijn. Zie http://daniel.haxx.se/http2/

Css sprites zijn door brede ondersteuning van base64 en icon fonts al jaren niet meer nodig.

Base64 is altijd 33% meer data, en icon fonts zijn alleen nuttig voor iconen met een enkele kleur.

In http1.1 leveren sprites nog grote voordelen.

"gzipped base64" is effectief een hack waardoor je maar ca. 1% extra data nodig hebt in plaats van 33%.

Bundling van javascript en css bestanden zal niet meer nodig zijn zou ik denken?

De tooling om dat te automatiseren is er al geruime tijd, dus echt veel winst zal dat ook niet opleveren Je wilt meestal toch nog wel een minify doen, dus je blijft zitten met wat processing voor een deployment.

(aanname: bundling = concat van diverse bestanden om het aantal benodigde requests te minimaliseren)

Dat klopt ... het was meer een antwoord op 'Wat verandert er voor de developer?' ... niet 'Welke gigantische productiviteitswinst haal ik er als developer uit?'

Door het niet meer moeten bundelen, heb je dan wel weer een voordeel als developer dat je ook in productieomgevingen makkelijk je JS kan debuggen.
Als alles gebundeld is, is het lastiger om uit te zoeken in welk bestand de fout zich juist voordoet.

Als je JS geminified is, kan je het makkelijk 'beautifien' (lang leve dutsj inglisj!) met plugins (https://addons.mozilla.or...on/javascript-deminifier/ bv).

Ik geef toe ... het is minimale winst hoor. De keren dat ik op een server met bundling en geminimaliseerde scripts moest debuggen, kan ik op één hand tellen

[Reactie gewijzigd door Nullius op 18 februari 2015 17:49]

http://chimera.labs.oreil...emoving_1_x_optimizations

Dat wil zeggen, doe bepaalde dingen voor SPDY / HTTP2 clients anders dan voor clients die geen SPDY ondersteunen.

Domainsharding bv> www.domain.com en images.domain.com / audio.domain.com kunnen voor HTTP2 clients beter alleen www.domain.com worden. Dan gaan ze namelijk over de bestaande multiplexed verbinding in plaats van een nieuwe DNS lookup, connection open, negotiation etc.

Betekent dit dat webservers tijdelijk "dubbel uitgevoerd" moeten worden om requests op beide manieren correct af te kunnen handelen en compatible te blijven met legacy systemen? (oude pc's, telefoons, embedded browsers in systemen enz)

Ik weet niet wat jij met "dubbel uitgevoerd" bedoeld. De meeste webservers (bijvoorbeeld Apache) kunnen gewoon beide soorten requests afhandelen.

Dat bedoelde ik inderdaad. Ik zie inmiddels dat IIS dit ook gewoon "dubbel" of "duo" zal ondersteunen:

1. Run regedit.exe

2. Browse to registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

3. Create a new DWORD value named “DuoEnabled” (without quotes)

4. Set its value to 1

5. Reboot your server

(bron: http://blogs.iis.net/nazi...10-technical-preview.aspx)

Nou, dubbel uitgevoerd...
Ze moeten twee protocollen ondersteunen. Maar dat is slechts een klein deel van de totale webserver.
Overigens ondersteunen bij mijn weten alle webservers nog steeds ook http/1, dus dat zijn dan 3 protocollen.

Volgens mij kan het principe van CDN's dan ook deels de deur uit, momenteel zetten grote diensten veel CDN's neer om zo het simultaan aantal connecties te verhogen en zo sneller de download binnen te hebben. Browsers, proxy-servers etc hanteren vaak een max aantal connecties per TLD en door dit te verspreiden voorkom je blocking connecties. Mogelijk dat een CDN zoals nu opgezet zelfs weer tegen je gaat werken omdat er dan veel meer connecties opgezet dienen te worden dan nu met multiplexing mogelijk is naar 1 server.

Dat is imho niet hoofdreden om CDN te gebruiken. Hoofdredenen zijn in mijn ervaring:
1) Geografische spreiding (dus sneller)
2) Spreiding load/bandwidth (offloading origin)

Extra (sub)domeinen hebben ook weer penalty van een additionele DNS lookup. Dus het is een precaire balans .

[Reactie gewijzigd door McVirusS op 18 februari 2015 10:46]

Misschien is misbruiken ipv gebruiken een betere bewoording inderdaad

Dat is niet de functie van een CDN. Om blokkages te voorkom gebruikt men soms veel sub domains, maar dat staat los van een CDN.

Hopelijk effectief! Zelf gebruiker van de spdy mod, werkt leuk met een paar minpuntjes. Hopelijk is dit in HTTP/2 gewoon goed.

En bravo voor google en Mozilla, trekken zoals gewoonlijk het voortouw weer. #veiligheid

Net nu webdevelopers hebben geleerd om automatisch spritesheets te genereren en JavaScript te packagen ;-). Is met HTTP2 veel minder nuttig.

Ook al maakt Gulp/GruntJS dit eenvoudig(er) het is toch weer een extra onderdeel wat onderhoud nodig heeft.

"maar Mozilla en Google hebben aangekondigd dat Firefox en Chrome http/2-verbindingen zonder tls niet zullen accepteren"

Hier kan ik heel kort over zijn, GOED ZO.

Mja... dan krijg je weer afwijkingen waar je weer rekening mee moet houden als IT'er.. Als ontwikkelaar kan ik me echt ergeren dat bepaalde browsers weer eens afwijken van de standaard. Ben ook blij dat ik IE8 en lager niet meer hoef te ondersteunen...

Maar waarom zou je niet al het verkeer via SSL of TLS laten lopen?

Onnodige CPU load bij servers met openbare informatie?

Dat jouw informatie openbaar is betekend niet dat ik als gebruiker ook wil dat anderen zien dat ik deze informatie raadpleeg.

Of TLS verplicht moet worden weet ik niet, maar dat de keuze nu impliciet bij de gebruiker komt te liggen vind ik een goede zaak.

Dat jouw informatie openbaar is betekend niet dat ik als gebruiker ook wil dat anderen zien dat ik deze informatie raadpleeg.

Daar helpt TLS niet altijd mee, het is genoeg om te weten dat jij een pagina bezoekt. Als de pagina openbaar is kan ik hem vervolgens zelf lezen om te zien wat jij gelezen hebt...

Je kan dan alleen zien dat hij de server benaderd, niet welke resources(/urls) hij opvraagt.

TLS laat je alleen de hostname zien. Verder niks. Jij ziet dan misschien dat ik Tweakers raadpleeg maar niet welke onderwerpen ik interesse in heb, wat mijn gebruikersnaam is en wie ik -1tjes geef.

Correct, en met name dan voor servers zoals CDN's. Juist die moeten veel informatie verstouwen, terwijl ze helemaal geen gebruik maken van sessies e.d. Dat soort servers willen helemaal geen user state hebben, terwijl dat juist essentieel is voor TLS.

Linux heeft zelfs optimalisaties zodat netwerkkaarten data rechtstreeks uit RAM naar TCP pakketjes kunnen kopieren zonder CPU te gebruiken (via DMA). Dat soort optimalisaties werken simpelweg niet meer met TLS.

Omdat dat tot voorheen een heel gedoe was, maar dat wordt snel beter, en binnenkort gratis.

Een andere belangrijke reden: veel sites gebruiken 3rd party widgets/scripts/ed welke gewoon nog over HTTP gaan.

Op zich hoef je niet met uitzonderingen rekening te houden. Als je HTTP/2 gewoon altijd via TLS laat lopen is het altijd compatible met alle browsers. Voor backward-compatibiliteit zul je voorlopig een HTTP/1.1 verbinding nodig blijven hebben.

Dat begrijp ik.. mijn punt is ook meer dat ik vind dat bedrijven zich eens moeten houden aan standaarden.. die zijn er om een reden..

offtopic: vreemd dat mijn vorige reactie geen +1 krijgt.. als die niet ontopic is weet ik het ook niet

In dit geval denk ik dat je je moet ergeren aan de standaard; voor zover ik het in kan schatten heeft deze maatregel van Mozilla en Google precies één doel: downgrade attacks voorkomen.