Brotli er en ny komprimeringsalgoritme utviklet av Google. Den mindre komprimeringsresponsen gir bedre plassutnyttelse og raskere sidelasting. I mange tilfeller overgår Brotli gzip. Fordeler: For typiske webressurser som css, html, js, overgår Brotli gzip med 17-25 %. Brotli -11 tetthet sammenlignet med gzip-9: html (flerspråklig korpus): spar 25 % av js (Alexas høyeste 10k): spar 17 % av krympende js (Alexas topp 10k): spar 17 % av css (Alexas topp 10k): 20 % besparelser.
Introduksjon til Brotli-algoritmen
Brotli ble opprinnelig lansert i 2015 for offline-komprimering av webfonter. Googles programvareingeniører lanserte en forbedret versjon av Brotli i september 2015 med spesielt fokus på HTTP-komprimering. Koderen er delvis omskrevet for å forbedre komprimeringsforholdet, både koderen og dekoderen er økt for hastighet, og strømme-API-et er forbedret for å legge til flere nivåer av komprimeringskvalitet. Den nye versjonen viser også ytelsesforbedringer på tvers av plattformer og redusert minnebehov for dekoding.
I motsetning til vanlige generelle komprimeringsalgoritmer bruker Brotli en forhåndsdefinert ordbok på 120 kilobyte. Ordboken inneholder over 13 000 vanlig brukte ord, fraser og andre understrenger fra et stort korpus av tekst- og HTML-dokumenter. Forhåndsdefinerte algoritmer kan øke komprimeringstettheten til mindre filer.
Å bruke Brotli i stedet for å komprimere tekstfiler kan vanligvis øke komprimeringstettheten med 20 %, mens komprimerings- og dekomprimeringshastigheten er omtrent den samme. Innholdskodingstypen for strømkomprimering ved bruk av Brotli har blitt foreslått å bruke "br".
Brotli vs. Gzip
Når vi evaluerer komprimeringsalgoritmer, fokuserer vi på to indikatorer: kompresjonshastighet og komprimeringshastighet. Som du kan se i figuren over, uansett hvilket av de 9 komprimeringsnivåene i gzip som brukes, er komprimeringsforholdet lavere enn for brotli (sammenlignet med gzip kan det også konfigureres til 10), og komprimeringshastigheten er også lavere.
Brotli-fordel: Brotli overgår gzip med 17-25 % for typiske webressurser som css, html, js. Brotli -11 tetthet sammenlignet med gzip-9: html (flerspråklig korpus): spar 25 % av js (Alexas høyeste 10k): spar 17 % av krympende js (Alexas topp 10k): spar 17 % av css (Alexas topp 10k): 20 % besparelser
asp.net kjernen muliggjør Brotli
Accept-Encoding header-verdi
Kodekonfigurasjon
Følgende kode demonstrerer hvordan man aktiverer responsiv komprimeringsmellomvare for standard MIME-type og komprimeringsleverandører (Brotli og Gzip):
Notat:
- app. UseResponseCompression må inkluderes i appen. UseMvc før du ringer.
- Bruk verktøy som Fiddler, Firebug eller Postman for å sette opp Accept-Encoding forespørselsheader og studer responsheaderen, størrelsen og kroppen.
Som standard legges Brotli-komprimeringsleverandøren til komprimeringsleverandørens array sammen med Gzip-komprimeringsleverandøren. Når klienten støtter Brotli-komprimert dataformat, går komprimeringen som standard over til Brotli-komprimering. Hvis klienten ikke støtter Brotli, går komprimeringen som standard til Gzip når klienten støtter Gzip-komprimering.
BR-kompresjonstest
Åpne fiddler-pakkefangstverktøyet og bruk en nettleser for å få tilgang til adressen til nettsiden vår, du kan se følgende:
Forespørselsheader: Accept-Encoding: gzip, deflate, br
Svarheader: Innhold-koding: br
Når komprimering utføres, fjernes Content-Length-headeren fordi innholdet endres når responsen komprimeres.
Når komprimering utføres, fjernes Content-MD5-headeren fordi innholdet i kroppen har endret seg og hashen ikke lenger er gyldig.
Når kjernen asp.net aktiverer https-funksjonen, vil ikke Brotli påvirke html- og json-komprimering, men det kan komprimere js og css. （Det er mulig at tegnlengden er for liten til å komprimeres, og den bør settes）
(Slutt)
|
Publisert 23.01.2021 12:12:25
|
|
|
|
Publisert 2022-9-24 10:48:26
|
Vert|
Publisert 2023-9-1 21:59:51
|
