1 / 29

CSE 524: Lecture 5

This lecture discusses web caches (proxy servers) and content distribution networks (CDNs) and their role in satisfying client requests without involving the origin server.

renright
Download Presentation

CSE 524: Lecture 5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application layer protocols CSE 524: Lecture 5

  2. Where we’re at… • Internet architecture and history • Internet protocols in practice • Application layer • Overview and functions • Network programming interface • Specific application protocols • HTTP • DNS, SMTP/POP, FTP • Transport layer • Network layer • Data-link layer • Physical layer

  3. Goal: satisfy client request without involving origin server AL: Web Caches (proxy server) • user sets browser: Web accesses via web cache • client sends all http requests to web cache • if object at web cache, web cache immediately returns object in http response • else requests object from origin server, then returns http response to client • Internet dense with caches enables “poor” content providers to effectively deliver content origin server Proxy server http request http request client http response http response http request http request http response http response client origin server

  4. AL: More about Web caching • Cache acts as both client to content servers • Cache acts as server to its users • Typically installed by ISP (university, company, residential ISP) • Cache can do up-to-date check using If-modified-since HTTP header • Issue: should cache take risk and deliver cached object without checking? • Heuristics are used.

  5. AL: Benefits of web caches Assume: cache is “close” to client (e.g., in same network) • smaller response time: cache “closer” to client • decrease traffic to distant servers • link out of institutional/local ISP network often bottleneck • Further info on web caching • http://www.ircache.net/ • http://www.squid.org • ICP • http://www.rfc-editor.org/rfc/rfc2186.txt • http://www.rfc-editor.org/rfc/rfc2187.txt origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache

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

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

  8. not just Web pages streaming stored audio/video streaming real-time audio/video CDN nodes create application-layer multicast overlay network More about CDNs routing requests • CDN creates a “map”, indicating distances from leaf ISPs and CDN nodes • when query arrives at authoritative DNS server: • server determines ISP from which query originates • uses “map” to determine best CDN server

  9. AL: Domain Name System (DNS) • Internet hosts, routers like to use fixed-length addresses (numbers) • IP address (32 bit) - used for addressing datagrams • Humans like to use variable-length names • www.cse.ogi.edu • keywords • DNS, keywords, naming protocols • Map from IP addresses to names • Map from names to IP addresses

  10. AL: Original Name to Address Mapping • Flat namespace • /etc/hosts • SRI kept main copy • Downloaded regularly • Problems • Count of hosts was increasing: machine per domain -> machine per user • Many more downloads • Many more updates

  11. AL: Goals for a new naming system • Implement a wide area distributed database • Scalability • Decentralized maintenance • Robustness, fault-tolerance • Global scope • Names mean the same thing everywhere • Don’t need • Atomicity • Strong consistency

  12. AL: Goals for a new naming system Why not centralize DNS? • Single server with all name-to-IP address mappings • single point of failure • traffic volume • distant centralized database (performance) • maintenance • doesn’t scale!

  13. AL: DNS (Domain Name System) • http://www.rfc-editor.org/rfc/rfc1034.txt • http://www.rfc-editor.org/rfc/rfc1035.txt • distributed database implemented in hierarchy of many name servers • decentralized control and management of data • application-layer protocol used by hosts and name servers • communicate to resolvenames (address/name translation) • core Internet function implemented as application-layer protocol • complexity at network’s “edge” • compare to phone network • Naming (none supported) • Addressing (complex mechanism within network)

  14. AL: DNS nutshell solution • Hierarchical canonical name space • www.cse.ogi.edu root edu uk com net org ca ogi bu mit ucb gwu cse ece www

  15. AL: DNS nutshell solution • Authoritative name servers store parts of the database • Names assigned to authoritative name servers • For a host, authority stores that host’s IP address, name • Responds to queries for host’s IP address • Perform name/address translation for that host’s name • Root name server knows authoritative servers for particular subdomains • Hierarchy organizes authoritative name servers • Reserving a domain gives you control of entry in root name server for particular names • DNS hierarchical lookup • Each host has a pointer to a local name server for which to query for unknown names • Each local name server knows root of hierarchy • Root points to sub-levels, sub-levels point to deeper sub-levels, … , deeper sub-levels point to leaf name server representing authority for unknown name

  16. local name server dns.eurecom.fr intermediate name server dns.umass.edu AL: DNS nutshell figure root name server Root name servers: • may not know authoratiative name server • may know intermediate name server: who to contact to find authoritative name server • multiple root name servers for fault-tolerance Example: • surf.eurecom.fr wants to talk to gaia.cs.umass.edu • contact local dns server • local dns contacts root • root contacts authoritative (or next level to authoritative) 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

  17. a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA 13 root name servers worldwide (all that fit in a 512 octet SOA record) b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA AL: DNS: Root name servers • contacted by local name server that can not resolve any part of the name • root name server: • contacts authoritative name server if name mapping not known • gets mapping • returns mapping to local name server

  18. AL: DNS server name database • DB contains tuples called resource records (RRs) • RR contains type, class and application data • Before types added, only one record type (A) • Classes = Internet (IN), Chaosnet (CH), etc. • Each class defines types, e.g. for IN: • A = address • NS = name server • CNAME = canonical name (for aliasing) • HINFO = CPU/OS info • MX = mail exchange • PTR = pointer for reverse mapping of address to name • nslookup example

  19. Type=NS name is domain (e.g. foo.com) value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl) • Type= CNAME • name is an alias name for some “cannonical” (the real) name • value is cannonical name • Type=A • name is hostname • value is IP address • Type=MX • value is hostname of mailserver associated with name AL: DNS record types Resource records (RR) and their types

  20. AL: DNS MX record type • MX records point to mail exchanger for a name • E.g. mail.acm.org is MX for acm.org • Addition of MX record type proved to be a challenge • How to get mail programs to lookup MX record for mail delivery rather than A record? • Needed critical mass of such mailers

  21. AL: DNS server database distribution • Administrative hierarchy • Organized into regions known as “zones” • “.” as separator • zone = contiguous section of name space • Zones created by convincing owner node to delegate a subzone • umass.edu zone delegates cs.umass.edu to a different set of authoritative name servers • Each zone contains multiple redundant servers • Primary (master) name server updated manually • Secondary (redundant) servers updated by zone transfer of name space • Provides fault-tolerance within zone • Host name to address section • Top-level domains -> edu, gov, ca, us, etc. • Sub-domains = subtrees • Human readable name = leaf -> root path

  22. AL: DNS client lookups • Each host has a resolver • Typically a library that applications can link gethostbyname() • Local name servers hand-configured (e.g. /etc/resolv.conf) or automatically configured (DHCP) • Can specify a file /etc/hosts • Can specify a name server by its IP address (i.e. 129.95.50.2) • Host queries local name server for unknown names • Name servers • Configured with well-known root servers • Currently {a-m}.root-servers.net • Local servers • Typically answer queries about local zone • Typically do a lookup of distant host names for local hosts

  23. AL: Lookup Methods • Recursive queries • Server goes out and searches for more info on behalf of the client (recursive) • Only returns final answer or “not found” • Iterative • Server responds with as much as it knows (i.e. name of server to contact next) • Client iteratively queries additional servers

  24. local name server dns.eurecom.fr AL: All recursive DNS example root name server host surf.eurecom.fr wants IP address of gaia.cs.umass.edu 1. Contacts its local DNS server, dns.eurecom.fr 2.dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.umass.edu, if necessary 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu

  25. recursive query: puts burden of name resolution on contacted name server heavy load? root servers now disable recursive queries (RFC 2010) iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu AL: DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

  26. AL: Typical Resolution • Client does recursive request to local name server • Local name server does iterative requests to find name • Local name server has knowledge of root servers • Steps for resolving www.ogi.edu • Application calls gethostbyname() • Resolver contacts local name server (S1) • S1 queries root server (S2) for (www.ogi.edu) • S2 returns NS record for ogi.edu (S3) • S1 queries S3 for www.ogi.edu • S3 returns A record for www.ogi.edu • Can return multiple addresses -> what does this mean?

  27. AL: DNS Caching • DNS responses are cached • Quick response for repeated translations • Other queries may reuse some parts of lookup • NS records for domains • DNS negative queries are also cached • Don’t have to repeat past mistakes • E.g. misspellings • Cached data periodically times out • Soft state • Lifetime (TTL) of data controlled by owner of data • TTL passed with every record • TTL affects DNS-based load balancing techniques • update/notify mechanisms under design by IETF • RFC 2136 • http://www.ietf.org/html.charters/dnsind-charter.html

  28. AL: DNS Lookup Caching Example root & edu DNS server www.cse.ogi.edu www.cse.ogi.edu NS ogi.edu ogi.edu DNS server Local DNS server NS cse.ogi.edu Client cse.ogi.edu DNS server www=IPaddr

  29. AL: Subsequent Lookup Example cse.ogi.edu entry cached root & edu DNS server ftp.cse.ogi.edu ogi.edu DNS server Local DNS server Client ftp.cse.ogi.edu cse.ogi.edu DNS server ftp=IPaddr

More Related