Chapter 2: Application Layer Chapter 2: layer outline 2.1 principles of s 2.2 Web and HTTP 2.3 electronic, POP3, IMAP 2.4 socket programming with UDP and TCP our goals: conceptual, implementation aspects of protocols -layer service models - paradigm peer-to-peer paradigm learn about protocols by examining popular -level protocols HTTP / POP3 / IMAP creating s socket API Application Layer 2-3 Application Layer 2-4 Some apps e- web text messaging remote login P2P file sharing multi- games streaming stored video (YouTube, Hulu, Netflix) voice over IP (e.g., Skype) real-time video conferencing social ing search Creating a app write programs that: run on (different) end systems communicate over e.g., web software communicates with browser software no need to write software for -core devices -core devices do not run s s on end systems allows for rapid app development, propagation data link data link data link Application Layer 2-5 Application Layer 2-6 Application architectures Client- architecture possible structure of s: - peer-to-peer (P2P) / : always-on host permanent IP address data centers for scaling s: communicate with may be intermittently connected may have dynamic IP addresses do not communicate directly with each other Application Layer 2-7 Application Layer 2-8 1
P2P architecture Processes communicating no always-on arbitrary end systems directly communicate peers request service from other peers, provide service in return to other peers self scalability new peers bring new service capacity, as well as new service demands peers are intermittently connected and change IP addresses complex management peer-peer process: program running within a host within same host, two processes communicate using inter-process communication (defined by OS) processes in different hosts communicate by exchanging messages s, s process: process that initiates communication process: process that waits to be contacted aside: s with P2P architectures have processes & processes Application Layer 2-9 Application Layer 2-10 Sockets process sends/receives messages to/from its socket socket analogous to door sending process shoves message out door sending process relies on infrastructure on other side of door to deliver message to socket at receiving process process link socket process link controlled by app developer controlled by OS 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? A: no, many processes can be running on same host identifier includes both IP address and port numbers associated with process on host. example port numbers: HTTP : 80 : 25 to send HTTP message to gaia.cs.umass.edu web : IP address: 128.119.245.12 port number: 80 more shortly Application Layer 2-11 Application Layer 2-12 App-layer protocol defines types of messages exchanged, e.g., request, response message syntax: what fields in messages & how fields are delineated message semantics meaning of information in fields rules for when and how processes send & respond to messages open protocols: defined in RFCs allows for interoperability e.g., HTTP, proprietary protocols: e.g., Skype What service does an app need? data integrity some apps (e.g., file transfer, web transactions) require 100% reliable data transfer other apps (e.g., audio) can tolerate some loss timing some apps (e.g., telephony, interactive games) require low delay to be effective throughput some apps (e.g., multimedia) require minimum amount of throughput to be effective other apps ( elastic apps ) make use of whatever throughput they get security encryption, data integrity, Application Layer 2-13 Application Layer 2-14 2
Transport service requirements: common apps protocols services file transfer e- Web documents real-time audio/video stored audio/video interactive games text messaging data loss no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss throughput time sensitive elastic no elastic no elastic no audio: 5kbps-1Mbps yes, 100 s video:10kbps-5mbps msec same as above few kbps up yes, few secs elastic yes, 100 s msec yes and no TCP service: reliable between sending and receiving process flow control: sender won t overwhelm receiver congestion control: throttle sender when overloaded does not provide: timing, minimum throughput guarantee, security connection-oriented: setup required between and processes UDP service: unreliable data transfer between sending and receiving process does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup, Q: why bother? Why is there a UDP? Application Layer 2-15 Application Layer 2-16 apps:, protocols Chapter 2: outline e- remote terminal access Web file transfer streaming multimedia telephony layer protocol [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP (e.g., YouTube), RTP [RFC 1889] SIP, RTP, proprietary (e.g., Skype) underlying protocol TCP TCP TCP TCP TCP or UDP TCP or UDP 2.1 principles of s 2.2 Web and HTTP 2.3 electronic, POP3, IMAP 2.4 P2P s 2.5 socket programming with UDP and TCP Application Layer 2-17 Application Layer 2-18 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, e.g., www.someschool.edu/somedept/pic.gif host name path name HTTP overview HTTP: hypertext transfer protocol Web s layer protocol / model : browser that requests, receives, (using HTTP protocol) and displays Web objects : Web sends (using HTTP protocol) objects in response to requests PC running Firefox browser iphone running Safari browser HTTP request HTTP request running Apache Web Application Layer 2-19 Application Layer 2-20 3
HTTP overview (continued) HTTP request message uses TCP: initiates TCP connection (creates socket) to, port 80 accepts TCP connection from HTTP messages (-layer protocol messages) exchanged between browser (HTTP ) and Web (HTTP ) TCP connection closed HTTP is stateless maintains no information about past requests aside protocols that maintain state are complex! past history (state) must be maintained if / crashes, their views of state may be inconsistent, must be reconciled two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) header lines carriage return, line feed at start of line indicates end of header lines carriage return character line-feed character GET /index.html HTTP/1.1\r\n Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n \r\n Application Layer 2-21 * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-22 HTTP request message: general format Uploading form input method sp URL sp version cr lf header field name value cr lf ~ ~ header field name cr lf value cr lf entity body ~ ~ request line header lines body POST method: web page often includes form input input is uploaded to in entity body URL method: uses GET method input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana Application Layer 2-23 Application Layer 2-24 Method types message HTTP/1.0: GET POST HEAD asks to leave requested object out of response HTTP/1.1: GET, POST, HEAD PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field status line (protocol status code status phrase) header lines data, e.g., requested HTML file HTTP/1.1 200 OK\r\n Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT \r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=iso-8859-1\r\n \r\n data data data data data... Application Layer 2-25 * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-26 4
status codes status code appears in 1st line in -to response message. some sample codes: 200 OK request succeeded, requested object later in this msg 301 Moved Permanently requested object moved, new location specified later in this msg (Location:) 400 Bad Request request msg not understood by 404 Not Found requested document not found on this 505 HTTP Version Not Supported Application Layer 2-27 Trying out HTTP ( side) for yourself 1. Telnet to your favorite Web : telnet gaia.cs.umass.edu 80 2. type in a GET HTTP request: opens TCP connection to port 80 (default HTTP port) at gaia.cs.umass. edu. anything typed in will be sent to port 80 at gaia.cs.umass.edu GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu by typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP 3. look at response message sent by HTTP! (or use Wireshark to look at captured HTTP request/response) Application Layer 2-28 User- state: cookies many Web sites use cookies four components: 1) cookie header line of message 2) cookie header line in next HTTP request message 3) cookie file kept on s host, managed by s browser 4) back-end database at Web site example: Susan always access from PC visits specific e-commerce site for first time when initial HTTP requests arrives at site, site creates: unique ID entry in backend database for ID Application Layer 2-29 Cookies: keeping state (cont.) ebay 8734 cookie file ebay 8734 amazon 1678 one week later: ebay 8734 amazon 1678 usual http request msg usual http response set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg Amazon creates ID 1678 for create backend entry database cookiespecific action cookiespecific action access access Application Layer 2-30 Cookies (continued) what cookies can be used for: authorization shopping carts recommendations session state (Web e-) how to keep state : protocol endpoints: maintain state at sender/receiver over multiple transactions cookies: http messages carry state aside cookies and privacy: cookies permit sites to learn a lot about you you may supply name and e- to sites Web caches (proxy ) goal: satisfy request without involving sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object else cache requests object from, then returns object to HTTP request HTTP request proxy HTTP request Application Layer 2-31 Application Layer 2-32 5
More about Web caching Caching example: cache acts as both and for al requesting to typically cache is installed by ISP (university, company, residential ISP) why Web caching? reduce response time for request reduce traffic on an institution s access link dense with caches: enables poor content providers to effectively deliver content (so too does P2P file sharing) assumptions: avg object size: 100K bits avg request rate from browsers to s:15/sec avg data rate to browsers: 1.50 Mbps RTT from institutional router to any : 2 sec access link rate: 1.54 Mbps consequences: LAN utilization: 0.15% problem! access link utilization = 99% total delay = delay + access delay + LAN delay = 2 sec + minutes + usecs institutional public 1.54 Mbps access link s 1 Gbps LAN Application Layer 2-33 Application Layer 2-34 Caching example: fatter access link Caching example: install local cache assumptions: avg object size: 100K bits avg request rate from browsers to s s:15/sec public avg data rate to browsers: 1.50 Mbps RTT from institutional router to any : 2 sec access link rate: 1.54 Mbps 154 Mbps 1.54 Mbps 154 Mbps access link consequences: LAN utilization: 0.15% institutional access link utilization = 99% 9.9% 1 Gbps LAN total delay = delay + access delay + LAN delay = 2 sec + minutes + usecs msecs Cost: increased access link speed (not cheap!) Application Layer 2-35 assumptions: avg object size: 100K bits avg request rate from browsers to s:15/sec avg data rate to browsers: 1.50 Mbps RTT from institutional router to any : 2 sec access link rate: 1.54 Mbps consequences: LAN utilization: 0.15% access link utilization = 100%? total delay =? delay + access delay + LAN delay How to compute link = 2 sec + minutes + usecs utilization, delay? Cost: web cache (cheap!) institutional public 1.54 Mbps access link s 1 Gbps LAN local web cache Application Layer 2-36 Caching example: install local cache Calculating access link utilization, delay with cache: suppose cache hit rate is 0.4 40% requests satisfied at cache, 60% requests satisfied at access link utilization: 60% of requests use access link data rate to browsers over access link = 0.6*1.50 Mbps =.9 Mbps utilization = 0.9/1.54 =.58 total delay = 0.6 * (delay from s) +0.4 * (delay when satisfied at cache) = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs less than with 154 Mbps link (and cheaper too!) institutional public 1.54 Mbps access link s 1 Gbps LAN local web cache Application Layer 2-37 Conditional GET Goal: don t send object if cache has up-to-date cached version no object transmission delay lower link utilization cache: specify date of cached copy in HTTP request If-modified-since: <date> : response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> HTTP/1.0 200 OK <data> object not modified before <date> object modified after <date> Application Layer 2-38 6
Chapter 2: outline 2.1 principles of s 2.2 Web and HTTP 2.3 electronic, POP3, IMAP 2.4 socket programming with UDP and TCP Application Layer 2-39 Electronic Three major components: s s simple transfer protocol: User Agent a.k.a. reader composing, editing, reading messages e.g., Outlook, Thunderbird, iphone outgoing, incoming messages stored on outgoing message queue box Application Layer 2-40 Electronic : s Electronic Mail: [RFC 2821] s: box contains incoming messages for message queue of outgoing (to be sent) messages protocol between s to send e messages : sending : receiving Application Layer 2-41 uses TCP to reliably transfer e message from to, port 25 direct transfer: sending to receiving three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction (like HTTP) commands: ASCII text response: status code and phrase messages must be in 7-bit ASCI Application Layer 2-42 Scenario: Alice sends message to Bob 1) Alice uses UA to compose message to bob@someschool.edu 2) Alice s UA sends message to her ; message placed in message queue 3) side of opens TCP connection with Bob s 4) sends Alice s message over the TCP connection 5) Bob s places the message in Bob s box 6) Bob invokes his to read message Try interaction for yourself: telnet name 25 see 220 reply from enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send e without using e (reader) 1 2 3 4 6 Alice s 5 Bob s Application Layer 2-43 Application Layer 2-44 7
: final words Mail message format uses persistent connections requires message (header & body) to be in 7-bit ASCII uses CRLF.CRLF to determine end of message comparison with HTTP: HTTP: pull : push both have ASCII command/response interaction, status codes HTTP: each object encapsulated in its own response message : multiple objects sent in multipart message : protocol for exchanging e messages RFC 822: standard for text message format: header lines, e.g., To: From: Subject: different from MAIL FROM, RCPT TO: commands! Body: the message ASCII characters only header body blank line Application Layer 2-45 Application Layer 2-46 Mail access protocols sender s receiver s access protocol (e.g., POP, IMAP) : delivery/storage to receiver s access protocol: retrieval from POP: Post Office Protocol [RFC 1939]: authorization, download IMAP: Mail Access Protocol [RFC 1730]: more features, including manipulation of stored messages on HTTP: g, Hot, Yahoo! Mail, etc. Application Layer 2-47 POP3 protocol authorization phase commands: : declare name pass: password responses +OK -ERR transaction phase, : list: list message numbers retr: retrieve message by number dele: delete quit S: +OK POP3 ready C: bob S: +OK C: pass hungry S: +OK successfully logged on C: list S: 1 498 S: 2 912 S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 signing off Application Layer 2-48 POP3 (more) and IMAP more about POP3 previous example uses POP3 download and delete mode Bob cannot re-read e- if he changes POP3 download-andkeep : copies of messages on different s POP3 is stateless across sessions IMAP keeps all messages in one place: at allows to organize messages in folders keeps state across sessions: names of folders and mappings between message IDs and folder name Chapter 2: outline 2.1 principles of s 2.2 Web and HTTP 2.3 electronic, POP3, IMAP 2.4 socket programming with UDP and TCP Application Layer 2-49 Application Layer 2-50 8
Socket programming goal: learn how to build / s that communicate using sockets socket: door between process and endend- protocol process link socket process link controlled by app developer controlled by OS Application Layer 2-51 Socket programming Two socket types for two services: UDP: unreliable datagram TCP: reliable, byte stream-oriented Application Example: 1. reads a line of characters (data) from its keyboard and sends data to 2. receives the data and converts characters to uppercase 3. sends modified data to 4. receives modified data and displays line on its screen Application Layer 2-52 Socket programming with UDP Client/ socket interaction: UDP UDP: no connection between & no handshaking before sending data sender explicitly attaches IP destination address and port # to each packet receiver extracts sender IP address and port# from received packet UDP: transmitted data may be lost or received out-of-order Application viewpoint: UDP provides unreliable transfer of groups of bytes ( datagrams ) between and (running on IP) create socket, port= x: Socket = socket(af_inet,sock_dgram) read datagram from Socket write reply to Socket specifying address, port number create socket: Socket = socket(af_inet,sock_dgram) Create datagram with IP and port=x; send datagram via Socket read datagram from Socket close Socket Application Layer 2-53 Application 2-54 Example app: UDP Example app: UDP include Python s socket library create UDP socket for get keyboard input Attach name, port to message; send into socket read reply characters from socket into string print out received string and close socket Python UDPClient from socket import * Name = hostname Port = 12000 Socket = socket(af_inet, SOCK_DGRAM) message = raw_input( Input lowercase sentence: ) Socket.sendto(message.encode(), (Name, Port)) modifiedmessage, Address = print modifiedmessage.decode() Socket.close() Socket.recvfrom(2048) Application Layer 2-55 create UDP socket bind socket to local port number 12000 loop forever Read from UDP socket into message, getting s address ( IP and port) send upper case string back to this Python UDPServer from socket import * Port = 12000 Socket = socket(af_inet, SOCK_DGRAM) Socket.bind(('', Port)) print ( The is ready to receive ) while True: message, Address = Socket.recvfrom(2048) modifiedmessage = message.decode().upper() Socket.sendto(modifiedMessage.encode(), Address) Application Layer 2-56 9
Socket programming with TCP must contact process must first be running must have created socket (door) that welcomes s contact contacts by: Creating TCP socket, specifying IP address, port number of process when creates socket: TCP establishes connection to TCP when contacted by, TCP creates new socket for process to communicate with that particular allows to talk with multiple s source port numbers used to distinguish s (more in Chap 3) viewpoint: TCP provides reliable, in-order byte-stream transfer ( pipe ) between and Client/ socket interaction: TCP (running on hostid) create socket, port=x, for incoming request: Socket = socket() wait for incoming connection request TCP connectionsocket = connection setup Socket.accept() read request from connectionsocket write reply to connectionsocket close connectionsocket create socket, connect to hostid, port=x Socket = socket() send request using Socket read reply from Socket close Socket Application Layer 2-57 Application Layer 2-58 Example app: TCP create TCP socket for, remote port 12000 No need to attach name, port Python TCPClient from socket import * Name = name Port = 12000 Socket = socket(af_inet, SOCK_STREAM) Socket.connect((Name,Port)) sentence = raw_input( Input lowercase sentence: ) Socket.send(sentence.encode()) modifiedsentence = Socket.recv(1024) print ( From Server:, modifiedsentence.decode()) Socket.close() Application Layer 2-59 Example app: TCP create TCP welcoming socket begins listening for incoming TCP requests loop forever waits on accept() for incoming requests, new socket created on return read bytes from socket (but not address as in UDP) close connection to this (but not welcoming socket) Python TCPServer from socket import * Port = 12000 Socket = socket(af_inet,sock_stream) Socket.bind((,Port)) Socket.listen(1) print The is ready to receive while True: connectionsocket, addr = Socket.accept() sentence = connectionsocket.recv(1024).decode() capitalizedsentence = sentence.upper() connectionsocket.send(capitalizedsentence. encode()) connectionsocket.close() Application Layer 2-60 Chapter 2: summary our study of apps now complete! architectures - P2P service requirements: reliability, bandwidth, delay service model connection-oriented, reliable: TCP unreliable, datagrams: UDP specific protocols: HTTP, POP, IMAP socket programming: TCP, UDP sockets Chapter 2: summary most importantly: learned about protocols! typical request/reply message exchange: requests info or service responds with data, status code message formats: headers: fields giving info about data data: info(payload) being communicated important themes: control vs. messages in-band, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable message transfer complexity at edge Application Layer 2-61 Application Layer 2-62 10