Google voegt ondersteuning voor http/2 toe in Chrome 40

Google heeft aangekondigd dat de aankomende Chrome 40 niet alleen spdy zal ondersteunen maar zal overstappen op het http/2-protocol. Http/2 is grotendeels gebaseerd op het door Google ontwikkelde spdy-protocol en moet uitgroeien tot de opvolger van http 1.1.

Google stelt dat de http/2-ondersteuning in Chrome de komende weken met versie 40 bij gebruiker komt. Begin volgend jaar wil de internetgigant ondersteuning voor het spdy-protocol helemaal laten vallen. Ook de tls-extensie npn zal dan niet meer ondersteund worden: Chrome zal voortaan de alpn-extensie gebruiken.

Het netwerkprotocol spdy is door Google ontwikkeld en is sinds Chrome 6 in de populaire webbrowser opgenomen. Spdy diende als aanvulling op het bestaande http 1.1-protocol en had tot doelstelling de laadtijd van webpagina's te verkorten. Daarvoor past het protocol onder andere compressie, multiplexing en flow control toe. Ook dwingt het protocol https-verbindingen af. Google claimde in 2013 dat websites gemiddeld 40 procent sneller opgevraagd konden worden.

Googles spdy-protocol gaf belangrijke input voor de ontwikkeling van http/2. Dit protocol integreert een groot deel van de innovaties van spdy. Http/2 heeft momenteel de draft-status maar naar verwachting zal het protocol op termijn gaan uitgroeien tot een van de fundamentele internetstandaarden als vervanger van http 1.1.

Reacties (59)

En wat is het voordeel van http/2 ?

Het is origineel een kopie van SPDY dus fixes voor Head-of-line blocking en Multiplexing. Dit komt dus allemaal neer op fixes op netwerk niveau, dus het transporteren van data, niet de opbouw van de headers etc.

Nieuw in HTTP/2.0 is dat het de mogelijkheid moet krijgen om content te pushen naar de client, als de server weet dat de client dit nodig heeft om de pagina te renderen. Dit minimaliseert (ook weer) het moeten openen van een hoop connecties naar de server.

Overall is HTTP/2 dus vooral een verbetering op netwerk performance niveau. Ik had bij de originele team-opzet ook vernomen dat ze HTTPS of SSL/TLS als standaard/verplichting wilden invoeren, maar ik weet niet of dat er door is gekomen...
TLS 1.2+ is nu verplicht. Dat betekend dat de meeste gebruikte attacks op HTTPS, aanvallen op basis van het laten degraderen van de gebruikte encriptie door een MiTM attack (vb. POODLE) niet meer werken of een stuk moeilijker worden. Gezien HTTPS nogsteeds SSL etc ondersteund welke een stuk onveiliger is en veel oudere en onveiligere algorithmen moet ondersteunen is HTTP/2 in de basis een stuk veiliger dan HTTPS.

Human-readable spec is hier te vinden: https://http2.github.io/

Edit: TLS stukje geupdated.

[Reactie gewijzigd door wizekid op 10 februari 2015 10:05]

Een lichte nuance: TLS wordt niet verplicht door de HTTP/2-standaard. Wel hebben zowel Google als Mozilla besloten om HTTP/2 enkel met TLS te implementeren. In de praktijk ongeveer hetzelfde, maar in principe *hoeft* het dus niet.

Bron: talk van Mozilla op FOSDEM dit jaar

Je kan overigens iig. in Chrome het minimum SSL/TLS versie zelf instellen. Dit kan wel als effect hebben dat sommige sites onbereikbaar worden.

De push functionaliteit is niet iets waar je op zit te wachten. Het zal voornamelijk gebruikt worden om reclame en plaatjes met voorrang te laden in plaats van tekst eerst. Het is beter als reclame en plaatjes met aparte connecties geopend worden zodat ze eenvoudig te blokkeren of te filteren zijn.

Grootste voordeel is het meer kunnen doen binnen één TCP sessie. Dus 30 get request naar de server sturen zonder 30 tcp sessies daarvoor nog te hebben.

Als browsers nu 30 tcp sessies op zouden kunnen zetten met een server dan zou de server heel snel door z'n maximale aantal verbinding heen zijn, dit wordt dus nu niet toegestaan.

Hoe staat het momenteel met proxy support voor http/2?

Korte samenvatting uit de draft versie:

HTTP/2 enables a more
efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients.

