Kapittel 2 Application Layer

Kapittel 2 Application Layer
Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. Slides adapted from the slides accompanying the book of Kurose & Ross. © J.F Kurose and K.W. Ross, All Rights Reserved Norsk versjon: © Christian F Heide, 2004. Kap 2: Applikasjonslaget

Kapittel 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server Kap 2: Applikasjonslaget

Kapittel 2: Application Layer
Våre mål: konseptuelle- og implementasjons-aspekter ved applikasjonslags-protokoller transportlaget tjenestemodeller klient-tjener-paradigmet peer-to-peer paradigmet lære om protokoller ved å studere noen populære applika-sjonslagsprotokoller HTTP FTP SMTP / POP3 / IMAP DNS programmering av nettverksapplikasjoner socket API Kap 2: Applikasjonslaget

Noen nettverksapplikasjoner
E-post Web Instant messaging (f. eks. MSN) Remote login P2P fildeling Multi-user nettverksspill Streaming av lagret video Internettelefoni Sanntids video-konferanse Massive parallel computing Kap 2: Applikasjonslaget

Kapittel 2 – Hvor er vi? 2.1 Principles of network applications
2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server Kap 2: Applikasjonslaget

Nettverksapplikasjoner: terminologi
Prosess: program som kjører på en maskin innen samme maskin kommuniserer to prosesser ved interprosess-kommunikasjon (definert av OS). prosesser på ulike maskiner kommuniserer ved en applikasjonslags-protokoll brukeragent: mellommann mellom bruker og nettverk implementerer bruker-grensesnitt og applikasjonslags-protokoll Web: nettleser (browser) E-post: e-postleser streaming audio/video: media player Kap 2: Applikasjonslaget

Lage nettverksapplikasjoner
Skriv programmer som kjører på ulike endesystemer og kommuniserer over et nettverk f.eks. Web: Web server programvare kommuniserer med nettleserprogramvare Ingen applikasjonsprogramvare skrives for noder i kjernen Noder i nettets kjerne opererer ikke på applikasjonslaget Dette designet muliggjør hurtig applikasjonsutvikling applikasjon transport nettverk link fysisk applikasjon transport nettverk link fysisk applikasjon transport nettverk link fysisk Kap 2: Applikasjonslaget

Applikasjoner og applikasjonslagsprotokoller
Applikasjon: kommuniserende, distribuerte prosesser f.eks. e-post, Web, P2P fildeling, meldingsformidling kjører i endesystemer (vertsmaskiner, hosts) utveksler meldinger Applikasjonslagsprotkoller en del av en applikasjon definerer meldinger som utveksles og handlinger som skal utføres bruker kommunikasjons-tjenester som tilbys av protokoller på laget under (transportlaget), TCP og UDP appl transport nettverk link fysisk Kap 2: Applikasjonslaget

Applikasjonsarkitekturer
Klient-tjener (client-server) Peer-to-peer (P2P) Hybrid av klient-tjener og P2P Kap 2: Applikasjonslaget

Klient-tjener arkitektur
tjener (server): “always-on” maskin permanent IP-adresse “server farmer” for skalering klienter: kommuniserer med tjener kan være sporadisk tilkoblet kan ha dynamisk IP-adresse kommuniserer ikke direkte med hverandre Kap 2: Applikasjonslaget

Ren P2P arkitektur ingen “always on” server nødvendig
endesystemer kommuniserer direkte med hverandre maskiner er sporadisk tilkoblet og kan endre IP-adresser eksempel: Gnutella Skalerer godt Noe vanskelig å drifte Kap 2: Applikasjonslaget

Hybrid av klient-tjener og P2P
Napster Filoverføring er P2P Filsøk er sentralisert: Peers registrerer objekter de vil dele i sentral server Peers benytter samme server for å finne ønskede objekter Instant messaging Chatting mellom to brukere er P2P Deteksjon av tilstedeværelse og adresse er sentralisert: Brukere registrerer sin IP-adresse i en sentral server når de logger på Brukere kontakter sentral server for å finne venners IP-adresser Kap 2: Applikasjonslaget

Klient-tjener paradigmet
appl transport nettverk link fysisk reply request tjener Kap 2: Applikasjonslaget

Kommuniserende prosesser
Klientprosess: prosessen som initierer kommunikasjonen Tjenerprosess: prosessen som venter på å bli kontaktet Prosess: program som kjører på en maskin innen samme maskin kommuniserer to prosesser ved interprosess-kommunikasjon (definert av OS). prosesser på ulike maskiner kommuniserer ved en applikasjonslags-protokoll Merk: applikasjoner med P2P-arkitektur har både klientprosesser og tjenerprosesser Kap 2: Applikasjonslaget

Prosesskommunikasjon over et nettverk
TCP med buffere og variable socket prosess TCP med buffere og variable socket kontrollert av applikasjons- utvikleren Internett kontrollert av OS Kap 2: Applikasjonslaget

Prosessadresser: For at en prosess skal kunne motta meldinger må den ha en adresse Hver maskin har en unik 32-bits IP-adresse Q: er IP-adressen tilstrekkelig for å identifisere en prosess? Svar: Nei, siden mange prosesser kan kjøre på samme maskin Prosessadressen består av både IP-adresse og et portnummer assosiert med prosessen på maskinen Eksempel på portnumre: HTTP server: 80 Mail server: 25 Mer om dette etterhvert Kap 2: Applikasjonslaget

