Chapter 2: Application Layer Our goals: learn about protocols - PowerPoint PPT Presentation

Nonpersistent HTTP (cont.) 4. HTTP server closes TCP connection. 5 . HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects time 6. Steps 1-5 repeated for each of 10 jpeg objects 2: Application Layer 22

Response time modeling Definition of RRT: time to send a small packet to travel from client to server and back. initiate TCP connection Response time: RTT  one RTT to initiate TCP request connection file time to RTT  one RTT for HTTP transmit file request and first few file bytes of HTTP response received to return time time  file transmission time total = 2RTT+transmit time 2: Application Layer 23

Persistent HTTP Persistent without pipelining: Nonpersistent HTTP issues:  client issues new request  requires 2 RTTs per object only when previous  OS must work and allocate response has been received host resources for each TCP  one RTT for each connection referenced object  but browsers often open Persistent with pipelining: parallel TCP connections to fetch referenced objects  default in HTTP/1.1 Persistent HTTP  client sends requests as soon as it encounters a  server leaves connection referenced object open after sending response  as little as one RTT for all  subsequent HTTP messages the referenced objects between same client/server are sent over connection 2: Application Layer 24

HTTP request message  two types of HTTP messages: request , response  HTTP request message: o ASCII (human-readable format) request line (GET, POST, GET /somedir/page.html HTTP/1.1 HEAD commands) Host: www.bilkent.edu.tr User-agent: Mozilla/4.0 header Connection: close lines Accept-language:fr Carriage return, (extra carriage return, line feed) line feed indicates end of message 2: Application Layer 25

HTTP request message: general format 2: Application Layer 26

Method types HTTP/1.0 HTTP/1.1  GET  GET, POST, HEAD  POST  PUT  HEAD o uploads file in entity body to path specified o asks server to leave in URL field requested object out of  DELETE response o deletes file specified in the URL field 2: Application Layer 27

Uploading form input Post method:  Web page often includes form input  Input is uploaded to server in entity body URL method:  Uses GET method  Input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana 2: Application Layer 28

HTTP response message status line (protocol status code HTTP/1.1 200 OK status phrase) Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) header Last- Modified: Mon, 22 Jun 1998 …... lines Content-Length: 6821 Content-Type: text/html data, e.g., data data data data data ... requested HTML file 2: Application Layer 29

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

Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: Opens TCP connection to port 80 telnet www.ee.bilkent.edu.tr 80 (default HTTP server port) at www.ee.bilkent.edu.tr. Anything typed in sent to port 80 at www.ee.bilkent.edu.tr 2. Type in a GET HTTP request: By typing this in (hit carriage GET /~ezhan/index.html HTTP/1.0 return twice), you send this minimal (but complete) GET request to HTTP server 3. Look at response message sent by HTTP server! 2: Application Layer 31

User-server interaction: authorization Authorization : control access to server client server content usual http request msg  authorization credentials: typically name, password 401: authorization req.  stateless: client must present WWW authenticate: authorization in each request authorization: header line in usual http request msg o each request + Authorization: <cred> o if no authorization : header, usual http response msg server refuses access, sends usual http request msg WWW authenticate: + Authorization: <cred> header line in response time usual http response msg 2: Application Layer 32

Cookies: keeping “state” Many major Web sites Example: use cookies o Susan access Internet always from same PC Four components: o She visits a specific e- 1) cookie header line in commerce site for first the HTTP response time message o When initial HTTP 2) cookie header line in requests arrives at site, HTTP request message site creates a unique ID 3) cookie file kept on and creates an entry in user’s host and managed backend database for by user’s browser ID 4) back-end database at Web site 2: Application Layer 33

Cookies: keeping “state” (cont.) client server usual http request msg server Cookie file creates ID usual http response + 1678 for user Set-cookie: 1678 ebay: 8734 Cookie file usual http request msg cookie- cookie: 1678 amazon: 1678 specific ebay: 8734 usual http response msg action one week later: usual http request msg cookie- Cookie file cookie: 1678 spectific amazon: 1678 usual http response msg action ebay: 8734 2: Application Layer 34