"Spdy diende als aanvulling op het bestaande http 1.1-protocol en had tot doelstelling de laadtijd van webpagina's te verkorten. Daarvoor past het protocol onder andere compressie, multiplexing en flow control toe. Ook dwingt http/2 https-verbindingen af. Google claimde in 2013 dat websites gemiddeld 40 procent sneller opgevraagd konden worden."

Google claimde in 2013 dat websites gemiddeld 40 procent sneller opgevraagd konden worden."

Een dergelijke tijdswinst gold dan wel alleen voor secure https verbindingen die onder http 1.x relatief nog heel traag opgezet werden.

[Reactie gewijzigd door Anoniem: 80466 op 10 februari 2015 10:12]

Een stukje sneller, als ik het goed heb voornamelijk met meerdere bestanden.

Sneller inderdaad, gaat veel beter om met resources en (zo ver ik weet) heeft minder overhead informatie. Het kan vooral beter parallel bestanden binnenhalen.

dat je de tekst sneller leest van dit nieuwsbericht

Jammer dat tweakers als technieksite nogsteeds geen spdy ondersteund, geen https (forced) en geen ipv6.

De reden dat Tweakers geen https gebruikt is heel simpel.

Als je https forced, dan kan je pagina alleen advertenties laten zien die ook uit een https-bron komen. Anders krijg je van die vervelende "onveilige inhoud" meldingen. Het gevolg daarvan is wel, dat er veel minder aanbieders zijn en de prijs per advertentieklik inzakt als een plum pudding.

Quote Google:

HTTPS-enabled sites require that all content on the page, including the ads, be SSL-compliant. As such, AdSense will remove all non-SSL compliant ads from competing in the auction on these pages. If you do decide to convert your HTTP site to HTTPS, please be aware that because we remove non-SSL compliant ads from the auction, thereby reducing auction pressure, ads on your HTTPS pages might earn less than those on your HTTP pages.

Https lijkt me niet zo zinvol op tweakers , dat maakt het enkel weer langzamer, ipv6 en Spdy is dat wel weer handig.

Https is onvermijdelijk op tweakers, geloof me. De browser bouwers zijn op dit moment in conclave om sites die niet HTTPs voeren aan te merken als onveilig (op welke manier is nog onduidelijk).

Het is de vraag wanneer, maar niet of.

Is dat niet alleen Google die HTTP sites als onveilig wil aanduiden. Microsoft en Mozilla heb ik daar nog niks over zien praten.

Het komt inderdaad van Google af....

http://www.chromium.org/H...arking-http-as-non-secure

...echter, bovenstaand voorstel is gedaan aan alle major browser bouwers. Wat die er mee doen is nog niet besloten, maar als je de draadjes in de mailing groups volgt is men er positief over.

[Reactie gewijzigd door Knippr op 10 februari 2015 21:47]

Uhm "Pagina niet gevonden"? Dode link?

Anyway, zeggen dat de browser bouwers in conclave zijn is nogal erg ver als dit alleen maar een proposal is voor Chromium.

Link is gefixed.

Alles begint met een proposal. Het is er nog niet, maar het wordt besproken, en dat is wat ik stelde. En de richting en toon van de discussie is dat dit er uiteindelijke gewoon gaat komen.

Daar maak je wel een goed punt. Maar ik denk dat het voor tweakers heel lastig gaat worden. Zeker omdat de site zo uitgebreid is. Ik denk dat de site dan last gaat krijgen van een probleem genaamd mixed content en dan krijgt de site als ook een onveilige status

Dat klopt, ook ads zijn mogelijk een issue. Daarom, als Tweakers verstandig is dan beginnen ze er nu al aan.

Ik overdrijf niet, hier is het proposal:
https://www.chromium.org/...arking-http-as-non-secure

De Firefox groep heeft ook een draadje. Dit gaat er gewoon komen.

Dat het langzamer is, is echt zo'n ouderwetse gedachte. Servers zijn tegenwoordig krachtig genoeg, we leven niet meer in 1990 .
Tuurlijk geeft het wat overhead, ook op je eigen PC, maar dat ga jij als gebruiker echt niet merken. Overigens is Spdy daar juist voor bedoelt, om ssl verkeer te optimaliseren waardoor de belasting minimaal blijft.

Het gaat niet zozeer om de snelheid van servers/client maar om om dat er veel communicatie nodig is tussen de server en de client. Hoe snel je computers ook maakt, en hoe breed je de internetverbinding ook maakt, je blijft vast zitten aan de +- 50ms die het pakketje data nodig heeft om tussen de twee computers te verplaatsen. Stel dat de client 5 losse vragen moet stellen aan de server, en moet wachten op antwoord van de server zit je dus al een halve seconden te wachten .

