Standaardenorganisatie publiceert officieel http/2-standaard

De IETF HTTP Working Group heeft de http/2-specificatie officieel goedgekeurd en gepubliceerd. Dit betekent dat er formeel een opvolger is voor de http 1.1-specificatie, die al zestien jaar aan de basis van het huidige web staat.

De specificatie is vastgelegd in RFC7540 nadat het publiek de afgelopen maanden zijn oordeel mocht vellen over de draft. Dit betekent dat er consensus is bereikt door de Internet Engineering Task Force, ofwel de IETF.

Http/2 introduceert onder meer 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. Dit resulteert in snelheidswinst. Verder gaat http/2 efficiënter om met encryptie via het tls-protocol en is er http-headercompressie mogelijk.

De http/2-standaard, voor een groot deel gebaseerd op het door Google ontwikkelde spdy-protocol, is na zestien jaar de vervanger voor het http 1.1-protocol. In tegenstelling tot het spdy-protocol is het in de http/2-standaard niet verplicht om tls-encryptie in te schakelen. Het zal overigens nog even duren voordat de specificatie dominant is: veel software moet daarvoor nog worden aangepast.

De browsers Firefox en Microsofts Edge en Internet Explorer bieden out-of-the-box de http/2-standaard aan. Chrome beschikt ook over de ondersteuning, maar biedt die voorlopig niet standaard aan. In toekomstige versies zal dit wel gebeuren, omdat het spdy-protocol naar verwachting begin volgend jaar helemaal verdwijnt.

Reacties (67)

De browsers Firefox en Microsofts Edge en Internet Explorer bieden out-of-the-box de http/2-standaard aan. Chrome beschikt ook over de ondersteuning, maar biedt die voorlopig niet standaard aan.

Waarom doet chrome dit niet?
Bij een 'standaard' lijkt mij toch wenselijk dat die 'standaard' is. Heeft chrome z'n eigen standaard die ze aanhangen en pushen ofzo?

Google gebruikt het spdy-protocol bij pagina's die het ondersteunen, anders gebruiken ze de http/1.1

Google heeft het SPDY protocol zelf ontwikkeld (ook met mensen die aan http/2 hebben gewerkt) en heeft in 2015 aangekondigd dit uit te faseren en dan uiteindelijk in 2016 de gehele ondersteuning laten vervallen.

Google Chrome is overigens niet de enigste browser die SPDY gebruikt:

• Google Chrome/Chromium. SPDY sessions in Chrome can be inspected via the URI: chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. There is a command-line switch for Google Chrome (--enable-websocket-over-spdy) which enables an early, experimental implementation of WebSocket over SPDY. SPDY protocol functionality can be (de)activated by toggling "Enable SPDY/4" setting on local chrome://flags page. Chromium is expected to remove support for SPDY and Next Protocol Negotiation in early 2016, in favor of HTTP/2 and ALPN. Starting with version 40.x in Feb 2015 Chrome has already dropped support for SPDY/3 and only supports SPDY/3.1 going forward. This has caused Apache websites to be without SPDY support when visited from Google Chrome.
• Firefox supports SPDY 2 from version 11, and default-enabled since 13 and later. (Also SeaMonkey version 2.8+.) SPDY protocol functionality can be (de)activated by toggling the network.http.spdy.enabled variable in about:config.[10] Firefox 15 added support for SPDY 3.[32] Firefox 27 has added SPDY 3.1 support.[34] Firefox 28 has removed support of SPDY 2.[29] about:networking (or the HTTP/2 and SPDY indicator add-on)[44] shows if a website uses SPDY.
• Opera browser added support for SPDY as of version 12.10
• Internet Explorer 11 added support for SPDY version 3, but not for the Windows 7 version. A problem experienced by some users of Windows 8.1 and Internet Explorer 11 is that on initial loading, Google says "Page not found" but on reloading, it is fine. One fix for this is to disable SPDY/3 in Internet Options > Advanced. After version 11, IE will drop the support of SPDY, as it will adopt HTTP/2.
• Amazon's Silk browser for the Kindle Fire uses the SPDY protocol to communicate with their EC2 service for Web page rendering.
• Safari 8 and third-party applications in OS X 10.10 and iOS 8 adds support for SPDY 2, 3 and 3.1.

bron: http://en.wikipedia.org/wiki/Google_Chrome#Speed
http://en.wikipedia.org/wiki/SPDY

[Reactie gewijzigd door Joostlek op 15 mei 2015 22:27]

