Presentation is loading. Please wait.

Presentation is loading. Please wait.

Network Applications 9/14/2009. 2 Outline  Recap r ISO/OSI Layering and Internet Layering r Application layer overview r Examples.

Similar presentations


Presentation on theme: "Network Applications 9/14/2009. 2 Outline  Recap r ISO/OSI Layering and Internet Layering r Application layer overview r Examples."— Presentation transcript:

1 Network Applications 9/14/2009

2 2 Outline  Recap r ISO/OSI Layering and Internet Layering r Application layer overview r Examples

3 3 Recap: Summary of the Taxonomy of Communication Networks circuit-switched network communication network switched network broadcast communication packet-switched network datagram network virtual circuit network

4 4 Recap: Statistical Multiplexing r no reservation: all arrivals into the single link with rate R, the queueing delay + transmission delay: r reservation: each flow uses its own reserved (sub)link with rate R/n, the queueing delay + transmission delay: A simple model to compare bandwidth efficiency of - reservation/dedication (aka circuit-switching) and - no reservation (aka packet switching) setup - a single bottleneck link with rate R - n flows; each flow has an arrival rate of a/n

5 Recap: Layering r Layered reference model for discussion r Modularization eases maintenance, updating of system r Physical vs logical communication r Key design decision: what functionalities to put in each layer? 5

6 6 Recap: End-to-End Arguments r If a higher layer can do it, don’t do it at a lower layer -- the higher the layer, the more it knows about the best what it needs r Add functionality in lower layers iff it (1) is used by and improves performance of a large number of (current and potential future) applications, (2) does not hurt (too much) other applications, and (3) does not increase (too much) complexity/overhead r Practical tradeoff, e.g., m allow multiple interfaces at a lower layer (one provides the function; one does not)

7 7 Examples r We used reliability as an example r Assume two layers (L1: network; L2: end-to-end). Where may you implement the following functions? r security (privacy of traffic) r quality of service (e.g., delay/bandwidth guarantee) r congestion control (e.g., not to overwhelm network links or receiver) L1 L2 L1 S R L2 A

8 8 Challenges r Challenges to build a good (networking) system: find the right balance between: reuse, interoperability, implementation effort (apply layering concepts) end-to-end arguments performance No universal answer: the answer depends on the goals and assumptions!

9 9 Outline r Recap  ISO/OSI Layering and Internet Layering r Application layer overview r Examples

10 10 ISO/OSI Reference Model r Seven layers m lower three layers are hop-by-hop m next four layers are end-to-end (host-to-host) Application Presentation Session Transport Network Datalink Physical Application Presentation Session Transport Network Datalink Physical Network Datalink Physical Physical medium

11 11 Internet Layering r Lower three layers are hop-by-hop r Next two layers are end-to-end Application Transport Network Datalink Physical Application Transport Network Datalink Physical Network Datalink Physical Physical medium

12 12 Internet Protocol Layers r A rough division r Five layers m Application: supporting network applications ftp, smtp, http, p2p, IP telephony m Transport: host-host data transfer tcp, udp m Network: routing of datagram from source to destination ip m Link: data transfer between neighboring network elements ethernet, 802.11, cable, DSL, … m Physical: bits “on the wire” cable, wireless, optical fiber application transport network link physical

13 13 The Hourglass Architecture of the Internet network infrastructure end users IP EthernetCable/DSLWireless TCP UDP Telnet Email FTPWWW

14 14 Link Layer: Services Provided by Ethernet r Multiple access control m send frame to peer sharing the common channel r Multiplexing/demultiplexing m from/to the network layer r Error detection IP Ethernet Cable/DSL Wireless TCP UDP Telnet Email FTPWWW

15 15 Network Layer: Services Provided by IP r Routing m best-effort to send packets from source to destination r Multiplexing/demultiplexing m from/to the transport r Fragmentation and reassembling m partition a fragment into smaller packets m removed in IPv6 r Error detection r Certain QoS/CoS r Does not provide m reliability or reservation IP EthernetCable/DSLWireless TCP UDP SSL Telnet Email FTPWWW

16 16 Network Layer: IPv4 Header

