HTTP-pakkaus - HTTP compression

HTTP-pakkaus on ominaisuus, joka voidaan rakentaa verkkopalvelimiin ja web-asiakkaisiin parantamaan siirtonopeutta ja kaistanleveyden käyttöä.

HTTP-tiedot pakataan ennen niiden lähettämistä palvelimelta: yhteensopivat selaimet ilmoittavat palvelimelle tuetut menetelmät ennen oikean muodon lataamista. selaimet, jotka eivät tue yhteensopivaa pakkaustapaa, lataavat pakkaamattomat tiedot. Yleisimpiä pakkausmenetelmiä ovat gzip ja Brotli ; IANA ylläpitää kuitenkin täydellistä luetteloa käytettävissä olevista järjestelmistä .

Pakkausta voidaan tehdä HTTP: ssä kahdella eri tavalla. Alemmalla tasolla Transfer-Encoding-otsikkokenttä voi osoittaa, että HTTP-viestin hyötykuorma on pakattu. Ylemmällä tasolla Content-Encoding-otsikkokenttä voi osoittaa, että siirrettävä, välimuistiin tallennettu tai muuten viitattu resurssi on pakattu. Sisällönkoodausta käyttävää pakkaamista tuetaan laajemmin kuin siirtokoodausta, ja jotkin selaimet eivät mainosta siirto-koodauksen pakkauksen tukea, jotta vältetään virheiden käynnistäminen palvelimissa.

Pakkausjärjestelmän neuvottelut

Neuvottelut käydään kahdessa vaiheessa, jotka kuvataan standardissa RFC 2616:

1. Verkkoasiakas mainostaa tukemiaan pakkausjärjestelmiä sisällyttämällä luettelon tunnisteista HTTP-pyyntöön . For Content-koodaus , luettelo on kentän nimeltään Accept-koodaus ; ja siirto-koodaus , kenttä on nimeltään TE .

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

2. Jos palvelin tukee yhtä tai useampaa pakkausmenetelmää, lähtevä data voidaan pakata yhdellä tai useammalla molempien osapuolten tukemalla menetelmällä. Jos näin on, palvelin lisää HTTP-vastaukseen sisällönkoodaus- tai siirtokoodauskentän käytetyillä kaavoilla pilkuilla erotettuna.

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

Web-palvelin ei ole mitenkään pakko käyttää mitään pakkausmenetelmä - tämä riippuu asetuksiin web-palvelimen ja voi riippua sisäinen arkkitehtuuri verkkosivuilla kyseessä.

Sisältöä koodaavat tunnukset

Palvelinten ja asiakkaiden käytettävissä olevien virallisten luetteloiden luetteloa ylläpitää IANA, ja se sisältää:

  • br - Brotli , erityisesti HTTP-sisällön koodausta varten suunniteltu pakkausalgoritmi, joka on määritelty RFC 7932: ssä ja joka on toteutettu kaikissa moderneissa suurimmissa selaimissa.
  • compress - UNIX "compress" -ohjelmatapa (historiallinen; vanhentunut useimmissa sovelluksissa ja korvattu gzipillä tai deflatuksella)
  • deflate - puristus, joka perustuu deflate- algoritmiin (kuvattu RFC 1951: ssä), LZ77- algoritmin ja Huffman-koodauksen yhdistelmä, kääritty zlib-datamuodon sisään (RFC 1950);
  • exi - Tehokas W3C XML -vaihto
  • gzip - GNU-zip-muoto (kuvattu RFC 1952: ssa). Käyttää pakkauksessa deflatointialgoritmia , mutta datamuoto ja tarkistussumman algoritmi poikkeavat "tyhjennä" -sisällönkoodauksesta. Tätä menetelmää tuetaan eniten maaliskuussa 2011.
  • identiteetti - Muunnosta ei käytetä. Tämä on sisällön koodauksen oletusarvo.
  • pack200-gzip - Verkonsiirtomuoto Java-arkistoille
  • zstd - Zstandard- pakkaus, määritelty standardissa RFC 8478

Näiden lisäksi joko palvelimet tai asiakkaat käyttävät luonnossa useita epävirallisia tai standardoimattomia tunnuksia:

  • bzip2 - pakkaus, joka perustuu vapaaseen bzip2-muotoon, jota lighttpd tukee
  • lzma - (raakaan) LZMA: han perustuva pakkaus on saatavana Opera 20: ssä ja elinksissä kääntöajan vaihtoehdon avulla
  • peerdist - Microsoft Peer -sisältövälimuisti ja haku
  • rsync - delta-koodaus HTTP: ssä , jonka toteuttaa rproxy- välityspalvelinpari.
  • xpress - Microsoftin pakkausprotokolla, jota Windows 8 ja uudemmat käyttävät Windows Store -sovellusten päivityksiin. LZ77- pohjainen pakkaus valinnaisesti käyttäen Huffman-koodausta.
  • xz - LZMA2-pohjainen sisällön pakkaus, jota tukee virallinen Firefox-korjaus; ja täysin toteutettu mgetissä vuodesta 2013-12-31.