spdy is opgegaan in HTTP/2: http://blog.chromium.org/...odbye-spdy-http-is_9.html

euuuhhh Nee.

SPDY is door Google ontwikkkeld en HTTP/2 door de standaardorganisatie. SPDY was wel door iedereen gebruikt maar dat was niet van de standaard organisatie. Maar misschien dat Google na HTTP/2's aankondeging plannen had gemaakt voor het uitfaseren.

SPDY was de basis voor de eerste "draft" van HTTP/2. Daarna zijn ze vanuit daar verder gaan werken. HTTP/2 heeft een aantal voordelen boven SPDY. Zo werkt het bijvoorbeeld ook voor niet-SSL traffic. SPDY werkt alleen met SSL. SPDY is opgezet vanuit de wensen van google, HTTP/2 vult deze aan met wensen van allerlei andere gebruikers.

Logisch dat opera het ook moet gebruiken.

Ze hebben zich vanaf 2013, geschikt om WEBKIT te gaan gebruiken. Defacto is Opera eigenlijk een dus de chromium engine gaan gebruiken. Dat men daarom ook google protocol moet gaan gebruiken is niet gek. Ik hoop voor ze dat zo snelmogelijk ook gebruik mogen gaan maken van de gewone standaard. Want ondanks chromium is Opera een fijne browser.

Ze gebruiken Blink, een fork van webkit...

Niet om het een of ander maar Opera 12.10 is nog gewoon Presto-gebaseerd. Pas vanaf Opera 15 gingen ze Blink gebruiken.

Mja vind het ook raar. Hier de methode om hem te activeren in Chrome:
https://ma.ttias.be/enable-http2-support-chrome/'

Andere die wel handig is, is NPAPI zodat Silverlight weer werkt in Chrome.

Twee items waarvan ik nog steeds niet begrijp dat ze ze niet gewoon standaard aanzetten

[Reactie gewijzigd door Martinspire op 15 mei 2015 23:45]

Omdat npapi verouderd is en afgeschreven moet worden...

Google probeert er zo een beetje vaart er in the brengen
Ipv internet exprorer 6 tafarelen

Door je gebruikers de mogelijkheid te ontnemen (de meesten zullen dit ook niet vinden) en geen alternatief te bieden, ben je helemaal niets goeds aan het doen. Ja, legacy moet verdwijnen, maar je moet het niet pushen. Zolang het nog breed gebruikt wordt, moet je het niet af gaan schaffen. Net als IE9 support voor veel sites. Ja je doet liever zonder, maar veel gebruikers kunnen niet anders (geen rechten om iets anders te installeren). Daarom is het ook belangrijk dat ze overstappen op een nieuwer besturingssysteem. Maar jouw methode zegt gewoon "fuck alle mensen en bedrijven die silverlight gebruiken". Lijkt me niet de oplossing

Simpel, kwestie van iedereen zo lang mogelijk dwars gaan zitten met hun eigen zut. ze zijn nu de "defacto" standaard gezien ze het grootste aandeel hebben op de markt, en daar willen ze het liefst geen zaken van anderen op toelaten. Een paar jaar terug waren de rollen andersom..

Dat had ik dus eerder verwacht van Internet Explorer. Microsoft had er namelijk nogal een handje van om van standaarden af te wijken.

Dat was Microsoft van voor 2015. Anno nu omarmen ze Open Source en Open standaarden.

Omdat Google de voorkeur geeft aan zijn eigen SPDY, maar ze hebben gemeld daar vanaf te willen stappen in de toekomst, en dat is beter vroeger dan later.

[Reactie gewijzigd door Loller1 op 15 mei 2015 22:13]

Google chrome ondersteund beide, SPDY komt in 2016 te vervallen.

HTTP/2 heeft de elementen van SPDY, maar doet HTTP header compressie op een iets andere manier dan SPDY (binair ipv Gzip meen ik). Google heeft daar geen problemen mee.

Zit je op de apache lijn dan moet je nog even wachten voor HTTP/2 support tenzij je ATS (traffic server) gebruikt. Die support SPDY en HTTP/2 direct, ik meen officieel pas sinds vandaag.
https://twitter.com/trafficserver/status/598560294881742848

Altijd handig om even te checken: http://caniuse.com/#feat=http2

[Reactie gewijzigd door randomnumber op 15 mei 2015 22:59]