Applikasjonslagsprotokoller definerer
Meldingstyper som utveksles, f.eks. request & response meldinger Meldingssyntaksen: hvilke felter meldingen inneholder Meldingssemantikken, dvs. betydningen av informasjonen i feltene Regler for når og hvordan prosesser skal sende og svare på meldinger Åpne protokoller (public-domain) : definert i RFCer tillater interoperabilitet f eks HTTP, SMTP Proprietære protokoller: f eks KaZaA Kap 2: Applikasjonslaget

Hvilke transporttjenester trenger en applikasjon?
Tap av data noen applikasjoner (f.eks. lyd) tåler en del tap av data andre applikasjoner (f.eks. fil-overføring, telnet) krever 100% pålitelig overføring Båndbredde noen appl (f.eks. multimedia) krever en viss båndbredde for å fungere andre appl (“elastiske appl”) tar til takke med den båndbredden de får Tidskrav noen appl (f.eks. Internettelefoni og interaktive spill) krever liten forsinkelse for å fungere Kap 2: Applikasjonslaget

Krav til transporttjenester fra noen applikasjoner
Følsom for forsinkelse nei ja, noen 100 ms ja, noen s Applikasjon filoverføring e-post Web sanntidsaudio/-video lagret audio/video interaktive spill Tap ingen tap tapstolerant Båndbredde elastisk audio: 5kb/s-1Mb/s video:10kb/s-5Mb/s som over noen kb/s og høyere Kap 2: Applikasjonslaget

Tjenester fra transport-protokoller i TCP/IP-nett
TCP-tjenster: forbindelsesorientert: oppkobling mellom klient- og tjenerprosessene nødvendig pålitelig transport mellom sender- og mottakerprosess flytkontroll: sender skal ikke oversvømme mottaker med data metningskontroll: redusere senderate når nettet er overbelastet gir ikke: tidsgaranti eller båndbreddegaranti UDP-tjenester: upålitelig dataoverføring mellom sender og mottaker gir ikke: oppsetting av forbindelse, pålitelig overføring, flytkontroll, metningskontroll, tidsgaranti eller båndbreddegaranti Kap 2: Applikasjonslaget

Internett apps: applikasjon- og transportprotokoll
Applikasjons- lagsprotokoll SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietær (f.eks. RealNetworks) (f.eks. Dialpad) Underliggende transportprotokoll TCP TCP eller UDP oftest UDP Applikasjon e-post remote terminalaksess Web filoverføring streaming av multimedia Internetttelefoni Kap 2: Applikasjonslaget

app architectures app requirements 2.2 Web and HTTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server Kap 2: Applikasjonslaget

Web og HTTP Språkbruk En webside består av objekter
Et objekt kan være en HTML-fil, et JPEG-bilde, en Java-applet, en lydfil osv. Websider består av en basis HTML-fil som inkluderer mange refererte objekter Hvert objekt adresseres ved en URL Eksempel på URL: maskinnavn stinavn Kap 2: Applikasjonslaget

HTTP oversikt HTTP: hypertext transfer protocol
Webs applikasjonslags-protokoll klient/tjener modell klient: browser som forespør, mottar og viser web-objekter tjener: web-tjeneren sender objekter som repsons på forespørsler HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2616 HTTP request PC med Explorer HTTP response HTTP request Tjener som kjører Apache Web server HTTP response Mac med Navigator Kap 2: Applikasjonslaget

HTTP oversikt (fortsatt)
Benytter TCP: klient initierer TCP-forbindelse (åpner socket) til tjener, port 80 tjener aksepterer TCP-forbindelsen fra klienten HTTP meldinger (applika-sjonslagets protokoll-meldinger) utveksles mellom browser (HTTP klient) og web-server (HTTP tjener) TCP-forbindelsen lukkes HTTP er tilstandsløs tjener tar ikke vare på informasjon om tidligere forespørsler fra klienten på siden Protokoller som har tilstands-informasjon er komplekse! må huske hva som har skjedd hvis tjener eller klient krasjer, kan deres syn på tilstanden bli inkonsistent Kap 2: Applikasjonslaget

HTTP-forbindelser Ikkepersistent HTTP
En TCP-forbindelse overfører kun ett objekt HTTP/1.0 benytter ikkepersistent HTTP Persistent HTTP Flere objekter kan sendes over en TCP-forbindelse mellom klient og tjener HTTP/1.1 benytter persistente forbindelser som default Kap 2: Applikasjonslaget

Ikkepersistent HTTP (inneholder tekst og referanser til 10 jpeg bilder) Bruker skriver inn URL 1a. HTTP klienten initierer en TCP- forbindelse til HTTP serveren (eller prosessen) på på port 80 1b. HTTP server på maskinen venter på en TCP-forbindelse på port 80. Aksepterer forbindelsen og gir beskjed til klienten 2. HTTP klienten sender en HTTP request melding (som URL) over TCP-forbindelsen. Meldingen indikerer at klienten ønsker objektet /cfh/tullogtoys/index.html 3. HTTP serveren mottar fore-spørselen, lager en response melding som inneholder det forespurte objektet og sender meldingen inn på socket tid Kap 2: Applikasjonslaget

Ikkepersistent HTTP (forts.)
4. HTTP server lukker TCP-forbindelsen 5. HTTP klienten mottar respons-meldingen som inneholder html-filen og viser denne. Ved “parsing” av html-fil finner den ti refererte jpeg-objekter tid 6. Trinn 1-5 repeteres for hvert av de ti jpeg-objektene Kap 2: Applikasjonslaget