17 17 Services Provided by UDP r A connectionless service r Does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee m why is there a UDP? IP EthernetCable/DSLWireless TCP UDP Telnet Email FTP WWW

18 18 Transport Layer: Services Provided by TCP r Multiplexing/demultiplexing r Reliable transport m between sending and receiving processes m setup required between sender and receiver: a connection-oriented service r Flow control m sender won’t overwhelm receiver r Congestion control m throttle sender when network overloaded r Error detection r Does not provide m timing, minimum bandwidth guarantees IP EthernetFDDIWireless TCP UDP Telnet Email FTPWWW

19 19 Transport Layer: TCP Header

20 Secure Socket Layer Architecture HTTP POP3

21 SSL Record-Layer Packet Format 20: change_cipher 21: alert 22: handshake 23: application

22 22 Summary: The Big Picture of the Internet r Hosts and routers: m >600 mil. Hosts (2009) m organized roughly hierarchical m backbone links 10  40Gbps r Software: m datagram switching with virtual circuit support at backbone m layered network architecture use end-to-end arguments to determine the services provided by each layer m the hourglass architecture of the Internet IP EthernetCable/DSLWireless TCP UDP Telnet Email FTPWWW SSL

23 23 Outline r Recap r ISO/OSI Layering and Internet Layering  Application layer overview r Examples

24 24 Application Layer: Goals r Conceptual + implementation aspects of network application protocols m client server paradigm m peer to peer paradigm m network app. programming r Learn about protocols by examining common application-layer protocols m smtp/pop m dns m http m ftp m p2p

25 25 Network Applications vs. Application-layer Protocols Network application: communicating, distributed processes m a process is a program that is running within a host a user agent is a process serving as an interface to the user –web: browser –streaming audio/video: media player m processes communicate by an application-layer protocol e.g., email, Web Application-layer protocols m one “piece” of an app m define messages exchanged by apps and actions taken m implementing services by using the service provided by the lower layer, i.e., the transport layer application transport network data link physical application transport network data link physical

26 26 How does an Application Access the Transport Service? API: application programming interface r Defines interface between application and transport layer r Example: Socket API m sometimes called "Berkeley sockets" acknowledging their heritage from Berkeley Unix m a socket consists of a host IP address and a port number e.g., email (SMTP) port number 25, web port number 80 m an application process binds to a socket %netstat –anp --tcp m two processes communicate by sending data into socket, reading data out of socket r There are other API’s such as XTI (X/Open Transport Interface), a slight modification of the Transport Layer Interface (TLI) developed by AT&T. More later!

27 27 App. and Trans.: App. Protocols and their Transport Protocols Application e-mail remote terminal access Web file transfer Internet telephony remote file server streaming multimedia Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g., Vocaltec) NFS proprietary Underlying transport protocol TCP/SSL TCP TCP/SSL TCP typically UDP TCP or UDP typically UDP r An application needs to choose the transport protocol

28 28 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 (C): r initiates contact with server (“speaks first”) r typically requests service from server r for Web, client is implemented in browser; for e-mail, in mail reader Server (S): r provides requested service to client r e.g., Web server sends requested Web page; mail server delivers e-mail request reply Two questions to ask about a C-S application - How does a client locate a server process? - Is the application extensible, scalable, robust, secure?

29 29 Outline r Recap r ISO/OSI Layering and Internet Layering r Application layer overview  Examples

30 30 Electronic Mail Three major components: r User agents r Mail servers r Protocols m Outgoing email SMTP m Retrieving email POP3: Post Office Protocol [RFC 1939] IMAP: Internet Mail Access Protocol [RFC 1730] user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP POP3 or IMAP SMTP

31 31 SMTP: Outgoing Email as a Client- Server Application S: 220 mr1.its.yale.edu C: HELO cyndra.yale.edu S: 250 Hello cyndra.cs.yale.edu, pleased to meet you C: MAIL FROM: S: 250 spoof@cs.yale.edu... Sender ok C: RCPT TO: S: 250 yry@yale.edu... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Date: Wed, 23 Jan 2008 11:20:27 -0500 (EST) C: From: "Y. R. Yang" C: To: "Y. R. Yang" C: Subject: This is subject C: C: This is the message body! C: Please don’t spoof! C: C:. S: 250 Message accepted for delivery C: QUIT S: 221 mr1.its.yale.edu closing connection

