Tall og Format i Internett

Transkript

1 Tall og Format i Internett Ketil Danielsen ketil.danielsen@himolde.no September 7, 2006 Det ble tidligere sagt at de binære tall (0 og 1) er basis i lagring og overføring av informasjon i datasystemer og datanett. Maskinen arbeider med binære tall og IT-fagfolk snakker om desimale tall, av og til heksadesimale eller oktale tall. Dette notatet gir en innføring i digital representasjon med Internettfrakt som utgangspunkt. Verdirom I det desimale tallsystem, titalls-systemet, har vi 10 mulige verdier for et siffer: 0, 1, 2, 3, 4, 5, 6, 7, 8 og 9. Med to siffer har vi 100 mulige verdier : Generelt sett: Med k siffer har vi 10 k mulige verdier. Og, enda mer generelt: Hvis det er b mulige tall per siffer, som for eksempel b = 10 i det desimale tallsystem, ja, da er det b k mulige verdier med k siffer. Datamaskiner arbeider med totalls-systemet, der b = 2. De eneste mulige tall er 0 og 1. Én enkelt bit er et sted som kan romme verdiene 0 eller 1 (21 = 2 mulige verdier). To bit kan romme verdiene 00, 01, 10 eller 11 (2 2 = 4 mulige). Tre bit kan romme verdiene 000, 001, 010, 011, 100, 101, 110 eller 111 (2 3 = 8 mulige). Og, k bit kan romme 2 k mulige verdier. Derfor sa vi om Internettfrakt, at med 8 bit Type of Service (TOS) i IP s pakkehode, kunne vi faktisk ha romme 2 8 = 256 ulike verdier. Mer spesifikt ville det være verdiene fra til i totalls-systemet, eller 0 til 255 i titalls-systemet. Sålangt er lite sagt om hvordan vi regner om et binært tall til et desimalt. Hvorfor blir i binær fasong, 255 i desimal fasong, for eksempel? Vi begynner med det enkleste, og antar at vi har en bitposisjon tilgjengelig, at k = 1. Her er 0 2 = 0 10 og 1 2 = Med slik subscript (nedtrekt i lavere font) indikeres hvilket tallsystem tallet er vist i. Omregning til desimalt For k = 2 var de mulige verdier 00, 01, 10 og Hvorfor disse skrives desimalt som 0, 1, 2 og 3 er problemet for de fleste som leser dette. 2 Reglene for omreg- 1 Notatet vil tidvis skrive tallsystemets base som subscript til tallet, for eksempel 00 2, 01 2, 10 2 og En handsopprekning viste at 5 av 30 hadde arbeidet med totalls-system fra VGS. 1

2 ning fra et annet tallsystem, til det desimale system (ikke andre veien) er at en tar summen av hvert siffer, etter at sifferet er mulitiplisert med tallsystemets base b opphøyd i p, der p er sifferets posisjon. Dette var tungt sagt, men lettere illustrert. For binære tall er b = 2, for desimale tall er b = 10 (for oktale tall er b = 8 og for heksadesimale tall er b = 16, men disse diskuteres ikke enda). Vi regner om tallet 10 2 fra det binære til det desimale som følger. Det er to siffer i posisjon 0 og 1, henholdsvis. I posisjon 0 (lengst til høyre) står en 0, og i posisjon 1 (nest lengst til høyre står en 1). Den desimale versjon av tallet er da Et litt lengre tall er som blir 10 2 = = = = = = Det er viktig å kunne potensrekka for 2, med andre ord, hvis en skal drive med mye slik omregning. I relasjon til TOS-feltet: Når en bare har fire bit igjen, etter at de fire første er gitt bort til flagging av kvalitetsønske: Hvilke verdier kan en angi med fire bit hvis en får ha de til et spesielt formål? Laveste verdi er som blir 0 10, høyeste er som blir 15 10, da = = = Tidligere ble det sagt at k = 4 bit ga 2 k = 2 4 = 16 mulige mulige verdier. Vel, disse mulige verdiene er da desimale 0, 1, , 15 og ikke rekka fra 1 til 16. Senere vil notatet komme tilbake til hvordan dette feltet faktisk har blitt brukt opp gjennom tidene. I det heksadesimale tallsystem er det 16 mulige verdier som vi konsumerer 4 bit for å representere. I det oktale er det 8 mulige, og vi trenger bare 3 bit til representasjon av hvert oktale tall. I tabellen under kan en ane et system i bitvariasjonene etterhvert som det desimale tallet stiger, 2

