Presentation is loading. Please wait.

Presentation is loading. Please wait.

Datakommunikasjon Høsten 2002 Forelesning nr 2, 19. august Chapter 2, Application Layer.

Similar presentations


Presentation on theme: "Datakommunikasjon Høsten 2002 Forelesning nr 2, 19. august Chapter 2, Application Layer."— Presentation transcript:

1 Datakommunikasjon Høsten 2002 Forelesning nr 2, 19. august Chapter 2, Application Layer

2 Øvingsoppgaver zIngen

3 Applikasjonsprotokoller zFTP – File Transfer protocol zDNS – Domain Name System zHTTP – HyperText Transfer protocol zTelnet, Rlogin  SNMP – Simple Network Management Protocol zSMTP - Simple Mail Transfer Protocol zPOP3 – Post Office Protocol zIMAP – Internet Mail Access Protocol

4 Kommunikasjonslagene (referert til OSI) ApplicationPresentationSession Ethernet IP ARP ICMP TCPUDP NetworkTransportData LinkPhysicalApplicationTransportNetworkData Link PPP FTPHTTP DNS OSI Internet-TCP/IP SMTP

5 Network applications: some jargon Process: program running within a host. zwithin same host, two processes communicate using interprocess communication (defined by OS). zprocesses running in different hosts communicate with an application-layer protocol z user agent: software process, interfacing with user “above” and network “below”. yimplements application-level protocol yWeb: browser y mail reader ystreaming audio/video: media player

6 Client-server paradigm Typical network app has two pieces: client and server application transport network data link physical application transport network data link physical Client: zinitiates contact with server (“speaks first”) ztypically requests service from server, zWeb: client implemented in browser; in mail reader request reply Server: zprovides requested service to client ze.g., Web server sends requested Web page, mail server delivers

7 Application-layer protocols (cont). API: application programming interface zdefines interface between application and transport layers zsocket: Internet API ytwo processes communicate by sending data into socket, reading data out of socket Q: how does a process “identify” the other process with which it wants to communicate? yIP address of host running other process y“port number” - allows receiving host to determine to which local process the message should be delivered

8 What transport service does an app need? Data loss zsome apps (e.g., audio) can tolerate some loss zother apps (e.g., file transfer, telnet) require 100% reliable data transfer Timing z some apps (e.g., Internet telephony, interactive games) require low delay to be “effective” Bandwidth zsome apps (e.g., multimedia) require minimum amount of bandwidth to be “effective” zother apps (“elastic apps”) make use of whatever bandwidth they get

9 Transport service requirements of common apps Application file transfer Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss loss-tolerant no loss Bandwidth elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

10 Internet transport protocols services TCP service: zconnection-oriented: setup required between client, server zreliable transport between sending and receiving process zflow control: sender won’t overwhelm receiver zcongestion control: throttle sender when network overloaded zdoes not providing: timing, minimum bandwidth guarantees UDP service: z unreliable data transfer between sending and receiving process z does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee

11 Internet apps: application, transport protocols Application remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NSF proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP or UDP typically UDP

12 ftp: the file transfer protocol ztransfer file to/from remote host zclient/server model yclient: side that initiates transfer (either to/from remote) yserver: remote host zftp: RFC 959 zftp server: port 21 file transfer FTP server FTP user interface FTP client local file system remote file system user at host

13 ftp: separate control, data connections zftp client contacts ftp server at port 21, specifying TCP as transport protocol ztwo parallel TCP connections opened: ycontrol: exchange commands, responses between client, server. “out of band control” ydata: file data to/from server zftp server maintains “state”: current directory, earlier authentication FTP client FTP server TCP control connection port 21 TCP data connection port 20

14 ftp commands, responses Sample commands: zsent as ASCII text over control channel  USER username  PASS password  LIST return list of file in current directory  RETR filename retrieves (gets) file  STOR filename stores (puts) file onto remote host Sample return codes z status code and phrase (as in http) z331 Username OK, password required z125 data connection already open; transfer starting z425 Can’t open data connection z452 Error writing file

15 DNS: Domain Name System People: many identifiers: ySSN, name, passport # Internet hosts, routers: yIP address (32 bit) - used for addressing datagrams y“name”, e.g., gaia.cs.umass.edu - used by humans Q: map between IP addresses and name ? Domain Name System: z distributed database implemented in hierarchy of many name servers z application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) ynote: core Internet function, implemented as application- layer protocol ycomplexity at network’s “edge”