Cookies (continued) Cookies and privacy: What cookies can bring:  cookies permit sites to  authorization learn a lot about you  shopping carts  you may supply name  recommendations and e-mail to sites  user session state  search engines use (Web e-mail) redirection & cookies how to keep “ state ” : to learn yet more  protocol endpoints:  advertising companies maintain state at obtain info across sender/receiver over sites multiple transactions  cookies: http messages carry state 2: Application Layer 35

Set-Cookie HTTP Response Header Set-Cookie: NAME = VALUE ; expires= DATE ; path= PATH ; domain= DOMAIN_NAME ; secure NAME = VALUE o • sequence of characters excluding semi-colon, comma and white space (the only required field) expires = DATE o Format: Wdy, DD-Mon-YYYY HH:MM:SS GMT domain = DOMAIN_NAME o • Browser performs “tail matching” searching through cookies file • Default domain is the host name of the server which generated the cookie response o path = PATH • the subset of URLs in a domain for which the cookie is valid o Secure: if secure cookie will only be transmitted if the communications channel with the host is secure, e.g., HTTPS 2: Application Layer 36

Cookies File  Netscape keeps all cookies in a single file ~username/.netscape/cookies whereas IE keeps each cookie in separate files in the folder C:\Documents and Settings\user\Cookies # Netscape HTTP Cookie File # http://www.netscape.com/newsref/std/cookie_spec.html # This is a generated file! Do not edit. .netscape.com TRUE / FALSE 1128258721 sampler 1097500321 .edge.ru4.com TRUE / FALSE 2074142135 ru4.uid 2|3|0#12740302632086421#1917818738 .edge.ru4.com TRUE / FALSE 1133246135 ru4.1188.gts :2 .netscape.com TRUE / FALSE 1128065747 RWHAT set|1128065747300 .nytimes.com TRUE / FALSE 1159598159 RMID 833ff0b33a03433cdccf603e .netscape.com TRUE / FALSE 1128148560 adsNetPopup0 1128062159725 servedby.advertising.com TRUE / FALSE 1130654161 1812261973 _433cdcd1,,695214^76559_ .advertising.com TRUE / FALSE 1285742161 ACID bb640011280621610000! .bluestreak.com TRUE / FALSE 1443407766 id 33167285258566120 bb=141A11twQw_"4totrKoAA| adv= .mediaplex.com TRUE / FALSE 1245628800 svid 80016269101 .nytdigital.com TRUE / FALSE 1625726176 TID 0e0pcsb11jpn70 .nytdigital.com TRUE / FALSE 1625726176 TData .nytimes.com TRUE / FALSE 1625726176 TID 0e0pcsb11jpn70 .nytimes.com TRUE / FALSE 1625726176 TData .doubleclick.net TRUE / FALSE 1222670215 id 8000006195fbc8b servedby.advertising.com TRUE / FALSE 1130654216 5907528 _433cdd08,,707769^243007_ www.yahoo.com TRUE / FALSE 1149188401 FPB fc1hmqbqc11jpnci 2: Application Layer 37

Cookies File Format Domain Accessible Path Secure Expiration Name Value by all (Unix time) hosts edge.ru4.com TRUE / FALSE 2074142135 ru4.uid 2|3|0#1274… nytimes.com TRUE / FALSE 1625726176 TID 0e0pcsb11jpn70 Thu, 8 Jul 2021 06:36:16 UTC Sun, 23 Sep 2035 06:35:35 UTC 2: Application Layer 38

Conditional GET: client-side caching server client  Goal: don’t send object if client has up-to-date cached HTTP request msg version If-modified-since: object  client: specify date of <date> not cached copy in HTTP request modified HTTP response If-modified-since: HTTP/1.0 <date> 304 Not Modified  server: response contains no object if cached copy is up- HTTP request msg to-date: If-modified-since: object HTTP/1.0 304 Not <date> modified Modified HTTP response HTTP/1.0 200 OK <data> 2: Application Layer 39

FTP: the file transfer protocol file transfer FTP FTP FTP user client server interface user remote file local file at host system system  transfer file to/from remote host  client/server model o client: side that initiates transfer (either to/from remote) o server: remote host  ftp: RFC 959  ftp server: port 21 2: Application Layer 40

