Komprese HTTP

HTTP compression 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. 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. 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

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 můžou 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

• 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 deflate – RFC 1951) v souladu s RFC 2616. Ve skutečnosti se ale implementace mezi zlib a deflate odchyluje od dohodnutých pravidel. 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).
• identity – Žádná transformace dat. Toto je defaultní nastavení položky content coding.
• pack200-gzip – Síťový transportní formát pro Java archivy.
• SDCH – Google Shared Dictionary Compression for HTTP
• bzip2 – Freeware open source bezztrátový kompresní algoritmus.
• peerdist – Microsoft 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

• Microsoft IIS – Vestavěný nebo používající moduly třetích stran.
• Apache HTTP Server – Prostřednictvím mod_deflate (navzdory svému jménu v současné době podporuje pouze gzip) nebo mod_gzip.
• Sun Java System Web Server
• Zeus Web Server
• Lighttpd – Pomocí mod_compress a novější mod_deflate (1.5.x).
• Nginx – Vestavěná.
• Geoserver

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

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

Externí Odkazy

• RFC 2616: Hypertext Transfer Protocol – HTTP/1.1
• HTTP Content-Coding Values publikovala Internet Assigned Numbers Authority.
• Apache: mod_deflate & mod_gzip
• Komprese s lighttpd
• Coding Horror: HTTP komprese na IIS 6.0
• 15 Seconds: Komprese webových stránek.
• HTTP Komprese: zdrojová strana zakladatele VIGOS AG, Constantina Racka.
• Použití HTTP Komprese podle Martina Browna z Server Watch.
• Použití HTTP Komprese v PHP.
• Ověřte si, zda zadaná stránka podporuje kompresi http.
• Dynamická a statická HTTP komprese s Apache httpd.