Brotli er en ny komprimeringsalgoritme udviklet af Google. Den mindre komprimeringsrespons giver bedre pladsudnyttelse og hurtigere sideindlæsning. I mange tilfælde overgår Brotli gzip. Fordele: For typiske webassets som css, html, js, overgår Brotli gzip med 17-25%. Brotli -11 densitet sammenlignet med gzip-9: html (flersproget korpus): gem 25% af js (Alexas højeste 10k): gem 17% af krympende js (Alexas top 10k): gem 17% af css (Alexas top 10k): 20% besparelser.
Introduktion til Brotli-algoritmen
Brotli blev oprindeligt udgivet i 2015 til offline-komprimering af webskrifttyper. Googles softwareingeniører udgav en forbedret version af Brotli i september 2015 med særligt fokus på HTTP-komprimering. Encoderen er delvist omskrevet for at forbedre komprimeringsforholdet, både encoder og decoder er blevet øget for hastighed, og streaming-API'en er blevet forbedret for at tilføje flere niveauer af komprimeringskvalitet. Den nye version viser også forbedringer i ydeevnen på tværs af platforme og reduceret hukommelse til dekodning.
I modsætning til almindelige generelle komprimeringsalgoritmer bruger Brotli en foruddefineret ordbog på 120 kilobyte. Ordbogen indeholder over 13.000 almindeligt anvendte ord, vendinger og andre understrenge fra et stort korpus af tekst- og HTML-dokumenter. Foruddefinerede algoritmer kan øge komprimeringstætheden af mindre filer.
Brug af Brotli i stedet for at defladere til at komprimere tekstfiler kan som regel øge komprimeringstætheden med 20 %, mens komprimerings- og dekomprimeringshastigheden er omtrent den samme. Indholdskodningstypen til streamkomprimering ved brug af Brotli er blevet foreslået at bruge "br".
Brotli vs. Gzip
Når vi evaluerer komprimeringsalgoritmer, fokuserer vi på to indikatorer: kompressionshastighed og kompressionshastighed. Som du kan se i figuren ovenfor, uanset hvilket af de 9 komprimeringsniveauer i gzip der bruges, er komprimeringsforholdet lavere end for brotli (sammenlignet med gzip kan det også konfigureres til 10), og komprimeringshastigheden er også langsommere.
Brotli Advantage: Brotli overgår gzip med 17-25% for typiske webassets som css, html, js. Brotli -11 tæthed sammenlignet med gzip-9: html (flersproget korpus): gem 25% af js (Alexas højeste 10k): spar 17% af krympende js (Alexas top 10k): spar 17% af css (Alexas top 10k): 20% besparelser
asp.net kerne muliggør Brotli
Accept-Encoding header-værdi
Kodekonfiguration
Følgende kode demonstrerer, hvordan man aktiverer responsiv komprimeringsmiddleware for standard MIME-typen og komprimeringsudbyderne (Brotli og Gzip):
Seddel:
- app. UseResponseCompression skal være inkluderet i appen. Brug Mvc før du ringer.
- Brug værktøjer som Fiddler, Firebug eller Postman til at opsætte Accept-Encoding-anmodningsheaderen og studere svarheaderen, størrelsen og kroppen.
Som standard tilføjes Brotli-komprimeringsudbyderen til komprimeringsudbyderens array sammen med Gzip-komprimeringsudbyderen. Når klienten understøtter Brotli-komprimeret dataformat, går komprimeringen som standard over til Brotli-komprimering. Hvis klienten ikke understøtter Brotli, går komprimeringen som standard til Gzip, når klienten understøtter Gzip-komprimering.
BR kompressionstest
Åbn fiddler-pakkefangstværktøjet og brug en browser til at få adgang til adressen på vores hjemmeside, du kan se følgende:
Anmodningsheader: Accept-Kodning: gzip, deflate, br
Svar-header: Indhold-kodning: br
Når komprimering udføres, fjernes Content-Length-headeren, fordi indholdet ændres, når responsen komprimeres.
Når komprimering udføres, fjernes Content-MD5-headeren, fordi indholdet i brødteksten er ændret, og hashen ikke længere er gyldig.
Når asp.net kerne aktiverer https-funktionen, vil Brotli ikke påvirke html- og json-komprimering, men det kan komprimere js og css. (Det er muligt, at tegnlængden er for lille til at blive komprimeret, og den bør sættes)
(Slut)
|