16 DNS - Domain Name System zMapper mellom hostnavn og IP-adresse (og omvendt) zBenyttes av TCP/IP applikasjoner zDistribuert, hierarkisk zBenytter både TCP og UDP som transport, port nummer 53 zEksempler yDNS QueryDNS Query yDNS ReplyDNS Reply RFC1034RFC1034, RFC1035RFC1035

17 DNS name servers zno server has all name-to- IP address mappings local name servers: yeach ISP, company has local (default) name server yhost DNS query first goes to local name server authoritative name server: yfor a host: stores that host’s IP address, name ycan perform name/address translation for that host’s name Why not centralize DNS? z single point of failure z traffic volume z distant centralized database z maintenance doesn’t scale!

18 DNS: Root name servers zcontacted by local name server that can not resolve name zroot name server: ycontacts authoritative name server if name mapping not known ygets mapping yreturns mapping to local name server 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 root name servers worldwide

19 Simple DNS example host surf.eurecom.fr wants IP address of gaia.cs.umass.edu 1. contacts its local DNS server, dns.eurecom.fr 2. dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.umass.edu, if necessary requesting host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu local name server dns.eurecom.fr

20 DNS example Root name server: zmay not know authoritative name server zmay know intermediate name server: who to contact to find authoritative name server requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

21 DNS: iterated queries recursive query: zputs burden of name resolution on contacted name server zheavy load? iterated query: zcontacted server replies with name of server to contact z“I don’t know this name, but ask this server” requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

22 DNS: caching and updating records zonce (any) name server learns mapping, it caches mapping ycache entries timeout (disappear) after some time zupdate/notify mechanisms under design by IETF yRFC 2136 yhttp://www.ietf.org/html.charters/dnsind-charter.html

23 DNS resource records DNS: distributed db storing resource records (RR) z Type=NS  name is domain (e.g. foo.com)  value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl) zType=A  name is hostname  value is IP address zType=CNAME  name is alias name for some “cannonical” (the real) name is really servereast.backup2.ibm.com  value is cannonical name zType=MX  value is name of mailserver associated with name

24 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header zidentification: 16 bit # for query, reply to query uses same # zflags: yquery or reply yrecursion desired yrecursion available yreply is authoritative

25 DNS - Domain Name System RFC1034RFC1034, RFC1035RFC1035 zDistribuert yIngen navneserver har lagret all informasjon yEt nett (firma, organisasjon o.l) har en eller flere navneservere xInneholder hele eller deler av egne definisjoner xHåndterer også forespørsler utenfra zHierarkisk yHvis egen server ikke har nødvendig informasjon, sendes forespørselen til nivået over yEt overliggende nivå vil gjenkjenne nok til å kunne velge underliggende nivå for forespørsel.

26 DNS - Domain Name System RFC1034RFC1034, RFC1035RFC1035 Top Level Domains Second Level Domains Unnamed root IN- ADDR YAHOO PEOPLE NO SCANDPOWER WWW Generic DomainsCountry Domains ARPA - Special Domain for address-to-name mappings COMEDUGOVMILNETORGARPAAENOZW

27 DNS - Domain Name System RFC1034RFC1034, RFC1035RFC1035 zResultat fra en ekstern forespørsel kan lagres i lokal navneserver til senere bruk zEn DNS respons vil inneholde informasjon om kilden er autoritativ eller ikke.

28 The Web: the http protocol http: hypertext transfer protocol zWeb’s application layer protocol zclient/server model yclient: browser that requests, receives, “displays” Web objects yserver: Web server sends objects in response to requests zhttp1.0: RFC 1945 zhttp1.1: RFC 2068 PC running Explorer Server running NCSA Web server Mac running Navigator http request http response

29 The http protocol: more http: TCP transport service: zclient initiates TCP connection (creates socket) to server, port 80 zserver accepts TCP connection from client zhttp messages (application-layer protocol messages) exchanged between browser (http client) and Web server (http server) zTCP connection closed http is “stateless” z server maintains no information about past client requests

30 http example Suppose user enters URL 1a. http client initiates TCP connection to http server (process) at Port 80 is default for http server. 2. http client sends http request message (containing URL) into TCP connection socket 1b. http server at host waiting for TCP connection at port 80. “accepts” connection, notifying client 3. http server receives request message, forms response message containing requested object ( someDepartment/home.index ), sends message into socket time (contains text, references to 10 jpeg images)

31 http example (cont.) 5. http client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4. http server closes TCP connection. time

32 Non-persistent, persistent connections Non-persistent zhttp/1.0: server parses request, responds, closes TCP connection zeach transfer suffers from TCP’s initially slow sending rate zmany browsers open multiple parallel connections Persistent z default for htp/1.1 z on same TCP connection: server, parses request, responds, parses new request,.. z client sends requests for all referenced objects as soon as it receives base HTML. z fewer RTTs, less slow start.

