Google aangekondigd een paar dagen geleden is het al begonnen de implementatie van HTTP / 3 en IETF QUIC in Chrome en in de aankondiging stelt hij dat hij verwacht dat deze update enkele aanvullende prestatieverbeteringen zal brengen, vooral met ondersteuning voor QUIC.
QUIC is een nieuw netwerktransportprotocol die de kenmerken van TCP, TLS en meer combineert. HTTP / 3 is de nieuwste versie van HTTP, het protocol dat de overgrote meerderheid van het webverkeer vervoert. HTTP / 3 werkt alleen op QUIC.
De Internet Engineering Task Force, of IETF, introduceerde HTTP / 2 in 2015, en een van de grote verbeteringen die het heeft aangebracht, is ondersteuning voor multiplexing.
Het gebruikte echter TCP als het transportprotocol en de verliesherstelmechanismen in TCP, dus verloren pakketten kunnen nog steeds een vertraging in alle actieve transacties veroorzaken.
Door QUIC te gebruiken, kan HTTP / 3 het overdrachtsproces verder verbeteren, aangezien de verloren pakketten in dit geval alleen de direct betrokken transacties beïnvloeden.
In feite QUIC is oorspronkelijk ontwikkeld door Google en voor het eerst aangekondigd in 2013. Sindsdien is het protocol volwassen geworden en is het momenteel verantwoordelijk voor het transport van een derde van het verkeer van Google.
Toen, in 2015, ging de ontwikkeling van QUIC over in handen van de IETF, de normalisatie-instelling die verantwoordelijk is voor het onderhoud van internetprotocollen. De IETF heeft QUIC verbeterd met verschillende wijzigingen. Tot op heden zijn er twee vergelijkbare, maar verschillende protocollen, namelijk: Google QUIC en IETF QUIC.
Google heeft aangekondigd dat het altijd zijn eigen versie van QUIC heeft gebruikt, maar dat zijn QUIC-team ook betrokken is bij de implementatie van de eigen versie van de IEFT. "We hebben de afgelopen vijf jaar aanzienlijke inspanningen geleverd om Google QUIC te ontwikkelen om gelijke tred te houden met de wijzigingen die door de IETF zijn aangebracht, en de huidige nieuwste versie van Google QUIC vertoont veel overeenkomsten met IETF QUIC", luidt de blogpost. Van Google, Daarnaast, verduidelijkte dat sommige dingen nog ontbraken.
Als voorbeeld tot nu toe de meeste Chrome-gebruikers kunnen niet communiceren met IETF QUIC-servers zonder enkele opdrachtregelopties in te schakelen. Hetzelfde, Google voegde eraan toe dat het nu heeft ontdekt dat IETF QUIC aanzienlijk beter presteert dan HTTP vergeleken met TLS 1.3 vergeleken met TCP.
Het bedrijf zei met name dat de latentie van Google bij zoekmachines met meer dan 2% wordt verminderd. De buffertijd van YouTube is met meer dan 9% verminderd. Bovendien zijn de clientprestaties op desktopcomputers met meer dan 3% gestegen.
Op mobiele telefoons zijn de prestaties van klanten met meer dan 7% gestegen. Deze en andere redenen liggen achter de overstap van Chrome naar de QUIC-versie van de IETF. "We zijn verheugd aan te kondigen dat Chrome ondersteuning implementeert voor de IETF QUIC (met name de h3-29-pilotversie).
Tegenwoordig gebruikt ongeveer 25% van de gebruikers van de stabiele versie van Chrome h3-29, en we zijn van plan dit aantal in de komende weken te verhogen door prestatiegegevens te blijven volgen ”, aldus het bedrijf in zijn blogpost.
"Chrome zal actief zowel de IETF QUIC h3-29 als de Google QUIC-versie (Q050) ondersteunen, zodat servers die Q050 ondersteunen, tijd hebben om te upgraden naar IETF QUIC," voegde hij eraan toe. Chrome m85 ondersteunt IETF QUIC 0-RTT nog niet en Google verwacht dat deze prestatie nog beter zal zijn wanneer het in de komende maanden ondersteuning vrijgeeft voor IETF QUIC 0-RTT. Bovendien, aangezien IETF QUIC versies 30 en 31 geen wijzigingen bevatten die de compatibiliteit zouden kunnen verbreken, is het bedrijf niet van plan de identifier "over-the-wire" te wijzigen.
Dit betekent dat zal wijzigingen in de IETF-versie blijven volgen, maar de zal implementeren als h3-29 / 0xff00001d.
Daarom raadt het aan dat servers h3-29 blijven ondersteunen totdat de definitieve RFC's zijn voltooid als ze willen samenwerken met Chrome. Als de IETF echter wijzigingen aanbrengt die de compatibiliteit in een toekomstig project verbreken, zal Chrome die beslissing ongedaan maken.
bron: https://blog.chromium.org