Waarschijnlijk gebruikt Google nu op zijn servers het SPDY protocol.
Dat moet langzaamaan uitgefaseerd worden, ter vervanging van HTTP/2.
Tot dat zover is, zal chrome nog het 'oude' protocol gebruiken.
Ook geeft dat ruimte voor andere sites - die nu al gebruik maken van SPDY - om op hun servers SPDY te vervangen door HTTP/2.

HTTP/2 is nu final, dus het implementeren in servers zal nu gaan beginnen. Er zijn echter al libs waardoor reeds SPDY gebruikt kan worden/wordt.

Omdat het nu pas een "final" standaard is. Een standaard compleet implementeren voordat ie af is is een beetje gek, m.u.v. HTML5 en CSS3 in browserland.

Is hier ook op server niveau al ondersteuning voor? Zoja, welk server os heeft al ondersteuning en welke niet? Moet er iets op serverniveau geconfigureerd voor worden hiervoor?
Zoniet kunnen serverbeheerders zelf zorgen dat dit ondersteund wordt? Of moeten die wachten tot er een update komt?

Nginx komt later dit jaar met ondersteuning. Apache volgt waarschijnlijk ook wel, al gaat alles daar meestal wat trager. Verder is er ook support in Apache Traffic Server (vergelijkbaar met Varnish), en in H2O (een experimentele basic webserver/reverse proxy). Buiten Apache Traffic Server denk ik niet dat er al iets production-ready is, dus het is nog even afwachten. Eens nginx met een compatibele release komt zullen er snel veel websites over HTTP/2 beschikbaar zijn.

Een goede eerste stap is nu al SPDY inschakelen op je website. Het proces en de vereisten zijn aan de serverkant vrijwel identiek aan die voor HTTP/2. Dat wil ook zeggen dat TLS/HTTPS vereist gaan zijn voor HTTP/2-ondersteuning. Alle browsermakers hebben gezegd HTTP/2 alleen te gaan ondersteunen over TLS. En aan HTTP/2 over TLS hangen extra vereisten vast.

Korte checklist:

• Geldig certificaat
• TLS 1.2
• Moderne ciphers (onder andere TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
• ALPN (Application Layer Protocol Negotiation) - hiermee geeft de server aan dat hij ondersteuning heeft voor HTTP/2. Beschikbaar in OpenSSL 1.0.2+.

Ik heb er dit weekend mee zitten spelen, en hoewel het allemaal wel werkt is het op dit moment nog niet interessant om te bekijken volgens mij, tenzij je Apache Traffic Server gebruikt. Alle huidige implementaties aan de serverkant zijn nog heel erg experimenteel en niet echt geschikt om vlot uit te rollen bovenop een bestaande setup. Waarschijnlijk is het beter om nu gewoon voor SPDY-support te zorgen, en later dit jaar kan je dan over naar HTTP/2. Denk ik toch.

[Reactie gewijzigd door AmbroosV op 15 mei 2015 23:11]

SPDY support is lastig. Ik heb een week of 3 geleden een poging gedaan om dit in te schakelen voor Apache 2.4. Deze moet je zelf compilen en installeren, dit is best te doen, maar de enige sources die er te vinden zijn, is van SPDY 3.0, terwijl Chrome alleen maar 3.1 ondersteund en dus terugvalt op HTTP1.1. Op Apache 2.2 is het volgens mij nog wel mogelijk, maar dit soort rare dingen kosten veel tijd om uit te zoeken en het werkt dus allemaal niet zoals je zou willen.

Ik kan niet wachten op HTTP/2 support in Apache.

Apache is inderdaad moeilijk. Nginx heeft redelijk wat backing van grote content providers waardoor SPDY snel een erg goede implementatie had. Apache is echter veel minder gericht op performance en de ontwikkeling van mod_spdy ligt stil.

Een simpele (en performante) oplossing? Zet nginx als reverse proxy voor Apache, op dezelfde server. Gooi je Apache dan gewoon op een random afgeschermde poort. De configuratie van nginx als reverse proxy is twee keer niets, en het is poepsimpel om HTTPS en SPDY goed op te zetten.

Mooie uitleg ! Vind het jammer dat tweakers dit soort zaken niet in hun artikels vernoemd.

Onder andere de volgende versie van Windows Server (2016) heeft hier ondersteuning voor. Jet valt niet te verwachten dat oudere Windows Servers versies dit gebackport krijgen, dit heeft Microsoft ook nooit eerder gedaan.

Zit deze ondersteuning in IIS of in DotNet?
Als het in DotNet zit, zullen alle oudere servers het waarschijnlijk ook gaan krijgen met een DotNet update.

Dit zit in IIS, of eigenlijk op OS-niveau. Http requests worden in Windows op kernelniveau afgehandeld (http.sys). Vandaar dat waarschijnlijk geen update voor oudere Windows versies komt. Met de introductie van WebSockets is dit ook bijvoorbeeld niet gebeurd.

Beide niet. Dit zit in Http.sys (Windows Library) die door IIS gebruikt wordt.

Verwacht dit dus maar niet in Windows 2012 of eerder. Dit hebben ze ook nooit gedaan voor https verbeteringen.

Daarom werkt bijvoorbeeld Windows xp RTM niet met TLS (enkel SSL) , want IE gebruikt dezelfde library.

Wel, het heeft lang geduurt. Weinig technologiën blijven 16 jaar lang ongewijzigd in gebruik. Op naar HTTP/3.

Ik heb liever dat IPv6 eens masaal wordt gebruikt. Nog steeds veel providers, servers en dienstverleners die dat niet ondersteunen. Zelf al een tijdje over op glas, maar nog steeds aan IPv4 vast.

En daar heb je last van omdat...?

Dingen als gameconsoles lopen nog steeds moeilijk te doen met port-forwarding. En zo nog meer apparaten die er voordeel van hebben als ze directer op het internet zitten aangesloten (hetzij nog wel achter een firewall maar met een handiger adres).

[Reactie gewijzigd door Martinspire op 16 mei 2015 11:06]

Mijn PS3 doet helemaal niet moeilijk. Gewoon UPnP aanzetten, en de console en router regelen alles vanzelf. Het wordt pas lastiger als je twee routers achter elkaar zet, maar zelfs dan is het nog redelijk eenvoudig zelf op te lossen.

Zet eens meerdere consoles op 1 netwerk. Of probeer een open NAT te krijgen met meerdere devices, zonder portforwarding of DMZ? Geloof me, het is hoogst irritant

Het is raadzaam om te wachten tot al je apparatuur een instelbare firewall heeft.

IPv6 is meer goed voor de omzet van hardwarefabrikanten dan de mogelijkheid om meer mensen een eigen ip-addres te geven. Er zijn IPv4-blokken zat waarvan de toewijzing bedenkelijk is. Neem nou eens de Amerikaanse DISA die 4 /8 blokken heeft. VIER /8 BLOKKEN! En kan komt er nog eens een andere Amerikaanse overheidsinstantie (US Department of Defence) die 2 /8 blokken toegewezen kreeg. Het is bespottelijk.

Met IPv4 hoef je de configuratie van je firewall enkel in je router(s) bijhouden. Als IPv6 wordt uitgerold wordt ieder apparaat blootgesteld aan het internet. Dan kun je lekker vol aan de bak om uit te vissen of de beveiliging van ieder apparaat in orde is. En als die apparaat geen fatsoenlijke beveiliging kan hebben, kan het in de container.

Maar ook al hangen ze als IP aan het internet, dan gaat dat verkeer toch nog steeds via je router? Of zie ik dat verkeerd?

Ik wil zolang mogelijk op IPv4 blijven, dat scheelt me lekker 3% bandbreedte

Hoe lager je gaat hoe minder er gewijzigd wordt aan de protocollen. Het heeft ook zoveel impact dat het bijna niet mogelijk is.

Zover ik weet zijn TCP & IPv4/6 al decennia constant.

• TCP (1981)
• IPv4 (1981)
• IPv6 (1998)

In ieder geval goed nieuws dat http v2 eindelijk uit is. De https vereiste van spdy maakte het niet echt nuttig voor veel websites.

Ook HTTP/2 vereist TLS

Http2 vereist geen TLS. Google Chromen zijn implementatie werkt alleen met TLS maar de standaard heeft een TLS en niet TLS versie. Alle dat is toch wat ik ervan heb begrepen.

Van http://en.m.wikipedia.org/wiki/HTTP/2

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).[20]

Klopt, ik had het over SPDY, welke TLS vereist. SPDY is gebruikt als basis in een eerste draft voor HTTP/2, maar de TLS requirement is komen te vervallen.

Eh, excuseer? Chrome heeft al een hele tijd ondersteuning voor HTTP/2 ingeschakeld. Eerst verschillende draft-versies, en ondertussen ook de final. Met deze kleine indicator kan je perfect zien over welk protocol je surft. Het zal snel opvallen dat veel Google-services al ondersteuning hebben voor HTTP/2, draft of final.