33 http message format: request ztwo types of http messages: request, response zhttp request message: yASCII (human-readable format) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message

34 http request message: general format

35 http message format: response HTTP/ OK 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... status line (protocol status code status phrase) header lines data, e.g., requested html file

36 http response status codes 200 OK yrequest succeeded, requested object later in this message 301 Moved Permanently yrequested object moved, new location specified later in this message (Location:) 400 Bad Request yrequest message not understood by server 404 Not Found yrequested document not found on this server 505 HTTP Version Not Supported In first line in server->client response message. A few sample codes:

37 Cookies: keeping “state” zserver-generated #, server-remembered #, later used for: yauthentication yremembering user preferences, previous choices zserver sends “cookie” to client in response msg Set-cookie: zclient presents cookie in later requests cookie: client server usual http request msg usual http response + Set-cookie: # usual http request msg cookie: # usual http response msgusual http request msg cookie: # usual http response msg cookie- specific action cookie- specific action

38 Web Caches (proxy server) zuser sets browser: Web accesses via web cache zclient sends all http requests to web cache yobject in web cache: web cache returns object yelse web cache requests object from origin server, then returns object to client Goal: satisfy client request without involving origin server client Proxy server client http request http response http request http response origin server origin server

39 Why Web Caching? Assume: cache is “close” to client (e.g., in same network) zsmaller response time: cache “closer” to client zdecrease traffic to distant servers ylink out of institutional/local ISP network often bottleneck origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

40 HTTP eksempel (GET) (REQUEST METODE) Line 1: GET / HTTP/1.1 (REQUEST HEADER PARAMETER) Line 2: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Line 3: Accept-Language: en Line 4: Accept-Encoding: gzip, deflate Line 5: If-Modified-Since: Wed, 26 Sep :30:23 GMT Line 6: If-None-Match: "502728de6d46c11:1c8e” Line 7: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4. 0; TUCOWS) Line 8: Host: intranett.halden.scandpower.no (GENERAL HEADER FIELD) Line 9: Connection: Keep-Alive

41 HTTP eksempel (Get response) Line 1: HTTP/ Not Modified Line 2: Server: Microsoft-IIS/4.0 Line 3: Date: Sun, 04 Nov :20:09 GMT Line 4: Content-Location: Line 5: ETag: "502728de6d46c11:1c8e" Line 6: Content-Length: 0

42 HTTP eksempel (response) Line 1: HTTP/ OK Line 2: Server: Microsoft-IIS/4.0 Line 3: Date: Sun, 04 Nov :20:09 GMT Line 4: Content-Type: application/x-javascript Line 5: Accept-Ranges: bytes Line 6: Last-Modified: Fri, 02 Nov :58:51 GMT Line 7: ETag: "80f66b80a663c11:1c8e" Line 8: Content-Length: 14481

43 Telnet og Rlogin zInnlogging fra en maskin til en annen over nettet zBenytter seg av klient-tjener begrepet zTelnet er en standard applikasjon som er implementert i alle TCP/IP applikasjoner zRlogin kommer fra Berkley Unix og ble utviklet for pålogging mellom to Unix systemer zTelnet er mer kompleks enn Rlogin

44 44 SNMP – Simple Network Management Protocol Request Response Unsolicited trap ManagerAgent Network Management Station Network Management ProtocolManaged Node (Management Information)

45 45 SNMP protokollen ManagerAgent GetRequest, GetNextRequest, SetRequest GetResponse Trap Port 161 Port 162

46 46 SNMP innkapsling LLC/MAC header IP header UDP header SNMP melding LLC/MAC trailer Data Link nivåNettverks- nivå Transport- nivå Applikasjons- nivå SNMP innkapsling:

47 47 SNMPv1 melding En SNMPv1 melding består av 3 deler: Versjons nummer Community string En av de 5 SNMP PDUene

48 Internet Mail zUser agent, dvs Outlook, Eudora, Pegasus osv zMail transfer Agent, dvs Microsoft Exchange, Sendmail zSMTP - Simple Mail Transfer Protocol yTCP/IP yKun sending av tekst zMIME - Multi-purpose Internet Mail Extension ySending av bilder, video osv zPOP 3 - Post Office Protocol ver 3 zIMAP - Internet Message Access Protocol zMX-records (Mail Exchange records) Del an DNS (Domain Name System)

49 SMTP Mail Flyt

50 User Agent (mail program) zLese og sende mail zOpsjoner: yVideresending til andre ySvarsfunksjon yFiltrering av innkommende mail til ulike mail bokser ySignatur fil yAdresslister, aliases