FTP: separate control, data connections TCP control connection  FTP client contacts FTP port 21 server at port 21, specifying TCP as transport protocol TCP data connection FTP FTP  Client obtains authorization port 20 client server over control connection  Client browses remote  Server opens a second TCP directory by sending data connection to transfer commands over control another file. connection.  Control connection: “out of  When server receives a band” command for a file transfer,  FTP server maintains “state”: the server opens a TCP data current directory, earlier connection to client authentication  After transferring one file, server closes connection. 2: Application Layer 41

FTP commands, responses Sample commands: Sample return codes  sent as ASCII text over  status code and phrase (as control channel in HTTP)  USER username  331 Username OK, password required  PASS password  125 data connection  LIST return list of file in already open; current directory transfer starting  RETR filename retrieves  425 Can’t open data (gets) file connection  STOR filename stores  452 Error writing (puts) file onto remote file host 2: Application Layer 42

Electronic Mail outgoing message queue user mailbox user Three major components: agent  user agents mail user server  mail servers agent SMTP  simple mail transfer mail protocol: SMTP server user SMTP agent User Agent SMTP  a.k.a. “mail reader” user mail  composing, editing, reading agent server mail messages  e.g., Eudora, Outlook, elm, user Netscape Messenger agent user  outgoing, incoming messages agent stored on server 2: Application Layer 43

Electronic Mail: mail servers Mail Servers user agent  mailbox contains incoming mail user messages for user server agent  message queue of outgoing SMTP (to be sent) mail messages mail server user  SMTP protocol between mail SMTP agent servers to send email messages SMTP user o client: sending mail mail agent server server o “server”: receiving mail user server agent user agent 2: Application Layer 44

Electronic Mail: SMTP [RFC 2821]  uses TCP to reliably transfer email message from client to server, port 25  direct transfer: sending server to receiving server  three phases of transfer o handshaking (greeting) o transfer of messages o closure  command/response interaction o commands: ASCII text o response: status code and phrase  messages must be in 7-bit ASCII 2: Application Layer 45

Scenario: Ayşe sends message to Ali 4) SMTP client sends Ay şe’s 1) Ay şe uses UA to compose message over the TCP message and “to” connection ali@bilkent.edu.tr 5) Ali’s mail server places the 2) Ay şe’s UA sends message message in Ali’s mailbox to her mail server; message placed in message queue 6) Ali invokes his user agent to read message 3) Client side of SMTP opens TCP connection with Ali’s mail server Ali Ay şe 1 mail mail user server user server agent 2 agent 6 3 4 5 2: Application Layer 46

SMTP interaction for yourself  telnet cs.bilkent.edu.tr 25 220 gordion.cs.bilkent.edu.tr ESMTP Sendmail 8.12.9/8.12.9; Wed, 3 Mar 2004 11:17:52 +0200 (EET)  HELO cs.bilkent.edu.tr 250 gordion.cs.bilkent.edu.tr Hello nemrut.ee.bilkent.edu. tr [139.179.12.28], pleased to meet you  MAIL FROM: <somebody@somewhere.net> 250 2.1.0 <somebody@somewhere.net>... Sender ok  RCPT TO: <ezhan@ee.bilkent.edu.tr> 250 2.1.5 <ezhan@ee.bilkent.edu.tr>... Recipient ok  DATA 354 Enter mail, end with "." on a line by itself  hello . 250 2.0.0 Message accepted for delivery  QUIT 221 2.0.0 gordion.cs.bilkent.edu.tr closing connection 2: Application Layer 47

SMTP: final words Comparison with HTTP:  SMTP uses persistent connections  HTTP: pull  SMTP requires message  SMTP: push (header & body) to be in 7- bit ASCII  both have ASCII  SMTP server uses command/response CRLF.CRLF to determine interaction, status codes end of message  HTTP: each object encapsulated in its own response msg  SMTP: multiple objects sent in multipart msg 2: Application Layer 48

Mail access protocols SMTP SMTP access user user protocol agent agent receiver’s mail sender’s mail server server  SMTP: delivery/storage to receiver’s server  Mail access protocol: retrieval from server o POP: Post Office Protocol [RFC 1939] • authorization (agent <-->server) and download o IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server o HTTP: Hotmail , Yahoo! Mail, etc. 2: Application Layer 49

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

