HTML-KOMPRESSION P1 Anders Rune Jensen Ester Mungure Ole Laursen Rasmus Jørgensen Jasper Kjersgaard Juhl Michael Knudsen Martin Qvist December 2001 AALBORG UNIVERSITET
Det Teknisk-Naturvidenskabelige Fakultet Aalborg Universitet Basisuddannelsen Titel: HTML-kompression Projektperiode: P1, 9. oktober 18. december, 2001 Projektgruppe: B333 Gruppemedlemmer: Anders Rune Jensen Jasper Kjersgaard Juhl Ole Laursen Martin Qvist Ester Mungure Rasmus Jørgensen Michael Knudsen Vejleder: Thomas Nielsen Bivejleder: Claus Monrad Spliid Synopsis: I denne rapport beskæftiger vi os med kompression af HTML. Dels fra en teoretisk synsvinkel i form af informationsteori, dels fra en mere konkret synsvinkel i form af en gennemgang af generelle algoritmer der kan bruges til at komprimere HTML-sider. Vi undersøger desuden om man kan udnytte nogle af egenskaberne ved HTML til at skabe en mere effektiv, specifik algoritme. Grunden til at HTML-kompression er interessant, skyldes at mængden af internettrafik vokser støt mens udbyderne ønsker at spare penge på stadigt voksende forbindelser, og brugerne ønsker en bedre internetoplevelse. Kompression af HTML har potentialet til at hjælpe på dette fordi HTML-sider kan komprimeres effektivt, ligesom billeder, lyd, video og software der allerede komprimeres rutinemæssigt. Spørgsmålet er om potentialet er stort nok. Og om behovet er stort nok. Antal kopier: 14 Rapport sideantal: 64 Appendiks sideantal: 11 Totalt sideantal: 79
Forord Denne rapport er udarbejdet som P1-opgave på Ålborg Universitets basisuddannelse. Den er resultat af 3 måneders arbejde med emnet kompression. Det forudsættes at læseren har grundlæggende kenskab til visse tekniske aspekter af internettet, som f.eks. router, proxyserver, webserver og browser. Rapporten må frit distribueres i en hvilken som helst form. En særlig tak til vores vejledere Thomas Nielsen og Claus Spliid, som har været en stor hjælp gennem projektperioden. God fornøjelse med rapporten Jasper, Martin, Ole, Ester, Rasmus, Michael og Anders 1
Indhold 1 Indledning 5 1.1 Problembeskrivelse......................... 5 1.2 Problemformulering......................... 6 1.3 Oversigt over projektet....................... 6 2 Introduktion til kompression 7 3 Behovsanalyse 9 3.1 Brugerne.............................. 9 3.1.1 Undersøgelse af datasammensætning........... 10 3.1.2 Undersøgelse af overførselshastighed........... 11 3.1.3 Kompression af forbindelser................ 13 3.2 Udbyderne.............................. 13 3.2.1 Undersøgelse af datasammensætning........... 14 3.3 Sammenfatning........................... 15 4 Informationsteori 17 4.1 Entropi............................... 17 4.2 Egenskaber ved entropi....................... 18 4.2.1 Optimal kodning...................... 19 4.2.2 Maksimal entropi ved ligelig fordeling........... 19 4.2.3 Afhængigheder reducerer entropi............. 19 4.3 Komprimering og entropi...................... 20 4.3.1 HTML, informationsteoretisk set.............. 21 5 Analyse af kompressionsmetoder 23 5.1 Statistiske metoder......................... 24 5.1.1 Præfikskoder........................ 24 5.1.2 Huffman.......................... 25 5.2 Ordbogsbaserede metoder..................... 30 5.2.1 Lempel-Ziv 77....................... 30 5.2.2 Lempel-Ziv 78....................... 34 5.2.3 Konklusion......................... 36 5.3 Transformationer.......................... 37 2
INDHOLD 5.3.1 Burrows-Wheeler-transformationen............ 37 5.3.2 Move-to-front........................ 40 5.3.3 Konklusion......................... 41 6 Udvælgelse af algoritme 43 6.1 Hvad kan komprimeres i HTML?.................. 43 6.2 Dynamisk ordbog.......................... 44 6.2.1 Fremgangsmåde...................... 44 6.2.2 Konklusion......................... 45 6.3 Ændring af alfabetet........................ 45 6.4 Opdeling af filerne......................... 46 6.5 Vores algoritme........................... 46 7 Implementering 48 7.1 Gennemgang af algoritme i pseudokode.............. 48 7.2 Øvrige funktioner.......................... 50 7.3 Programmets grænseflade...................... 51 7.4 Afvikling af programmet...................... 51 7.5 Test................................. 51 7.5.1 Komprimeringsevne.................... 53 7.5.2 Tidsaspektet........................ 54 7.5.3 Sammenfatning....................... 54 7.5.4 Algoritmens tidskompleksitet............... 55 7.5.5 Konklusion......................... 56 8 Praktiske overvejelser 57 8.1 Fordele og ulemper for udbyder.................. 57 8.2 Brugerne.............................. 58 8.3 Eksisterende løsninger....................... 59 8.4 Anvendelse af HTTP 1.1-kompression............... 59 9 Konklusion 61 9.1 Resultater fra rapporten....................... 61 9.2 Perspektivering........................... 62 A Eksempler 65 A.1 Eksempler fra statistiske metoder.................. 65 A.1.1 Fortsat eksempel fra Huffman-kodning.......... 65 A.2 Eksempler fra ordbogsbaserede metoder.............. 67 A.2.1 Eksempel fra Lempel-Ziv 78................ 67 A.3 Eksempler fra transformationer................... 67 A.3.1 Eksempel fra Burrows-Wheeler.............. 67 3
INDHOLD B Beskrivelse af undersøgelser 70 B.1 Testsiderne............................. 70 B.2 Datasammensætning i logfiler................... 71 B.2.1 Proxyserveren granit.but.auc.dk.............. 71 B.2.2 IT-Avisen.......................... 72 B.3 Overførselstid for forskellige forbindelser............. 72 B.4 Test af kompressionshastighed................... 73 C Kompressionstest 74 D Udbredelse af HTML-kompression 75 E Telefoninterviews 76 E.1 www.tv2.dk............................. 76 E.2 www.dating.dk........................... 77 E.3 www.ofir.dk............................. 77 4
Kapitel 1 Indledning 1.1 Problembeskrivelse Internet er verdens hurtigst voksende medie med et udbud af mange milliarder websider. Men forbindelserne til internet er begrænset i båndbredde, dvs. der er grænse for hvor meget data der kan sendes mellem to computere pr. sekund. At købe ekstra båndbredde er relativt dyrt dels er det dyrt for virksomheder der driver websites, og dels er det dyrt for brugerne. Derfor er der behov for at udnytte disse forbindelser bedre, og det er her kompression kommer ind som en mulig løsning. Kompression handler om at kode data for derved at formindske mængden af dem på en måde så de kan gendannes når de skal bruges. Denne teknik er allerede meget udbredt når det gælder billeder, lyd og film, men ikke for HTML-sider (der er de filer man læser når man surfer på internettet) på trods af at disse kan komprimeres meget effektivt. Men hvorfor bliver siderne så ikke komprimeret? Det kunne være fordi HTML-filerne udgør en for lille del af trafikken til at det kan betale sig at bruge kompression på dem. Hvis man skal komprimere HTML-filer, hvilken algoritme skal man så bruge? Det kan ikke være en af de ellers meget effektive algoritmer med tab, som indebærer at filerne ikke kan genskabes til nøjagtigt det samme som før kompression; i modsætning til billeder og lyd kan man nemlig ved HTML-sider ikke tillade ændringer, da dette kunne lave om på layout og mening for udbydernes websider. Men der findes stadig mange algoritmer der er tabsfri. Hvilken skal vi vælge, og hvis vi endelig finder en algoritme, findes der så de tekniske forudsætninger til at løsningen kan implementeres? Kan man overhovedet få folk til at bruge det? Dette afhænger selvfølgelig af hvor stor en evt. besparelse ville være, hvor godt teknologien kunne integreres med eksisterende praksis og hvorvidt den nødvendige viden er til stede hos udbyderne af disse websider, men dette er alle spørgsmål der bliver diskuteret i rapporten. 5
Kapitel 1: Indledning 1.2 Problemformulering Problemet er altså om det er en fordel at indføre kompression af HTML-sider over internettet for brugere og udbydere, og hvilken metode man i givet fald skulle bruge. 1.3 Oversigt over projektet Vi starter med at undersøge hvad kompression af data er for noget for at få opbygget en fast referenceramme til resten af rapporten. Herefter behandler vi spørgsmålet om det overhovedet kan betale sig at indføre kompression af websider bl.a. undersøger vi for de to hovedparter, brugerne og udbyderne, hvor stor en mængde data HTML-siderne udgør i forhold til den totale mængde data der overføres, dette inkluderer bla. billeder og lyd. Dette kan, ud over at indikere i hvor stor udstrækning det er relevant at komprimere HTML-filer, give en baggrund for at vurdere de algoritmer vi senere analyserer. Herefter kommer vi ind på informationsteori som giver en teoretisk forståelse for og et overblik over hvorfor kompressionsalgoritmer virker. Denne forståelse sætter os i stand til at foretage en undersøgelse af forskellige algoritmer dette resulterer i en analyse og sammenligning af forskellige måder at komprimere på og en afvejning af deres styrker og svagheder i forbindelse med websidekompression. Sammen med de resultater vi har opnået ved behovsanalysen, forsøger vi derefter at vurdere en alternativ metode til at opnå bedre komprimering af websider. Dette følges op af en implementation der tillader os at foretage en test der kan holdes op mod gængse komprimeringsmetoder som gzip [10]. Vores praktiske test giver desuden et grundlag for at besvare spørgsmålet om de krav som brugerne og udbyderne måtte stille til en kompressionsløsning, kan opfyldes, og kan derfor hjælpe med at afklare om en kompressionsløsning overhovedet vil have nogen chance for blive anvendt hos henholdsvis brugerne og udbyderne. Sidste del af rapporten behandler dette emne. Men vi starter med en grundlæggende undersøgelse af kompression. 6
Kapitel 2 Introduktion til kompression Der er forskel på størrelsen af en datamængde og størrelsen af informationsindholdet i dataene. At komprimere handler om at formindske størrelsen af data uden at ødelægge informationsindholdet. I rapporten opfatter vi data som bestående af en ordnet række af symboler, eller tegn, der via en kompressionsalgoritme gennemgår en kodning så de bliver til en ordnet række af kodeord, eller bare koder, der gerne samlet skulle være mindre end den oprindelige række. Grunden til at man kan komprimere, hænger dels sammen med at man ofte har data liggende i en form som gør at det er hurtigere og/eller lettere at bruge dem f.eks. bruger man som regel 8 bit til at repræsentere tegn, også selvom man reelt kun bruger måske 128 forskellige tegn som kunne lagres på 7 bit. Dels hænger det sammen med at de data vi almindeligvis beskæftiger os med, f.eks. tekst, normalt fylder mere end den information de viderebringer der er redundans i dem. Den første type af overflødigt data som beskrevet i ovenstående er relativt let at skære væk da det blot kræver at man i stedet for at optimere mht. hastighed, går over til at opbevare dataene mere kompakt. F.eks. kunne modtager og afsender enes om at bruge en ordbog, en fortegnelse over symboler med deres tilhørende kodeord, hvor der kun optræder de tegn der faktisk bruges så man kun behøvede f.eks. 5 bit til at repræsentere et tegn. Det er imidlertid sværere at komme redundansen i dataene til livs man kan grundlæggende gå to veje: enten kan man vælge en generel metode, som en af de der er beskrevet i kapitel 5, eller en metode som er optimeret til netop den type data man arbejder med. En undersøgelse af dataene giver naturligvis mulighed for bedre kompression og oftest sker der også en analyse af de data der ønskes komprimeret, inden den reelle kompression igangsættes, også ved de generelle metoder. En uddybning og forklaring af redundansfænomenet gives i kapitel 4, men et kort eksempel med sekvenslængdekodning kan illustrere det. Sekvenslængdekodning eller run length encoding, RLE, går ud på at erstatte gentagelser af samme symbol med et enkelt symbol samt antallet af forekomster f.eks. kan muuuuuuuuh erstattes med m*8uh hvor stjernen repræsenterer et 7
Kapitel 2: Introduktion til kompression kontroltegn som bruges ved afkodningen til at afgøre at næste tegn skal duplikeres et antal gange. Dette nedbringer datamængden fra 10 til 5 tegn, dvs. giver kompressionsforholdet 50% (kompressionsforhold er defineret som forholdet mellem størrelsen af de komprimerede data og størrelsen af de oprindelige data, f.eks. 1:2). Dette forhold er naturligvis ikke generelt for RLE som ikke er særligt velegnet til at komprimere almindelig tekst, men kan være effektiv i andre sammenhænge. Det skal i øvrigt bemærkes at de generelle algoritmer ikke er så generelle at de kan komprimere alle typer data kompression kan jo betragtes som en funktion der afbilder en given mængde data over i en værdimængde. Funktionen skal imidlertid være en bijektion hvis man altid skal kunne komme tilbage til de samme data, hvorfor værdimængden skal være lige så stor som definitionsmængden hvis alle elementer i definitionsmængden kan forekomme i dataene. Altså kan man ikke generelt gå fra f.eks. 8 bit til 7, ikke alle data kan komprimeres. I nogle tilfælde af kompression kan man tillade et tab af data så kompression fulgt af dekompression ikke giver præcist de samme data. Dette sker ofte ved kompression af lyd eller billeder som man som regel kan beskrive med færre detaljer og nuancer uden at det behøver at være mærkbart. Derved reducerer man antallet af forskellige tegn så der kan opnås en bedre kompression; JPEG og MP3 er eksempler på dette. Som tidligere nævnt vil vi dog i denne rapport beskæftige os med tabsfri kompression fordi udseendet og indholdet af siderne ikke må blive forstyrret. Der er dog to sider af HTML det indhold som f.eks. forfatteren af dokumentet ser, koderne og teksten, og den formaterede fremstilling som brugerne af siderne ser i deres browser. Man kan argumentere for at små ændringer i HTML-koderne, f.eks. skift fra små bogstaver til store, der ikke giver nogen forskel i udseendet i browseren, ikke medfører noget tab. Vi overvejer dette i kapitel 6. Efter denne korte introduktion til komprimeringsbegrebet følger en analyse af behovet for en kompression af websider. 8
Kapitel 3 Behovsanalyse Udgangspunktet for denne rapport er at kompression af websider har et potentiale for udbredelse. Men hvad består potentialet egentligt af, og hvem gælder det? Formålet med behovsanalysen er at få klarlagt disse spørgsmål især er det interessant om et evt. behov er stort nok til at kunne motivere en almen brug. Man kan skelne mellem to parter: de almindelige brugere af websider og udbyderne, dem der ejer og driver de foreskellige websites. Den følgende analyse fokuserer på tekniske problemer problemer som brugervenlighed og økonomiske forhold i forbindelse med at indføre en løsning ude i erhvervslivet bliver behandlet i kapitel 8. 3.1 Brugerne For brugerne er det mest af alt et spørgsmål om at komprimerede sider kan give en hastighedsgevinst også rent økonomisk er selve trafikmængden ikke så interessant fordi man som oftest betaler pr. tid og ikke pr. kb hentet data 1. Hastighedsforbedringen kan dels komme direkte ved at mindre filer tager kortere tid at hente, dels indirekte ved at en generelt mindre trafikmængde på internettet alt andet lige burde give kortere responstider for alle. Sidstnævnte er dog i sagens natur svært at undersøge, og vi beskæftiger os i det følgende kun med den umiddelbare gevinst. Hastighedsgevinsten afhænger naturligvis af komprimeringsalgoritmen dels hvor effektivt den komprimerer, dels hvor hurtig den er. Gevinsten afhænger imidlertid også af HTML-dataenes andel af den samlede overførte mængde data hvis f.eks. kun 1% af dataene er HTML, vil en kompressionsløsning, ligegyldigt hvor effektiv den er, næppe være interessant fordi den mulige gevinst er for lille. Desuden skal en hastighedsgevinst i forbindelse med overførslerne sættes i forhold til hvor lang tid det tager at overføre dataene nu. Selvom den relative gevinst kan være stor, f.eks. 50%, ville det ikke betyde noget hvis en given bruger sammenlagt kun sparede en hundredel sekund. 1 Dog med enkelte undtagelser, heriblandt StofaNet 9
Kapitel 3: Behovsanalyse I begge tilfælde ville der ikke være behov for en løsning. Vi er derfor nødt til at foretage en undersøgelse af dels HTML-filernes andel af den samlede datamængde, dels af de nuværende overførselstider. 3.1.1 Undersøgelse af datasammensætning Til analysen betragter vi en logfil for proxyserveren granit.but.auc.dk, en maskine der sidder mellem de lokale brugere på basisuddannelsen på Aalborg Universitet, og resten af internettet og gemmer ofte benyttede filer midlertidigt. Logfilen indeholder oplysninger om hvilke filer på internettet brugere på basisuddannelsen har besøgt, og en analyse af den kan derfor give et overblik over omkring 900 menneskers dataforbrug, se tabel 3.1 (selve analyseprogrammet og sorteringskriterierne er beskrevet i afsnit B.2). Der er dog ingen garanti for at dataforbruget fra maskiner på universitetet modsvarer forbrugsmønstret når folk sidder hjemme. Dette antager vi dog. datatype mængde (Mb) andel (%) i cache (%) stør. (kb) HTML 1879,37 11,69 15,16 7,79 billeder 1622,76 10,09 61,6 6,62 andet 12580,49 78,22 2,19 27,02 statisk 364,45 19,39 41,18 9,71 dynamisk 1514,92 80,61 8,9 7,44 Tabel 3.1: Tabel over en uges trafik fra basisuddannelsens proxyserver Fordelingen af datamængden Tabel 3.1 giver oplysninger om tre forskellige kategoriers andel af trafikken, HTML som er de websider vi kunne være interesseret i at komprimere, billeder der ofte indgår som en del af siderne, men ligger særskilt og så godt som altid er komprimerede, og andet der dækker over 65% programdata (næsten udelukkende fra distributed.net-klienter 2 ), 4% lyd, 7% video og 24% andre ting som ISOfiler (til cd ere), programmer og andre pakkede ting. Umiddelbart giver fordelingen med kun omtrent 12% på HTML-sider ikke plads til megen forbedring. I midlertid dækker de 78% over data som ikke er en typisk del af navigationsmønstret på websider hentning af lyd, video og programmer foregår ofte parallelt med selve surfningen hvorfor en bruger ikke sidder og venter på de data før vedkommende kan se siden, som det ellers er tilfældet med billederne der typisk vises indlejret. Hvis vi ser bort fra dem, er fordelingen på omtrent halvdelen på websider og halvdelen på billeder her er der altså mulighed for at effektivisere. I øvrigt kan 2 Program der arbejder i baggrunden og løser svære problemer fra en central server 10
Kapitel 3: Behovsanalyse fordelingen være noget skæv i retning af de 78% andre data fordi universitetets internetforbindelse er meget hurtigere end de flestes brugers linjer, 100 Mbit/s, og dermed bedre er i stand til at klare de tunge datatyper. En sidste pointe er at de datamængder der er angivet i tabellen, er for de faktiske overførsler mellem proxyserveren og internettet kolonnen med i cache viser at f.eks. billeder ofte kan hentes fra proxyserveren i stedet for direkte fra webserveren, og dette er altså indregnet i tallene for datamængderne. Hvis dette ikke var tilfældet, ville billeddatamængden f.eks. være en del højere. En almindelig bruger har selvfølgelig næppe adgang til en proxyserver lokalt, men på den anden side udfører browsere i forvejen samme funktion. Men i hvert fald ses det på fordelingen af datamængden at en kompression af HTML ville kunne give brugeren en hastighedsgevinst. Statisk og dynamisk indhold Tabellen angiver også fordelingen mellem statiske og dynamiske websider. En statisk webside er en almindelig HTML-fil der ligger i sin færdige version direkte på serveren, mens en dynamisk side er en side som sættes sammen af serveren lige før den sendes, f.eks. ud fra oplysninger i en database. Grunden til at det er interessant at undersøge, er at det kan vanskeliggøre komprimeringen af siderne. Statiske sider kan komprimeres på forhånd så hastigheden af komprimeringsalgoritmen er relativt ligegyldig dynamiske sider skal derimod komprimeres løbende hvad der stiller større krav til hastigheden. Måske noget overraskende kan man i tabellen se at 80% af siderne er dynamiske, altså skal en effektiv løsning også kunne bruges på dynamiske sider. Vi kan derfor konstatere at hastighed spiller en rolle. Filstørrelser Den gennemsnitlige filstørrelse fremgår i den sidste kolonne i tabellen. Den gennemsnitlige størrelse siger imidlertid ikke så meget om fordelingen hvorfor et diagram over de forskellige filstørrelser for datatyperne fremgår i figur 3.1 på den følgende side. Filerne er inddelt i 1 kb s intervaller hvis andele af det samlede antal filer derefter er plottet op til 40 kb (over denne størrelse var antallet af filer så lille at det ikke kan ses på diagrammet). Diagrammet viser at størstedelen af filerne er mindre end 10 kb. Så komprimeringsmetoden skulle gerne være effektiv på små filer. Selvom det ikke er så stort et problem fordi de små filer jo i sagens natur ikke fylder så meget og derfor kan hentes hurtigere. 3.1.2 Undersøgelse af overførselshastighed For at få et indtryk af hvor meget der er at spare for brugerne har vi gennemført en test af overførselstiderne for en række websider (de er beskrevet i afsnit B.1) for 11
Kapitel 3: Behovsanalyse 50 45 40 statisk dynamisk 35 % andel 30 25 20 15 10 5 0 0 5 10 15 20 25 filstørrelse kb 30 35 40 Figur 3.1: Fordelingen af filstørrelser for granit.but.auc.dk. henholdsvis et almindeligt analogt modem med en 56k-forbindelse, en enkeltkanals ISDN-linje på 64 kbit/s og en ADSL-forbindelse på 256 kbit/s. Resultatet kan ses i tabel 3.2, selve testen er dokumenteret i bilag B.3 på side 72. HTML-side modem (s) ISDN (s) ADSL (s) filstør. (kb) Carlsberg 2,0 0,6 0,6 7,0 The Voice 5,6 2,2 2,2 28,0 IT-Avisen 6,9 2,3 2,4 30,8 ITL 4,7 1,5 1,5 18,4 Jyllandsposten 15,3 5,7 5,1 66,2 Jubii 10,7 3,6 3,4 43,5 Tabel 3.2: Overførselstiderne for forskellige forbindelser Det fremgår af tabel 3.2 at der faktisk er en vis ventetid selv for de hurtigere forbindelser; allerede omkring 2 sekunders ventetid kan mærkes. I hvert fald er 5-10 sekunders ventetid for de middelstore sider med det analoge modem nok til at kunne forstyrre, og ifølge [19] er der 2,8 mill. danskere med abonnement til analogt modem og kun ca. 400.000 med ISDN og 70.000 med ADSL (svarende til andelene 86%, 12% og 2%). Altså er der grundlag for en forbedring. Det kan virke mærkeligt at ISDN-linjen er nogenlunde lige så hurtig som ADSLforbindelsen, men det kan skyldes at der over ISDN-forbindelsen allerede bruges komprimering, se afsnit 3.1.3. 12
Kapitel 3: Behovsanalyse 3.1.3 Kompression af forbindelser Noget, der kan undergrave ideen i at komprimere HTML-filerne, er, hvis forbindelserne allerede bliver komprimeret. På større forbindelser f.eks. over Atlanterhavet og på ruter internetudbydere imellem benyttes der ingen kompression. Årsagen til dette er formodentlig at hardwarekravene til at komprimere så store mængder data tilstrækkeligt hurtigt gør det for dyrt. I teknologien for analoge modemer er der imidlertid allerede indbygget kompression [3] i form af V.42bis som benytter en variant af LZW (se evt. afsnit 5.2.2). Kompressionen foregår løbende og slås fra hvis den ikke er effektiv nok [16]. Kompressionen er dog ikke specielt kraftig, og det er ikke klart defineret, hvad effektivt nok betyder. Vores undersøgelser har ikke vist, at der bruges nogen form for hardwarekompression på ISDN-forbindelser, men der kan dog benyttes softwarekompression [8]. Der er foreslået nogle standarder, bl.a. LZ-Stac 3, omkring det [14], og disse har ved test vist sig at give en temmelig effektiv kompression [9] som det også fremgår af tabel 3.2 på forrige side. Vores undersøgelser har heller ikke vist, at ADSL-opkoblinger benytter hardwarekompression. Der er dog foreslået en standard [15], som medfører at ADSLforbindelser kan benytte LZ-Stac. En del routere og lignende udstyr kan benytte denne standard og at stadigt mere hardware understøtter det. Som nævnt er LZ-Stac kun en foreslået standard. Det betyder også, at der ved oprettelse af opkaldsforbindelser forhandles, om der skal benyttes kompression. Det vil sige, at det kræver, at internetudbyderne understøtter og benytter LZ-Stac, for at man kan bruge det. 3.2 Udbyderne Mens besparelser på trafikmængden i sig selv ikke er så interessant for brugerne, er det anderledes for udbyderne, da en mindre trafikmængde direkte kan oversættes til en billigere forbindelse med mindre båndbredde (eller evt. en udskydelse af en planlagt udvidelse). Hastigheden af hele processen i forbindelse med overførslen betyder naturligvis stadig også meget fordi den er afgørende for hvor mange brugere en server kan betjene. Både båndbredden og behandlingstiden for en betjening kan være flaskehalse. Som ved brugersiden er det nødvendigt at få fastslået om andelen af HTML er tilstrækkelig stor i forhold til andre data. Desuden er forholdet mellem statiske og dynamiske sider yderligere interessant fordi det kan have stor betydning for hvor meget regnekraft udbyderen skal have til rådighed hvis komprimeringsalgoritmen viser sig at være relativ langsom. 3 Den kaldes også MS-Stac, da den angiveligt er udviklet af Microsoft 13
Kapitel 3: Behovsanalyse 3.2.1 Undersøgelse af datasammensætning Analysen for udbydersiden bygger på en logfil fra serverprogrammet på www. it-avisen.dk, se tabel 3.3, der repræsenterer et typisk nyhedssted. datatype mængde (Mb) andel (%) HTML 2424.77 63,4 billeder 1399.53 36,6 Tabel 3.3: 11 dages logfil fra www.it-avisen.dk Det ses at andelen af websider i forhold til billeder er 63%, dvs. at der kunne være en del at hente ved at komprimere. Det viste sig at IT-Avisen udelukkende har dynamiske sider. Til gengæld er alt indholdet dynamiske sider så man kan ikke komme uden om at komprimere løbende. Fordelingen af filstørrelser for IT-Avisen fremgår på figur 3.2. Det ses at en stor del af websiderne som ved brugersiden er mindre end 10 kb, men til gengæld er der to toppe mellem 20 og 30 kb der samlet kan ses at stå for omtrent 25% af filerne. 60 50 html % andel 40 30 20 10 0 0 5 10 15 20 25 filstørrelse kb 30 35 40 Figur 3.2: Fordelingen af filstørrelser for IT-Avisen. Spørgsmålet er om tallene fra IT-Avisen er typiske for alle udbydere. Det kan kun afklares ved yderligere undersøgelser af andre udbydere, men desværre er det ikke helt let at få udleveret logfilerne, og vi har derfor været afskåret fra det. Umiddelbart ser siderne hos IT-Avisen typiske ud; Men er altså ikke nødvendigvis repræsentative. 14
Kapitel 3: Behovsanalyse 3.3 Sammenfatning Fra brugernes synspunkt skal en gevinst komme fra en hastighedsforbedring brugeren skal kunne skære ned på den tid vedkommende skal vente før en side dukker op i browseren. At der faktisk er mulighed for en gevinst forudsat en passende kompressionsmetode, dokumenteres af undersøgelsen af datasammensætningen der viser at en betragtelig del af de overførte data er websider. Samtidig viser hastighedstesten at der faktisk er noget tid at afkorte idet analoge modemer, som flertallet i danmark har, kan give ventetider på 5-10 sekunder for middelstore sider. Til gengæld udhuler testen af eksisterende kompression i modemer og i forbindelse med ISDN-linjer dog dette noget, også selvom den ikke er nær så effektiv som det et almindeligt program kan klare. For udbydersiden er der penge at spare i at begrænse mængden af overført data; tabel 3.4 viser et eksempel på priserne for diverse hastigheder for en fast internetforbindelse hos Cybercity [5]. Hvis man antager at kompression kan reducere datamængden for HTML til, kan halvdelen af webtrafikken spares, hvad der, som det ses i tabellen, næsten kan halvere udgifterne til internetforbindelsen. hastighed årspris (kr.) 256 kbit 30.000 512 kbit 35.000 1 Mbit 40.000 2 Mbit 70.000 4 Mbit 110.000 8 Mbit 180.000 Tabel 3.4: Priseksempel fra Cybercity Erhverv Med hensyn til krav til kompressionsmetoden har undersøgelserne af datasammensætningen vist at andelen af dynamiske sider i forhold til statiske er så stor at der er behov for en metode der også kan bruges på dynamiske sider for udbyderne kan dette betyde større krav til servernes beregningskraft fordi denne må foregå løbende, statiske sider ville bare kunne komprimeres en gang for alle, men når de i forvejen har investeret en del i den for at kunne omsætte de dynamiske sider til HTML, er det muligvis relativt billigt at foretage den fornødne udvidelse. Desuden er en stor del af websiderne ret små, dvs. under 10 kb, så medmindre metoden også er effektiv på små filer, kan en del af gevinsten forsvinde (mindre filer fylder dog ikke så meget så de udgør forholdsmæssigt mindre af den samlede datamængde). Kravene til en kompressionsalgoritme er altså at den er effektiv på HTML-sider kan bruges i forbindelse med dynamiske sider 15
Kapitel 3: Behovsanalyse ikke er for beregningskrævende, dvs. er hurtig til at komprimere og dekomprimere er god til små såvel som store filer Nogle af disse krav kan være i konflikt med hinanden så en given algoritmes egenskaber må afhænge af en afvejning. Når potentialet for en kompressionløsning og nogle krav til den således er blevet fastslået, kan vi gå over til at definere selve kompressionsbegrebet, først fra en teoretisk synspunkt i form af begrebet informationsteori. 16
Kapitel 4 Informationsteori Informationsindholdet er som nævnt i indledningen ikke nødvendigvis lig med størrelsen af data. Hvordan finder man da ud af hvor meget information der er i en given mængde data? En måde at gribe problemet an på er at stille en række ja/nej-spørgsmål om dataene er det næste tegn et bogstav? Er det et stort bogstav? Er det et a? Er det et b? Et ja eller et nej kan opfattes som enten et 0 eller et 1 så rækken af svar bliver til en binær streng. Hvis vi opfatter dataene som adskilte tegn, kan målet for information være det gennemsnitlige antal af spørgsmål, svarende til den gennemsnitlige længde af de binære strenge, der er nødvendige for at kunne identificere hvert tegn. Antallet af nødvendige spørgsmål afhænger imidlertid af sandsynlighederne for de enkelte udfald; hvis et givent udfald var meget sandsynligt kunne det jo f.eks. godt betale sig at starte med at spørge direkte efter netop det udfald, mens hvis modsat alle udfald var omtrent lige sandsynlige, kunne det bedst betale sig at spørge om det konkrete udfald var et fra den ene halvdel af udfaldene så fik man hurtigst muligt indkredset det. 4.1 Entropi Antallet af nødvendige spørgsmål til et meget sandsynligt udfald er altså mindre end for et med en lille sandsynlighed, hvilket kan opfattes som at informationsindholdet for det første udfald er mindre end for det andet. Dette forhold kan opnås matematisk ved at definere informationsindholdet for et givent udfald som [17, s. 14] hvor er et udfald for en diskret stokastisk variabel og sandsynligheden for at udfaldet optræder (vi benytter herefter en kortere notation hvor ). Her er benyttet totalslogaritmen hvad der giver resultatet i bit, 17
Kapitel 4: Informationsteori andre logaritmer giver en anden enhed der dog kun afviger fra bit-enheden med en konstant faktor [4, s. 14]. Før vi kan fortsætte, skal vi have definitionen af et alfabet på plads. Et alfabet er mængden af forskellige symboler som en algoritme kan finde i en given mængde data; f.eks. kan abccba repræsenteres vha. alfabetet, men det kan også repræsenteres vha.. For en given diskret stokastisk variabel hvis udfaldsrum er alfabetet, og hvis udfald er bestemt af sandsynlighedsfordelingsfunktionen, definerer man så entropien som den forventede middelværdi af informationsindholdene for alle udfaldene [4, s. 13]: Tag som et eksempel den stokastiske variabel i tabel 4.1 som bygger på tegnfølgen aaabbcbcbcababaa med alfabetet. Ud fra sandsynlighedsfordelingen kan entropien beregnes til "! "! # %$ &! $ (' *)+,).- a b c $ Tabel 4.1: Frekvensfordeling med alfabetet / 0 Hvis man betragter tegnfølgen, ses det at vi også kan bruge alfabetet da a, b og c kun optræder i denne rækkefølge. Hvis man gør det, bliver entropien i stedet 21 3&! &1 3 $ 34! $ 3 $ 3"! 3 $ 5' *).6'87 Entropien afhænger altså hvordan man vælger sit alfabet. Ved at vælge et med blokke af to tegn, har vi næsten halveret entropien 1,505 bit pr. symbol mod 1,561 bit pr. to datategn svarende til 0,7807 bit pr. datategn. 4.2 Egenskaber ved entropi Man kan bevise nogle interessante træk ved det er faktisk disse egenskaber der gør at entropi er et nyttigt begreb at beskæftige sig med. Sætningerne vil ikke blive bevist her, da en udtømmende bevisførelse ikke er relevant for projektet som helhed. 18
Kapitel 4: Informationsteori 4.2.1 Optimal kodning Når man skal vælge et alfabet og dets repræsentation i form af kodeord, gælder det naturligvis om at kodeordene resulterer i den kortest mulige tekst når de bliver sat sammen til den komprimerede tekst. Der er eksisterer altså optimale koder der giver et bedre kompressionsforhold end alle andre koder på en given mængde data. Hvis er længderne af de optimale kodeord for en stokastisk variabel med sandsynlighedsfordelingen, og er den forventede længde af den optimale kode ( ), gælder så [4, s. 86 88] ' Det vil sige at den mindste mængde data man kan bruge til at repræsentere et tegn, ligger inden for én bit af entropien af dataene. Vi kan presse dataene ned til, men så heller ikke længere. At det optimale ligger inden for én bit og ikke er mindre, hænger sammen med at der er et vist spild hvis entropien ikke giver et helt tal vi kan ikke sende halve bit. Dette problem kan formindskes ved at kode større blokke af gangen så spildet bliver spredt ud på flere tegn og dermed samlet bliver mindre. 4.2.2 Maksimal entropi ved ligelig fordeling Hvis er antallet af udfald i fordelingen for, opnås den maksimale entropi hvis sandsynlighederne for udfaldene er ens ( ), og har værdien [4, s. 27]. Hvis f.eks. kan antage 256 værdier med lige stor sandsynlighed, er entropien -.).6 bit. Hvis der er forskel på sandsynlighederne, bliver entropien mindre end 8 bit. Denne egenskab fortæller noget om hvorfor almindelige data normalt kan komprimeres. Hvis en tegnfølge er genereret helt tilfældigt, vil de forskellige værdier naturligvis optræde med nogenlunde samme sandsynlighed hvis man betragter en tilstrækkeligt stor datamængde det vil sige at entropien for sådan en tegnfølge vil ligge lige omkring en almindelig repræsentation af tegnene hvor man bruger et fast antal bit, altså kan disse ikke komprimeres. For data der ikke er genereret helt tilfældigt, vil der derimod som regel være en struktur der gør at nogle ting går igen mange gange. F.eks. optræder e meget hyppigere end z i en almindelig dansk tekst, og dermed bliver entropien mindre. Det kan virke mærkeligt at helt tilfældige data indeholder mere information end omhyggeligt udformede, menneskeskabte data, men den menneskelige bearbejdningsproces er jo netop gået ud på at sortere og ordne dataene. En større orden giver færre muligheder, og gør det muligt at forudsige data. 4.2.3 Afhængigheder reducerer entropi I almindelig tekst optræder tegnene med en vis indbyrdes afhængighed. Hvis f.eks. bogstaverne b ld står i en dansk tekst, er der en meget stor sandsynlighed for 19
Kapitel 4: Informationsteori at enten er et o eller et y. Det viser sig at indbyrdes afhængigheder mellem tegnene forårsager at entropien reduceres. Først er der dog brug for at få defineret fælles entropi og betinget entropi. Den fælles entropi for to diskrete stokastiske variable med den fælles sandsynlighedsfordeling er defineret som [4, s. 15] mens den betingede entropi er defineret som hvor vi har benyttet definitionen for entropi og skrevet lidt om. Den fælles entropi kan vha. en kæderegel udvides til at opfatte flere variable med fælles fordeling. Man kan da bevise [4, s. 27 28] at for to afhængige stokastiske variable og med en fælles sandsynlighedsfordeling udfaldet af er kendt, være mindre end entropien for blot :, vil entropien for givet at Det kan bl.a. bevises at have den følge at entropien for en blok af tegn altid vil være mindre end (eller evt. lig med) de sammenlagte entropier for de enkelte tegn Eksemplet fra afsnit 4.1 hvor entropien blev halveret ved at vælge et alfabet med blokke af to tegn, illustrerer dette. Ud fra denne egenskab fås yderligere en begrundelse for at f.eks. almindelig tekst kan komprimeres. Den struktur, der er i menneskeskabte data, gør at sandsynligheden for at et tegn optræder, afhænger meget af konteksten. Denne afhængighed formindsker entropien hvis ens model af dataene er i stand til at tage hensyn til den, f.eks. ved at arbejde på blokke af tegn i stedet for kun enkelte. 4.3 Komprimering og entropi og ' er mulig at konstruere (endda ret simpelt, en algoritme til at gøre det Man kan faktisk vise at en optimal kode der ligger inden for grænserne præsenteres i afnit 5.1.2), men som det også ses er der forskellige måder man kan 20
Kapitel 4: Informationsteori formindske datamængden yderligere på. Alt afhængig af hvordan man vælger sit alfabet, repræsenteret ved den stokastiske variabel, kan nemlig variere. For at optimere kompressionsforholdet gælder det altså om at vælge en model der passer til dataene. Hvis modellen har som en grundlæggende antagelse at hvert tegn er helt uafhængigt af det foregående, mister man en mulig gevinst hvis hvert tegn faktisk afhænger til en vis udstrækning af sin forgænger i de data man benytter modellen på. Med de ovennævnte egenskaber kan vi allerede se at det kan være en fordel at slå flere tegn sammen fordi man så dels kan udnytte afhængigheder mellem tegnene, afhængigheder der kommer fra den underliggende datastruktur; dels kan reducere det spild der opstår i forbindelse med generering af kodeordene. For at få en fornemmelse af hvordan informationsindholdet i HTML-filer udmønter sig, beskæftiger vi os i det følgende lidt med deres struktur. 4.3.1 HTML, informationsteoretisk set HTML består af bidder af almindelig tekst omgivet af opmærkninger, tags, af hvilke kun et vist antal er gyldige, f.eks. <P> eller <TABLE>. Simple tags som de nævnte er hyppige og indeholder kun lidt information. Imidlertid kan de fleste tags også tage parametre, f.eks. <a href= fil.html >, og da indholdet af parametrene ikke er begrænset på nogen måde, kan den form for opmærkninger besidde et større informationsindhold. Tags uden parametre kan altså teoretisk komprimeres rigtigt meget, mens vi ikke kan forvente at kunne komprimere de andre tags så meget medmindre de optræder flere gange i HTML-filen. Ud over opmærkningen er der også den almindelige tekst. Kompressionen af denne kan være meget effektiv fordi bogstaverne i almindelig tekst som før nævnt afhænger meget af hinanden. Desuden kan vi spare på alfabetet fordi f.eks. almindelig dansk tekst kun består af typisk omkring 26 bogstaver samt nogle få symboler som bindestreg, komma og punktum så alfabetet med stor sandsynlighed vil holde sig på under 64 forskellige tegn. Dvs. at vi umiddelbart, uden at være overdrevent sofistikerede, kan spare 2 bit for hvert tegn. Et af de teoretiske udledte resultater er at en skæv frekvensfordeling giver en mindre entropi end en ligelig, hvorfor vi har undersøgt frekvensfordelingen for tegnene på vores udvalgte sider (beskrevet i afsnit B.1), se figur 4.1 på næste side. Figuren viser at fordelingen faktisk ikke er ligelig. Men derimod er den overraskende ens i de forskellige filer. Den eneste tydelige forskel er højden på toppen omkring 32 som svarer til ASCII-koden for mellemrum, hvilket kan skyldes forskellige måder at indrykke HTML-filerne på. Med et almindeligt kompressionsprogram i hånden kan man hurtigt overbevise sig om at HTML kan komprimeres meget, og dette støttes af de ovenstående observationer. Frekvensfordelingernes ensartethed antyder at HTML-filerne vil ligge meget lige mht. kompressionsforholdet og tyder desuden på at der kan spares data. Hvor meget der kan komprimeres varierer naturligvis lidt med skrivestil, opsæt- 21
Kapitel 4: Informationsteori frekvens 45 40 35 30 25 20 15 Carlsberg ITL IT-Avisen Jyllandsposten Jubii The Voice 10 5 0 0 50 100 tegn 150 200 250 Figur 4.1: Frekvensfordeling for tegnene (repræsenteret ved deres kode ifølge kodningen ISO-8859-1) på vores udvalgte sider ning, mængden af opmærkninger, den valgte algoritmes styrker osv., men alt i alt viser vores overvejelser et stort potentiale for kompression. På baggrund af dette undersøger vi herefter nogle algoritmer der kan bruges til at komprimere HTML-filerne. 22
Kapitel 5 Analyse af kompressionsmetoder Der findes to grundlæggende forskellige metoder at komprimere på. Den statistiske, der baserer sin kompression på statistisk analyse af data, og den ordbogsbaserede, der opretholder en ordbog over gentagne mønstre i data. Under de statistiske metoder undersøger vi Huffman-koder og aritmetiske koder som er klassiske metoder indenfor kompression. Grundideen i statistiske kompressionsmetoder er at symboler der bruges tit, ikke skal beskrives med lige så meget data som symboler der bruges sjældent. Altså at de skal beskrives med værdien af deres entropi. Første eksempel på denne form for kompression finder vi i midten af 1800- tallet takket være Samuel Morses alfabet [17]. Han opdagede nemlig at man kunne spare tid i transmission af beskeder, og dermed også kunne opnå en form for kompression, ved at tildele hyppigt anvendte bogstaver som e korte kodeord. For at kunne udtale sig om hyppighed bliver man nødt til at finde eller estimere frekvenser for disse symboler. Jo tættere disse symbolsandsynligheder ligger på de faktiske forhold i dataene, jo bedre kan der komprimeres man kan vha. informationsteori bevise at man så kommer tættere på entropien [4]. Under de ordbogsbaserede metoder undersøger vi de klassiske Lempel-Ziv 77 og Lempel-Ziv 78, samt populære varianter her af. Disse kompressionsmetoder blev udviklet i 1970erne af de to forskere Jacob Ziv og Abraham Lempel [16] (navnene fik de efter de respektive årstal de blev udviklet i). De to metoder varierer på den måde de laver deres henvisninger til ordbogen, og på deres måde at opretholde denne. Ordbogen i de ordbogsbaserede komprimeringsmetoder er en liste over ofte forekomne tegnfølger i dataene; metoderne arbejder nemlig ikke kun med enkelte symboler, men med mønstre som dækker flere tegn. Ideen er så at erstatte mønstre af variable længder med kodeord af faste længder, omvendt statistiske metoder hvor symbolerne har faste størrelser og koderne variable længder. Ud over disse metoder undersøger vi også en transformation der kan gøre metoderne mere effektive. Den transformation vi ser på, går under navnet Burrows- Wheeler-transformationen og bruges ofte sammen med kodningsprincippet move- 23
Kapitel 5: Analyse af kompressionsmetoder to-front. Ideen er at transformationen ændrer dataene på en sådan måde at de slutteligt kan komprimeres bedre også selvom der kræves lidt mere data undervejs til at holde styr på transformationen for at gøre den reversibel. Burrows-Wheeler-transformationen kan anvendes på alle former for data, men den stiller dog et krav om at de skal kunne deles op i blokke. Move-to-frontkodning er kun effektiv at bruge på specielle data hvor ens symboler ligger i nærheden af hinanden. Sådanne data er netop det Burrows-Wheeler-transformationen producerer. Alle disse komprimeringsmetoder kan bruges på HTML-filer. I vores gennemgang af metoderne tager vi udgangspunkt i det samme eksempel: <HTML><body><p>Test af en HTML-side</p></body></HTML> Dette er ikke for at kunne sammenligne metodernes effektivitet, men for at gøre det lettere at se forskellen i deres virkemåde. Eksemplet er på 53 tegn, inklusive mellemrum, og består af symbolerne {<, >, -, /,, a, b, d, e, f, H, i, L, M, n, o, p, s, T, t, y} som altså udgør vores alfabet. Ukomprimeret vil dette eksempel sædvanligvis optage 8 bit pr. symbol, eller! ).7 - bit i alt. Med den antagelse at hvert tegn er uafhængigt af de andre, er entropien på 4,18 bit pr. symbol så der er plads til forbedringer. Vi vil nu undersøge hvor godt Huffman klarer det. 5.1 Statistiske metoder 5.1.1 Præfikskoder Før beskrivelsen af Huffman-kodning introducerer vi præfikskoder da Huffmankodning netop danner præfikskoder. En præfikskode er en kode som har den egenskab at inget kodeord er et præfiks i noget andet kodeord. Det vil sige at ingen lange kodeord begynder med samme talsekvens som nogle af de andre kortere kodeord. Antag at a har koden 0, b koden 10 og c koden 11. Så ses det at man uden at kende længden af koden umiddelbart kan se hvilken kode man skal vælge. Hvis man f.eks. skriver 00, ved vi at dette betyder aa. 0 1 a 0 1 b c Figur 5.1: Kodeordene illustreret ved et binært træ 24
Kapitel 5: Analyse af kompressionsmetoder Koderne kan vises som et binært træ som i figur 5.1 på forrige side hvor bladene svarer til symbolerne det kan man gøre med alle præfikskoder. Hvis vi så har fået sendt bitrækken 00100111001111, kan vi ved hjælp af træet entydigt afkode den oprindelige tekst: 0 0 10 0 11 10 0 11 11 a a b a c b a c c Den afkodede tekst fylder! bit, mens bitrækken kun optager 14 bit. Det hænger sammen med at vi kun har 3 symboler i vores alfabet, og vi kan dermed nøjes med 2 bit til hver for at beskrive dem entydigt. Præfikskoderne gør det muligt at bruge forskellige længder kode til at beskrive vores symboler med, og i vores ' *6.6 eksempel beskrives hvert symbol med bit pr. symbol i gennemsnit. Men hvordan laver vi vores træ optimalt? Dette svar ligger i Huffman-kodning. 5.1.2 Huffman Huffman-kodning er udviklet af David Huffman i 1950 erne [16], deraf navnet, og efterfulgte Shannon-Fano-kodning som var udviklet af Shannon, Weaver og Fano. Shannon-Fano-algoritmen komprimerer ikke så godt som Huffman, selvom dens operationer ligner. Huffmans metode går ud på at finde frekvenser for symbolerne i dataene og derefter oprette en træstruktur hvori man indsætter disse symboler ud fra deres frekvens. Herefter kan man ved hjælp af træet let udlede et kodeord med forskellige antal bit til hvert symbol. For at lave dette træ starter vi med at tage de to symboler med lavest frekvens og erstatte dem med et fælles, kombineret symbol. Dette symbol tildeles frekvensen svarende til summen af frekvenserne for de to symboler. Herefter indgår igen i mængden af symboler til næste iteration af algoritmen hvor bliver fundet. Dette fortsætter til der kun er ét symbol tilbage. Vha. -metasymbolerne kan vi så generere træet. Eksempel Vi illustrerer Huffman-metoden ved hjælp af vores eksempel. <HTML><body><p>Test af en HTML-side</p></body></HTML>, hvor er et symbol fra, altså hvert symbols frekvens. Den findes ved at tælle forekomster af de enkelte symboler og dividere dem med længden af teksten. Resultatet ses i tabel 5.1 på næste side. Her har vi samtidig sorteret tabellen efter frekvens. Først skal vi finde Huffmantræet Vi kan nu gå i gang med at danne Huffman-træet ved at finde de to symboler med mindste frekvens, altså n og t. Disse to symboler beskrives samlet som, og dette danner så den første del af træet, se figur 5.2 på den følgende side. 25
Kapitel 5: Analyse af kompressionsmetoder Symbol < > T / d e Forekomster 6 6 4 3 3 3 3 0,1132 0,1132 0,0754 0,0566 0,056 0,0566 0,0566 Symbol H L M b o p s Forekomster 3 3 3 2 2 2 2 0,0566 0,0566 0,0566 0,0377 0,0377 0,0377 0,0377 Symbol y - a f i n t Forekomster 2 1 1 1 1 1 1 0,0377 0,0188 0,0188 0,0188 0,0188 0,0188 0,0188 Tabel 5.1: Tabel over frekvenser C1 n t Figur 5.2: -delen af Huffman-træet optræder nu med den sammenlagte frekvens for n og t og anbringes i skemaet i stedet for de to. Bemærk at placeres så højt i skemaet som dens frekvens tillader, det vil i dette tilfælde sige lige efter M. Se tabel 5.2 Symbol < > T / d e Forekomster 6 6 4 3 3 3 3 0,1132 0,1132 0,0754 0,0566 0,0566 0,0566 0,0566 Symbol H L M b o p Forekomster 3 3 3 2 2 2 2 0,0566 0,0566 0,0566 0,0377 0,0377 0,0377 0,0377 Symbol s y - a f i Forekomster 2 2 1 1 1 1 0,0377 0,0377 0,0188 0,0188 0,0188 0,0188 Tabel 5.2: Første skridt i Huffman-algoritmen Herefter finder vi igen de to mindst sandsynlige tegn i skemaet. På denne måde danner vi op til, se figur 5.3 på den følgende side. Det nye skema ses i tabel 5.3 på næste side. I næste skridt skal vi kombinere og b. Dette foregår på samme måde som hvis havde været et enkelt symbol. Frekvenserne lægges sammen og det nye symbol skal anbringes i skemaet. består af b og og dette gør træet dybere, som det ses på figur 5.4. Vi fortsætter nu på samme måde indtil der kun er ét kombineret symbol til- 26
Kapitel 5: Analyse af kompressionsmetoder C5 C4 C3 C2 C1 1 0 o p s y - a f i n t Figur 5.3: Huffman-træet med,,, og Symbol < > T / Forekomster 6 6 4 4 4 3 3 0,1132 0,1132 0,0754 0,0754 0,0754 0,0566 0,0566 Symbol d e H L M Forekomster 3 3 3 3 3 2 2 0,0566 0,0566 0,0566 0,0566 0,0566 0,0377 0,0377 Symbol b Forekomster 2 2 0,0377 0,0377 Tabel 5.3: Andet skridt i Huffman-algoritmen Symbol < > T / Forekomster 6 6 4 4 4 4 3 0,1132 0,1132 0,0754 0,0754 0,0754 0,0754 0,0566 Symbol d e H L M Forekomster 3 3 3 3 3 3 2 0,0566 0,0566 0,0566 0,0566 0,0566 0,0566 0,0377 Symbol Forekomster 2 0,0377 Tabel 5.4: Tredje skridt i Huffman-algoritmen C6 C5 C4 C3 C2 C1 b o p s y - a f i 1 n 0 t Figur 5.4: Træet bliver dybere med 27
Kapitel 5: Analyse af kompressionsmetoder bage 1. Dette symbol vil have frekvensen 1 da det består af alle symbolerne i dataene. Det færdige træ kommer således til syne i figur 5.5 (hvor et mellemrum skrives ). C20 C19 C18 C17 C16 C15 C14 C13 C12 C11 C10 C9 C8 < > C7 C6 C5 C4 T / " " d e H L M 1 0 C3 C2 C1 b o p s y 1 0 - a f i n t Figur 5.5: Det færdige Huffman-træ Nu kan vi danne koderne for hvert symbol ud fra træet. For at finde koden skal man blot følge grenene ud til symbolet og nedskrive de enkelte nuller eller et-taller på vejen. Eksempelvis bliver koden for > til 000 og koden for t bliver 111010. Bemærk at vores kombinerede symboler - ikke længere har nogen betydning. Symbol Kode Symbol Kode > 000 < 001 M 0100 L 0101 H 0110 e 0111 d 1000 1001 / 1010 T 1011 y 11000 s 11001 p 11010 o 11011 b 11100 t 111010 n 111011 i 111100 f 111101 a 111110-111111 Nu kan vi skrive vores oprindelige tekst som følgende bitstreng: 1 Se eventuelt disse skridt i bilag A.1.1 på side 65 28