Datateknikk TELE1004-A 13H HiST-AFT-EDT Delemne digitalteknikk og datakommunikasjon Øving 5; løysing Oppgåve 1 Forklar (kort) med eigne ord kvifor ein bruker ein lagdelt modell for pakkesvitsja datakommunikasjon. Datakommunikasjon er komplisert, og det gjev betre oversyn å gruppera arbeidsoppgåvene i fleire lag. På kvart lag finst det eit sett av rutinar som tek seg av oppgåver som har tydeleg skyldskap med kvarandre. Grensesnitt mellom dei ulike laga er definerte, slik at eit lag kan bruka tenestene på laget under. Og eit lag kan tilby tenester til laget over. Dessutan «kamuflerer» eit lag i OSI-modellen detaljane i laget som ligg under. Lagdelingsteknikken gjev høve til å byta ut delkomponentar i modellen utan at det må få konsekvensar for funksjonaliteten på dei andre laga. b) Kva er ein kommunikasjonsprotokoll? Eit system av definisjonar for meldingsformat og regelsett for utveksling av data mellom (eller innanføre) kommunikasjonsvertar. I eit lagdelt system vil det seia utveksling av data mellom entitetar som høyrer heime på eitt og same laget. c) Kvifor eignar eit pakkesvisja nett seg betre enn eit linesvitsja nett for skurfordelt trafikk? Det er meir effektivt å tildela overføringskapasitet dynamisk når skurfordelte data skal overførast, for då kan andre brukarar utnytta kapasiteten når ein brukar ikkje overfører noko sjølv. Transmisjonsmediet er gjerne felles for alle brukarane, og då kan det godt ha stor kapasitet (høg bitrate) utan at det vert for dyrt for kvar einskild brukar. I eit linesvitsja nett har sambanda som regel lågare bitrate, for der er dei er individuelle. Dersom det er ein del pausar i dataoverføringa, vert resultatet dårleg utnytting av overføringskapasiteten. d) Kva har ein sesjon i eit pakkesvitsja nett til felles med ein samtale i eit linesvitsja nett?
I båe tilfella er kommunikasjonen sesjonsorientert (tilstandsbasert): Ein sesjon vert kopla opp før dataoverføringa og kopla ned etterpå: oppkoplingsfase (tildeling av ressursar, ev. overøring av adresseinfo.) overføringsfase (brukarinformasjon ende til ende) nedkoplingsfase (frigjering av ressursar) [Ein virtuell kanal kan ev. vera kopla opp gjennom nodane slik at han fylgjer ein eintydig veg gjennom nettet, men dette gjeld generelt ikkje for TCP over IP.] Oppgåve 2 Ein overfører ikkje e-post direkte over ei einskild TCP-forbinding ende til ende frå sendar til mottakar. Kva ville ha vore den store ulempa med ei slik løysing? Mottakar-klienten måtte ha vore kontinuerleg oppe og fast tilknytt IP-nettet. Det ville ha vore ei upraktisk løysing for brukarar som koplar seg til i berre korte tidsrom. Ev. nedetid i det mellomliggjande nettet ville òg ha ført til problem for ei slik løysing. b) Nemn nokre av kommandoane i POP3-protokollen som ein klient kan sende mot ein tenar. Sjå ev. standarddokumentet RFC 1939: http://www.ietf.org/rfc/rfc1939.txt USER PASS LIST RETR DELE QUIT Brukarnamn for postkasse Passord (Merk: Ukryptert overføring!) Lista opp eit oversyn over innhaldet i postkassa, med lengd i oktettar Lasta ned melding nr. frå postkassa Sletta melding nr. frå postkassa Nedkopling av TCP-sesjonen Nyare versjonar av POP3-applikasjonar stør òg: APOP Brukarnamn og kryptert passord Sjå òg RFC 1939: http://www.ietf.org/rfc/rfc1939.txt c) Kva er Base64-koding? Vert det overførte datavolumet større eller mindre enn det opphavlege som fylgje av denne kodinga, og i så fall kor mykje?
Base64-koding er ein mekanisme for å representere bitsekvensar frå binærfiler ved å omforma dei til skrivbare 7-bit ASCII-teikn. 6 og 6 bitar av binærdatafila vert konverterte til eitt av 64 teikn: {A Z}, {a z}, {0 9}, + og /. Teiknet = vert brukt som utfylling for å oppnå eintydig slutt. 3 og 3 oktettar binærdata vert omforma til 4 og 4 ASCII-teikn. Kvart ASCII-teikn vert overført som åtte bit; TCP/IP er oktettorientert. Konsekvensen for den overførde datamengda er at ho aukar med ein faktor 4/3 eller 33⅓ % (frå 24 til 32 bit eller, om ein vil, med to ekstra bit for kvar sjette databit). Sjå òg RFC 3548: http://www.ietf.org/rfc/rfc3548.txt Oppgåve 3 PRAKTISK OPPGÅVE. Denne oppgåva skal utførast med utgangspunkt i Linux-maskina Hekta ved EDT. Grunnen til det er m.a. at alle som utfører oppgåva skal kunna koma fram til den same fasiten. For å få tilgang til terminaltenaren/linux-skalet på Hekta skal ein bruka SSH-protokollen mot TCP-port 22 på hekta.org. (Hekta tillèt ikkje ukryptert Telnet-innlogging.) Bruk gjerne SSH-klienten PuTTY, som kan køyrast direkte under MS-Windows frå nedlasta fil utan at ein må gå gjennom nokon installasjonsprosedyre fyrst. PuTTY ligg på dei fleste PC-ane ved EDT, ev. kan fila lastast ned frå øvingsmenyen i It s learning. Alle studentar skal logga seg inn på den same brukaren: Sjå brukarnamn og passord på It s learning. Føremålet med oppgåva er å demonstrera at ein HTTP-tenar svarer «alle» som koplar seg opp mot TCP-port 80 og sender HTTP-protokollkode. Ein Telnet-klient er eit lite applikasjonsprogram som kan senda og motta ASCII-tekststrenger over ein TCP-socket. HTTP er ein tekstbasert protokoll, og då kan du simulera ein HTTP-klient (dvs. ein nettlesar) vha. Telnet-klienten og senda førespurnader til tenaren frå tastaturet. Praktisk gjennomføring: For å ha ein referanse kan du starta ein nettlesar (Internet Explorer/Firefox/Chrome/Opera/Safari e.l.) og gå til URL-en http://venus.edt.hist.no/~herman/test/ Start opp og gjer klar TELNET-klienten. Merk at leieteksten er datakomm@hekta:~$. Opna ein TCP-sesjon mot port 80 på den same tenarmaskina. Syntaksen er telnet venus.edt.hist.no 80 Skriv manuelt ein HTTP-nedlastingskommando: GET /~herman/test/ HTTP/1.0 (Dersom det er vanskar med å skriva ~-teiknet, kan du bruka %7e i staden: GET /%7eherman/test/ HTTP/1.0 Trykk retur-tasten to gonger etter at du har skrive inn kommandoen. Merk: Få med blankteikna i tekststrengene som du skriv inn! HTTP er versalsensitiv småe og store bokstavar kan ikkje veljast fritt! Klipp ut og lim inn i svaret responsen (teksten) som kjem frå tenaren. Kva for informasjon ligg i den fyrste lina i responsen? Kva fortel den sjette lina i responsen?
TCP-oppkopling, tre meldingar frå TELNET-klienten på VENUS, og endeleg ein HTTP-kommando: datakomm@hekta:~$ telnet venus.edt.hist.no 80 Trying 158.38.51.9... Connected to venus.edt.hist.no. Escape character is '^]'. GET /%7eherman/test/ HTTP/1.0 Respons frå tenaren på venus.edt.hist.no (Dei seks fyrste linene er HTTP-protokoll-header, medan resten er nedlasta innhaldsdata, i dette tilfellet HTML-kode): HTTP/1.1 200 OK Date: Mon, 21 Oct 2013 11:30:02 GMT Server: Apache/2.2.0 (Fedor mod_perl/2.0.4 Perl/v5.10.0 Content-Length: 1064 Connection: close Content-Type: text/html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="nn"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>dette er dokumenttittelen</title> </head> <body> <h1>dette er den største overskrifta</h1> <h2>dette er ei ikkje fullt så stor overskrift</h2> <h3>dette er ei endå litt mindre overskrift</h3> <p>dette er vanleg tekst, ev. <em>kursivert</em> eller <strong>halvfeit</strong>.</p> <p>dette er neste avsnitt. Under dette kjem eit grafikkbilete og ein tabell:</p> <p><img src="hist.png" alt="hist" /></p> <table border="1"> <tr align="right"><td>1</td><td>22</td><td>333</td></tr> <tr align="right"><td>4 444</td><td>55 555</td><td>666 666</td></tr> <tr align="right"><td>7 777 777</td><td>88 888 888</td><td>999 999 999</td></tr> </table> <p>til slutt hypertekst: <a href="http://venus.edt.hist.no/~herman/">heimeside</a> og <a href="mailto:herman.ranes@hist.no">e-postadresse</a>.</p> </body> </html>
Til slutt ei melding frå TELNET-klienten på Hekta når venus.edt.hist.no har kopla ned TCP-socketen: Connection closed by foreign host. datakomm@hekta:~$ Den fyrste lina i HTTP-header inneheld HTTP-versjonsnummeret som tenarapplikasjonen har stønad for (t.o.m. 1.1) og responskoden 200, dvs. handlinga var vellukka (og dei førespurde innhaldsdata kjem etter HTTP-header). Den sjette lina inneheld MIME-informasjon: Dei etterfølgjande innhaldsdata er ASCII-tekstdata for HTML-kode. b) I staden for HTML-kode skal du no prøva å lasta ned ei binær JPEG-grafikkfil frå HTTP-tenaren: Praktisk gjennomføring: Start TELNET-klienten. Merk at leieteksten er datakomm@hekta:~$. Opna ein TCP-socket mot port 80 på den same tenarmaskina. Syntaksen er telnet venus.edt.hist.no 80 Skriv manuelt ein HTTP-nedlastingskommando: GET /~herman/test/hist.jpg HTTP/1.0 Trykk retur-tasten to gonger etter at du har skrive inn kommandoen. Forklår det du ser på skjermen. Etter HTTP-protokollheader fylgjer om lag 4500 oktettar med binære data. Dei kan ikkje presenterast av TELNET-klienten som nokon meiningsfylt tekst (og då har det som kjem på skjermen liten informasjonsverdi for ein brukar). Protokollheader inneheld (som i deloppg. tekstformatert tilleggsinformasjon, men i dette tilfellet kjem nok teksten til å «drukna» i dei etterfylgjande binære brukardata. c) Byt ut GET med ein annan HTTP-kommando: HEAD HEAD /~herman/test/hist.png HTTP/1.0 Hugs to trykk på retur-tasten. Kva for informasjon ligg i den niande lina i responsen? TCP-oppkopling, tre meldingar frå TELNET-klienten på Venus, og endeleg ein HTTP-kommando: datakomm@hekta:~$ telnet venus.edt.hist.no 80 Trying 158.38.51.9... Connected to venus.edt.hist.no. Escape character is '^]'. HEAD /%7eherman/test/hist.png HTTP/1.0
Respons frå tenaren på venus.edt.hist.no : HTTP/1.1 200 OK Date: Mon, 21 Oct 2013 11:51:56 GMT Server: Apache/2.2.0 (Fedor mod_perl/2.0.4 Perl/v5.10.0 Last-Modified: Mon, 21 Oct 2013 11:48:08 GMT ETag: "16403f-11f0-4e93edb940e00" Accept-Ranges: bytes Content-Length: 4592 Connection: close Content-Type: image/jpeg Connection closed by foreign host. datakomm@hekta:~$ Dette er protokollheader, som inneheld tekstformatert tilleggsinformasjon. I dette tilfellet vert dei etterfylgjande binære brukardata ikkje sende frå tenaren, og skjermutskrifta er framleis ryddig. Den niande lina inneheld MIME-informasjon: HTTP-innhaldsdata (som ikkje vart sende her; jf. delspørsmål b) er binære data for JPEG-grafikk. d) Kva meiner ein med at ein protokoll på applikasjonslaget er tekstbasert? Finst det eit klårt svar på spørsmålet: «Er HTTP ein tekstbasert protokoll?»? Ved tekstbasert overføring vert dei overførde oktettverdiane tolka innanføre ulike kategoriar: Skrivbare teikn kan vera bokstavar, siffer eller andre tekstsymbol. Kontrollteikn kan m.a. nyttast til å formatera tekst (lineskift, tabulator osb.) Dei einaste kontrollteikna i tekstbaserte protokollar er lineslutt-/lineskiftsekvensen, som alltid er 0x0d 0x0a, dvs. <CR><LF>, uavhengig av OS/plattform. I mange tilfelle er protokollkommandoane og -responsane ord (eller forkortingar) som kan gje eit vink om kva funksjon dei har. Alle HTTP-kommandoar og respons-header er tekstbaserte. Applikasjonsdata kan vera tekstbaserte eller binære. Oppgåve 4 Kva er hovudføremålet med å bruka ein transportprotokoll i eit datanett?
Transportprotokollen skal tilby ende til ende-kommunikasjon mellom to definerte endepunkt. (I TCP/IP er desse endepunkta portar, adresserte grensesnitt mot spesifikke applikasjonsentitetar). Protokollen skal «kamuflera» det mellomliggjande nettet, slik at dei to applikasjonsentitetane er logisk (tilsynelatande) direkte samankopla. Transportlaget kan ev. tilby påliteleg overføring (auka tenestekvalitet). TCP (Transmission Control Protocol) tilbyd slik påliteleg overføring mellom dei to portane. b) Kva er dei to viktigaste skilnadene mellom TCP (Transmission Control Protocol) og UDP (User Datagram Protocol)? TCP er sesjonsorientert (oppkopling, dataoverføring og nedkopling), medan UDP er datagramorientert («send og gløym»). TCP tilbyd påliteleg overføring av data, m.a. ved å bruka ARQ, flytkontroll og metningskontroll. UDP er like upåliteleg som det dei underliggjande laga er, men protokollen kan vera betre eigna til sanntidstenester og korte transaksjonar pga. mindre tidsforseinking. c) Korleis fungerer ein ARQ-protokoll (Automatic Repeat Request)? Svar kort! «Automatic Repeat Request» er ein protokollteknikk der primær (sendaren av dat ventar på ei kvittering frå sekundær (mottakaren av dat om at ei datapakke er komen fram feilfritt. Dersom det kjem ei negativ kvittering, eller inga positiv kvittering er komen før retransmisjonsklokka har nådd null, vert datapakka send om att. Kvar datapakke har eit sekvensnummer som m.a. kan brukast til å sortera ut dupliserte datapakker. Oppgåve 5 Vertsmaskin B mottek ein oktettstraum frå vertsmaskin A, som på si side returnerer ein annan oktettstraum til B. Sjå det (ufullstendige) tidssekvensskjemaet under. TCP-segmenta nr. 3 og nr. 5 gjekk tapt før dei kom fram til vertsmaskin B. A ---------------- 1500 oct --------> SEQ = 2464 ACK = 19880 B <-------- 500 oct ---------------- SEQ = 19880 ACK = 3964 \ / ---------------- 1500 oct ------ X SEQ = 3964 / \ ACK = 20380
<-------- 500 oct ---------------- SEQ = 20380 ACK =? \ / ---------------- 1500 oct ------- X SEQ =? / \ ACK =? <-------- 500 oct ---------------- SEQ = 20880 ACK =? Skriv opp header-data (SEQ og ACK) i TCP-segmenta nr. 4, nr. 5 og nr. 6. Det 4. TCP-segmentet repeterer kvitteringsverdien i segment nr. 2, som er det siste i ein komplett sekvens: ACK=3964 Det 5. TCP-segmentet er ein retransmisjon av segment nr. 3, og det inneheld ei kvittering for det 4. segmentet: SEQ=3964; ACK=20880 Det 6. segmentet repeterer kvitteringa i det 4. segmentet: ACK=3964