1 / 33

Content Distribution Networks

Content Distribution Networks. ECE544 Dhananjay Makwana ( makwana@semandex.net ), Principal Software Engineer, Semandex Networks. Paul Krzyzanowski , Rutgers University Vyas Sekar , Stony Brook University Peter Steenkiste , CMU. Credits. 1. Motivation / Problem 2. Evolution

claus
Download Presentation

Content Distribution Networks

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. Content Distribution Networks ECE544 Dhananjay Makwana (makwana@semandex.net), Principal Software Engineer, Semandex Networks ECE544

  2. Paul Krzyzanowski, Rutgers University • VyasSekar, Stony Brook University • Peter Steenkiste, CMU Credits ECE544

  3. 1. Motivation / Problem • 2. Evolution • 3. Implementation • 4. Mapping users to CDN servers • 5. Types of Content • 6. Hybrid Approaches • 7. Further Reading • 8. Q&A Overview ECE544

  4. Quality/Performance expectations are rising • Serving Content from a single location • Scalability • Reliability • Performance • “Flash Crowd” problem Motivation / Problem ECE544

  5. ECE544

  6. ECE544

  7. ECE544

  8. ECE544

  9. ECE544

  10. ECE544

  11. ECE544

  12. Edge Caches: work with ISP and networks everywhere to install edge caches • Edge = close to customers • Content delivery: getting content to the edge caches • Content can be objects, video, or entire web sites • Mapping: find the “closest” edge server for each user and deliver content from that server • Network proximity not the same as geographic proximity • Focus is on performance as observed by user (quality) CDN to the rescue ECE544

  13. ECE544

  14. ECE544

  15. ECE544

  16. ECE544

  17. ECE544

  18. ECE544

  19. ECE544

  20. ECE544

  21. How to map clients to servers? • What metrics? Latency, Load • DNS, HTTP 304 response, anycast, etc. • How/where to replicate content? • On demand? • Proactive/prefetch? • everywhere or close to demands? Questions ECE544

  22. Application based • Routing based • DNS based Mapping ECE544

  23. HTTP supports simple way to indicate that Web page has moved (30X responses) • Server receives Get request from client • Decides which server is best suited for particular client and object • Returns HTTP redirect to that server • Pros • Can make informed application specific decision • Cons • Mayintroduce additionaloverhead • Multiple connection setup, name lookups, etc. • Could interact poorly with some browser implementations Application Based ECE544

  24. IP Anycast • Use BGP to announce same destination IP from multiple places. • Clients are agnostic and connect to Anycast address • ISP router routes to “nearest” anycast server. • Pros • All IP infrastructure is available • Potential scaling to internet level • Cons • Cannot incorporate application policy • Stateful connections may create problems • Relatively less dynamic Routing Based ECE544

  25. DNS • Clients perform typical DNS query. • DNS servers are locality aware • Reply with “best” server available • Pros • Existing DNS protocol (fully supported) • Fully flexible application/content provider policies • Potential other uses (e.g. Ad serving, Video transcoding) • Cons • Multiple DNS queries • Depends upon an efficient implementation DNS Based ECE544

  26. Example Akamai • Akamai does this via Dynamic DNS • Customer modifies URLs (akamizes) • Direct requests to right content servers • Resolve a host name based on: • Service requested (e.g. QuickTime, Windows Media, HTML) • Content requested (css, js, swf, jpeg etc.) • Server health • Server load • User location • Network status • Load balancing Mapping (DNS Based) ECE544

  27. ECE544

  28. ECE544

  29. Resolve a7.g.akamai.net • NS resolver contacts root server • Root server sends a referral to a name server responsible for .net • Resolver queries .netname server • Returns a referral for .akamai.net • This is the top-level Akamai server • Resolver queries a top-level Akamai server • Returns a referral for .g.akamai.net • Low-level Akamai server (TTL approx 1 hour) • Low-level servers are in the same location as edge servers closest to user • Resolver queries a low-level Akamai server • Returns IP addresses of servers available to satisfy the request • Short TTL (several seconds to 1 minute) DNS Resolution ECE544

  30. ECE544

  31. Static content • Cached depending on original site's requirements (never to forever) • Dynamic content • Caching proxies cannot do this • Akamai uses Edge Side Includes technology (www.esi.org) • Assembles dynamic content on edge servers • Similar to server-side includes • Page is broken into fragments with independent caching properties • Assembled on demand • Streaming media • Live stream is sent to an entry-point server in the Akamai network • Stream is delivered from the entry-point server to multiple edge servers • Edge servers serve content to end users. Content Types ECE544

  32. The Akamai Network: A Platform for High-Performance Internet Applications • Erik Nygren, Ramesh Sitaraman & Jennifer Sun • Improving performance on the Internet • Tom Leighton • Globally Distributed Content Delivery • John Dilley et. al Further Reading ECE544

  33. Thank You ! Questions? ECE544

More Related