Estimering av responsetid
Definisjon av RTT: tiden det tar for en liten pakke å vandre fra klienten til tjeneren og tilbake. Responstid: én RTT for å initiere en TCP-forbindelse én RTT for en HTTP request med ankomst av den første byte av HTTP responsen sendetiden for fila totalt: 2RTT + sendetid sendetiden for fil initiere TCP- forbindelse RTT request mottatt tid Kap 2: Applikasjonslaget

Persistent HTTP Ulemper med ikkepersistent HTTP:
trenger 2 RTT pr objekt OS må allokere ressurser for hver TCP-forbindelse men nettlesere åpner ofte parallelle TCP-forbindelser for å hente refererte objekter Persistent HTTP tjener lar forbindelsen være åpen etter å ha sendt sin respons etterfølgende HTTP-meldinger mellom samme klient og tjener sendes over samme forbindelse Persistent uten pipelining: klient sender ny forespørsel først når respons er mottatt en RTT for hvert referert objekt Persistent med pipelining: default i HTTP/1.1 klient sender forespørsel med en gang den kommer over et referert objekt bare en RTT for alle de refererte objekter Kap 2: Applikasjonslaget

HTTP request-meldinger
Tekst (lesbart for mennesker) request linje (GET, POST, HEAD kommandoer) GET /somedir/page.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr header linjer “Carriage return, line feed” indikerer slutten på meldingen Kap 2: Applikasjonslaget

HTTP request-melding: generelt format
Kap 2: Applikasjonslaget

Metoder i HTTP HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT
“send bare header, ikke selve objektet” HTTP/1.1 GET, POST, HEAD PUT laster opp filer DELETE sletter filer spesifisert i URL-feltet Kap 2: Applikasjonslaget

HTTP respons-melding statuslinje (protokoll, statuskode, statusfrase)
HTTP/ OK Connection close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... headerlinjer data, f eks etterspurt HTML-fil Kap 2: Applikasjonslaget

HTTP respons-melding: generelt format

Noen HTTP responsstatuskoder
200 OK forespørsel lyktes, etterspurt objekt følger senere i meldingen 301 Moved Permanently etterspurt objekt er flyttet, ny lokasjon spesifisert senere i meldingen (Location:) 400 Bad Request forespørsel ikke forstått av serveren 404 Not Found etterspurt dokument ikke funnet på serveren 505 HTTP Version Not Supported Kap 2: Applikasjonslaget

Cookies: tilstandsinformasjon
Mange store nettsteder bruker cookies Fire komponenter: 1) cookie header linje i HTTP-responsmelding 2) cookie header linje i HTTP-requestmelding 3) cookie fil på brukerens maskin håndtert av nettleseren 4) “back-end” database på nettstedet Eksempel: Susan bruker alltid Internett fra samme PC Hun besøker en spesifikk e-handelsside for første gang Når den første HTTP-requesten når nettstedet, lages det en unik ID for Susan og et innslag i back-end databasen for denne IDen Kap 2: Applikasjonslaget

Cookies klient server server genererer ID 1678 for bruker
vanlig http request vanlig http respons + Set-cookie: 1678 cookie: 1678 vanlig http respons cookie- spesifikk aksjon Cookie-fil ebay: 8734 server genererer ID 1678 for bruker entry i database Cookie-fil amazon: 1678 ebay: 8734 aksess en uke senere: aksess Cookie-fil amazon: 1678 ebay: 8734 Kap 2: Applikasjonslaget

Cookies (forts) Cookies og personvern:
på siden Cookies og personvern: cookies gjør at nettsteder kan holde øye med hva du foretar deg kan gi navn og e-post-adresse til nettsteder søkemotorer benytter redirigering sammen med cookies for å finne ut ennå mer kan samle inn informasjon om deg fra flere nettsteder Hva cookies kan gi: autorisering handlevogn anbefalinger sesjonstilstand (f eks for web e-post) Kap 2: Applikasjonslaget

Web caching (proxy server)
Mål: oppfylle klientens forespørsel uten å involvere opprinnelsesserver opprinnelsesserver bruker setter nettleser: Web-aksess via cache nettleser sender alle HTTP-forespørsler til cache objektet finnes i cache: cache returnerer objektet objektet finnes ikke i cache: cache forespør objektet fra opprinnelses-serveren, og returnerer objektet til klienten Proxy server HTTP request HTTP request klient HTTP response HTTP response HTTP request HTTP response klient opprinnelsesserver Kap 2: Applikasjonslaget

Mer om web-caching Cache opptrer som både klient og tjener
Cache installeres ofte av ISP (høgskole, bedrift, privat ISP) Hvorfor web-caching? redusere responstid for klientforespørsler. redusere trafikken på institusjonens aksesslink. cacher gjør at “fattige” innholdsleverandører kan gi gode leveranser Kap 2: Applikasjonslaget

Caching eksempel opprinnelses Antagelser servere
gjennomsnittlig objektstørrelse = 100,000 bit gjennomsn. foresp. rate fra nettlesere = 15 pr sekund forsinkelse fra institusjonens ruter til opprinnelsesservere og tilbake = 2 sekunder Konsekvenser utnyttelse av LAN = 15% utnyttelse av aksesslink = 100% total forsinkelse = Internett-forsinkelse + aksessforsinkelse + LAN forsinkelse = 2 s + minutter + ms Internett 1.5 Mb/s aksesslink institusjonens nettverk 10 Mb/s LAN institusjonell cache Kap 2: Applikasjonslaget