DNS Why not centralize DNS? DNS services  single point of failure  Hostname to IP address translation  traffic volume  Host aliasing  distant centralized database o Canonical and alias names  maintenance  Mail server aliasing  Load distribution doesn’t scale! o Replicated Web servers: set of IP addresses for one canonical name 2: Application Layer 51

Distributed, Hierarchical Database Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu umass.edu pbs.org yahoo.com amazon.com DNS servers DNS servers DNS servers DNS servers DNS servers Client wants IP for www.amazon.com; 1 st approx:  Client queries a root server to find com DNS server  Client queries com DNS server to get amazon.com DNS server  Client queries amazon.com DNS server to get IP address for www.amazon.com 2: Application Layer 52

DNS: Root name servers  contacted by local name server that can not resolve name  root name server: o contacts authoritative name server if name mapping not known o gets mapping o returns mapping to local name server a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD k RIPE London (also Amsterdam, g US DoD Vienna, VA Frankfurt) i Autonomica, Stockholm (plus 3 h ARL Aberdeen, MD other locations) j Verisign, ( 11 locations) m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Application Layer 53

TLD and Authoritative Servers  Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. o Network solutions maintains servers for com TLD o Educause for edu TLD  Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail). o Can be maintained by organization or service provider 2: Application Layer 54

Local Name Server  Does not strictly belong to hierarchy  Each ISP (residential ISP, company, university) has one. o Also called “default name server”  When a host makes a DNS query, query is sent to its local DNS server o Acts as a proxy, forwards query into hierarchy. 2: Application Layer 55

Example root DNS server 2  Host at 3 TLD DNS server firat.bilkent.edu.tr 4 wants IP address for 5 gaia.cs.umass.edu local DNS server dns.bilkent.edu.tr 6 7 1 8 authoritative DNS server dns.cs.umass.edu requesting host Firat.bilkent.edu.tr gaia.cs.umass.edu 2: Application Layer 56

Recursive queries root DNS server recursive query: 2  puts burden of name 3 resolution on 6 7 contacted name TLD DNS server server  heavy load? local DNS server 4 iterated query: dns.bilkent.edu.tr 5  contacted server 1 8 replies with name of server to contact authoritative DNS server  “I don’t know this dns.cs.umass.edu requesting host name, but ask this Firat.bilkent.edu.tr server” gaia.cs.umass.edu 2: Application Layer 57

DNS: caching and updating records  once (any) name server learns mapping, it caches mapping o cache entries timeout (disappear) after some time o TLD servers typically cached in local name servers • Thus root name servers not often visited  update/notify mechanisms under design by IETF o RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html o 2: Application Layer 58

DNS records DNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl)  Type=A  Type=CNAME o name is hostname o name is alias name for some “cannonical” (the real) name o value is IP address www.ibm.com is really  Type=NS name is domain (e.g. servereast.backup2.ibm.com o foo.com) o value is cannonical name value is IP address of o authoritative name server  Type=MX for this domain o value is name of mailserver associated with name 2: Application Layer 59

DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header  identification: 16 bit # for query, reply to query uses same #  flags: o query or reply o recursion desired o recursion available o reply is authoritative 2: Application Layer 60

DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used 2: Application Layer 61

Inserting records into DNS  Example: just created startup “Network Utopia”  Register name networkuptopia.com at a registrar (e.g., Network Solutions) o Need to provide registrar with names and IP addresses of your authoritative name server (primary and secondary) o Registrar inserts two RRs into the com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)  Put in authoritative server Type A record for www.networkutopia.com and Type MX record for mail.networkutopia.com 2: Application Layer 62

How do people connect to Web server? com TLD DNS server contains type A and NS RRs for 3: reply contains IP Network Utopia address for auth. name server for 2 Network Utopia authoritative name (212.212.212.1) server for Network local DNS server 4 Utopia dns.bilkent.edu.tr 5: reply contains IP IP: 212.212.212.1 address for Web 1 6 server for Network Utopia (212.212.212.178) Web server for Network Utopia requesting host TCP connection IP: 212.212.212.178 7: firat.bilkent.edu.tr 2: Application Layer 63

Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API socket  introduced in BSD4.1 UNIX, a host-local , 1981 application-created ,  explicitly created, used, OS-controlled interface released by apps (a “door”) into which application process can  client/server paradigm both send and  two types of transport receive messages to/from service via socket API: another application o unreliable datagram process o reliable, byte stream- oriented 2: Application Layer 64

