source: computer-networks-webdesign.com CSCI x760 - Computer Networks Spring 2016 Instructor: Prof. Roberto Perdisci perdisci@cs.uga.edu These slides are adapted from the textbook slides by J.F. Kurose and K.W. Ross
Chapter 2: Application layer 2.1 Principles of network applications 2.6 P2P applications 2.2 Web and HTTP 2.7 Socket programming with TCP 2.3 FTP 2.8 Socket programming with 2.4 Electronic Mail UDP } SMTP , POP3, IMAP 2.5 DNS Application 2-2
Chapter 2: Application Layer Our goals: } learn about protocols by examining popular } conceptual, application-level implementation aspects protocols of network application protocols } HTTP } FTP } transport-layer service models } SMTP / POP3 / IMAP } DNS } client-server paradigm } programming network } peer-to-peer paradigm applications } socket API Application 2-3
Some network apps } e-mail } voice over IP } web } real-time video conferencing } instant messaging } cloud computing } remote login } … } P2P file sharing } … } multi-user network games } } streaming stored video (YouTube) Application 2-4
Creating a network app application transport network data link write programs that physical } run on (different) end systems } communicate over network } e.g., web server software communicates with browser software No need to write software for application transport network-core devices network data link application physical } network-core devices do not run transport network user applications data link physical } applications on end systems allows for rapid app development, propagation Application 2-5
Chapter 2: Application layer 2.1 Principles of network applications 2.6 P2P applications 2.2 Web and HTTP 2.7 Socket programming with TCP 2.3 FTP 2.8 Socket programming with 2.4 Electronic Mail UDP SMTP , POP3, IMAP 2.5 DNS Application 2-6
Application architectures } client-server } peer-to-peer (P2P) } hybrid of client-server and P2P Application 2-7
Client-server architecture server: } always-on host } permanent IP address } server farms for scaling clients: } communicate with server } may be intermittently connected client/server } may have dynamic IP addresses } do not communicate directly with each other Application 2-8
Pure P2P architecture } no always-on server } arbitrary end systems directly communicate peer-peer } peers are intermittently connected and change IP addresses highly scalable but difficult to manage Application 2-9
Hybrid of client-server and P2P Skype } voice-over-IP P2P application } centralized server: finding address of remote party: } client-client connection: direct (not through server) Instant messaging } chatting between two users is P2P } centralized service: client presence detection/location } user registers its IP address with central server when it comes online } user contacts central server to find IP addresses of buddies Application 2-10
Processes communicating client process: process that process: program running initiates communication within a host. server process: process that } within same host, two waits to be contacted processes communicate using inter-process communication (defined by OS). v aside: applications with } processes in different hosts P2P architectures have communicate by exchanging client processes & messages server processes Application 2-11
Sockets } process sends/receives host or host or messages to/from its socket server server } socket analogous to door controlled by } sending process shoves message app developer process process out door socket } sending process relies on socket transport infrastructure on other TCP with TCP with Internet buffers, side of door which brings buffers, variables variables message to socket at receiving process controlled by OS v API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) Application 2-12
Addressing processes } to receive messages, process must have identifier } host device has unique 32-bit IP address } Q: does IP address of host on which process runs suffice for identifying the process? Application 2-13
Addressing processes } to receive messages, process } identifier includes both IP must have identifier address and port numbers associated with process on } host device has unique 32- host. bit IP address } example port numbers: } Q: does IP address of host on which process runs } HTTP server: 80 suffice for identifying the } Mail server: 25 process? } to send HTTP message to gaia.cs.umass.edu web server: } A: No, many processes can be running on same host } IP address: 128.119.245.12 } Port number: 80 } more shortly… Application 2-14
App-layer protocol defines public-domain protocols: } types of messages exchanged, } defined in RFCs } e.g., request, response } allows for interoperability } message syntax: } e.g., HTTP , SMTP } what fields in messages & how proprietary protocols: fields are delineated } e.g., Skype } message semantics } meaning of information in fields } rules for when and how processes send & respond to messages Application 2-15
What transport service does an app need? Throughput Reliability } some apps (e.g., audio) can v some apps (e.g., multimedia) tolerate some loss require minimum amount of } other apps (e.g., file transfer, throughput to be “effective” telnet) require 100% reliable v other apps (“elastic apps”) data transfer make use of whatever throughput they get Timing Security } some apps (e.g., Internet v encryption, data integrity, … telephony, interactive games) require low delay to be “effective” Application 2-16
Transport service requirements of common apps Time Sensitive Application Data loss Throughput no file transfer no loss elastic no e-mail no loss elastic no Web documents no loss elastic yes, 100’s msec real-time audio/video loss-tolerant audio: 5kbps-1Mbps video:10kbps-5Mbps yes, few secs stored audio/video loss-tolerant same as above yes, 100’s msec interactive games loss-tolerant few kbps up instant messaging yes and no no loss elastic Application 2-17
Internet transport protocols services UDP service: TCP service: } unreliable data transfer } connection-oriented: setup required between sending and receiving between client and server process processes } does not provide: connection } reliable transport between sending setup, reliability, flow control, and receiving process congestion control, timing, } flow control: sender won’t throughput guarantee, or overwhelm receiver security } congestion control: throttle sender when network overloaded Q: why bother? Why is there a } does not provide: timing, minimum UDP? throughput guarantees, security Application 2-18
Internet apps: application, transport protocols*** Application Underlying layer protocol Application transport protocol SMTP [RFC 2821] e-mail TCP Telnet [RFC 854] remote terminal access TCP HTTP [RFC 2616] Web TCP FTP [RFC 959] file transfer TCP HTTP (eg Youtube), streaming multimedia TCP or UDP RTP [RFC 1889] SIP, RTP, proprietary Internet telephony (e.g., Skype) typically UDP Application 2-19
Chapter 2: Application layer 2.1 Principles of network applications 2.6 P2P applications } app architectures 2.7 Socket programming with } app requirements TCP 2.2 Web and HTTP 2.8 Socket programming with 2.3 FTP UDP 2.4 Electronic Mail } SMTP , POP3, IMAP 2.5 DNS Application 2-20
Web and HTTP First, a review… } web page consists of objects } object can be HTML file, JPEG image, Java applet, audio file,… } web page consists of base HTML-file which includes several referenced objects } each object is addressable by a URL } example URL: www.someschool.edu/someDept/pic.gif path name host name Application 2-21
HTTP overview HTTP: hypertext transfer protocol } Web’s application layer protocol } client/server model PC running Firefox } client: browser that requests, receives, “displays” Web objects } server: Web server sends objects in response to requests Server running Apache Web server Mac running Chrome Application 2-22
HTTP overview (continued) HTTP is “stateless” Uses TCP: } server maintains no } client initiates TCP connection information about past (creates socket) to server, port client requests 80 } server accepts TCP connection aside from client protocols that maintain } HTTP messages (application-layer “state” are complex! protocol messages) exchanged v past history (state) must between browser (HTTP client) be maintained and Web server (HTTP server) v if server/client crashes, } TCP connection closed their views of “state” may be inconsistent, must be reconciled Application 2-23
HTTP connections non-persistent HTTP persistent HTTP } at most one object sent over } multiple objects can be sent TCP connection. over single TCP connection between client, server. Application 2-24
Recommend
More recommend