32 32 Mail Message Data Format SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: r Header lines, e.g., m To: m From: m Subject: r Body m the “message”, ASCII characters only blank line header body

33 33 Message Format: Multimedia Extensions r MIME: multimedia mail extension, RFC 2045, 2056 r Additional lines in msg header declare MIME content type From: yry@cs.yale.edu To: cs433@cs.yale.edu Subject: Network map. MIME-Version: 1.0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 base64 encoded data....................................base64 encoded data multimedia data type, subtype, parameter declaration method used to encode data MIME version encoded data

34 34 Multipart Type: How Attachment Works From: yry@cs.yale.edu To: cs433@cs.yale.edu Subject: Network map. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Hi, Attached is network topology map. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data --98766789--

35 35 POP3 Protocol: Mail Access Authorization phase r client commands:  user: declare username  pass: password r server responses m +OK  -ERR Transaction phase, client:  list: list message numbers  retr: retrieve message by number  dele: delete r quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on %telnet.mail.yale.edu 110 %openssl s_client –connect pop.gmail.com:995

36 36 Discussions: Positive r Some nice designs we can learn from the design of the email application m separate protocols for different functions email retrieval (e.g., POP3, IMAP) email transmission (SMTP) m simple/basic requests to implement basic control; fine- grain control through ASCII header and message body make the protocol easy to read/debug/extend (analogy with end-to-end layered design?) m status code in response makes message easy to parse

37 37 Discussions: Negative r Some design challenges m handling spam http://www.yale.edu/its/metrics/email/index.html

38 Recap: 38 Two questions to ask about a C-S application How does a client locate a server process? Is the application extensible, scalable, robust, secure?

39 39 DNS: Domain Name System r Function m map between (domain name, service) to value, e.g., (www.cs.yale.edu, Addr) -> 128.36.229.30 (cs.yale.edu, Email) -> netra.cs.yale.edu (netra.cs.yale.edu, Addr) -> 128.36.229.21 r Why use name, instead of IP address directly? routers DNS Hostname, Service Address servers clients

40 40 DNS: Domain Name System r Naming scheme m a hierarchical naming space divided into zones m each zone is a sub-tree of the global tree called a zone

41 41 Distributed Management of the Domain Name Space r A distributed database managed by authoritative name servers m each zone has its own authoritative name servers m an authoritative name server of a zone may delegate a subset (i.e. a sub-tree) of its zone to another name server called a zone

42 42 Root Zone and Root Servers r The root zone is managed by the root name servers m 13 root name servers worldwide

43 43 Linking the Name Servers r Each name server knows the addresses of the root servers r Each name server knows the addresses of its immediate children (i.e., those it delegates) Top level domain (TLD)

44 44 DNS Message Flow: Two Types of Queries Recursive query: r Puts burden of name resolution on contacted name server m the contacted name server resolves the name completely Iterated query: r Contacted server replies with name of server to contact m “I don’t know this name, but ask this server”

45 45 DNS Message Flow: Examples Local DNS server helps requesting hosts to query the DNS system Local DNS server is learned from DHCP, or configured, e.g. /etc/resolv.conf

46 46 DNS Message Flow: The Hybrid Case requesting host cyndra.cs.yale.edu gaia.cs.umass.edu root name server 1 2 3 4 authoritative name server dns.cs.umass.edu 56 TLD name server 7 8 iterated query local name server 130.132.1.9

47 47 DNS Records DNS: distributed db storing resource records (RR) r Type=NS  name is domain (e.g. yale.edu)  value is the name of the authoritative name server for this domain RR format: (name, type, value, ttl) r Type=A  name is hostname  value is IP address r Type=CNAME  name is an alias name for some “canonical” (the real) name  value is canonical name r Type=MX  value is hostname of mail server associated with name r Type=SRV m general extension

48 48 DNS Protocol, Messages DNS protocol : over UDP/TCP; query and reply messages, both with the same message format DNS Msg header: r identification: 16 bit # for query, the reply to a query uses the same # r flags: m query or reply m recursion desired m recursion available m reply is authoritative

