Application Layer CS 3516 Computer Networks CS 3516 Computer - PDF document

Application Layer CS 3516 – Computer Networks CS 3516 Computer Networks 2: Application Layer 2 Chapter 2: Application Layer Some network apps • learn about protocols Goals: • conceptual, • e-mail • social networks by examining popular • web • voice over IP application-level implementation aspects of network protocols • instant messaging • real-time video application protocols – HTTP • remote login conferencing f g remote login – FTP FTP • grid computing – transport-layer • P2P file sharing service models – SMTP / POP3 / IMAP • multi-user network – DNS – client-server • programming network games paradigm • streaming stored video applications – peer-to-peer clips – socket API paradigm 3 4 Creating a Network App Chapter 2: Application layer application transport network data link Write programs that physical • 2.1 Principles of • 2.6 P2P applications – run on (different) end • 2.7 Socket programming systems network applications – communicate over network • 2.2 Web and HTTP with UDP – e.g., web server software • 2.3 FTP • 2.8 Socket programming p g g communicates with browser commun cates w th browser • 2.4 Electronic Mail with TCP software application No need to write software transport – SMTP, POP3, IMAP network • 2.5 DNS for network-core devices data link application physical transport network – Network-core devices do data link physical not run user applications – applications on end systems allows for rapid app development, propagation 5 6 1

Client-server Architecture Application architectures server: • Client-server (CS) – always-on host – permanent IP address – Including data centers / cloud computing – server farms for scaling • Peer-to-peer (P2P) clients: • Hybrid of client-server and P2P – communicate with server – may be intermittently connected client/server – may have dynamic IP addresses – do not communicate directly with each other 8 Server Example - Google Data Pure P2P Architecture Centers • Estimated cost of data center: $600M • no always-on server • Google spent $2.4B in 2007 on new data • arbitrary end systems directly communicate centers peer-peer • peers are intermittently • Each data center uses 50-100 megawatts g connected and change IP connected and change IP of power addresses Highly scalable but difficult to manage Hybrid of Client-server and P2P Processes Communicating • E.g. Skype Client process: process Process: program running – voice-over-IP P2P application that initiates within a host. – centralized server: finding address of • Within same host, two communication remote party Server process: process processes communicate – client-client connection: often direct (not that waits to be using inter-process g p through server) through server) • E.g. Instant messaging contacted communication (defined by OS). – chatting between two users is P2P • Processes in different – centralized service: client presence • Note: applications with detection/location P2P architectures have hosts communicate by • user registers its IP address with central exchanging messages client processes & server when it comes online server processes • user contacts central server to find IP addresses of buddies 2

Addressing Processes Sockets • Q: does IP address of • To receive messages, host on which process • Process sends/receives host or host or process must have runs suffice for server server messages to/from its identifier identifying the process? • Host device has unique socket controlled by – A: No, many processes • Socket analogous to door app developer process 32-bit IP address process can be running on • Exercise: use ipconfig – sending process shoves g p socket socket Exercise: use ipconfig same same message out door • Identifier includes both TCP with from command prompt to TCP with Internet – sending process relies on buffers, buffers, get your IP address variables variables IP address and port transport infrastructure (Windows) on other side of door which numbers associated with brings message to socket controlled process on host. by OS at receiving process • Example port numbers: • API: (1) choice of transport protocol; (2) ability to – HTTP server: 80 fix a few parameters (see Sockets slide deck) – Mail server: 25 What Transport Service Does an App Need? App-layer Protocol Defines Throughput Data loss • some apps (e.g., audio) can • Types of messages • some apps (e.g., Public-domain protocols: multimedia) require • Defined in RFCs tolerate some loss exchanged, • other apps (e.g., file minimum amount of • allows for – e.g., request, response throughput to be • Message syntax: transfer, telnet) require interoperability 100% reliable data “effective” • • e.g., HTTP, SMTP, – what fields in messages & what fields in messages & HTTP SMTP t transfer f • other apps (“elastic apps”) th (“ l ti ”) how fields are delineated BitTorrent Timing make use of whatever • Message semantics • some apps (e.g., throughput they get Proprietary protocols: – meaning of information in • e.g., Skype, ppstream Security Internet telephony, fields interactive games) • encryption, data integrity, • Rules for when and how require low delay to be … processes send & “effective” respond to messages Transport Service Requirements of Common Internet Transport Protocols Services Apps UDP service: TCP service: Application Time Sensitive Data loss Throughput • unreliable data transfer • connection-oriented: setup between sending and required between client and file transfer no no loss elastic receiving process server processes e-mail no no loss elastic • does not provide: • reliable transport between Web documents no no loss elastic connection setup, connection setup real-time audio/video real time audio/video yes 100’s msec yes, 100 s msec sending and receiving process di d i i l loss-tolerant t l t audio: 5kbps-1Mbps di 5kb 1Mb • flow control: sender won’t reliability, flow control, video:10kbps-5Mbps congestion control, timing, yes, few secs stored audio/video loss-tolerant same as above overwhelm receiver • congestion control: throttle throughput guarantee, or yes, 100’s msec interactive games loss-tolerant few kbps up security yes and no instant messaging no loss elastic sender when network overloaded • does not provide: timing, Q: why bother? Why is there a UDP? minimum throughput guarantees, security 3

Internet Apps: Application, Transport Protocols Chapter 2: Application layer Application Underlying • 2.1 Principles of • 2.6 P2P applications Application layer protocol transport protocol network applications • 2.7 Socket programming • 2.2 Web and HTTP e-mail SMTP [RFC 2821] TCP with UDP remote terminal access Telnet [RFC 854] TCP • 2.3 FTP • 2 8 Socket programming Web HTTP [RFC 2616] TCP 2.8 Socket programming • 2.4 Electronic Mail fil file transfer t f FTP [RFC 959] FTP [RFC 959] TCP TCP with TCP streaming multimedia HTTP (eg Youtube), TCP or UDP – SMTP, POP3, IMAP RTP [RFC 1889] • 2.5 DNS Internet telephony SIP, RTP, proprietary (e.g., Skype) typically UDP Web and HTTP HTTP Overview First some jargon HTTP: hypertext • Web page consists of objects transfer protocol • Object can be HTML file, JPEG image, Java • Web’s application layer PC running Explorer applet, audio file,… protocol • Web page consists of base HTML-file which • W b • • client/server model i t f b HTML fil hi h li t/ d l includes several referenced objects – client: browser that Server • Each object is addressable by a URL requests, receives, running “displays” Web objects • Example URL: Apache Web – server: Web server server sends objects in www.someschool.edu/someDept/pic.gif response to requests Mac running Navigator path name host name HTTP Overview (continued) HTTP connections HTTP is “stateless” Uses TCP: Nonpersistent HTTP Persistent HTTP • server maintains no • client initiates TCP • At most one object is • Multiple objects can information about connection (creates socket) past client requests to server, port 80 sent over a TCP be sent over single • server accepts TCP connection. TCP connection aside aside connection from client ti f li t between client and Protocols that maintain • HTTP messages (application- “state” are complex! server. layer protocol messages) past history (state) must • exchanged between browser be maintained (HTTP client) and Web if server/client crashes, • server (HTTP server) their views of “state” may • TCP connection closed be inconsistent, must be reconciled 4