Ook een leuk detail: geen enkele van de grote browserbouwers gaat HTTP/2 ondersteunen over niet-versleutelde verbindingen. Geen TLS? Geen HTTP/2. Technisch gezien is het niet verplicht volgens de standaard, maar in de praktijk gaat het daar wel op neerkomen. En goed ook, certificaten kosten tegenwoordig echt niets meer (je krijgt ze zelfs gratis bij je domein bij sommige registrars), de setup van HTTPS is zo moeilijk niet en qua performance is het al lang geen probleem meer. Het internet by default veiliger maken is een goede stap vooruit.

Er staat ook nergens dat Google Chrome geen http/2 heeft, er staat in het artikel

Chrome beschikt ook over de ondersteuning, maar biedt die voorlopig niet standaard aan. In toekomstige versies zal dit wel gebeuren, omdat het spdy-protocol naar verwachting begin volgend jaar helemaal verdwijnt.

Dat is net wat niet klopt in het artikel. Ondersteuning is wel standaard ingeschakeld en gebruikt.

De volgorde van protocols in Chrome is op dit moment de volgende:

• QUIC (standaard nog niet aan)
• HTTP/2
• HTTP/2 draft
• SPDY 3.1
• HTTP/1.1

Begin volgend jaar gaan SPDY en waarschijnlijk HTTP/2 draft uit dit lijstje verdwijnen. Ooit zal misschien QUIC ook standaard ingeschakeld worden.

[Reactie gewijzigd door AmbroosV op 15 mei 2015 23:50]

Bij mij staat ie anders bij Chrome Flags gewoon uit hoor?

Zelfs zonder de flag is HTTP/2 nu altijd standaard ingeschakeld (Chrome 43). Het zou kunnen dat in versie 42 (stable) dat nog niet het geval is, maar de release van 43 is normaal in de loop van volgende week, dus dat gaat al snel niet meer van toepassing zijn.

Hoe kan je een http/2 server installeren in Linux?

Zit standaard in nginx, en met een module werkt t ook in apache

Dat klopt helaas niet. Nginx en apache ondersteunen spdy en geen http/2. De enige die http/2 ondersteunen zijn: IIS(Windows 10), OpenLiteSpeed, LiteSpeed web server en Akamai Edge Servers. Akamai heeft zelfs een server zodat je http/2 kan proberen: https://http2.akamai.com
Bron: http://en.wikipedia.org/wiki/HTTP/2

[Reactie gewijzigd door Rubenskoo op 15 mei 2015 22:34]

In Firefox krijg ik about:blank bij http2.akami.com als ik op de link klik, ga ik er handmatig heen:

Beveiligde verbinding mislukt

De verbinding met de server werd geherinitialiseerd tijdens het laden van de pagina.

De pagina die u wilt bekijken kan niet worden weergegeven, omdat de echtheid van de ontvangen gegevens niet kon worden geverifieerd.
Neem contact op met de website-eigenaars om ze over dit probleem te informeren.

En in Chrome werkt het wel "Your browser supports HTTP/2!"

Lijkt dus dat ik het tegenovergestelde krijg van wat er in het nieuwsartikel staat, of akamai moet het over spdy hebben en het http2 noemen.

In chrome://net-internals/#spdy kun je "Live" alle HTTP/2 streams bekijken. Daar heeft Chrome het over een SPDY_SESSION naar Akamai.

Het zou zomaar kunnen dat SPDY en HTTP/2 voor Chrome hetzelfde zijn. De verschillen zijn immers minimaal.

Volgens mij gaat het wel echt om http/2. Ik krijg namelijk de melding: This browser is not HTTP/2 enabled (but at least supports SPDY). Blijkbaar gaat er iets fout in Firefox.

Voor Chrome (en ik meen firefox) moet je in iedergeval SSL / TLS hebben. Niet vanwege het protocol maar meer om te zorgen dat er geen issues zijn met proxies en andere middleware.

In het geval van apache, gebruik een ATS > apache traffic server. Of gebruik de SPDY module voor apache < 2.4.

Ik heb toch wat vragen bij die multiplexing. Menig webdev probeert zo weinig mogelijk requests te doen (minify, combine en cachen). Als multiplexing asynchroon bestanden kan laden van de server (maar hopelijk synchroon laden in de browser om geen dependency issues te hebben), is het dan nog nuttig om te combinen? (Van vele stylesheets of scripts een geheel te maken om het aantal requests te beperken?)