Socket-programming using TCP Socket: a door between application process and end- end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by controlled by process application process application developer socket developer socket TCP with controlled by TCP with controlled by buffers, operating operating buffers, internet system variables system variables host or host or server server 2: Application Layer 65

Socket programming with TCP Client must contact server  When contacted by client, server TCP creates new  server process must first socket for server process to be running communicate with client  server must have created o allows server to talk with socket (door) that multiple clients welcomes client’s contact o source port numbers Client contacts server by: used to distinguish  creating client-local TCP clients (more in Chap 3) socket  specifying IP address, port application viewpoint number of server process TCP provides reliable, in-order  When client creates transfer of bytes (“pipe”) socket: client TCP between client and server establishes connection to server TCP 2: Application Layer 66

Stream jargon  A stream is a sequence of characters that flow into or out of a process.  An input stream is attached to some input source for the process, eg, keyboard or socket.  An output stream is attached to an output source, eg, monitor or socket. 2: Application Layer 67

Socket programming with TCP keyboard monitor Example client-server app: 1) client reads line from standard input ( inFromUser inFromUser input stream stream) , sends to server via Client socket ( outToServer Process process stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to inFromServer outToServer client output input stream stream 4) client reads, prints modified client TCP line from socket clientSocket socket ( inFromServer stream) TCP socket to network from network 2: Application Layer 68

Client/server socket interaction: TCP Server (running on hostid ) Client create socket, port= x , for incoming request: welcomeSocket = ServerSocket() TCP create socket, wait for incoming connection setup connect to hostid , port= x connection request clientSocket = connectionSocket = Socket() welcomeSocket.accept() send request using read request from clientSocket connectionSocket write reply to connectionSocket read reply from clientSocket close close connectionSocket clientSocket 2: Application Layer 69

Example: Java client (TCP) import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; Create BufferedReader inFromUser = input stream new BufferedReader(new InputStreamReader(System.in)); Create client socket, Socket clientSocket = new Socket("hostname", 6789); connect to server Create DataOutputStream outToServer = output stream new DataOutputStream(clientSocket.getOutputStream()); attached to socket 2: Application Layer 70

Example: Java client (TCP), cont. Create BufferedReader inFromServer = input stream new BufferedReader(new attached to socket InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); Send line to server outToServer.writeBytes(sentence + '\n'); Read line modifiedSentence = inFromServer.readLine(); from server System.out.println ("FROM SERVER: " + modifiedSentence ); clientSocket.close(); } } 2: Application Layer 71

Example: Java server (TCP) import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; Create String capitalizedSentence; welcoming socket ServerSocket welcomeSocket = new ServerSocket(6789); at port 6789 while(true) { Wait, on welcoming socket for contact Socket connectionSocket = welcomeSocket.accept(); by client BufferedReader inFromClient = Create input new BufferedReader(new stream, attached InputStreamReader(connectionSocket.getInputStream())); to socket 2: Application Layer 72

Example: Java server (TCP), cont Create output stream, attached DataOutputStream outToClient = to socket new DataOutputStream (connectionSocket.getOutputStream()); Read in line clientSentence = inFromClient.readLine(); from socket capitalizedSentence = clientSentence.toUpperCase() + '\n'; Write out line outToClient.writeBytes(capitalizedSentence); to socket } } End of while loop, } loop back and wait for another client connection 2: Application Layer 73

Socket programming with UDP UDP: no “connection” between client and server  no handshaking  sender explicitly attaches application viewpoint IP address and port of UDP provides unreliable transfer destination to each packet of groups of bytes (“datagrams”)  server must extract IP between client and server address, port of sender from received packet UDP: transmitted data may be received out of order, or lost 2: Application Layer 74

