1 / 68

Datakommunikasjon Høsten 2002

Datakommunikasjon Høsten 2002. Forelesning nr 2, 19. august Chapter 2, Application Layer. Øvingsoppgaver. Ingen. Applikasjonsprotokoller. FTP – File Transfer protocol DNS – Domain Name System HTTP – HyperText Transfer protocol Telnet, Rlogin SNMP – Simple Network Management Protocol

aidan-king
Download Presentation

Datakommunikasjon Høsten 2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Øvingsoppgaver • Ingen

  3. Applikasjonsprotokoller • FTP – File Transfer protocol • DNS – Domain Name System • HTTP – HyperText Transfer protocol • Telnet, Rlogin • SNMP – Simple Network Management Protocol • SMTP - Simple Mail Transfer Protocol • POP3 – Post Office Protocol • IMAP – Internet Mail Access Protocol

  4. Application Application Presentation Session Transport Transport Network Network Data Link Data Link Physical Kommunikasjonslagene (referert til OSI) OSI Internet-TCP/IP FTP HTTP SMTP DNS TCP UDP ICMP IP ARP PPP Ethernet

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

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

  7. API: application programming interface defines interface between application and transport layers socket: Internet API two 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? IP address of host running other process “port number” - allows receiving host to determine to which local process the message should be delivered Application-layer protocols (cont).

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

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

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

  11. Internet apps: application, transport protocols 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 TCP TCP TCP or UDP TCP or UDP typically UDP Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony

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

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

  14. Sample commands: sent as ASCII text over control channel USER username PASS password LISTreturn list of file in current directory RETR filenameretrieves (gets) file STOR filenamestores (puts) file onto remote host Sample return codes status code and phrase (as in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file ftp commands, responses

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

  16. DNS - Domain Name System RFC1034, RFC1035 • Mapper mellom hostnavn og IP-adresse(og omvendt) • Benyttes av TCP/IP applikasjoner • Distribuert, hierarkisk • Benytter både TCP og UDP som transport, port nummer 53 • Eksempler • DNS Query • DNS Reply

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

  18. contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server 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 k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA DNS: Root name servers 13 root name servers worldwide

  19. 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 local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu

  20. Root name server: may not know authoritative name server may know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

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

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

  23. DNS: distributed db storing resource records (RR) 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) DNS resource records • Type=A • name is hostname • value is IP address • Type=CNAME • name is alias name for some “cannonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com • value is cannonical name • Type=MX • value is name of mailserver associated with name

  24. DNS protocol :queryand reply messages, both with same message format DNS protocol, messages msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative

  25. DNS - Domain Name System RFC1034, RFC1035 • Distribuert • Ingen navneserver har lagret all informasjon • Et nett (firma, organisasjon o.l) har en eller flere navneservere • Inneholder hele eller deler av egne definisjoner • Håndterer også forespørsler utenfra • Hierarkisk • Hvis egen server ikke har nødvendig informasjon, sendes forespørselen til nivået over • Et overliggende nivå vil gjenkjenne nok til å kunne velge underliggende nivå for forespørsel.

  26. COM EDU GOV MIL NET ORG AE NO ZW ARPA YAHOO SCANDPOWER IN-ADDR PEOPLE WWW 36 NO 136 69 Generic Domains Country Domains 196 DNS - Domain Name System RFC1034, RFC1035 Unnamed root Top Level Domains Second Level Domains ARPA - Special Domain for address-to-name mappings

  27. DNS - Domain Name System RFC1034, RFC1035 • Resultat fra en ekstern forespørsel kan lagres i lokal navneserver til senere bruk • En DNS respons vil inneholde informasjon om kilden er autoritativ eller ikke.

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

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

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

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

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

  33. http message format: request • two types of http messages: request, response • http request message: • ASCII (human-readable format) request line (GET, POST, HEAD commands) 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) header lines Carriage return, line feed indicates end of message

  34. http request message: general format

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

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

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

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

  39. Assume: cache is “close” to client (e.g., in same network) smaller response time: cache “closer” to client decrease traffic to distant servers link out of institutional/local ISP network often bottleneck Why Web Caching? origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN 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: enLine 4: Accept-Encoding: gzip, deflateLine 5: If-Modified-Since: Wed, 26 Sep 2001 09:30:23 GMTLine 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/1.1 304 Not Modified Line 2: Server: Microsoft-IIS/4.0 Line 3: Date: Sun, 04 Nov 2001 16:20:09 GMT Line 4: Content-Location: http://intranett.halden.scandpower.no/Default.htm Line 5: ETag: "502728de6d46c11:1c8e" Line 6: Content-Length: 0

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

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

  44. SNMP – Simple Network Management Protocol Request Manager Agent Response Unsolicited trap Network Management Station Network Management Protocol Managed Node (Management Information)

  45. SNMP protokollen GetRequest, GetNextRequest, SetRequest Manager Agent Port 161 GetResponse Trap Port 162

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

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

  48. Internet Mail • User agent, dvs Outlook, Eudora, Pegasus osv • Mail transfer Agent, dvs Microsoft Exchange, Sendmail • SMTP - Simple Mail Transfer Protocol • TCP/IP • Kun sending av tekst • MIME - Multi-purpose Internet Mail Extension • Sending av bilder, video osv • POP 3 - Post Office Protocol ver 3 • IMAP - Internet Message Access Protocol • MX-records (Mail Exchange records) Del an DNS (Domain Name System)

  49. SMTP Mail Flyt

  50. User Agent (mail program) • Lese og sende mail • Opsjoner: • Videresending til andre • Svarsfunksjon • Filtrering av innkommende mail til ulike mail bokser • Signatur fil • Adresslister, aliases

More Related