HTTP-komprimering - HTTP compression

HTTP-komprimering er en funktion, der kan indbygges i webservere og webklienter for at forbedre overførselshastighed og udnyttelse af båndbredde.

HTTP-data komprimeres, før de sendes fra serveren: kompatible browsere vil meddele, hvilke metoder der understøttes til serveren, før de downloader det korrekte format; browsere, der ikke understøtter kompatibel komprimeringsmetode, downloader ukomprimerede data. De mest almindelige komprimeringsordninger inkluderer gzip og Brotli ; dog opretholdes en fuld liste over tilgængelige ordninger af IANA .

Der er to forskellige måder, hvor komprimering kan udføres i HTTP. På et lavere niveau kan et overførsels-kodende headerfelt angive nyttelasten for en HTTP-meddelelse er komprimeret. På et højere niveau kan et Content-Encoding header-felt indikere, at en ressource, der overføres, caches eller på anden måde refereres til, er komprimeret. Komprimering ved hjælp af indholdskodning understøttes bredere end overførselskodning, og nogle browsere reklamerer ikke for komprimering af overførselskodning for at undgå at udløse fejl på servere.

Komprimeringsordning forhandling

Forhandlingerne udføres i to trin, beskrevet i RFC 2616:

1. Webklienten annoncerer hvilke komprimeringsordninger den understøtter ved at inkludere en liste over tokens i HTTP-anmodningen . For indholdskodning er listen i et felt kaldet Accept-kodning ; til Transfer-Encoding kaldes feltet TE .

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate

2. Hvis serveren understøtter en eller flere komprimeringsordninger, kan de udgående data komprimeres ved hjælp af en eller flere metoder, der understøttes af begge parter. Hvis dette er tilfældet, tilføjer serveren et Content-Encoding eller Transfer-Encoding- felt i HTTP-svaret med de anvendte skemaer, adskilt af kommaer.

HTTP/1.1 200 OK
Date: mon, 26 June 2016 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

Den webserver er på ingen måde forpligtet til at bruge enhver komprimeringsmetode - det afhænger af interne indstillinger webserveren og også kan afhænge af den interne arkitektur af den pågældende hjemmeside.

Indholdskodning tokens

Den officielle liste over tokens, der er tilgængelige for servere og klienter, vedligeholdes af IANA, og den inkluderer:

  • br - Brotli , en kompressionsalgoritme, der er specielt designet til HTTP-indholdskodning, defineret i RFC 7932 og implementeret i alle moderne større browsere.
  • komprimere - UNIX "komprimere" programmetode (historisk; udfaset i de fleste applikationer og erstattet af gzip eller deflate)
  • deflate - komprimering baseret på deflate- algoritmen (beskrevet i RFC 1951), en kombination af LZ77- algoritmen og Huffman-kodning, pakket ind i zlib -dataformatet (RFC 1950);
  • exi - W3C Effektiv XML-udveksling
  • gzip - GNU zip-format (beskrevet i RFC 1952). Bruger deflate- algoritmen til komprimering, men dataformatet og checksum-algoritmen adskiller sig fra "deflate" -indholdskodningen. Denne metode understøttes mest i marts 2011.
  • identitet - Ingen transformation bruges. Dette er standardværdien for indholdskodning.
  • pack200-gzip - Netværksoverførselsformat til Java-arkiver
  • zstd - Zstandard komprimering, defineret i RFC 8478

Ud over disse bruges et antal uofficielle eller ikke-standardiserede tokens i naturen af ​​enten servere eller klienter:

  • bzip2 - komprimering baseret på det gratis bzip2-format, understøttet af lighttpd
  • lzma - komprimering baseret på (rå) LZMA er tilgængelig i Opera 20 og i elinks via en kompileringstid
  • peerdist - Microsoft Peer Content Caching og hentning
  • rsync - delta-kodning i HTTP , implementeret af et par rproxy- proxyer.
  • xpress - Microsoft-komprimeringsprotokol, der bruges af Windows 8 og senere til Windows Store-applikationsopdateringer. LZ77- baseret komprimering valgfrit ved hjælp af en Huffman-kodning.
  • xz - LZMA2-baseret indholdskomprimering, understøttet af en ikke-officiel Firefox-patch; og fuldt implementeret i mget siden 2013-12-31.

