Komprese HTTP

Z Wikipedie, otevřené encyklopedie

Komprese HTTP je v informatice vestavěná vlastnost webových serverů a prohlížečů umožňující lépe využít dostupný datový tok a zároveň zajistit rychlejší přenosové rychlosti mezi serverem a klientem.[1] Data přenášená přes protokol HTTP jsou komprimována ještě před odesláním klientovi; kompatibilní prohlížeč podá HTTP žádost o data zhruba tak, že do požadavku vloží hlavičku Accept-encoding, do které zapíše podporované kompresní algoritmy, a následně dostane odpověď s daty zkomprimovanými jedním z těchto algoritmů. Nekompatibilní prohlížeč by nebyl schopen přijatá zkomprimovaná data rozbalit, takže by bylo zbytečné žádat o komprimovaná data. Současné nejběžnější komprimační algoritmy jsou gzip a deflate (abstraktní knihovna využívající deflate je například zlib), ačkoli kompletní seznam dostupných algoritmů je udržován IANA.[2] Kromě toho třetí strany vyvíjejí nové kompresní metody a vkládají je do jejich softwarových produktů (například Google SDCH systém je implementován ve vyhledávači Google Chrome, který ho využívá při komunikaci s určitým okruhem serverů Google).

V roce 2009 vyšel od inženýrů Google Arvinda Jaina a Jasona Glasgowa článek, ve kterém spočítali časové ztráty v případě, že by se kompresní metody nepoužívaly. Součet promarněného času všech uživatelů internetu za jeden den by v takové situaci převyšoval 99 let. K problémům s komprimovaným přenosem dochází také například v situacích, kdy antivirový software nutí prohlížeč přijímat nekomprimovaná data, kdy je použito připojení přes proxy a opatrné prohlížeče nepovolí kompresi, pokud jsou špatně nastavené servery, nebo pokud jsou v prohlížečích chyby zabraňující správnému běhu HTTP komprese. Pokud byl Internet Explorer 6 za proxy (běžné nastavení v podnicích), byl nastaven tak, aby spadnul z technologie HTTP 1.1 na HTTP 1.0 (která prakticky neumožňuje kompresi a vůbec zřetězování). Díky těmto skutečnostem byl IE6, ve své době nejpoužívanější prohlížeč, nejvíce náchylný na využívání nekomprimovaného HTTP.

Vyjednávání komprese[editovat | editovat zdroj]

Ve většině případů, vyjma použití SDCH, se vyjednávání provede ve dvou krocích popsaných v RFC 2616:

1. HTTP žádost poslaná webovým klientem obsahuje řádek Accept-Encoding se jmény podporovaných kompresních schémat (pojmenovaných content-coding tokens) oddělených čárkami.

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

2. Pokud server podporuje jedno nebo více z uvedených kompresních schémat, odchozí data mohou být komprimována jednou nebo více metodami podporovanými oběma stranami. V takovém případě server přidá řádek Content-Encoding do hlavičky HTTP odpovědi se seznamem použitých schémat oddělených čárkami.

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

Webový server není v žádném případě povinen použít jakoukoliv kompresní metodu. Použití kompresních metod závisí výhradně na vnitřním nastavení serveru a také může záviset na vnitřní architektuře žádaných webových stránek.

V případě použití SDCH je slovníkové vyjednávání také vyžadováno, může ovšem zahrnovat dodatečné kroky jako stažení přesného slovníku z externího serveru.

Hodnoty pro Content-coding[editovat | editovat zdroj]

  • compress – metoda používaná stejnojmenný un*xovým programem
  • deflate – Navzdory svému jménu by komprese zlib (RFC 1950) měla být použita (v kombinaci s deflateRFC 1951) v souladu s RFC 2616. Ve skutečnosti se ale implementace mezi zlib a deflate odchyluje od dohodnutých pravidel.[3][4] Díky těmto zmatkům se lidem podporujícím gzip podařilo přesvědčit internetovou komunitu, že gzip je spolehlivější výchozí metoda (březen 2011).
  • exi – W3C Efficient XML Interchange
  • gzip – GNU zip formát (popsán v RFC 1952). Tato metoda je v současnosti nejšířeji podporovaná (březen 2011).[5]
  • identity – Žádná transformace dat. Toto je výchozí nastavení položky content coding.
  • pack200-gzip – Síťový transportní formát pro Java archivy.[6]
  • SDCHGoogle Shared Dictionary Compression for HTTP
  • bzip2 – Freeware open source bezztrátový kompresní algoritmus.
  • peerdistMicrosoft Peer Content Caching and Retrieval (ukládání obsahu do vyrovnávací paměti a jeho znovunačtení, popsáno v MS-PCCRPT)

Servery podporující HTTP kompresi[editovat | editovat zdroj]

Komprese HTTP může být také dosaženo použitím funkcionality jazyků podporujících skriptování na straně severu, například PHP nebo Java.

Reference[editovat | editovat zdroj]

  1. Using HTTP Compression (IIS 6.0) [online]. Microsoft Corporation [cit. 2010-02-09]. Dostupné online. 
  2. RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens."
  3. Compression Tests [online]. Verve Studios, Co [cit. 2011-03-23]. Dostupné v archivu pořízeném dne 2015-01-02. 
  4. Frequently Asked Questions about zlib – What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? [online]. Greg Roelofs, Jean-loup Gailly and Mark Adler [cit. 2011-03-23]. Dostupné v archivu pořízeném dne 2011-02-26. 
  5. Compression Tests: Results [online]. Verve Studios, Co [cit. 2011-03-23]. Dostupné v archivu pořízeném dne 2012-03-21. 
  6. JSR 200: Network Transfer Format for Java Archives.
  7. HOWTO: Use Apache mod_deflate To Compress Web Content (Accept-Encoding: gzip) – Mark S. Kolich [online]. Mark S. Kolich [cit. 2011-03-23]. Dostupné v archivu pořízeném dne 2011-08-20. 

V tomto článku byl použit překlad textu z článku HTTP compression na anglické Wikipedii.

Externí odkazy[editovat | editovat zdroj]