Client/server socket interaction: UDP Server (running on hostid ) Client create socket, create socket, port= x , for clientSocket = incoming request: DatagramSocket() serverSocket = DatagramSocket() Create, address ( hostid, port=x, send datagram request using clientSocket read request from serverSocket write reply to serverSocket read reply from specifying client clientSocket host address, port number close clientSocket 2: Application Layer 75

Example: Java client (UDP) keyboard monitor inFromUser input stream Client Process Input: receives process packet (TCP received “byte Output: sends stream”) packet (TCP sent receivePacket sendPacket “byte stream”) UDP UDP packet packet client UDP clientSocket socket UDP socket to network from network 2: Application Layer 76

Example: Java client (UDP) import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { Create input stream BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Create client socket DatagramSocket clientSocket = new DatagramSocket(); Translate InetAddress IPAddress = InetAddress.getByName("hostname"); hostname to IP address using DNS byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); 2: Application Layer 77

Example: Java client (UDP), cont. Create datagram with data-to-send, DatagramPacket sendPacket = length, IP addr, port new DatagramPacket(sendData, sendData.length, IPAddress, 9876); Send datagram clientSocket.send(sendPacket); to server DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Read datagram clientSocket.receive(receivePacket); from server String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } 2: Application Layer 78

Example: Java server (UDP) import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception Create { datagram socket DatagramSocket serverSocket = new DatagramSocket(9876); at port 9876 byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { Create space for received datagram DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Receive serverSocket.receive(receivePacket); datagram 2: Application Layer 79

Example: Java server (UDP), cont String sentence = new String(receivePacket.getData()); Get IP addr InetAddress IPAddress = receivePacket.getAddress(); port #, of sender int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); Create datagram DatagramPacket sendPacket = to send to client new DatagramPacket(sendData, sendData.length, IPAddress, port); Write out datagram serverSocket.send(sendPacket); to socket } } End of while loop, } loop back and wait for another datagram 2: Application Layer 80

Socket programming: references Java-tutorials:  “All About Sockets” (Sun tutorial), http://www.javaworld.com/javaworld/jw-12- 1996/jw-12-sockets.html  “Socket Programming in Java: a tutorial,” http://www.javaworld.com/javaworld/jw-12- 1996/jw-12-sockets.html 2: Application Layer 81

Web caches (proxy server) Goal: satisfy client request without involving origin server  user sets browser: Web origin server accesses via cache  browser sends all HTTP Proxy requests to cache server client object in cache: cache o returns object else cache requests o object from origin server, then returns object to client client origin server 2: Application Layer 82

More about Web caching Why Web caching?  Cache acts as both client and server  Reduce response time for  Cache can do up-to-date client request. check using If-modified-  Reduce traffic on an since HTTP header institution’s access link. Issue: should cache take o  Internet dense with caches risk and deliver cached enables “poor” content object without checking? providers to effectively Heuristics are used. o deliver content  Typically cache is installed by ISP (university, company, residential ISP) 2: Application Layer 83

Caching example (1) origin Assumptions servers  average object size = 100,000 public bits Internet  avg. request rate from institution’s browser to origin serves = 15/sec 1.5 Mbps  delay from institutional router access link to any origin server and back institutional to router = 2 sec network 10 Mbps LAN Consequences utilization on LAN = 15%  utilization on access link = 100%  institutional total delay = Internet delay +  cache access delay + LAN delay = 2 sec + minutes + milliseconds 2: Application Layer 84

Caching example (2) origin Possible solution servers  increase bandwidth of access public link to, say, 10 Mbps Internet Consequences utilization on LAN = 15%  utilization on access link = 15%  10 Mbps Total delay = Internet delay +  access link access delay + LAN delay institutional = 2 sec + msecs + msecs network 10 Mbps LAN often a costly upgrade  institutional cache 2: Application Layer 85

Caching example (3) origin servers Install cache public  suppose hit rate is .4 Internet Consequence  40% requests will be satisfied almost immediately 1.5 Mbps  60% requests satisfied by access link origin server institutional  utilization of access link network 10 Mbps LAN reduced to 60%, resulting in negligible delays (say 10 msec) institutional cache 2: Application Layer 86

Content distribution networks (CDNs) origin server in North America  The content providers are the CDN customers. Content replication  CDN company installs CDN distribution node hundreds of CDN servers throughout Internet o in lower-tier ISPs, close to users  CDN replicates its customers’ content in CDN servers. When provider updates CDN server CDN server content, CDN updates in S. America CDN server in Asia servers in Europe 2: Application Layer 87

CDN example HTTP request for www.foo.com/sports/sports.html Origin server 1 2 DNS query for www.cdn.com CDNs authoritative DNS server 3 HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif Nearby CDN server CDN company origin server  cdn.com  www.foo.com  distributes gif files  distributes HTML  uses its authoritative Replaces:  DNS server to route http://www.foo.com/sports.ruth.gif with redirect requests h ttp://www.cdn.com/www.foo.com/sports/ruth.gif 2: Application Layer 88

Streaming stored video simple scenario : Internet video server client (stored video) 2- Application Layer 89

Streaming multimedia: DASH  DASH: D ynamic, A daptive S treaming over H TTP  server: o divides video file into multiple chunks o each chunk stored, encoded at different rates o manifest file: provides URLs for different chunks  client: o periodically measures server-to-client bandwidth o consulting manifest, requests one chunk at a time • chooses maximum coding rate sustainable given current bandwidth • can choose different coding rates at different points in time (depending on available bandwidth at time) 2- Application Layer 90

Streaming multimedia: DASH  DASH: D ynamic, A daptive S treaming over H TTP  “ intelligence ” at client: client determines o when to request chunk (so that buffer starvation, or overflow does not occur) o what encoding rate to request (higher quality when more bandwidth available) o where to request chunk (can request from URL server that is “ close ” to client or has high available bandwidth) 2- Application Layer 91

Content distribution networks  challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users?  option 1: single, large “ mega-server ” o single point of failure o point of network congestion o long path to distant clients o multiple copies of video sent over outgoing link ….quite simply: this solution doesn ’ t scale 2- Application Layer 92

Content distribution networks  challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users?  option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN) o enter deep: push CDN servers deep into many access networks • close to users • used by Akamai, 1700 locations o bring home: smaller number (10 ’ s) of larger clusters in POPs near (but not within) access networks • used by Limelight 2- Application Layer 93

Content Distribution Networks (CDNs)  CDN: stores copies of content at CDN nodes • e.g. Netflix stores copies of MadMen  subscriber requests content from CDN • directed to nearby copy, retrieves content • may choose different copy if network path congested where ’ s Madmen? 2- Application Layer 94

Content Distribution Networks (CDNs) Challenges: coping with a congested Internet o from which CDN node to retrieve content? o viewer behavior in presence of congestion? o what content to place in which CDN node?

Case study: Netflix upload copies of Amazon cloud multiple versions of video to CDN servers CDN server Netflix registration, accounting servers 3. Manifest file returned for 2. Bob browses CDN requested video Netflix video 2 server 3 1 1. Bob manages CDN Netflix account server 4. DASH streaming 2- Application Layer 96

Pure P2P architecture  no always-on server  arbitrary end systems directly communicate peer-peer  peers are intermittently connected and change IP addresses examples: o file distribution (BitTorrent) o Streaming (KanKan) o VoIP (Skype) 2: Application Layer 2: Application Layer 97 97

File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers ? u s : server upload bandwidth Server u i : peer i upload bandwidth u 2 u 1 d 1 d 2 u s d i : peer i download File, size F bandwidth d N Network (with abundant bandwidth) u N 2: Application Layer 2: Application Layer 98 98

File distribution time: server-client Server  server sequentially F u 2 u 1 d 1 sends N copies: d 2 u s o NF/u s time Network (with d N abundant bandwidth)  client i takes F/d i u N time to download Time to distribute F = d cs = max { NF/u s , F/min(d i ) } to N clients using i client/server approach increases linearly in N (for large N) 2: Application Layer 2: Application Layer 99 99

File distribution time: P2P Server  server must send one F u 2 copy: F /u s time u 1 d 1 d 2 u s  client i takes F/d i time Network (with to download d N abundant bandwidth)  NF bits must be u N downloaded (aggregate)  fastest possible upload rate: u s + S u i d P2P = max { F/u s , F/min i d i ) , NF/(u s + S u i ) } 2: Application Layer 2: Application Layer 100 100