3 desimal binær heksa oktal b = 10 b = 2 b = 16 b = A B C D E F I tabellen er det ikke tatt med innledende null er, men de kunne godt legges til for å sikre at tallene blir like lange. Det endrer ikke verdien og er ikke viktig. Adressefelt I dette avsnittet diskuteres regning med IP-adressene, disse som ble introdusert tidligere som 32 bit og blant annet figurerer i IP-pakkenes felt for avsender og mottaker. Det viktigste med en IP-adresse er at ruterne kan bruke den til sitt viktigste arbeid, nemlig styring av pakker langs en (eller flere) korteste vei(er) mot mottaker (unicast) eller mottakere (multicast). Mottakeren er en innlink i en maskin, og adressen til denne er gitt av den som disponerer det aktuelle adresserommet for den organisasjonen, der maskinen befinner seg. Adresserommet er tildelt av en annen organisasjon lenger opp i hierarkiet for adresseforvaltning i Internettet. Som eksempel om forvaltningen kan nevnes at labnettet har et lite adresserom tildelt av IT-senteret ved skolen. Hver maskin i labnettet har en link inn i Internettet, og denne skal ha egen IP-adresse. Dette er ett av flere adresserom skolen disponerer, og som er gitt til skolen av det nasjonale akademiske nett, Uninett. Og, til sist har Uninett blitt tildelt ett sett med ganske store adresserom til intern fordeling blant norske skoler. Hvis labnettet legges ned kan adresserommet gjenbrukes til dekning av nye lokale behov. Hvis labnettet blir for lite, kan det kompletteres med flere ledige adresserom (hvis det finnes). Og, labnettet kan deles inn i flere undernett, noe som kalles subnetting, og blir sentralt etterhvert i diskusjonen om adressering. 3

4 Men, hensikten er relasjon til tallsystemer, og da kan en begynne med IPadressenes gruppering inn i fem hovedgrupper: A, B, C, D og E. Labnettet er et rom med sammenhengende adresser, alle er B-adresse som en ser av de tre initielle bit i adressen som er 10. Resten av adressen er 30 bit og er todelt: NettID og vertsid. Ruterne vil videresende en pakke etter hvilken NettID, bortsett fra siste ruter (som ligger i mottakerens nett) som leverer direkte etter mottakeradressens vertsid. klasse prefix type nett nettid hostid A 0 store 7 24 B 10 mellomstore C 110 mindre 21 8 D 1110 multicast - - E 1111 eksperimentell - - Labnettet er i dotted decimal notation (DDN) /25, det vil si at de 25 initielle bit er nett, og de syv siste er vertsid. Dette er settingen for hvordan omregning fra desimalt utføres. Omregning fra desimalt Generelt sett (og tungt forklart) er overgangen fra desimalt slik at en skal finne hvilket tall som skal inn i alle sifferposisjoner i det nye tallet. Restverdien utsettes for en heltalls-divisjon med b k inntil en har null i rest. Det siffer som skal inn i posisjon k i det nye tallet er resultatet av heltalls-divisjonen (se illustrasjons-tabell under). En av maskinene er , som har binær verdi utledet under. I tabellen vises omregningen av 158, og dette er fra desimal til to-tallssystemet (binær), derfor er b = 2 i divisorkolonnen. Senere skal vi ta overgangen mot oktale (b = 8) og heksadesimale tallsystem (b = 16). 4

5 posisjon desimal b k = verdi i posisjon k (k) rest 2 k i binærtall / 128 = / 64 = / 32 = / 16 = / 8 = / 4 = / 2 = / 1 = 0-0 Merk, at tegnet for heltalls-divisjon er skråtegnet (slash). Resultatet er kun heltallsdelen, og desimalene er utelatt. De første 8 bit av de 32 bit i numerisk IP-adresse blir da: = De tre siste oktettene (8 bit kalles oktett, et annet navn er det mye mer kjente Byte) finner vi ut med en kalkulator, for eksempel calc.exe i Windows: = = , = = , og = Tabellen under viser helheten: Det er de initielle bit som avdekker adressens klasse: 10 betyr klasse B. Hvis vi tar samme 158 og lager oktal representasjon blir gangen: posisjon desimal b k = verdi i posisjon k (k) rest 8 k i oktaltall / 64 = / 8 = / 1 = 6-6 Vi sier at = Tilsist vises at = 9C 16. 5

6 posisjon desimal b k = verdi i posisjon k (k) rest 16 k i heksatall / 256 = / 16 = / 1 = C -14 I en aktuell pakkefanger (sniffer) vises avsenderadresse for en utsendt HTTPpakke heksadesimalt: 9e (store og små bokstaver er likeverdige). Her vil 9e representere 8 bit, der 9 er 1001 og e er I tabellen under vises hele oversettingen til 2-tallssystemet. Merk, at prefix 0x denne gang er brukt for heksadesimale tall, og er heller ikke uvanlig notasjon: 0x9e 0x26 0x52 0x En noterer seg at her dreier det seg om en annen maskin med annen IP-adresse enn den som ble eksemplifisert tidligere. Uansett, tilsammen er det 32 bit. Desimal versjon er vist i tredje linje, og merk at en her beveger seg fra totallssystemet til 10-tallssystemet, motsatt av prosedyren over. I tabellen under vises oversettelsen av siste oktett: posisjon verdi i posisjon k b k = (k) i binærtall 2 k = = = = = = = = 1 = 89 Et datasystem er fullt av adresser av ulike typer og lengder. En annen type adresse som ofte helst vises heksadesimalt, fordi den er lang (48 bit) er hardwareadressen. Ethernet-adresse skrives vanligvis for eksempel 00:b0:d0:20:da:59 som tilsvarer 12 heksadesimale tall, som igjen (fordi ett heksadesimalt tall trenger 4 bit) summerer til 48 bit. Adressen skrives av og til 0x00b0d020da59 uten at det blir lettere av den grunn. Men, det er lettere enn om 2-tallssystemet ble brukt. Varierende definisjon og bruk Hittil har vi brukt TOS-feltet som eksempel i arbeidet med å lære om tall og formater i Internett, og egentlig i datasystemer generelt. Og, det ble sagt at 6