Dat is echt onzin. Ik zal het je sterker vertellen. Als je https goed implementeert kan het even snel of zelfs sneller zijn.
Check : https://www.httpvshttps.com/

Het ging er om waarom Spdy/HTTP2 sneller is dan HTTP1, en waarom je niet alles kunt oplossen door snellere computers neer te zetten.

Was er trouwens een specifiek stuk in mijn redenering die je probeert te ontkrachten met die link?

(Over je link gesproken, ja in dit specifieke geval is HTTPS sneller dan HTTP, HTTPS is over het algemeen langzamer bij een groot aantal kleine requests, maar sneller bij een klein aantal grote (zoals een image)).

Hoe dan ook is HTTPS vaak de juiste keuze

En laat met HTTP2 het aantal kleine request ook lager worden, door push-mogelijkheid vanaf de server. Maar dan wil je wel zeker weten dat je de juiste content naar de juiste client pusht, en daar is die veiligere verbinding dan wel weer handig voor.
Overigens snap ik het van Holhuizen niet dat een beveiligde verbinding op t.net niet nodig zou zijn. Ik kan hier toch inloggen, reacties plaatsen (nog niet zo heel kritisch, maar toch vervelend als iemand anders misbruik van mijn account maakt) en (belangrijker) zaken doen in vraag/aanbod? Dan wordt't toch wel vervelend als daar misbruik van gemaakt wordt...