49 49 Observing DNS r Use the command dig (or nslookup):  force iterated query to see the trace: %dig +trace www.cnn.com see the manual for more details r Capture the messages using Ethereal m DNS server is at port 53

50 50 What DNS did Right? r Hierarchical delegation avoids central control, improving manageability and scalability r Redundant servers improve robustness m see http://www.internetnews.com/dev- news/article.php/1486981 for DDoS attack on root servers in Oct. 2002 (9 of the 13 root servers were crippled, but only slowed the network)http://www.internetnews.com/dev- news/article.php/1486981 m see http://www.cymru.com/DNS/index.html for performance monitoringhttp://www.cymru.com/DNS/index.html r Caching reduces workload and improve robustness

51 51 Problems of DNS r Domain names may not be the best way to name other resources, e.g. files r Relatively static resource types make it hard to introduce new services or handle mobility r Although theoretically you can update the values of the records, it is rarely enabled r Simple query model makes it hard to implement advanced query r Early binding (separation of DNS query from application query) does not work well in mobile, dynamic environments m e.g., load balancing, locate the nearest printer - How does a client locate a server? - Is the application secure extensible, robust, scalable?

52 Optional Slides 52

53 53 Services Provided by Transport r Transmission control protocol (TCP) m multiplexing/demultiplexing m reliable data transfer m rate control: flow control and congestion control r User data protocol (UDP) m multiplexing/demultiplexing Host A Hello Host B I am ready DATA ACK

54 Secure Socket Layer: Services r server authentication m authentication through trusted certificate authority (CA): server obtains a certificate from one of the trusted CAs r data encryption and integrity r client authentication (optional)

55 Details of the Seven ISO/OSI Layers

56 56 Physical Layer (1) r Service: moves information between two systems connected by a physical link r Interface: specifies how to send a bit r Protocol: coding scheme used to represent a bit, voltage levels, duration of a bit r Examples: coaxial cable, optical fiber links; transmitters, receivers

57 57 Datalink Layer (2) r Service: m framing, i.e., attach frames separator m send data frames between peers m others: arbitrates the access to common physical media ensures reliable transmission provides flow control r Interface: sends a data unit (packet) to a machine connected to the same physical media r Protocol: layer addresses, implement Medium Access Control (MAC) (e.g., CSMA/CD)…

58 58 Network Layer (3) r Service: m delivers a packet to a specified destination m performs fragmentation/reassembly of packets m others: packet scheduling buffer management r Interface: sends a packet to a specified destination r Protocol: defines global unique addresses; constructs routing tables; implement packet forwarding; fragments/reassembles packets

59 59 Data and Control Planes r Data plane: concerned with m packet forwarding m buffer management m packet scheduling r Control Plane: concerned with installing and maintaining the states for the data plane

60 60 Transport Layer (4) r Service: m provides an in-order, error-free, and flow and congestion controlled end-to-end connection m multiplex/demuliplex packets r Interface: sends a packet to a destination r Protocol: implements reliability, as well as flow and congestion control r Examples: TCP and UDP m TCP: in-order, error free, flow and congestion control

61 61 Session Layer (5) r Service: m full-duplex m access management, e.g., token control m synchronization, e.g., provide check points for long transfers r Interface: depends on service r Protocols: token management; insert checkpoints, implement roll-back functions

62 62 Presentation Layer (6) r Service: converts data between various representations r Interface: depends on service r Protocol: defines data formats and rules to convert from one format to another

63 63 Application Layer (7) r Service: any service provided to end users r Interface: depends on the application r Protocol: depends on the application r Examples: FTP, Telnet, WWW

64 64 What Transport Service Does an App Need? Data loss r some apps can tolerate some packet losses r other apps require 100% reliable data transfer Timing r some apps require low delay to be “effective” Bandwidth r some apps require minimum amount of bandwidth to be “effective” r other apps make use of whatever bandwidth they get

65 65 Transport Service Requirements of Common Apps Application file transfer e-mail 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


Download ppt "Network Applications 9/14/2009. 2 Outline  Recap r ISO/OSI Layering and Internet Layering r Application layer overview r Examples."

Similar presentations


Ads by Google