Brotli är en ny komprimeringsalgoritm utvecklad av Google. Den mindre komprimeringsresponsen möjliggör bättre utrymmesutnyttjande och snabbare sidladdning. I många fall överträffar Brotli gzip. Fördelar: För typiska webbresurser som css, html, js, överträffar Brotli gzip med 17–25 %. Brotli -11 densitet jämfört med gzip-9: html (flerspråkigt korpus): spara 25% av js (Alexas högsta 10k): spara 17% av krympande js (Alexas topp 10k): spara 17% av css (Alexas topp 10k): 20% sparande.
Introduktion till Brotli-algoritmen
Brotli släpptes ursprungligen 2015 för offline-komprimering av webbtypsnitt. Googles mjukvaruingenjörer släppte en förbättrad version av Brotli i september 2015 med särskilt fokus på HTTP-komprimering. Kodaren har delvis skrivits om för att förbättra komprimeringsförhållandet, både kodaren och avkodaren har ökat för hastighet, och streaming-API:et har förbättrats för att lägga till fler nivåer av komprimeringskvalitet. Den nya versionen visar också prestandaförbättringar över plattformar och minskat minne som krävs för avkodning.
Till skillnad från vanliga allmänna komprimeringsalgoritmer använder Brotli en fördefinierad ordbok på 120 kilobyte. Ordboken innehåller över 13 000 vanligt förekommande ord, fraser och andra delsträngar från en stor korpus av text- och HTML-dokument. Fördefinierade algoritmer kan öka komprimeringstätheten för mindre filer.
Att använda Brotli istället för att dekomprimera textfiler kan vanligtvis öka komprimeringstätheten med 20 %, medan komprimerings- och dekomprimeringshastigheten är ungefär densamma. Innehållskodningstypen för strömkomprimering med Brotli har föreslagits använda "br".
Brotli vs. Gzip
När vi utvärderar komprimeringsalgoritmer fokuserar vi på två indikatorer: kompressionshastighet och kompressionshastighet. Som du kan se i figuren ovan, oavsett vilken av de 9 komprimeringsnivåerna i gzip som används, är dess komprimeringsförhållande lägre än för brotli (jämfört med gzip kan det också konfigureras till 10), och komprimeringshastigheten är också långsammare.
Brotli-fördel: Brotli överträffar gzip med 17–25 % för typiska webbresurser som css, html, js. Brotli -11 densitet jämfört med gzip-9: html (flerspråkig korpus): spara 25% av js (Alexas högsta 10k): spara 17% av krympande js (Alexas topp 10k): spara 17% av css (Alexas topp 10k): 20% besparingar
asp.net kärna möjliggör Brotli
Accept-Encoding header-värde
Kodkonfiguration
Följande kod visar hur man aktiverar responsiv komprimeringsmiddleware för standard-MIME-typen och komprimeringsleverantörerna (Brotli och Gzip):
Not:
- app. UseResponseCompression måste ingå i appen. Använd Mvc innan du ringer.
- Använd verktyg som Fiddler, Firebug eller Postman för att ställa in Accept-Encoding-förfrågningsheadern och studera svarsheadern, storleken och brödtexten.
Som standard läggs Brotli-komprimeringsleverantören till komprimeringsleverantörens array tillsammans med Gzip-komprimeringsleverantören. När klienten stödjer Brotli-komprimerat dataformat går komprimeringen tillbaka till Brotli-komprimering. Om klienten inte stödjer Brotli går komprimeringen till Gzip som standard när klienten stödjer Gzip-komprimering.
BR-kompressionstest
Öppna fiddler-paketfångstverktyget och använd en webbläsare för att komma åt adressen till vår webbplats, du kan se följande:
Begäran: Accept-Kodning: gzip, deflate, br
Svarshuvud: Innehåll-kodning: br
När komprimering utförs tas huvudet Content-Length bort eftersom innehållet i brödtexten ändras när svaret komprimeras.
När komprimering utförs tas Content-MD5-headern bort eftersom innehållet i bröddelen har ändrats och hashen inte längre är giltig.
När asp.net kärna aktiverar https-funktionen påverkar inte Brotli html- och json-komprimering, men den kan komprimera js och css. (Det är möjligt att teckenlängden är för liten för att komprimeras, och den bör sättas)
(Slut)
|