Jou link speelt ook een beetje "vals", ze vergelijken http met spdy https (wat 'm, aangezien spdy praktisch http/2 is, dus eigenlijk zeer ontopic maakt! )

50ms ping naar Tweakers toe?
Reply from 213.239.154.20: bytes=32 time=12ms TTL=58

Tweakers.net forcereert wel HTTPS op de inlogpagina. Op pagina's waar je je wachtwoord niet invoert en gewoon publiek beschikbare content raadpleegt, is SSL niet zo relevant.

En de gebruikerscommentaren dan? Het zou zomaar kunnen dat een man in the middle jouw mening aanpast.in iets waar je helemaal niet achterstaat.

Het zou zomaar kunnen dat een man in the middle jouw mening aanpast.in iets waar je helemaal niet achterstaat.

Mijn eerste reactie daarop was "het maakt me niet uit wat mensen van me denken" en "ach, niemand neemt mijn mening toch serieus", tot ik me bedacht dat je iemand flink kunt benadelen door een doodbedreiging onder zijn naam te maken op een veel gelezen en publieke website zoals deze. Je kunt potentiele concurrenten (tijdelijk) uitschakelen door ze te laten oppakken voor doodsbedreigingen. Maar een man-in-the-middle is niet makkelijk en mensen die zulke kennis hebben zullen waarschijnlijk sneller voor een andere oplossing kiezen.

Niet helemaal onbelangrijk, want ondanks dat het publieke informatie is en die informatie zelf dus niet het afluisteren waard is, kan het wel interessant zijn dát je die informatie leest. Zelf gebruik ik hiervoor de extensie HTTPS Everywhere.

Voor niet ingelogde lezers van tweakers is een secure verbinding onnodig en betekent een verplichte https verbinding het alleen maar overhead en daarmee ook relatief een iets langzamere verbinding.

Overhead en de langzamere verbinding zal niet merkbaar zijn. De secure verbinding zal er dan ook gewoon komen.

tweakers is wel degelijk bereikbaar op ipv6, maar je moet het zelf opnemen in je hosts file daar er bewust gekozen is om nog geen DNS entry te zetten. Ik bezoek van thuis uit t.net dan ook netjes over IPv6.

Heb het ook een tijdje gedaan met geforceerde https met behulp van een plugin. Maar niet alles werkt dan even goed. Zo werden comments niet gesubmit via een ajax request, maar werd de pagina telkens helemaal opnieuw geladen.

De redachtie van tweakers beheert volgens miij ook niet zelf hun serverpark. Dit is ondergebracht bij De Persgroep, het moederbedrijf van Tweakers. En De Persgroep is geen technologiebedrijf

Zie ook de discussies van HTTP2 op HN [0][1][2]. Hier wordt geclaimd dat Google een erg grote invloed op deze standaard heeft en, chargerend, de IETF slechts stempels zet onder de voorstellen van Google. Dit lukt ze o.a. doordat ze het halve internet in hun mandje hebben met o.a. Chrome. De verbeteringen van HTTP/2 zijn dus vooral SPDY wat met name interessant is voor grote content providers, maar gaat ten koste van de simpliciteit van het gehele protocol voor iedereen [3].

[0] https://news.ycombinator.com/item?id=9022470
[1] https://news.ycombinator.com/item?id=6012525
[2] https://news.ycombinator.com/item?id=8850059
[3] https://en.wikipedia.org/wiki/HTTP/2#Criticisms

En een html pagina moet daar ook op aangepast worden neem ik aan?
Extra code in "kladblok" ?

Nee. html != http

Als je gebruik wil maken van features als het pushen van content, dan heb je natuurlijk wel ergens aanpassingen nodig in je systeem.

De webserver zou zelf al kunnen kijken welke bestanden nodig zijn om een pagina volledig te renderen nog voor of tijdens dat deze verstuurd word. Op deze manier kan het de content al mee pushen zonder dat je daar als site ontwerper zelf rekening mee moet houden.

Om dit te implementeren hoef je niets aan te passen in de code. Maar eigenlijk moet iedereen daarmee beginnen. Alle websites kunnen de meeste winst in snelheid halen door code optimalisaties. Dit voorstel van Google geeft slechts een verwaarloosbaar snelheidswinst op. Maar alle beetjes helpen natuurlijk.

+/- 40% noem je verwaarloosbaar?

Ongeveer 40% in theorie. Niet altijd in praktijk.

Klopt, maar vaak wel. Vaak zijn het Wordpress installaties met tal van plugins die allemaal CSS nodig denken te hebben

Nee, het vereist een aanpassing/instelling aan de webserver. De ondersteuning moet komen van bekende webservers als Apache, Nginx, JBoss etc. Die zijn in meerdere of mindere mate al bezig met HTTP/2 ondersteuning.

Als webdeveloper hoef je niets te doen.

Leuk, ik heb hem al blijkbaar!

Version 40.0.2214.111 m (64-bit)

Google Chrome is up to date.

Er staat in de blog post dat het de komende weken word uitgerold. Er staat niet dat er vanaf versie 40 ondersteuning is, maar dat er in een van de subversies ondersteuning wordt uitgerold.

Als je Chrome Canary draait dan zit je al op versie 42.0.2300.2.

Onder [url="chrome://flags/"]chrome://flags/[/url] heb je al langere tijd de optie "Enable SPDY/4", maar mogelijk is dat nog een test-implementatie.

-nevermind

[Reactie gewijzigd door aval0ne op 10 februari 2015 10:40]

SPDY v4 is echter niet volledig gelijk aan HTTP2. Het is een apparate implementatie van Google, die waarschijnlijk alleen zij gaan gebruiken. Microsoft heeft SPDY bijvoorbeeld toegevoegd in IE11, maar de ondersteuning is ook al weg in IET¨P.

Spdy diende als aanvulling op het bestaande http 1.1-protocol en had tot doelstelling de laadtijd van webpagina's te verkorten. Daarvoor past het protocol onder andere compressie, multiplexing en flow control toe. Ook dwingt http/2 https-verbindingen af. Google claimde in 2013 dat websites gemiddeld 40 procent sneller opgevraagd konden worden.

Zou die 40% hogere opvraagtijden van httpS verbindingen ook handig zijn voor de veiligheidsdiensten? Of geldt hij daar niet voor? nieuws: 'Speciale NSA-afdeling kraakt vpn-, https- en ssh-verbindingen'

Huh? Chrome 40 is er toch al? Ik heb 40.0.2214.111 m hier...

Volgensmij in een nieuwe build van Chrome 40 want volgensmij is 40 bij de meesten al geïnstalleerd.

Wel spannend,meer standaard HTTPS websites.

Sinds SNI zie je in de HTTPS packetjes nog steeds naar welke website je wilt.

Dus HTTPS != anoniem.

Iedereen die in jou verkeer kan meekijken (wat de overheid sinds gister een goed idee vind) kan zien dat je via HTTPS naar t.net wilt. Dus het idee dat HTTPS er voor zorgt dat er niet meer mee gekeken kan worden is onzin, tenzij je nog met IE6 internet. (IE6 heeft geen SNI)

Met HTTPS kan b.v. de overheid niet zien wat jij op die website doet. Alleen met een beetje pech wordt er een iFrame geladen met b.v. reclame die via HTTP gaat, en zie je netjes in de referrer staat welke url je precies bezocht.

kortom: denken dat je met HTTPS anoniem internet valt toch een beetje tegen.

Uiteraard (SFW)

[Reactie gewijzigd door ATS op 10 februari 2015 11:51]

Ik durf deze link niet te klikken op werk.

Ga je gang, de link is veilig. SFW.