51 Mail Transfer Agent (MTA) zAnsvarlig for å sende mailen gjennom nettet zBaseres på SMTP (Simple Mail Transfer Protocol) zSMTP er en enkel ASCII protokoll zBenytter TCP og port 25 for å opprette en forbindelse mellom to MTA-er

52 Sammensetning av en mail zEnvelopes yBrukes av Message Transfer Agent zHeaders yBrukes av User Agent zBody yInnholdet i mailen (tekst og vedlegg)

53 Envelopes - eksempel Received: from sara.halden.scandpower.no ([ ]) by Received: from sara.halden.scandpower.no ([ ]) by janis.halden.scandpower.no with SMTP (Microsoft Exchange Internet Mail Service Version ) id RCM02KCM; Mon, 20 Aug :41: Received: from fw.scandpower.no (mail.hrp.no [ ]) by sara.halden.scandpower.no (8.9.3/8.9.3) with SMTP id MAA12382 for ; Mon, 20 Aug :43: Received: from mail.hrp.no ([ ]) by fw.scandpower.no via smtpd (for sara.halden.scandpower.com [ ]) with SMTP; 20 Aug :44:06 UT Received: from pcthorbjornb (pc-thorbjornb.hrp.no [ ]) by mail.hrp.no (8.10.1/8.9.0) with SMTP id f7KAlXK14155; Mon, 20 Aug :47: (METDST)

54 Header - eksempel zMessage-ID: zFrom: Per Hansen zTo: zSubject: security

55 SMTP-kommandoer (RFC 821) zHELO zMAIL FROM: zRCPT TO: zDATA z. zQUIT

56 MX-records zBrukes for å fortelle omverdenen om hvem som er mail server zDel av DNS (Domain Name System) zMX-recorden for en domene forteller i prioritert rekkefølge hvor mailen skal sendes

57 MX-record eksempel zMX-record for scandpower.no 1. prioritet: bill.halden.scandpower.no 2. prioritet: mail.globalone.no  Mail leveres til mail.globalone.no hvis mailserver bill er nede eller forbindelsen til Internett er nede

58 POP 3 zPost Office Protocol number 3 zProtokoll for å hente mail fra mail server til en mail klient (f.eks Outlook eller Eudora) zBruker TCP og port 110 zBaserer seg på enkle ASCII kommandoer

59 POP3 kommandoer zUSER username zPASS password zSTAT [gir antall uleste meldinger] zLIST (n) 8gir størrelse på melding n] zRETR n [hent melding nr n] zDELE n [slett melding nr n] zQUIT

60 Internet Message Access Protocol - IMAP zMail klient zTilsvarende som POP3, men all behandling av mail foregår på mailserveren zPOP3 henter mailen ned til User Agent

61 MIME – Multipurpose Internet Mail Extension zUtvidelse av SMTP for å kunne overføre filer som ikke er 7-bit ASCII zMIME informasjon i mail: yMIME-Version yContent-Type yContent-Transfer-Encoding y(Content-Description) y(Content-ID)

62 MIME – Content Type zText zImage zAudio zApplication (Word, Postscript, ) zMultipart (Mixed, alternative)

63 MIME – Content-transfer encoding zForteller hvordan innholdet av mailen er kodet z Fem forskjellige kode formater er definert y7 bits ASCII yQuoted Printable ybase64 y8 bits som inneholder linjer ybinær koding, 8 bit data uten linjer

64 Quoted Printable z7 bit ASCII med alle karakterer 127 kodes som likhetstegn + verdien av tegnet som to hexadecimale tegn zeks. bokstaven ”å” kodes som =E5 zKarakteresettet ISO-8859 gir å=229 desimalt 229= z1110=E z1110=5 z”å” kodes som =E5

65 Base 64 Encoding

66 Base 64 encoding zTre bytes med data kodes som fire 6 bits karakterer zOrginale data: Hi! H i ! (24 bit) S G k h zDatamengden øker med 25%

67 MIME - eksempel zMIME-Version: 1.0 zX-Mailer: Internet Mail Service ( ) zContent-Type: text/plain; zcharset="iso " zContent-Transfer-Encoding: quoted-printable

68 MIME eks. Word fil som vedlegg MIME-Version: 1.0 Content-Type: multipart/mixed; Content-Type: text/plain; charset="iso " Content-Type: application/msword; Content-Transfer-Encoding: base64


Download ppt "Datakommunikasjon Høsten 2002 Forelesning nr 2, 19. august Chapter 2, Application Layer."

Similar presentations


Ads by Google