Caching eksempel (forts.)
opprinnelses servere Mulig løsning øke aksesslinkens båndbredde til f eks 10 Mb/s Konsekvenser utnyttelse av LAN = 15% utnyttelse av aksesslink = 15% Total forsinkelse = Internett-forsinkelse + aksessforsinkelse + LAN forsinkelse = 2 s + ms + ms ofte en kostbar oppgradering Internett 10 Mb/s aksesslink institusjonens nettverk 10 Mb/s LAN institusjonell cache Kap 2: Applikasjonslaget

Caching eksempel (forts.)
opprinnelses servere Installere cache anta at treffraten er 0.4 Konsekvenser 40% av forespørslene vil besvares umiddelbart av cache 60% av forespørslene besvares av opprinnelses-server utnyttelse av aksesslink reduseres til 60%, noe som resulterer i neglisjerbare forsinkelser (størrelse 10 ms) gjennomsnittlig forsinkelse = Internettforsinkelse + aksessforsinkelse + LAN forsinkelse = 0.6 * 2.01 s + noen ms < 1.4 s Internet 1.5 Mb/s aksesslink institusjonens nettverk 10 Mb/s LAN institusjonell cache Kap 2: Applikasjonslaget

Betinget GET: klient-side caching
tjener Mål: ikke send objektet dersom klienten har en oppdatert versjon i sin cache klient: specifisere dato for sin cachede kopi i HTT-forespørselen If-modified-since: <dato> tjener: respons inneholder ikke noe objekt dersom det ikke finnes en nyere versjon enn den cachede kopien: HTTP/ Not Modified HTTP request mld If-modified-since: <date> objekt ikke endret HTTP respons HTTP/1.0 304 Not Modified HTTP request mld If-modified-since: <date> objekt endret HTTP respons HTTP/ OK <data> Kap 2: Applikasjonslaget

Kapittel 2 – hvor er vi? 2.1 Principles of app layer protocols
2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Kap 2: Applikasjonslaget

FTP: the file transfer protocol
bruker- grense-snitt klient filoverføring FTP server bruker lokalt filsystem fjerntliggende filsystem Kap 2: Applikasjonslaget

FTP: the file transfer protocol
TCP kontrollforbindelse port 21 TCP dataforbindelse port 20 FTP klient FTP server Kap 2: Applikasjonslaget

FTP: separat kontroll og dataforbindelse
klient server TCP kontrollforbindelse port 21 TCP dataforbindelse port 20 FTP klient kontakter FTP-server på port 21, spesifiserer TCP som transportprotokoll Klient får autorisasjon over kontrollforbindelsen Klient lister serverens kataloger ved å sende kontroll-meldinger over kontroll-forbindelsen Når server mottar en kommando for en filoverføring vil den åpne en TCP dataforbindelse til klienten Etter overføring av en fil vil server lukke forbindelsen Server åpner en ny TCP dataforbindelse for hver ny fil som skal overføres Kontrollforbindelse: “out of band” FTP server har tilstands-informasjon: stående katalog og tidligere autentisering Kap 2: Applikasjonslaget

FTP kommandoer og responser
Noen kommandoer: USER username PASS password LIST returnerer liste av filer i katalogen RETR filename henter fil til lokal maskin STOR filename lagrer (laster opp) fil på fjernliggende maskin Noen responser 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file Kap 2: Applikasjonslaget

Kapittel 2 – hvor er vi? 2.1 Principles of network applications

Elektronisk post Tre hovedkomponenter: SMTP SMTP SMTP brukeragenter
utgående meldingekø brukerens postkasse bruker agent Tre hovedkomponenter: brukeragenter mail-servere simple mail transfer protocol: SMTP Brukeragent samme som “epost-leser” skrive og lese epost-meldinger Eksempler: Eudora, Outlook, pine, Netscape Messenger utgående og innkommende meldinger lagres på server mail server bruker agent SMTP mail server bruker agent SMTP mail server SMTP bruker agent bruker agent bruker agent Kap 2: Applikasjonslaget

Elektronisk post: mailservere
user agent Mailservere mailbox inneholder innkommende meldinger meldingskø for utgående meldinger SMTP protokoll mellom mailservere for å overføre eposter klient: mailserver som sender “server”: mailserver som mottar mail server user agent SMTP mail server user agent SMTP mail server SMTP user agent user agent user agent Kap 2: Applikasjonslaget

Elektronisk post: SMTP [RFC 2821]
benytter TCP for pålitelig overføring av epost fra klient til tjener, port 25 direkte overføring: fra avsenders mailserver til mottakers mailserver overføringens tre faser hilsing (“handshaking”) overføring av melding nedkobling (closure) kommando/respons interaksjon kommandoer: ASCII tekst respons: statuskode og -frase meldinger må være 7-bits ASCII Kap 2: Applikasjonslaget

Scenario: Alice sender melding til Bob
1) Alice benytter UA for å skrive melding og legger adressen og trykker “send” 2) Alices UA sender meldingen til hennes mailserver; melding legges i meldingskø 3) Klientsiden av SMTP åpner en TCP-forbindelse til Bobs mailserver 4) SMTP-klienten “hilser på” SMTP-serveren og sender deretter Alices melding over TCP-forbindelsen 5) Bobs mailserver legger meldingen i Bobs postkasse (mailbox) 6) Bob bruker sin UA (epost-program) for å lese meldingen mail server mail server 1 user agent user agent 2 3 6 4 5 Kap 2: Applikasjonslaget