Palvelimet, jotka tukevat HTTP-pakkausta


Pakkaus HTTP: ssä voidaan saavuttaa myös käyttämällä palvelinpuolen komentosarjakieliä, kuten PHP , tai ohjelmointikieliä, kuten Java .

Ongelmia HTTP-pakkauksen käytön estämisessä

Googlen insinöörien Arvind Jainin ja Jason Glasgow'n vuonna 2009 julkaisemassa artikkelissa todetaan, että yli 99 henkilötyövuotta tuhlataan päivittäin sivun latausajan pidentymisen vuoksi, kun käyttäjät eivät saa pakattua sisältöä. Tämä tapahtuu, kun virustorjuntaohjelmisto häiritsee yhteyksiä pakottaakseen ne pakkaamattomaksi, missä käytetään välityspalvelimia (liian varovaisilla verkkoselaimilla), missä palvelimet on määritetty väärin ja joissa selainvirheet lopettavat pakkaamisen. Internet Explorer 6, joka putoaa HTTP 1.0: een (ilman ominaisuuksia, kuten pakkaus tai putkisto) välityspalvelimen takana - yhteinen kokoonpano yritysympäristöissä - oli valtavirran selain, joka on alttiin epäonnistumaan takaisin pakkaamattomalle HTTP: lle.

Toinen ongelma, joka löydettiin HTTP-pakkauksen käyttöönotossa laajamittaisesti, johtuu deflatointikoodauksen määritelmästä: kun taas HTTP 1.1 määrittelee deflatointikoodauksen dataksi, joka on pakattu deflateilla (RFC 1951) zlib- muotoisen virran (RFC 1950) sisällä, Microsoft-palvelin ja asiakastuotteet ovat historiallisesti toteutti sen "raakana" tyhjennettynä virtana, mikä teki sen käytöstä epäluotettavaa. Tästä syystä jotkut ohjelmistot, mukaan lukien Apache HTTP Server, toteuttavat vain gzip- koodauksen.

Turvallisuusvaikutukset

Pakkaus sallii valitun selkokielisen hyökkäyksen muodon : jos hyökkääjä voi pistää minkä tahansa valitun sisällön sivulle, hän voi tietää, sisältääkö sivu heidän annetun sisällön, tarkkailemalla salatun virran koon kasvua. Jos kasvu on pienempi kuin satunnaisten injektioiden odotettu, se tarkoittaa, että kompressori on löytänyt tekstissä toiston, ts. Injektoitu sisältö menee päällekkäin salaisen tiedon kanssa. Tämä on rikollisuuden idea.

Vuonna 2012 ilmoitettiin yleinen hyökkäys tietojen pakkaamista vastaan, nimeltään CRIME . Vaikka CRIME-hyökkäys voisi toimia tehokkaasti suurella määrällä protokollia, mukaan lukien, mutta ei rajoittuen, TLS: ään, ja sovelluskerroksen protokolliin, kuten SPDY tai HTTP, vain TLS: ää ja SPDY: tä vastaan ​​tehdyt hyökkäykset osoitettiin ja lievennettiin suurelta osin selaimissa ja palvelimissa. CRIME-hyväksikäyttöä HTTP-pakkausta vastaan ​​ei ole lainkaan lievennetty, vaikka CRIME-kirjoittajat ovat varoittaneet, että tämä haavoittuvuus saattaa olla jopa laajempi kuin SPDY- ja TLS-pakkaus yhteensä.

Vuonna 2013 julkaistiin uusi ilmentymä HTTP-pakkausta vastaan ​​tehdystä CRIME-hyökkäyksestä, jonka nimi on BREACH. RIKKOMIS-hyökkäys voi poimia kirjautumistunnuksia, sähköpostiosoitteita tai muita arkaluontoisia tietoja TLS-salatusta verkkoliikenteestä vain 30 sekunnissa (riippuen purettavien tavujen lukumäärästä), jos hyökkääjä huijaa uhrin vierailemaan haitallisessa verkkolinkissä. Kaikki TLS- ja SSL-versiot ovat vaarassa rikkoutua käytetystä salausalgoritmista tai salauksesta riippumatta. Toisin kuin aiemmat CRIME- esiintymät , joita voidaan suojata onnistuneesti sammuttamalla TLS-pakkaus tai SPDY-otsikkopakkaus, BREACH hyödyntää HTTP-pakkausta, jota ei voida realistisesti sammuttaa, koska käytännössä kaikki verkkopalvelimet luottavat siihen käyttäjien tiedonsiirtonopeuksien parantamiseen.

Vuodesta 2016 lähtien TIME-hyökkäys ja HEIST-hyökkäys ovat nyt julkisia.

Viitteet

Ulkoiset linkit