7 TOS-feltet er et fast sted i IP-pakkens hode, der avsender kan si hvilken kvalitet som ønskes i befraktningen. I dette avsnittet sies litt om posisjonering av bits i et større avsatt felt, altså noe om formatet i et pakkehode. Diskusjonen er basert på RFC3168 som er fra September 2001, og omhandler alternative bruksområder for dette 8-bits felt. I praksis har støtten for TOS-feltet i Internettet vært svært varierende, og egentlig skuffende. Det vil si at uansett hvor mye senderne markerer sine ønsker, er det usikkert om noen internt i nettet egentlig tar hensyn til dette. I den senere tid har andre initiativ til modernisering av IP tatt i bruk TOS-feltet til andre formål, og tatt utgangspunkt i at dagens TOS-bruk er død, og vi må se om vi kan bruke det på andre måter. Det var RFC791 som definerte TOS-feltet, og det ble satt opp et 8-bits felt der bitposisjonene var benevnt b0, b1... b7. I RFC791 var b0-b2 avsatt til presedens, b3-b5 til TOS og b6-b7 udefinert (til fremtidig bruk). I RFC1122 ble b6-b7 tatt med i TOS-gruppen som nå inkluderte b3-b7. I RFC1349 ble siste bit (b7) tatt ut av TOS-gruppen og erklært som MBZ (must be zero); i realiteten avsatt til fremtidige formål. Differentiated Services Midt på 90-tallet begynte eksperimentering med Differentiated Services (DS) som skulle gi ulike klasser ulik betjening i ruterne. I essens ville dette bety at man kunne gi en slags garanti for et minimum av ressurstilgang for en gitt klasse, en forbedring fra det å gi alle samme leveringsforhold. I DS må avsender indikere hvilken trafikkgruppe avsenderen er med i, og b0-b5 i TOS-feltet ble avsatt til noe som kalles DS Code Point, og b6-b7 ble da avsatt til fremtidig bruk. Tidligere definisjon av TOS-feltet var nå lagt bort for godt. Men, dette er en eksperimentell standard, ikke en vedtatt standard. Disse seks bit gir 2 6 = 64 mulige verdier, altså 64 ulike koder. Disse er av Internet Address and Numbering Agency (IANA) gruppert i pools. Et blikk inn i inndelingen er nyttig for å illustrere tallsystemet. Stressindikatorer pool kodeområde bruksområde (viser kun b0-b5) 1 xxxxx0 standardisering ( ) 2 5 = 32 ulike koder 2 xxxx11 eksperiment og lokal bruk ( ) 2 4 = 16 ulike koder 3 xxxx01 eksperiment og lokal bruk, men kan omgjøres til standardisering ( ) 2 4 = 16 ulike koder I et nytt utkast til standard fra IETF er bit 6 og 7 av TOS-feltet angitt som et sted der ruteren kan angi til mottakeren at det er belastningsproblemer, i noe 7

8 som kalles en Explicit Congestion Notification (ECN). Ønsket fra ruteren er at senderen som skal oversende et bilde, videokonferanse eller annet, reagerer på signalet. b6-b7 betydning 00 endemaskinene forstår ikke ECN (settes av senderen) 01 ECN-transport kapabilitet 1, ECT(1) (settes av senderen) 10 ECN-transport kapabilitet 2, ECT(2) (settes av senderen) 11 CE (Congestion Experienced) (settes av ruteren) Dette demonstrerer hvordan k = 2 bit, nemlig b6 og b7 i TOS-feltet, gir fire mulige verdier. I høyre kolonne vises hva verdien indikerer. Det antas nå at den opprinnelige bruk av TOS-feltet er forgangen, og at en i noen år fremover vil bruke det som nevnt over: 6 bit til DSCP og 2 bit til ECN. Oppgave Som tidligere er det veldig nyttig å gjøre oppgaver for å befeste stoffet. Lag tabell som viser verdirommet for k = 1, 2,..., 8 siffer i alle fire tallsystem. Venstre kolonne viser k, neste kolonne viser laveste og høyeste verdi, tredje kolonne viser antall verdier i verdirommet. Bruk gjerne maskinens kalkulator. Anta at vi satt og skulle planlegge anvendelsen av TOS-feltet. Hvor mange bit var nødvendig for at senderne i TOS-feltet skulle kunne indikere tre ulike graderinger for throughput (leveringskvalitetene ikke viktig, middels viktig eller veldig viktig ). 8