Eksempel på SMTP interaksjon
S: 220 brage.ia.hiof.no C: HELO mail.halden.net S: 250 Hello mail.halden.net, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 brage.ia.hiof.no closing connection Kap 2: Applikasjonslaget

Forsøk SMTP interaksjon:
telnet <servernavn> 25 motta svar “220” fra server skriv HELO, MAIL FROM, RCPT TO, DATA og QUIT kommandoer Lar deg sende epost uten bruk av UA (epost-leser) Kap 2: Applikasjonslaget

SMTP: avrunding Sammenligning med HTTP:
SMTP benytter persistente forbindelser SMTP krever at meldingen er i 7-bits ASCII SMTP-server benytter CRLF.CRLF for å finne hvor meldingen slutter Sammenligning med HTTP: HTTP: pull SMTP: push begge har ASCII kommando/respons interaksjon og status koder HTTP: hvert objekt sendes i sin egen responsmelding SMTP: flere objekter kan sendes i samme melding Kap 2: Applikasjonslaget

Meldingsformat for epost
SMTP: protokoll for utveksling av epost RFC 822: standard for meldingsformat: headerlinjer, f.eks. To: From: Subject: forskjell fra SMTP kommandoer! meldingskropp (body) selve meldingen, kun ASCII-tegn header blank linje body Kap 2: Applikasjonslaget

Meldingsformat: multimedia-utvidelser
From: To: Subject: Fint bilde MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64-kodede data ..... ......base64-kodede data MIME versjon kodings- metode multimedia-data type, subtype, parameterdeklarering kodede data Kap 2: Applikasjonslaget

MIME typer Content-Type: type/subtype; parametere
Text eksempel på subtyper: plain, html Image eksempel på subtyper: jpeg, gif Audio eksempel på subtyper: basic (8-bit μ-lov koding), 32kadpcm (32 kb/s koding) Video eksempel på subtyper: mpeg, quicktime Application andre typer data som må prosesseres før de er “lesbare” eksempel på subtyper: msword, octet-stream Kap 2: Applikasjonslaget

Multipart Type From: cfh@halden.net To: christian.heide@hiof.no
Subject: Fint bilde MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Hei Christian! Sjekk disse blomstene! Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64-kodede data ..... ......base64-kodede data Fine å ha på kontoret? Kap 2: Applikasjonslaget

Epost aksessprotokoller
POP3 IMAP SMTP SMTP bruker agent bruker agent senders mailserver mottakers mailserver Kap 2: Applikasjonslaget

POP3 protokoll autorisasjonsfase C: list transaksjonsfase, klient:
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on autorisasjonsfase klient-kommandoer: user: brukernavn pass: passord server-responser +OK -ERR transaksjonsfase, klient: list: liste meldinger retr: hente meldinger dele: slette quit: avslutte C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 C: dele 2 C: quit S: +OK POP3 server signing off Kap 2: Applikasjonslaget

POP3 og IMAP Mer om POP3 IMAP
Forrige eksempel benyttet “download and delete” modus. Kan da ikke lese epost på ny dersom man bytter lokasjon/klient “Download-and-keep”: kopier av meldinger på ulike klienter POP3 er tilstandsløs mellom sesjoner IMAP Beholder meldinger på mail-serveren Tillater brukeren å organisere meldinger i mapper IMAP tar vare på tilstand mellom sesjoner: navn på mapper og kobling mellom meldings-ID og mappenavn Kap 2: Applikasjonslaget

DNS: Domain Name System
Mennesker har flere identifikatorer: personnummer, navn, passnummer Maskiner på Internett: IP-adresse (32 bit) – brukes for å adressere datagrammer “navn” f.eks. odin.hiof.no – brukes av mennesker Q: kobling mellom IP-adresser og navn? Domain Name System: distribuert database implementert i hierarki av mange navnetjenere (name servers) applikasjonslagsprotokoll maskiner, rutere og navne-tjenere kommuniserer for å resolve navn (adresse/navn-oversettelse) merk: dette er en kjernefunksjon i Internett implementert som en applikasjonslagsprotokoll kompleksiteten er i nettverkets “kant” Kap 2: Applikasjonslaget

DNS Hvorfor ikke sentralisere DNS? DNS tjenester
“single point of failure” trafikkvolum stor avstand til sentralisert database for mange vedlikehold skalerer ikke! DNS tjenester Maskinnavn til IP-adresse oversetting Host aliasing Kanoniske og alias navn Mail server aliasing Lastdeling Replikerte webservere: sett av IP-adresser tilhørende ett kanonisk navn Kap 2: Applikasjonslaget

DNS navnetjenere ingen server har alle navn-til-IP-adresse mappingene
lokale navnetjenere: hver ISP og bedrift har en lokal (default) navnetjener DNS-forespørsler sendes først til lokal navnetjener autoritativ navnetjener: lagrer en maskins IP-adresse knyttet til maskinens navn kan utføre navn/adresse-oversettelse for maskinen Kap 2: Applikasjonslaget