Servere, der understøtter HTTP-komprimering


Komprimering i HTTP kan også opnås ved hjælp af funktionaliteten på serversidescriptsprog som PHP eller programmeringssprog som Java .

Problemer, der forhindrer brugen af ​​HTTP-komprimering

En artikel fra Google, ingeniører Arvind Jain og Jason Glasgow fra 2009, siger, at mere end 99 årsværk spildes dagligt på grund af forøgelse af sideindlæsningstid, når brugere ikke modtager komprimeret indhold. Dette sker, når anti-virussoftware interfererer med forbindelser for at tvinge dem til at blive komprimeret, hvor proxies benyttes (med for forsigtige webbrowsere), hvor servere er forkert konfigureret, og hvor browserfejl stopper komprimering. Internet Explorer 6, der falder til HTTP 1.0 (uden funktioner som komprimering eller pipelining), når der er bag en proxy - en almindelig konfiguration i virksomhedsmiljøer - var den almindelige browser, der var mest tilbøjelig til at fejle tilbage til ukomprimeret HTTP.

Et andet problem, der findes under implementering af HTTP-komprimering i stor skala, skyldes definitionen af deflate- kodning: mens HTTP 1.1 definerer deflate- kodning som data komprimeret med deflate (RFC 1951) inde i en zlib- formateret stream (RFC 1950), har Microsoft-server og klientprodukter historisk set implementerede den som en "rå" deflateret strøm, hvilket gør dens implementering upålidelig. Af denne grund implementerer nogle software, inklusive Apache HTTP Server, kun gzip- kodning.

Sikkerhedsimplikationer

Komprimering gør det muligt at udføre en form for valgt almindeligt tekstangreb : hvis en angriber kan injicere et hvilket som helst valgt indhold på siden, kan de vide, om siden indeholder deres givne indhold ved at observere størrelsesforøgelsen af ​​den krypterede strøm. Hvis stigningen er mindre end forventet ved tilfældige injektioner, betyder det, at kompressoren har fundet en gentagelse i teksten, dvs. det indsprøjtede indhold overlapper den hemmelige information. Dette er ideen bag CRIME.

I 2012 blev et generelt angreb mod brugen af ​​datakomprimering, kaldet CRIME , annonceret. Mens CRIME-angrebet kunne arbejde effektivt mod et stort antal protokoller, inklusive men ikke begrænset til TLS, og applikationslagsprotokoller som SPDY eller HTTP, blev kun udnyttelser mod TLS og SPDY demonstreret og i vid udstrækning afbødet i browsere og servere. CRIME-udnyttelsen mod HTTP-komprimering er overhovedet ikke blevet mildnet, selvom forfatterne af CRIME har advaret om, at denne sårbarhed måske er endnu mere udbredt end SPDY- og TLS-komprimering kombineret.

I 2013 blev en ny forekomst af CRIME-angrebet mod HTTP-komprimering, kaldet BREACH, offentliggjort. Et BREACH-angreb kan udtrække login-tokens, e-mail-adresser eller andre følsomme oplysninger fra TLS-krypteret webtrafik på så lidt som 30 sekunder (afhængigt af antallet af bytes, der skal udtrækkes), forudsat at angriberen lokker offeret til at besøge et ondsindet weblink. Alle versioner af TLS og SSL er i fare fra BREACH uanset den anvendte krypteringsalgoritme eller kryptering. I modsætning til tidligere forekomster af CRIME , som med succes kan forsvares ved at slå TLS-komprimering eller SPDY-headerkomprimering fra, udnytter BREACH HTTP-komprimering, som ikke realistisk kan slås fra, da stort set alle webservere stoler på det for at forbedre datatransmissionshastighederne for brugerne.

Fra 2016 er TIME-angrebet og HEIST-angrebet nu offentligt kendt.

Referencer

eksterne links