En wat was er dan voor http 1? Toen was er toch ook al internet?

Voor HTTP 1.0 was er HTTP 0.9
HTTP 1.0 was er in 1996
HTTP 0.9 was er in 1991
http://www.w3.org/Protocols/HTTP/AsImplemented.html

HTTP 0.9 is ook een tijd gebruikt. Maar zonder HTTP was er gewoon Internet. FTP (bestanden uitwisselen), NNTP (news) en POP3/SMTP (mail) stammen bijvoorbeeld uit de jaren 80.

Ik heb ook nog een tijdje met Gopher gewerkt, wat eigenlijk het meest lijkt op HTTP. Het succes van HTTP heeft denk ik ook vooral te maken met HTML en het concept van "links" en niet zoveel met HTTP zelf.

internet : ja
world wide web : nope

Ik ben benieuwd hoe lang het duurt voordat de meerderheid van alle populaire websites het gebruiken.

Ik denk dat dat verrassend snel gaat gaan. Alle Google-services zijn al een hele tijd over HTTP/2 bereikbaar. Twitter sinds een paar dagen/weken ook. Facebook was heel erg snel met SPDY, ik vermoed dat HTTP/2 dan ook vlug gaat volgen. CloudFlare is gigantisch groot en gebruikt nginx, dus daar zal support ook tegen eind dit jaar wel vlot aanwezig zijn. Akamai is meer dan 15% van alle internettraffic en is ook al stevig aan het experimenteren, maar door de complexiteit van hun netwerk kan het daar wat langer duren (vooral qua HTTPS-certificaten).

Netflix is ook een enorme speler qua traffic, daar gaat het nog wat langer duren. Ze zijn daar nu aan het werken aan het leveren van de videostreams over TLS, maar ik denk niet dat die onderliggend nog HTTP gebruiken, of dat HTTP/2 veel voordelen heeft voor streaming.

Het zal vooral liggen aan server support en de uitrol van HTTPS voor kleinere sites. Eens je server ondersteuning heeft voor HTTP/2 én je alles klaar hebt staan voor HTTPS (qua keys en configuratie) is het meestal een kwestie van een paar seconden om HTTP/2 in te schakelen (voor één enkele server, that is).

Ik hoop wel dat er een module komt voor Apache waarmee ik HTTP/2 in kan schakelen, want bijna al mijn sites gebruiken nogsteeds Apache.
Als het beschikbaar is schakel ik het direct in.

Ik hoop juist niet dat het in een module komt, maar gewoon in de core van Apache.

idd, module is er geloof ik al, maar das nog best ingewikkeld, en daar moet je even voor gaan zitten, ik hoop dat het gewoon in de core komt.

Voor de webdevelopers, de Go(lang) implementatie is ook al ver gevorderd, de serverkant lijkt al heel ver.
Demo op https://http2.golang.org/

""Http/2 introduceert onder meer 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. Dit resulteert in snelheidswinst.""

Helpt dit ook om de impact van DOS aanvallen te reduceren ?

een DOS aanval ga je niet vanuit de browser lanceren hé.
er staat "multiplexing-mogelijkheid". DOS tools gaan die dus gewoon niet gebruiken en nog steeds zoveel mogelijk connecties opzetten. (of hoe ze ook werken)

Hey, ik heb geen idee hoe een DOS aanval werkt, ik vroeg het me gewoon af.......
Wanneer zo'n DOS aanval wel werkt via een browser zouden de hoeveelheid verbindingen moeten afnemen, maar blijkbaar werkt dat dus anders.

Hij heeft het ook niet over de browser, maar over het protocol. Daarbij zijn er 'zat' mogelijkheden om via http een DoS uit te voeren. In elk geval zul je net zo goed met http2 een DoS kunnen uitvoeren, dat is iets wat niet direct te voorkomen is in een protocol.
Verder heeft deze feature niets direct iets te maken met een DoS, het is meer een soort van implementatie, niet direct dat als je 10 requests stuurt dat het opeens maar één is aan de 'andere kant' (server dus). Tenzij je dus echt specifiek meerdere requests middels zo'n multiplex verstuurd, maar meestal wil je dat niet als een DDoS want dan maak je het minder effectief.
Overigens probeer je met een DoS meer op een 'sneaky' manier hele dikke load met weinig resources (vaak 1 pc/server) te versturen, terwijl dan een DDoS meestal heel veel requests zijn vanuit heel veel clients.

Maar goed, een valide vraag alleen heeft het er eigenlijk niets mee te maken.