TLD og autoritative servere
Top-level domain (TLD) servere: ansvarlige for com, org, net, edu osv., samt alle top-nivå landdomener som uk, fr, ca og no Norid er ansvarlig for no-domenet ( Autoritative DNS-servere: en organisasjons DNS-servere, gir autoritative maskinnavn til IP mappinger for organisasjonens servere (f.eks. web- og mail-server). Kan vedlikeholdes av organisasjonen eller en tjenestetilbyder (“service provider”) Kap 2: Applikasjonslaget

Lokal navnetjener Ikke noe strengt hierarki
Hver ISP (ISP-firma, bedrift, universitet) har en kalles også “default navnetjener” Når en maskin sender en DNS query, sendes den til dens lokale navnetjener (DNS server) Fungerer som en proxy, videresender forespørsel inn i hierarkiet Kap 2: Applikasjonslaget

Distribuert, hierarkisk database
Rot DNS-Servere com DNS-servere org DNS-servere edu DNS-servere poly.edu DNS-servere umass.edu yahoo.com amazon.com ietf.org Klient ønsker IP for Klient spør en rot-tjener om DNS-server for “com” Klient spør “com” DNS-server om amazon.com sin DNS-server Klient spør amazon.com sin DNS-server om IP-adressen til Kap 2: Applikasjonslaget

DNS: Rot-navnetjener 13 rot-navnetjenere i verden
b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 13 rot-navnetjenere i verden Kap 2: Applikasjonslaget

DNS - Domain Name System
RFC1034, RFC1035 Navnløs rot COM EDU GOV MIL NET ORG ARPA AE NO ZW Top Level Domains (TLD) IN-ADDR 36 136 69 196 YAHOO PEOPLE NO HIOF IT Second Level Domains .gov og .mil er reservert for USAs myndigheter og militære Generiske domener Landdomener ARPA - spesielt domene for adresse-til-navn mapping Kap 2: Applikasjonslaget

autoritativ DNS-server
Eksempel rot DNS-server Maskin på cis.poly.edu ønsker IP-adressen til gaia.cs.umass.edu rekursiv forespørsel (query): legger byrden med navneoppslag på kontaktet navnetjener kan gi stor belastning 2 3 6 7 TLD DNS-server lokal DNS-server dns.poly.edu 4 5 1 8 autoritativ DNS-server dns.cs.umass.edu spørrende maskin cis.poly.edu gaia.cs.umass.edu Kap 2: Applikasjonslaget

autoritativ DNS-server
Iterativ forespørsel rot DNS-server 2 iterativ forespørsel: kontaktet navnetjener svarer med adressen til navnetjener som kan kontaktes 3 TLD DNS-server 4 5 lokal DNS-server dns.poly.edu 7 6 1 8 autoritativ DNS-server dns.cs.umass.edu spørrende maskin cis.poly.edu gaia.cs.umass.edu Kap 2: Applikasjonslaget

DNS: caching og recordoppdatering
når en navnetjener får kjennskap til en “mapping”, vil den cache den mappinger i cache vil fjernes etter en tid TLD servere vil typisk caches i lokale navnetjenere Trenger derfor sjelden å kontakte rotnavnetjenere “update/notify” mekanismer designes nå av IETF RFC 2136, RFC 3007 Kap 2: Applikasjonslaget

RR format: (navn, verdi, type, ttl)
DNS records RR format: (navn, verdi, type, ttl) Type=A navn er maskinnavn verdi er IP-adresse Type=CNAME navn er alias-navn for et “kanonisk” (et virkelig) navn is really servereast.backup2.ibm.com verdi er kanonisk navn Type=NS navn er domene (f eks foo.com) verdi er IP-adressen til autoritativ navnetjener for dette domenet Type=MX verdi er navn på mail-serveren assosiert med navn Kap 2: Applikasjonslaget

DNS-meldinger DNS protokollen : query (forespørsel) og reply (svar) meldinger har samme meldingsformat meldingsheader identification: 16 bits id-nummer for forespørsel, svar på spørsmål benytter samme nummer flagg: query (0) eller reply (1) rekursjon ønsket rekursjon tilgjengelig svar er autoritativt Kap 2: Applikasjonslaget

DNS-meldinger (forts)
Navn- og type-felt for en query RR som svar på query records for andre autoritative tjenere tilleggsinfo som kan benyttes Kap 2: Applikasjonslaget

Innlegging av records i DNS
Eksempel: har laget “Network Utopia” Registrerer navnet networkuptopia.com hos en registrar (liste hos Internic (.com) eller Norid (.no)) Gir registraren navn og IP-adresser til dine autoritative navnetjenere (primær og sekundær) Registrar legger inn to RRs i com TLD-server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Legger inn autoritativ server Type A record for og Type MX record for networkutopia.com Kap 2: Applikasjonslaget

P2P fildeling Alice velger en av dem, Bob
Filen kopieres fra Bobs PC til Alices PC v.hj.a HTTP Men Alice laster ned sangen kan andre brukere hente filer fra Alice Alices peer er både en web-klient og en midlertidig webserver Alle peers er servere = skalerer bra! Eksempel Alice kjører en P2P klient applikasjon på sin PC Av og til knytter hun seg til Internett; får ny IP-adresse hver gang Spør etter “Beautiful” Applikasjonen viser andre peers som har en kopi av Beautiful Kap 2: Applikasjonslaget

P2P: sentralisert katalog
katalogserver peers Alice Bob 1 2 3 det originale “Napster”-designet 1) når peer knytter seg opp, informerer den en sentral server om: IP-adresse innhold den vil dele 2) Alice spør serveren om “Beautiful” 3) Alice ber Bob om å overføre filen Kap 2: Applikasjonslaget

