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

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

  • 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

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

  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