P2P: problemer med sentralisert katalog
“Single point of failure” Flaskehals for ytelsen Problemer med opphavsrett (copyright) Filoverføringen er desentralisert, men å finne innhold er sentralisert Kap 2: Applikasjonslaget

Query flooding: Gnutella
helt distribuert ingen sentral server offentlige (public domain) protokoller many Gnutella clients implementing protocol “overlay network”: graf kant mellom peer X og Y hvis det eksisterer en TCP-forbindelse alle aktive peers og kanter utgjør “overlay nettet” Kant er ikke en fysisk link Hver peer vil typisk være knyttet til færre enn 10 naboer Kap 2: Applikasjonslaget

Gnutella: protokoll Filoverføring: HTTP Forespørsel sendes over eksisterende TCP-forbindelser peers videresender forespørsler QueryHit sendes over tilbake samme vei Query QueryHit Skalerbarhet: begrense rekke- vidde på flooding Kap 2: Applikasjonslaget

Gnutella: Tilknytning av ny peer
Når peer X ønsker å knytte seg til, må den finne en annen peer i Gnutella nettet: bruker liste av mulige peers X forsøker å etablere TCP-forbindelse etter tur med nodene på listen inntil den får kontakt med en node, Y X sender ”ping”-melding til Y; Y videresender den Alle peers som mottar ”ping”-melding svarer med en ”pong”-melding X mottar mange ”pong”-meldinger og kan da sette opp flere TCP-forbindelser Kap 2: Applikasjonslaget

Utnyttelse av heterogenitet: KaZaA
Hver peer er enten en gruppeleder eller tilordnet et en gruppeleder TCP-forbindelse mellom peer og dens gruppeleder TCP-forbindelse mellom noen gruppeledere Gruppeleder har info om innhold hos alle sine “barn” Kap 2: Applikasjonslaget

KaZaA: Forespørsel Hver fil har en “hash” og en deskriptor
Klient sender nøkkelord-forespørsel til sin gruppeleder Gruppeleder svarer med de treff den har funnet: For hvert treff: metadata, hash og IP-adresse Hvis gruppeleder videresender forespørsel til andre gruppeledere, vil de svare med sine treff Klient velger de filer den ønsker å laste ned HTTP-forespørsel med hash som identifikator sendes til de som har den ønskede filen Kap 2: Applikasjonslaget

KaZaA-teknikker Begrensninger i samtidige opplastinger Forespørselskø
Incentiv-prioriteringer Parallell nedlasting Kap 2: Applikasjonslaget

applikasjonsgenerert,
Socketprogrammering Mål: lære hvordan man lager klient/tjener-applikasjoner som kommuniserer via sockets Socket API introdusert i BSD4.1 UNIX, 1981 genereres, brukes og fjernes av applikasjoner klient/tjener paradigme to typer transport-tjenester via socket API: upålitelig datagram pålitelig, byte-strøm- orientert et maskin-lokalt, applikasjonsgenerert, OS-kontrollert grensesnitt (en “dør”) som applikasjonsprosesser kan sende og motta meldinger gjennom, meldinger til eller fra andre applikasjonsprosesser socket Kap 2: Applikasjonslaget

Socketprogrammering med TCP
Socket: en dør mellom applikasjonsprosess og ende-til-ende protokoll (UCP eller TCP) TCP tjeneste: pålitelig overføring av byte fra en prosess til en annen styrt av applikasjons- utvikler styrt av applikasjons- utvikler prosess TCP med buffere, variable socket prosess TCP med buffere, variable socket styrt av operativ- systemet styrt av operativ- systemet internett maskin eller tjener maskin eller tjener Kap 2: Applikasjonslaget

Socket programmering med TCP
Klient må kontakte server server prosess må være kjørende server må ha etablert en velkomst-socket Klient kontakter server ved å: lage en TCP socket hos seg selv spesifisere IP-adresse og portnummer til server-prosessen Når klienten etablerer socket: klient-TCP etablerer forbindelse til server-TCP Når den kontaktes av en klienten, vil server TCP etablere en ny socket som kan brukes av serverprosessen for å kommunisere med klienten tillater at server snakker med flere klienter avsenders portnummer brukes for å skille klienter (mer om dette i kap 3) applikasjonens ståsted TCP gir pålitelig, rekkefølge- bevarende overføring av byte (“rør”) mellom klient og server Kap 2: Applikasjonslaget

Oppretting av forbindelse

“Strøm”-terminologi En strøm er en sekvens av tegn som flyter inn i eller ut av en prosess En input strøm er knyttet til en input-kilde for prosessen, f eks tastatur eller socket En output strøm er knyttet til en utgang, f eks skjerm eller socket Kap 2: Applikasjonslaget

Socket programmering med TCP
Eksempel klient-server app: 1) klient leser linje fra standard input (inFromUser strøm) , sender denne til server via socket (outToServer strøm) 2) server leser linje fra socket 3) server konverterer linja til versaler og sender den tilbake til klient 4) klient leser og skriver ut modifisert linje fra socket (inFromServer strøm) Klient- prosess klient TCP socket Kap 2: Applikasjonslaget

Klient/tjener socket-interaksjon: TCP
Tjener (kjører på maskinen hostid) Klient generér socket, port = x, for innkommende forespørsel: welcomeSocket = ServerSocket() TCP oppsetting av forbindelse lukk connectionSocket les svar fra clientSocket generér socket, etablér forbindelse til hostid, port x clientSocket = Socket() vent på innkommde foresp. om forbindelse connectionSocket = welcomeSocket.accept() send foresp. clientSocket les foresp. fra connectionSocket skriv svar til Kap 2: Applikasjonslaget

Eksempel: Java-klient (TCP)
import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Lag input-strøm Generér klient-socket, kontakt tjener Lag output-strøm forbundet med socket Kap 2: Applikasjonslaget

Eksempel: Java-klient (TCP), forts.
Lag input- strøm forbundet med socket BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } Send linje til tjener Les linje fra tjener Kap 2: Applikasjonslaget

Klientprosessen: socket og strømmer
tastatur skjerm input strøm inFromUser Client process Klient- prosess output input strøm outToServer inFromServer strøm klient TCP- socket TCP socket til nettet fra nettet Kap 2: Applikasjonslaget

Eksempel: Java-server (TCP)
import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Generér velkomst-socket på port 6789 Vent ved velkomst- socket på å bli kontaktet av klient Lag input- strøm knyttet til socket Kap 2: Applikasjonslaget

Eksempel: Java-server (TCP), forts.
DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Lag output- strøm knyttet til socket Les inn linje fra socket Skriv ut linje til socket enden av while-løkke, vent på neste kontakt (fra annen klient) Kap 2: Applikasjonslaget

Socket programmering med UDP
UDP: ingen “forbindelse” mellom klient og server ingen håndhilsing sender må eksplisitt sette på mottagers IP-adresse og portnummer på hver pakke server må ekstrahere senderens IP-adresse og portnummer fra den mottatte pakken UDP: data som sendes kan mottas i feil rekkefølge eller de kan gå tapt på veien applikasjonens ståsted UDP gir upålitelig overføring av pakker (“datagrams”) mellom klient og server Kap 2: Applikasjonslaget

Klient/tjener socket-interaksjon: UDP
Tjener (kjører på hostid) generér socket clientSocket = DatagramSocket() Klient Lag datagram med data og adresse (hostid, port=x) og send datagram ved hjelp av clientSocket generér socket, port = x, for innkommende forespørsel: serverSocket = DatagramSocket() les foresp. fra serverSocket lukk clientSocket les svar fra clientSocket skriv svar til serverSocket med angivelse av klientens adresse og portnummer Kap 2: Applikasjonslaget

Eksempel: Java-klient (UDP)
import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[ ] sendData = new byte[1024]; byte[ ] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Lag input-strøm Generér klient-socket Oversett maskinnavn til IP-adresse v.hj.a. DNS Kap 2: Applikasjonslaget

Eksempel: Java-klient (UDP), forts.
Lag datagram med data som skal sendes, lengde, IP-adr, port DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Send datagram til tjener Les datagram fra tjener Kap 2: Applikasjonslaget

Eksempel: Java-klient (UDP)
tastatur skjerm input Klient prosess strøm inFromUser Input: mottar pakke (TCP mottok “byte stream”) Output: sender pakke (TCP sendte “byte stream”) UDP sendPacket receivePacket UDP pakke pakke klient UDP- socket UDP socket til nettet fra nettet Kap 2: Applikasjonslaget

Eksempel: Java-tjener (UDP)
import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[ ] receiveData = new byte[1024]; byte[ ] sendData = new byte[1024]; while(true) DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Generér datagram socket på port 9876 Lag plass for mottatt datagram Motta datagram Kap 2: Applikasjonslaget

Eksempel: Java-tjener (UDP), forts
String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Få IP-adr og portnr fra avsender Lag datagram for sending til klient Skriv ut datagram til socket Enden av while-løkke, vent på neste datagram Kap 2: Applikasjonslaget

Bygge en enkel web-server
håndterer kun en HTTP-forespørsel av gangen aksepterer forespørselen parser headeren finner ønsket fil i serverens filsystem lager HTTP-respons-melding: header-linjer + fil sender responsen til klienten Kap 2: Applikasjonslaget

Kapittel 2: Oppsummering
Vårt studium av nettverksapplikasjoner er nå ferdig protokoller vi har sett på: HTTP FTP SMTP, POP, IMAP DNS socket programmering Applikasjonsarkitekturer klient-tjener P2P hybrid tjenestekrav fra applikasjonene: pålitelighet, båndbredde, forsinkelse Internetts transport-tjenester forbindelsesorientert, pålitelig: TCP upålitelig, datagram: UDP Kap 2: Applikasjonslaget

Kapittel 2: Oppsummering
Viktigste: lært om protokoller typisk request/reply meldingsutveksling: klient ber om info eller tjeneste tjener (server) svarer med data og/eller statuskode meldingsformater: headere: felter med info om data data: info som skal oversendes kontroll- vs. datameldinger in-band, out-of-band sentralisert vs. desentralisert tilstandsløs vs. tilstandsorientert pålitelig vs. upålitelig meldingsoverføring “kompleksitet i kanten av nettet” Kap 2: Applikasjonslaget

Kapittel 2 Application Layer

Liknende presentasjoner

Presentasjon om: "Kapittel 2 Application Layer"— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding

Logg inn

Logg deg på via sosiale nettverk:

Kapittel 2 Application Layer

Liknende presentasjoner

Presentasjon om: "Kapittel 2 Application Layer"— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding