US20140108674A1 - Anycast redirect to unicast content download - Google Patents
Anycast redirect to unicast content download Download PDFInfo
- Publication number
- US20140108674A1 US20140108674A1 US14/047,824 US201314047824A US2014108674A1 US 20140108674 A1 US20140108674 A1 US 20140108674A1 US 201314047824 A US201314047824 A US 201314047824A US 2014108674 A1 US2014108674 A1 US 2014108674A1
- Authority
- US
- United States
- Prior art keywords
- server
- request
- address
- content
- content object
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H04L61/1511—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
Definitions
- This disclosure relates in general to a content delivery network (CDN) and, but not by way of limitation, to selection of an edge server for a CDN.
- CDN content delivery network
- CDNs will use Anycast to find a point of presence (POP) that can deliver content hosted or cached by the CDN.
- POP point of presence
- DNS domain name service
- a POP can be assigned that is inefficient because the DNS was located in an unexpected place on the Internet masking the network location of the user computer. An inefficient POP negatively affects quality of service (QoS) perceived by the user. Anycast DNS is desirable because it is fast.
- Anycast can be used to choose the edge server.
- the edge server is often in close network proximity to the location of the user's DNS and hopefully the user computer.
- clients can have problems staying connected to an assigned edge server.
- Unexpectedly changing to another edge server because of Anycast route changes or server selection can interrupt the download or stream.
- HTTP proxy caches are used to relay information.
- the present disclosure provides a method and system for delivering content with a content delivery network (CDN) to a user computer.
- CDN content delivery network
- IP Anycast Internet protocol
- the user computer requests the content object which may find its way to the same or a different POP depending on what is closer in Internet terms.
- the request returns a POP-specific IP address in a redirect such that the request resolves uniquely to the POP referenced in the immediately preceding sentence.
- One or more edge servers deliver the content object to the user computer.
- the present disclosure provides a method for assigning a server of a content delivery network (CDN).
- a request for a content object is received at a first point of presence (POP), which is one of a plurality of POPs that comprise the CDN and are distributed across the Internet.
- a first Internet protocol (IP) address is returned, which could route to any of the plurality of POPs using Anycast.
- IP Internet protocol
- the request is received at a second POP using the first IP address.
- a user computer is redirected to request the content object from the second POP with a second IP address unique to the second POP.
- the request is received at the second POP using the second IP address.
- the server associated with the second IP address is determined.
- the content object is served from the second POP using the server to the user computer.
- the present disclosure provides a machine-readable physical medium having machine-executable instructions, comprising code for:
- the present disclosure provides a CDN for delivering a plurality of content objects to user computers.
- the CDN includes: a plurality of POPs distributed across the Internet including a first POP and a second POP, a domain name service to return a first Internet protocol (IP) address, switch fabric that receives the request at a second POP using the first IP address, and a plurality of servers that redirect a user computer to request the content object from the second POP with a second IP address unique to the second POP.
- the first IP address could route to any of the plurality of POPs using Anycast.
- the first IP address is associated with a request for a content object at the first POP.
- the plurality of servers include a server the second POP receives the request at the second IP address.
- the switch fabric determines the server associated with the second IP address.
- the server delivers the content object from the second POP to the user computer.
- FIG. 1 depicts a block diagram of an embodiment of a content distribution system
- FIG. 2 depicts a block diagram of an embodiment of a point of presence (POP);
- FIGS. 3A , 3 B, 3 C, and 3 D depict functional block diagrams of embodiments of a POP.
- FIGS. 4A , 4 B, 4 C, and 4 D illustrate flowcharts of embodiments of a process for delivering a content object from a POP.
- the content originator 106 offloads delivery of the content objects to a content delivery network (CDN) 110 in this embodiment.
- the content originator 106 produces and/or distributes content objects and includes a content provider 108 , a content site 116 , and an origin server 112 .
- the CDN 110 can cache, redistribute and/or host content in various embodiments for third parties such as the content originator 106 to offload delivery and typically provide better quality of service (QoS).
- QoS quality of service
- the content distribution system 100 locates the content objects (or portions thereof) and distributes the content objects to an end user system 102 .
- the content objects are dynamically cached or processed within the CDN 110 to improve the QoS without necessarily replicating the whole content object, unless subsequently requested by the end user 128 .
- a content object is any content file or content stream and could include, for example, video, pictures, data, audio, software, and/or text.
- the content object could be live, delayed or stored.
- the CDN 110 includes a number of points of presence (POPs) 120 , which are geographically distributed through the content distribution system 100 to deliver content.
- POPs points of presence
- Various embodiments may have any number of POPs 120 within the CDN 110 that are generally distributed in various locations around the Internet 104 to be proximate to end user systems 102 .
- Multiple POPs 120 use the same IP address such that an Anycast routing scheme is used to find a POP 120 likely to be close, in network terms, to the end user for each request.
- WAN wide area network
- 114 may couple the POPs 120 with each other and also couple the POPs 120 with other parts of the CDN 110 .
- the request for the web page is passed either directly or indirectly via the Internet 104 to the content originator 106 .
- the content originator 106 is the source or re-distributor of content objects.
- the content site 116 is a web site accessible by the end user system 102 .
- the content site 116 could be a web site where the content is viewable with a web browser.
- the content site 116 could be accessible with application software other than a web browser.
- the content provider 108 directs content requests to a CDN 110 after they are made or formulates the delivery path by embedding the delivery path into the URLs for a web page.
- the request for content is handed over to the CDN 110 by using an Anycast IP address corresponding to one, two or more POPs 120 .
- the request is associated with a particular POP 120 within the CDN 110 using the Anycast routing scheme.
- the POP 120 found with Anycast is not particularly close to the end user system 102 , being only close to the DNS server used by the end user system 102 .
- the particular POP 120 may retrieve the portion of the content object from the content provider 108 if not already within the CDN 110 .
- the content provider 108 may directly provide the content object to the CDN 110 and its associated POPs 120 through pre-population, i.e., in advance of the first request.
- the content objects are provided to the CDN 110 and stored in one or more CDN servers such that the portion of the requested content may be served from the CDN 110 .
- the CDN servers include edge servers that actually serve end user requests.
- the origin server 112 holds a copy of each content object for the content originator 106 . Periodically, the content of the origin server 112 may be reconciled with the CDN 110 through a cache, hosting and/or pre-population algorithm. Some content providers 108 could use an origin server within the CDN 110 to host the content and avoid the need to maintain an accessible copy of the content object.
- the content object is stored within the particular POP 120 and is served from that POP 120 to the end user systems 102 .
- Streamed content objects can have real time or near real time information or can be previously stored.
- the end user system 102 receives the content object and processes it for use by the end user 128 or an automated processing systems.
- the end user system 102 could be a personal computer, media player, handheld computer, Internet appliance, phone, IPTV set top, web server, processing system, streaming radio or any other device that receives and/or plays content objects.
- a number of the end user systems 102 could be networked together.
- edge servers 230 are coupled to each other and the Internet 104 and WAN 114 using switching fabric 240 .
- Edge servers 230 number in the thousands in a given POP 120 . They could be divided by function and/or customer. Loading algorithms can be used to divide load among the edge servers 230 in any number of ways.
- the edge servers 230 perform caching, streaming, hosting, storage, and/or other functions within the POP 120 .
- An edge server 230 is typically a rack-mounted computer that could have varying levels of processing power, memory and storage.
- Software running on the edge server 230 includes, for example, HTTP proxy caching, media servers, FlashTM servers, JavaTM application servers, SilverlightTM servers, etc.
- the switching fabric 240 is used for several functions. Incoming requests for content objects are routed to the edge servers 230 using the switching fabric. This could be done using routing, redirection or domain name service (DNS). In this embodiment, requests are assigned to a virtual Internet protocol (VIP) address of the POP 120 that the switching fabric 240 assigns to a particular edge server 230 to service. Load balancing, round-robin, and/or other techniques could be used by the switching fabric 240 to route requests to edge servers 230 .
- VIP virtual Internet protocol
- Edge servers 230 could have multiple software applications running that communicate with other edge servers 230 .
- embodiments could have HTTP caching proxies arranged in different levels such that a cache on one edge server could communicate through another edge server to deliver a content object to an end user system 102 .
- the DNS 250 is used to assign an IP address or a Virtual (VIP) address to requests for domains or CNAMEs.
- VIP Virtual
- the VIP address could be unique to the POP 120 or shared among a number of POPs 120 to allow Anycast routing of the request to a possibly closer POP 120 .
- the DNS 120 s as part of a domain resolution process that can include any number of DNS servers elsewhere on the Internet 104 .
- Switching fabric 240 includes network interface(s) 304 , a request assignment engine (RAE) 308 , cache array routing protocol (CARP) logic 312 , and a hierarchical cache router 316 .
- RAE request assignment engine
- CARP cache array routing protocol
- CARP logic 312 is shown separately for illustration purposes, in this embodiment, each level 2 HTTP proxy 328 has its own CARP logic 312 that can deterministically locate the level 1 HTTP proxy 320 to use on a cache miss.
- Other embodiments could have a separate server with the CARP logic 312 .
- the network interface 304 is coupled to the Internet 104 and/or WAN 114 to allow communication with the POP 120 .
- the RAE 308 uses routing, DNS, round robin, random assignment, and/or load balancing to assign content object requests between a number of level 2 HTTP proxies 328 .
- Each HTTP proxy 328 is coupled with a level 2 HTTP cache 332 that is generally small and configured for popular content. If a content object is found in the level 2 HTTP cache 332 , it is coupled to the end user system 102 through the level 2 HTTP proxy 328 .
- the level 2 HTTP proxy 328 uses the CARP logic 312 to be assigned a level 1 HTTP proxy 320 to locate the content object.
- the CARP logic 312 divides the name space between the level 1 HTTP proxy using a hash of the URL to deterministically find the level 1 HTTP proxy that handles requests for a particular content object. Other embodiments could divide the namespace by directory, customer, file type, etc.
- the level 1 HTTP proxy 320 looks for the content object requested in its corresponding level 1 HTTP cache 324 , which is typically larger than the level 2 HTTP cache 332 . Where the content object is found on the level 1 HTTP cache 324 , it is relayed through the level 1 HTTP proxy 320 and the level 2 HTTP proxy 328 , etc. to the end user system 102 . Should the content object not be located on the level 1 HTTP cache 324 , the content object is located using the hierarchical cache router 316 and loaded onto the level 1 HTTP cache 324 . The hierarchical cache router 316 is used to locate the content object elsewhere in the POP 120 , CDN 110 or origin server 112 .
- FIG. 3B a functional block diagram of an embodiment of various functions within a POP 120 - 2 is shown.
- This embodiment does not have caching for the level 2 HTTP proxy 328 .
- Content requests are assigned to the POP 120 using Anycast VIPs and converted to static VIPs unique to the POP 120 .
- the Anycast VIPs are common to all or some of the POPs 120 in the CDN 110 . When requested by the end user system 102 the are likely to find the POP 120 closest in Internet terms and likely to provide better QoS.
- the request assignment engine 308 passes the content object request, typically a URL, to one of the level 2 HTTP proxies 328 .
- the level 2 HTTP proxies 328 do not have an associated cache.
- the level 2 HTTP proxy 328 uses the CARP logic 312 to pass the request to the level 1 HTTP proxy 320 .
- the level 1 HTTP proxy 320 calculates a redirect URL that identifies the request uniquely and issues a 302 -redirect back to the end user system 102 before closing the connection. Some embodiments could use a 301-redirect instead of a 302-redirect.
- the redirect will cause the end user system 102 to request the URL directly from the level 1 HTTP proxy 320 without using Anycast.
- the network interface 304 sends those requests direct to the appropriate level 1 HTTP proxy 320 when received.
- the level 1 HTTP proxy 320 will search the level 1 HTTP cache 324 for the content object before resorting to the hierarchical cache router 316 on a cache miss.
- FIG. 3C a functional block diagram of an embodiment of various functions within a POP 120 - 3 is shown.
- This embodiment operates in two modes with one mode used for some content objects much as the embodiment of FIG. 3A operates and another mode for other content objects much as the embodiment of FIG. 3B operates.
- a determination is made in the level 2 HTTP proxy 328 as to whether a 302 -redirect will be used to get off the Anycast VIP.
- Other embodiments could make the determination in the RAE 308 or network interface 304 .
- the level 2 HTTP proxy 328 uses a code inserted into the URL to signal to the level 1 HTTP proxy 320 how to handle a particular request, but other embodiments could use a side channel, protocol handshake and/or physical path isolation. Beyond size deciding which mode, other embodiments could use application, format, encoding, customer, directory, level of QoS, loading of the HTTP proxies 320 , 328 , loading of the Ethernet connections in the POP, likelihood the Anycast VIP would reroute mid-delivery, etc. to decide which mode to operate in.
- FIG. 3D a functional block diagram of an embodiment of various functions within a POP 120 - 4 is shown.
- This embodiment redirects a request at Anycast IP address to an XML file that includes one or more URLs that are converted to POP-specific IP addresses.
- An Anycast IP or Anycast VIP address is received in a request and directed by the RAE 308 to one lookup API 327 chosen from a number of lookup APIs 327 .
- the lookup API 327 determines or retrieves XML associated with the request, for example, the XML could be a playlist having a number of URLs.
- the lookup API 327 interacts with the CARP logic 312 to determine which level 1 HTTP proxy 320 would be used for each URL.
- the CARP logic 312 could be integral to the lookup API 327 .
- the URLs are rewritten by the lookup API 327 and the XML is returned to the end user system 102 . Requests are made by a FlashTM player or other application by the end user system 102 using the URLs having the POP-specific IP addresses rather than the Anycast IP addresses that started the process.
- FIG. 4A a flowchart of an embodiment of a process 400 - 1 for delivering a content object from a POP 120 is shown.
- This embodiment corresponds to the functional block diagram of FIG. 3A .
- An end user system 102 through a browser, player or other application requests a content object that is hosted by the CDN 110 .
- DNS redirection and/or routing, the request reaches a POP 120 close in Internet terms to the end user system 102 . More precisely, the POP 120 is likely close to the DNS used by the end user system 102 , which may be very distant from the end user system 102 such that the POP 120 is a poor choice for delivering the content object.
- This embodiment uses Anycast to find the POP 120 in block 404 .
- the DNS 250 at the POP 120 returns a VIP unique to the POP 120 that points to the edge servers.
- the end user system 102 requests the URL with the VIP inserted.
- the RAE 308 receives the request before routing the request to one of the many edge servers 230 in block 412 .
- the first edge server 230 that receives the request checks a level 2 HTTP cache 332 for the content object in block 416 . Where the level 2 HTTP cache 332 has the content object as determined in block 420 , processing continues to block 440 where the content object is proxied through the level 2 HTTP proxy 328 running on the edge server 230 to the end user system 102 .
- processing continues to block 424 where the level 2 HTTP proxy 328 passes the request to a CARP logic 312 .
- the CARP logic 312 calculates a hash on the URL and finds one of the many level 1 HTTP proxies 320 corresponding to the hash.
- the level 1 HTTP proxy 320 checks its level 1 HTTP cache 324 for the content object. If the content object is missing, in whole or in part, it is found elsewhere in the CDN 110 or at the origin server 112 in block 432 . Once the content object is located in the level 1 HTTP cache 324 or found elsewhere, the content object is proxied through the level 1 HTTP proxy 320 and the level 2 HTTP proxy 328 to the end user system 102 .
- FIG. 4B a flowchart of an embodiment of a process 400 - 2 for delivering a content object from a POP 120 is shown.
- This embodiment corresponds to the functional block diagram of FIG. 3B .
- the depicted portion of the process 400 - 2 begins in step 404 where the request or domain name resolution is delivered to a POP 120 likely close to the end user system 102 .
- the DNS 250 at the POP 120 returns Anycast VIPs to the end user system 102 .
- the Anycast VIPs can resolve to any number of POPs 120 throughout the CDN 110 .
- the Anycast VIPs are different from IP addresses in that the RAE 308 could assign them to any number of edge servers 230 .
- Other embodiments could use Anycast IP addresses that reference servers that appear in a number of POPs.
- the end user system 102 request the content object at the Anycast VIP. This will resolve though the Internet to a nearby POP 120 .
- the nearby POP 120 may or may not be the POP 120 that was used in block 410 for the DNS resolution.
- the received request is processed by the RAE 308 for assignment to one of many edge servers 230 .
- the RAE 308 in this embodiment does round robin assignment between a number of the edge servers 230 with the right capability that were assigned to the customer.
- a level 2 HTTP proxy 328 on the edge server 230 passes the request with a special header indicating the request came from an Anycast VIP to the CARP logic 312 .
- the CARP logic 312 assigns the request to a second edge server 230 running level 1 HTTP proxy 320 .
- a unique URL is computed that refers back to the level 1 HTTP proxy 320 in block 426 .
- a 302-redirect is issued to the end user system 102 to relay back the computed URL through the two HTTP proxies 328 , 320 before the link is closed.
- the end user system 102 requests the computed URL to issue it back to the level 1 HTTP proxy 320 in block 430 .
- the level 1 HTTP cache 324 is also queried. On a cache miss determined in block 428 , the content object is found and loaded into the level 1 HTTP cache 324 in block 432 . For a cache hit or after the content object is loaded in the cache in block 432 , the content object is proxied through the level 1 HTTP proxy to the end user system 102 .
- FIG. 4C a flowchart of an embodiment of a process 400 - 3 for delivering a content object from a POP 120 is shown.
- This embodiment corresponds to the functional block diagram of FIG. 3C .
- the content object is analyzed to determine whether an Anycast VIP should be used or not in block 415 .
- the determination in block 425 for this embodiment uses an Anycast VIP for large content objects and a POP-unique VIP for small content objects.
- a first group of blocks 475 from FIG. 4A are performed or a second group of blocks 485 from FIG. 4B are performed. Any number of factors can be used in the determination of block 425 to decide which mode to operate in.
- edge servers two banks of edge servers are shown in FIG. 2 , but it is to be understood that the banks could be the same bank.
- One hardware edge server 230 could simultaneously run both any number of level 2 HTTP proxy and any number level 2 HTTP proxy. Additional functions could also run on a hardware server such as DNS, RAE, CARP logic, etc.
- Anycast VIPs changing from a first POP to a second POP, but that is not necessarily the case. Often, the POP chosen during DNS resolution is also the POP that will receive the redirected request.
- FIG. 4D a flowchart of an embodiment of a process 400 - 4 for delivering a content object from a POP 120 is shown.
- the depicted portion of the process begins in block 404 where the request for content uses DNS, Anycast or routing to find a POP 120 close to the requestor or at least their DNS server.
- the DNS server 250 at the POP 120 returns Anycast IP addresses for the domain, but could return VIP addresses in other embodiments.
- the end user device 102 requests the URL.
- a FlashTM player on the end user device 102 is requesting a XML playlist containing a number of URLs that could be video or audio clips, for example.
- a second POP nearby the end user device 102 receives the request on the Anycast IP address.
- the second POP could be the same as the first POP in some cases, but could be in a completely different geographic location in some instances.
- the RAE 308 routes the request to one of many lookup APIs 327 .
- the lookup API 327 retrieves or formulates a XML file corresponding to the URL in block 415 .
- the URLs are rewritten after using the CARP logic 312 to determine the server(s) in the POP that would be servicing each URL.
- the IP addresses are POP-specific.
- the rewritten XML is returned to the Flash player before closing the link on the Anycast IP address.
- the URLs are passed from the FlashTM player to the POP-specific IP address for fulfillment.
- the level 1 HTTP proxy 320 will locate the content object referenced by the URL in the level 1 HTTP cache 324 or elsewhere and return it in blocks 430 , 428 , 432 , and 438 . For each URL these blocks 430 , 428 , 432 , 438 will reference the appropriate level 1 HTTP proxy 320 and return the content object. While this embodiment uses an XML file with redirection to POP-specific IP addresses, any type of file or control information could be used to redirect away from Anycast IP addresses in other embodiments.
- Implementation of the techniques, blocks, steps and means described above may be done in various ways. For example, these techniques, blocks, steps and means may be implemented in hardware, software, or a combination thereof. Also, it is noted that the embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
- embodiments may be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof.
- the program code or code segments to perform the necessary tasks may be stored in a machine readable medium such as a storage medium.
- a code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements.
- a code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
- the term “storage medium” may represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information.
- ROM read only memory
- RAM random access memory
- magnetic RAM magnetic RAM
- core memory magnetic disk storage mediums
- optical storage mediums flash memory devices and/or other machine readable mediums for storing information.
- machine-readable medium includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.
Abstract
A method and system for delivering content with a content delivery network (CDN) to a user computer is disclosed. After an initial request to a point of presence (POP) of the CDN for the location of the content object, an Anycast Internet protocol (IP) address is assigned. The user computer requests the content object which may find its way to the same or a different POP depending on what is closer in Internet terms. The request returns a POP-specific IP in a redirect such that the request resolves to the POP referenced in the immediately preceding sentence. One or more edge servers deliver the content object to the user computer.
Description
- This application is a continuation of U.S. patent application Ser. No. 13/344,497, filed Jan. 5, 2012, entitled “ANYCAST REDIRECT TO UNICAST CONTENT DOWNLOAD,” which is related by priority to PCT/US10/062156 filed Dec. 27, 2010, and Australian Patent No. 2011200629 issued Nov. 17, 2011, all of which are hereby incorporated by reference in their entirety for all purposes.
- This disclosure relates in general to a content delivery network (CDN) and, but not by way of limitation, to selection of an edge server for a CDN.
- CDNs will use Anycast to find a point of presence (POP) that can deliver content hosted or cached by the CDN. To find the POP, a user computer will query a domain name service (DNS) that may or may not be close in network terms to the user computer. A POP can be assigned that is inefficient because the DNS was located in an unexpected place on the Internet masking the network location of the user computer. An inefficient POP negatively affects quality of service (QoS) perceived by the user. Anycast DNS is desirable because it is fast.
- Anycast can be used to choose the edge server. The edge server is often in close network proximity to the location of the user's DNS and hopefully the user computer. During download of large files or playback of long streams, clients can have problems staying connected to an assigned edge server. Unexpectedly changing to another edge server because of Anycast route changes or server selection can interrupt the download or stream.
- Within a network, HTTP proxy caches are used to relay information. In some cases, there are multiple layers of HTTP proxy caches to move a content object. Each extra hop of multiple proxy layers in a route consumes bandwidth. Ethernet bandwidth is relative plentiful, but can still become overloaded.
- In one embodiment, the present disclosure provides a method and system for delivering content with a content delivery network (CDN) to a user computer. After an initial request to a point of presence (POP) of the CDN for the location of the content object, an Anycast Internet protocol (IP) address is assigned. The user computer requests the content object which may find its way to the same or a different POP depending on what is closer in Internet terms. The request returns a POP-specific IP address in a redirect such that the request resolves uniquely to the POP referenced in the immediately preceding sentence. One or more edge servers deliver the content object to the user computer.
- In another embodiment, the present disclosure provides a method for assigning a server of a content delivery network (CDN). A request for a content object is received at a first point of presence (POP), which is one of a plurality of POPs that comprise the CDN and are distributed across the Internet. A first Internet protocol (IP) address is returned, which could route to any of the plurality of POPs using Anycast. The request is received at a second POP using the first IP address. A user computer is redirected to request the content object from the second POP with a second IP address unique to the second POP. The request is received at the second POP using the second IP address. The server associated with the second IP address is determined. The content object is served from the second POP using the server to the user computer.
- In yet another embodiment, the present disclosure provides a machine-readable physical medium having machine-executable instructions, comprising code for:
-
- receiving a request for a content object at a first point of presence (POP), which is one of a plurality of POPs that comprise the CDN and are distributed across the Internet;
- returning a first Internet protocol (IP) address, which could route to any of the plurality of POPs using Anycast;
- receiving the request at a second POP using the first IP address;
- redirecting a user computer to request the content object from the second POP with a second IP address unique to the second POP;
- receiving the request at the second POP using the second IP address;
- determining the server associated with the second IP address; and
- serving the content object from the second POP using the server to the user computer.
- In still yet another embodiment, the present disclosure provides a CDN for delivering a plurality of content objects to user computers. The CDN includes: a plurality of POPs distributed across the Internet including a first POP and a second POP, a domain name service to return a first Internet protocol (IP) address, switch fabric that receives the request at a second POP using the first IP address, and a plurality of servers that redirect a user computer to request the content object from the second POP with a second IP address unique to the second POP. The first IP address could route to any of the plurality of POPs using Anycast. The first IP address is associated with a request for a content object at the first POP. The plurality of servers include a server the second POP receives the request at the second IP address. The switch fabric determines the server associated with the second IP address. The server delivers the content object from the second POP to the user computer.
- Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the disclosure.
- The present disclosure is described in conjunction with the appended figures:
-
FIG. 1 depicts a block diagram of an embodiment of a content distribution system; -
FIG. 2 depicts a block diagram of an embodiment of a point of presence (POP); -
FIGS. 3A , 3B, 3C, and 3D depict functional block diagrams of embodiments of a POP; and -
FIGS. 4A , 4B, 4C, and 4D illustrate flowcharts of embodiments of a process for delivering a content object from a POP. - In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
- The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.
- Referring first to
FIG. 1 , a block diagram of an embodiment of acontent distribution system 100 is shown. Thecontent originator 106 offloads delivery of the content objects to a content delivery network (CDN) 110 in this embodiment. Thecontent originator 106 produces and/or distributes content objects and includes acontent provider 108, acontent site 116, and anorigin server 112. TheCDN 110 can cache, redistribute and/or host content in various embodiments for third parties such as thecontent originator 106 to offload delivery and typically provide better quality of service (QoS). - In this embodiment, the
content distribution system 100 locates the content objects (or portions thereof) and distributes the content objects to anend user system 102. The content objects are dynamically cached or processed within theCDN 110 to improve the QoS without necessarily replicating the whole content object, unless subsequently requested by theend user 128. A content object is any content file or content stream and could include, for example, video, pictures, data, audio, software, and/or text. The content object could be live, delayed or stored. Throughout the specification, references may be made to a content object, content, content stream and/or content file, but it is to be understood that those terms could be used interchangeably wherever they may appear. -
Many content providers 108 use aCDN 110 to deliver the content objects over theInternet 104 to endusers 128. TheCDN 110 includes a number of points of presence (POPs) 120, which are geographically distributed through thecontent distribution system 100 to deliver content. Various embodiments may have any number ofPOPs 120 within theCDN 110 that are generally distributed in various locations around theInternet 104 to be proximate toend user systems 102.Multiple POPs 120 use the same IP address such that an Anycast routing scheme is used to find aPOP 120 likely to be close, in network terms, to the end user for each request. In addition to theInternet 104, a wide area network (WAN) 114 or other backbone may couple thePOPs 120 with each other and also couple thePOPs 120 with other parts of theCDN 110. - When an
end user 128 requests a web page through its respectiveend user system 102, the request for the web page is passed either directly or indirectly via theInternet 104 to thecontent originator 106. Thecontent originator 106 is the source or re-distributor of content objects. Thecontent site 116 is a web site accessible by theend user system 102. In one embodiment, thecontent site 116 could be a web site where the content is viewable with a web browser. In other embodiments, thecontent site 116 could be accessible with application software other than a web browser. In this embodiment, thecontent provider 108 directs content requests to aCDN 110 after they are made or formulates the delivery path by embedding the delivery path into the URLs for a web page. In any event, the request for content is handed over to theCDN 110 by using an Anycast IP address corresponding to one, two ormore POPs 120. - Once the request for a content object is passed to the
CDN 110, the request is associated with aparticular POP 120 within theCDN 110 using the Anycast routing scheme. In some cases, thePOP 120 found with Anycast is not particularly close to theend user system 102, being only close to the DNS server used by theend user system 102. Theparticular POP 120 may retrieve the portion of the content object from thecontent provider 108 if not already within theCDN 110. Alternatively, thecontent provider 108 may directly provide the content object to theCDN 110 and its associatedPOPs 120 through pre-population, i.e., in advance of the first request. In this embodiment, the content objects are provided to theCDN 110 and stored in one or more CDN servers such that the portion of the requested content may be served from theCDN 110. The CDN servers include edge servers that actually serve end user requests. Theorigin server 112 holds a copy of each content object for thecontent originator 106. Periodically, the content of theorigin server 112 may be reconciled with theCDN 110 through a cache, hosting and/or pre-population algorithm. Somecontent providers 108 could use an origin server within theCDN 110 to host the content and avoid the need to maintain an accessible copy of the content object. - Once the content object is retrieved from the
origin server 112 by theCDN 110, the content object is stored within theparticular POP 120 and is served from thatPOP 120 to theend user systems 102. Streamed content objects can have real time or near real time information or can be previously stored. Theend user system 102 receives the content object and processes it for use by theend user 128 or an automated processing systems. Theend user system 102 could be a personal computer, media player, handheld computer, Internet appliance, phone, IPTV set top, web server, processing system, streaming radio or any other device that receives and/or plays content objects. In some embodiments, a number of theend user systems 102 could be networked together. Although this embodiment only shows asingle content originator 106 and asingle CDN 110, it is to be understood that there could be many of each in various embodiments. - With reference to
FIG. 2 , a block diagram of an embodiment of aPOP 120 is shown. There are a number ofedge servers 230 coupled to each other and theInternet 104 andWAN 114 using switchingfabric 240.Edge servers 230 number in the thousands in a givenPOP 120. They could be divided by function and/or customer. Loading algorithms can be used to divide load among theedge servers 230 in any number of ways. Theedge servers 230 perform caching, streaming, hosting, storage, and/or other functions within thePOP 120. Anedge server 230 is typically a rack-mounted computer that could have varying levels of processing power, memory and storage. Software running on theedge server 230 includes, for example, HTTP proxy caching, media servers, Flash™ servers, Java™ application servers, Silverlight™ servers, etc. - The switching
fabric 240 is used for several functions. Incoming requests for content objects are routed to theedge servers 230 using the switching fabric. This could be done using routing, redirection or domain name service (DNS). In this embodiment, requests are assigned to a virtual Internet protocol (VIP) address of thePOP 120 that the switchingfabric 240 assigns to aparticular edge server 230 to service. Load balancing, round-robin, and/or other techniques could be used by the switchingfabric 240 to route requests to edgeservers 230. - Communication within the
POP 120 also uses the switchingfabric 240.Edge servers 230 could have multiple software applications running that communicate withother edge servers 230. For example, embodiments could have HTTP caching proxies arranged in different levels such that a cache on one edge server could communicate through another edge server to deliver a content object to anend user system 102. - The
DNS 250 is used to assign an IP address or a Virtual (VIP) address to requests for domains or CNAMEs. The VIP address could be unique to thePOP 120 or shared among a number ofPOPs 120 to allow Anycast routing of the request to a possiblycloser POP 120. The DNS 120 s as part of a domain resolution process that can include any number of DNS servers elsewhere on theInternet 104. - Referring next to
FIG. 3A , a functional block diagram of an embodiment of various functions within a POP 120-1 is shown. There are two levels of HTTP proxy caching in this embodiment where each HTTP proxy has an HTTP cache. The HTTP proxy caching may be performed on edge servers.Switching fabric 240 includes network interface(s) 304, a request assignment engine (RAE) 308, cache array routing protocol (CARP)logic 312, and ahierarchical cache router 316. Although theCARP logic 312 is shown separately for illustration purposes, in this embodiment, eachlevel 2HTTP proxy 328 has itsown CARP logic 312 that can deterministically locate thelevel 1HTTP proxy 320 to use on a cache miss. Other embodiments could have a separate server with theCARP logic 312. - The
network interface 304 is coupled to theInternet 104 and/orWAN 114 to allow communication with thePOP 120. TheRAE 308 uses routing, DNS, round robin, random assignment, and/or load balancing to assign content object requests between a number oflevel 2HTTP proxies 328. EachHTTP proxy 328 is coupled with alevel 2HTTP cache 332 that is generally small and configured for popular content. If a content object is found in thelevel 2HTTP cache 332, it is coupled to theend user system 102 through thelevel 2HTTP proxy 328. - Where the
level 2HTTP cache 332 does not store the content object, thelevel 2HTTP proxy 328 uses theCARP logic 312 to be assigned alevel 1HTTP proxy 320 to locate the content object. TheCARP logic 312 divides the name space between thelevel 1 HTTP proxy using a hash of the URL to deterministically find thelevel 1 HTTP proxy that handles requests for a particular content object. Other embodiments could divide the namespace by directory, customer, file type, etc. - The
level 1HTTP proxy 320 looks for the content object requested in itscorresponding level 1HTTP cache 324, which is typically larger than thelevel 2HTTP cache 332. Where the content object is found on thelevel 1HTTP cache 324, it is relayed through thelevel 1HTTP proxy 320 and thelevel 2HTTP proxy 328, etc. to theend user system 102. Should the content object not be located on thelevel 1HTTP cache 324, the content object is located using thehierarchical cache router 316 and loaded onto thelevel 1HTTP cache 324. Thehierarchical cache router 316 is used to locate the content object elsewhere in thePOP 120,CDN 110 ororigin server 112. - With reference to
FIG. 3B , a functional block diagram of an embodiment of various functions within a POP 120-2 is shown. This embodiment does not have caching for thelevel 2HTTP proxy 328. Content requests are assigned to thePOP 120 using Anycast VIPs and converted to static VIPs unique to thePOP 120. The Anycast VIPs are common to all or some of thePOPs 120 in theCDN 110. When requested by theend user system 102 the are likely to find thePOP 120 closest in Internet terms and likely to provide better QoS. - The
request assignment engine 308 passes the content object request, typically a URL, to one of thelevel 2HTTP proxies 328. In this embodiment, thelevel 2HTTP proxies 328 do not have an associated cache. Thelevel 2HTTP proxy 328 uses theCARP logic 312 to pass the request to thelevel 1HTTP proxy 320. Thelevel 1HTTP proxy 320 calculates a redirect URL that identifies the request uniquely and issues a 302-redirect back to theend user system 102 before closing the connection. Some embodiments could use a 301-redirect instead of a 302-redirect. - The redirect will cause the
end user system 102 to request the URL directly from thelevel 1HTTP proxy 320 without using Anycast. Thenetwork interface 304 sends those requests direct to theappropriate level 1HTTP proxy 320 when received. As before, thelevel 1HTTP proxy 320 will search thelevel 1HTTP cache 324 for the content object before resorting to thehierarchical cache router 316 on a cache miss. - Referring next to
FIG. 3C , a functional block diagram of an embodiment of various functions within a POP 120-3 is shown. This embodiment operates in two modes with one mode used for some content objects much as the embodiment ofFIG. 3A operates and another mode for other content objects much as the embodiment ofFIG. 3B operates. A determination is made in thelevel 2HTTP proxy 328 as to whether a 302-redirect will be used to get off the Anycast VIP. Other embodiments could make the determination in theRAE 308 ornetwork interface 304. - In this embodiment, small content objects stay on an Anycast VIP with two-level HTTP proxy and large content objects move to a VIP for the
level 1HTTP proxy 320 through the redirect process. Thelevel 2HTTP proxy 328 uses a code inserted into the URL to signal to thelevel 1HTTP proxy 320 how to handle a particular request, but other embodiments could use a side channel, protocol handshake and/or physical path isolation. Beyond size deciding which mode, other embodiments could use application, format, encoding, customer, directory, level of QoS, loading of theHTTP proxies - Referring next to
FIG. 3D , a functional block diagram of an embodiment of various functions within a POP 120-4 is shown. This embodiment redirects a request at Anycast IP address to an XML file that includes one or more URLs that are converted to POP-specific IP addresses. An Anycast IP or Anycast VIP address is received in a request and directed by theRAE 308 to onelookup API 327 chosen from a number oflookup APIs 327. Thelookup API 327 determines or retrieves XML associated with the request, for example, the XML could be a playlist having a number of URLs. Thelookup API 327 interacts with theCARP logic 312 to determine whichlevel 1HTTP proxy 320 would be used for each URL. TheCARP logic 312 could be integral to thelookup API 327. The URLs are rewritten by thelookup API 327 and the XML is returned to theend user system 102. Requests are made by a Flash™ player or other application by theend user system 102 using the URLs having the POP-specific IP addresses rather than the Anycast IP addresses that started the process. - With reference to
FIG. 4A , a flowchart of an embodiment of a process 400-1 for delivering a content object from aPOP 120 is shown. This embodiment corresponds to the functional block diagram ofFIG. 3A . Anend user system 102 through a browser, player or other application requests a content object that is hosted by theCDN 110. Through DNS, redirection and/or routing, the request reaches aPOP 120 close in Internet terms to theend user system 102. More precisely, thePOP 120 is likely close to the DNS used by theend user system 102, which may be very distant from theend user system 102 such that thePOP 120 is a poor choice for delivering the content object. This embodiment uses Anycast to find thePOP 120 inblock 404. TheDNS 250 at thePOP 120 returns a VIP unique to thePOP 120 that points to the edge servers. - With the VIP, the
end user system 102 requests the URL with the VIP inserted. TheRAE 308 receives the request before routing the request to one of themany edge servers 230 inblock 412. Thefirst edge server 230 that receives the request checks alevel 2HTTP cache 332 for the content object inblock 416. Where thelevel 2HTTP cache 332 has the content object as determined inblock 420, processing continues to block 440 where the content object is proxied through thelevel 2HTTP proxy 328 running on theedge server 230 to theend user system 102. - Where there is a cache miss in
block 420, processing continues to block 424 where thelevel 2HTTP proxy 328 passes the request to aCARP logic 312. TheCARP logic 312 calculates a hash on the URL and finds one of themany level 1HTTP proxies 320 corresponding to the hash. Thelevel 1HTTP proxy 320 checks itslevel 1HTTP cache 324 for the content object. If the content object is missing, in whole or in part, it is found elsewhere in theCDN 110 or at theorigin server 112 inblock 432. Once the content object is located in thelevel 1HTTP cache 324 or found elsewhere, the content object is proxied through thelevel 1HTTP proxy 320 and thelevel 2HTTP proxy 328 to theend user system 102. - With reference to
FIG. 4B , a flowchart of an embodiment of a process 400-2 for delivering a content object from aPOP 120 is shown. This embodiment corresponds to the functional block diagram ofFIG. 3B . The depicted portion of the process 400-2 begins instep 404 where the request or domain name resolution is delivered to aPOP 120 likely close to theend user system 102. TheDNS 250 at thePOP 120 returns Anycast VIPs to theend user system 102. The Anycast VIPs can resolve to any number ofPOPs 120 throughout theCDN 110. The Anycast VIPs are different from IP addresses in that theRAE 308 could assign them to any number ofedge servers 230. Other embodiments could use Anycast IP addresses that reference servers that appear in a number of POPs. - The
end user system 102 request the content object at the Anycast VIP. This will resolve though the Internet to anearby POP 120. Thenearby POP 120 may or may not be thePOP 120 that was used inblock 410 for the DNS resolution. Inblock 414, the received request is processed by theRAE 308 for assignment to one ofmany edge servers 230. TheRAE 308 in this embodiment does round robin assignment between a number of theedge servers 230 with the right capability that were assigned to the customer. - In
block 416, alevel 2HTTP proxy 328 on theedge server 230 passes the request with a special header indicating the request came from an Anycast VIP to theCARP logic 312. Using CARP, theCARP logic 312 assigns the request to asecond edge server 230running level 1HTTP proxy 320. After recognizing the special header, thelevel 1HTTP proxy 320, a unique URL is computed that refers back to thelevel 1HTTP proxy 320 inblock 426. A 302-redirect is issued to theend user system 102 to relay back the computed URL through the twoHTTP proxies - The
end user system 102 requests the computed URL to issue it back to thelevel 1HTTP proxy 320 inblock 430. Thelevel 1HTTP cache 324 is also queried. On a cache miss determined inblock 428, the content object is found and loaded into thelevel 1HTTP cache 324 inblock 432. For a cache hit or after the content object is loaded in the cache inblock 432, the content object is proxied through thelevel 1 HTTP proxy to theend user system 102. - With reference to
FIG. 4C , a flowchart of an embodiment of a process 400-3 for delivering a content object from aPOP 120 is shown. This embodiment corresponds to the functional block diagram ofFIG. 3C . After finding the POP inblock 404, the content object is analyzed to determine whether an Anycast VIP should be used or not inblock 415. The determination inblock 425 for this embodiment uses an Anycast VIP for large content objects and a POP-unique VIP for small content objects. Depending on that determination, either a first group ofblocks 475 fromFIG. 4A are performed or a second group ofblocks 485 fromFIG. 4B are performed. Any number of factors can be used in the determination ofblock 425 to decide which mode to operate in. - A number of variations and modifications of the disclosed embodiments can also be used. For example, two banks of edge servers are shown in
FIG. 2 , but it is to be understood that the banks could be the same bank. Onehardware edge server 230 could simultaneously run both any number oflevel 2 HTTP proxy and anynumber level 2 HTTP proxy. Additional functions could also run on a hardware server such as DNS, RAE, CARP logic, etc. In another example, we discuss the Anycast VIPs changing from a first POP to a second POP, but that is not necessarily the case. Often, the POP chosen during DNS resolution is also the POP that will receive the redirected request. - With reference to
FIG. 4D , a flowchart of an embodiment of a process 400-4 for delivering a content object from aPOP 120 is shown. The depicted portion of the process begins inblock 404 where the request for content uses DNS, Anycast or routing to find aPOP 120 close to the requestor or at least their DNS server. TheDNS server 250 at thePOP 120 returns Anycast IP addresses for the domain, but could return VIP addresses in other embodiments. - With the Anycast IP addresses, the
end user device 102 requests the URL. In this embodiment, a Flash™ player on theend user device 102 is requesting a XML playlist containing a number of URLs that could be video or audio clips, for example. Inblock 413, a second POP nearby theend user device 102 receives the request on the Anycast IP address. The second POP could be the same as the first POP in some cases, but could be in a completely different geographic location in some instances. TheRAE 308 routes the request to one ofmany lookup APIs 327. - With the URL request, the
lookup API 327 retrieves or formulates a XML file corresponding to the URL inblock 415. The URLs are rewritten after using theCARP logic 312 to determine the server(s) in the POP that would be servicing each URL. After conversion, the IP addresses are POP-specific. Inblock 425, the rewritten XML is returned to the Flash player before closing the link on the Anycast IP address. - In
block 427, the URLs are passed from the Flash™ player to the POP-specific IP address for fulfillment. Thelevel 1HTTP proxy 320 will locate the content object referenced by the URL in thelevel 1HTTP cache 324 or elsewhere and return it inblocks blocks appropriate level 1HTTP proxy 320 and return the content object. While this embodiment uses an XML file with redirection to POP-specific IP addresses, any type of file or control information could be used to redirect away from Anycast IP addresses in other embodiments. - Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
- Implementation of the techniques, blocks, steps and means described above may be done in various ways. For example, these techniques, blocks, steps and means may be implemented in hardware, software, or a combination thereof. Also, it is noted that the embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
- Furthermore, embodiments may be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
- Moreover, as disclosed herein, the term “storage medium” may represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term “machine-readable medium” includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.
- While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure.
Claims (21)
1. (canceled)
2. A delivery network for delivering a plurality of content objects to user computers, the delivery network comprising:
a plurality of POPs distributed across the Internet;
a first server configured to:
receive a Domain Name Service (DNS) request wherein:
the DNS request is from an end-user system;
the DNS request is for identifying a server to provide a first content object to the end-user system; and
the first server is located in a first POP of the plurality of POPs; and
return an anycast IP address to the end-user system;
a second server, the second server configured to:
receive a request for the first content object, wherein:
the request for the first content object is from the end-user system;
the request for the first content object uses the anycast IP address; and
the second server is in a second POP of the plurality of POPs;
identify that the first content object references two additional content objects, a second content object and a third content object; and
return a response to the end-user system, the response comprising:
a first Uniform Resource Locator (URL), wherein:
the first URL is used to locate the second content object;
the first URL resolves to a first IP address;
the first IP address is a unicast IP address; and
the first IP address identifies a third server; and
a second URL, wherein:
the second URL is used to locate the third content object;
the second URL resolves to a second IP address;
the second IP address is a unicast IP address;
the second IP address identifies a fourth server; and
the fourth server is different from the third server;
the third server, wherein the third server is configured to receive a request for the second content object; and
the fourth server, wherein the fourth sever is configured to receive a request for the third content object.
3. The delivery network for delivering a plurality of content objects to user computers as recited in claim 2 , wherein both the third server and the fourth server are in a third POP of the plurality of POPs.
4. The delivery network for delivering a plurality of content objects to user computers as recited in claim 2 , wherein the third server is the same as the second server.
5. The delivery network for delivering a plurality of content objects to user computers as recited in claim 4 , wherein the first POP is different from the second POP.
6. The delivery network for delivering a plurality of content objects to user computers as recited in claim 2 , wherein the first URL and the second URL are part of a markup language file returned to the end-user system.
7. The delivery network for delivering a plurality of content objects to user computers as recited in claim 2 , wherein returning the response to the end-user system by the second server is done before closing a link with the end-user system, wherein the link was created with the anycast IP address.
8. A method for assigning multiple servers of a delivery network for fulfillment of a single content request, the method comprising:
receiving a Domain Name Service (DNS) request, wherein:
the DNS request is from an end-user system;
the DNS request is for identifying a server to provide a first content object to the end-user system;
the DNS request is received at a first server in a content delivery network;
the content delivery network comprises a plurality of (Points of Presence) POPs distributed geographically; and
the first server is located in a first POP of the plurality of POPs;
returning an anycast IP address to the end-user system;
receiving a request for the first content object, wherein:
the request for the first content object is from the end-user system;
the request for the first content object uses the anycast IP address;
the request for the first content object is received at a second server; and
the second server is in a second POP of the plurality of POPs;
identifying that the first content object references two additional content objects, a second content object and a third content object; and
returning a response to the end-user system, the response comprising:
a first Uniform Resource Locator (URL), wherein:
the first URL is used to locate the second content object;
the first URL resolves to a first IP address;
the first IP address is a unicast IP address; and
the first IP address identifies a third server; and
a second Uniform Resource Locator (URL), wherein:
the second URL is used to locate the third content object;
the second URL resolves to a second IP address;
the second IP address is a unicast IP address;
the second IP address identifies a fourth server; and
the fourth server is different from the third server.
9. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 8 , wherein:
the third server is in a third POP of the plurality of POPs;
the fourth server is in fourth POP of the plurality of POPs; and
the third POP is different than the fourth POP.
10. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 8 , wherein the third server is the same as the second server.
11. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 8 , wherein the method further comprises receiving a request for the second content object at the second POP.
12. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 8 , wherein the first URL and the second URL are part of markup language file returned to the end-user system.
13. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 12 , further comprising terminating a link with the end-user system, wherein:
the link was formed with the end-user system using the anycast IP address;
terminating the link is performed after returning the response to the end-user system;
terminating the link is performed before the third server receives a request from the end-user system for the second content object; and
terminating the link is performed before the fourth server receives a request from the end-user system for the third content object.
14. The method for assigning multiple servers of the delivery network for fulfillment of the single content request as recited in claim 8 , wherein returning the response to the end-user system is performed by the second server.
15. A computer-memory device having instructions that when executed perform the following steps for assigning multiple servers of a delivery network for fulfillment of a single content request:
receive a request for the first content object, wherein:
the request for the first content object is from an end-user system;
the request for the first content object uses an anycast IP address;
the anycast IP address was returned to the end-user system from a first server;
the first server is in a first point of presence (POP) of a plurality of POPs;
the plurality of POPs is distributed geographically;
the request for the first content object is received at a second server; and
the second server is in a second POP of the plurality of POPs;
identify that the first content object references two additional content objects, a second content object and a third content object; and
return a response to the end-user system, the response comprising:
a first Uniform Resource Locator (URL), wherein:
the first URL is used to locate the second content object;
the first URL resolves to a first IP address;
the first IP address is a unicast IP address; and
the first IP address identifies a third server; and
a second URL, wherein:
the second URL is used to locate the third content object;
the second URL resolves to a second IP address;
the second IP address is a unicast IP address;
the second IP address identifies a fourth server; and
the fourth server is different from the third server.
16. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , the instructions further performing the following steps when executed:
receive a Domain Name Service (DNS) request, wherein:
the DNS request is from an end-user system;
the DNS request is for identifying a server to provide the first content object to the end-user system; and
the DNS request is received at the first server; and
return the anycast IP address to the end-user system.
17. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , wherein the fourth server and the third server are in different POPs of the plurality of POPs.
18. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , wherein the first POP is the same as the second POP.
19. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , wherein the first URL and the second URL are part of a markup language file returned to a player on the end-user system.
20. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , wherein returning the response to the end-user system is performed after closing a link with the end-user system, wherein the link was formed with the end-user system using the anycast IP address.
21. The computer-memory device having instructions for assigning multiple servers of a delivery network for fulfillment of a single content request as recited in claim 15 , wherein the second POP is closer to the end-user system than the first POP.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/047,824 US20140108674A1 (en) | 2010-12-27 | 2013-10-07 | Anycast redirect to unicast content download |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2010/062156 WO2012091694A1 (en) | 2010-12-27 | 2010-12-27 | Anycast redirect to unicast content download |
AU2011200629A AU2011200629B1 (en) | 2011-02-15 | 2011-02-15 | Anycast redirect to unicast content download |
AU2011200629 | 2011-11-17 | ||
US13/344,497 US8621042B2 (en) | 2010-12-27 | 2012-01-05 | Anycast redirect to unicast content download |
US14/047,824 US20140108674A1 (en) | 2010-12-27 | 2013-10-07 | Anycast redirect to unicast content download |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/344,497 Continuation US8621042B2 (en) | 2010-12-27 | 2012-01-05 | Anycast redirect to unicast content download |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140108674A1 true US20140108674A1 (en) | 2014-04-17 |
Family
ID=46318386
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/344,497 Active 2031-02-15 US8621042B2 (en) | 2010-12-27 | 2012-01-05 | Anycast redirect to unicast content download |
US14/047,824 Abandoned US20140108674A1 (en) | 2010-12-27 | 2013-10-07 | Anycast redirect to unicast content download |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/344,497 Active 2031-02-15 US8621042B2 (en) | 2010-12-27 | 2012-01-05 | Anycast redirect to unicast content download |
Country Status (1)
Country | Link |
---|---|
US (2) | US8621042B2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3275138A4 (en) * | 2015-03-27 | 2018-08-01 | Akamai Technologies, Inc. | Traffic delivery using anycast and end user-based mapping in an overlay network |
WO2021031562A1 (en) * | 2019-08-20 | 2021-02-25 | 华为技术有限公司 | Information obtaining method and device |
US11601513B2 (en) * | 2014-10-27 | 2023-03-07 | Level 3 Communications, Llc | Content delivery systems and methods |
US11706292B1 (en) * | 2022-03-15 | 2023-07-18 | Disney Enterprises, Inc. | Local preference in anycast CDN routing |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7797426B1 (en) * | 2008-06-27 | 2010-09-14 | BitGravity, Inc. | Managing TCP anycast requests |
US8745122B2 (en) | 2011-06-14 | 2014-06-03 | At&T Intellectual Property I, L.P. | System and method for providing an adjunct device in a content delivery network |
US8819187B1 (en) | 2013-10-29 | 2014-08-26 | Limelight Networks, Inc. | End-to-end acceleration of dynamic content |
EP3085147A1 (en) * | 2013-12-17 | 2016-10-26 | Nokia Solutions and Networks GmbH & Co. KG | Cell load based content data network selection |
US20150172354A1 (en) * | 2013-12-17 | 2015-06-18 | Limelight Networks, Inc. | Content-delivery transfer for cooperative delivery systems |
US9838497B2 (en) | 2014-02-19 | 2017-12-05 | Level 3 Communications, Llc | Content delivery network architecture with edge proxy |
CN105227535B (en) | 2014-07-01 | 2019-12-06 | 思科技术公司 | Apparatus and method for edge caching and client devices |
CN106101201B (en) * | 2016-06-02 | 2019-03-22 | 南京师范大学 | Based on the expansible anycast's method and system for redirecting and rewriteeing in a kind of NDN |
US10764391B2 (en) * | 2017-09-14 | 2020-09-01 | Akamai Technologies, Inc. | Origin and cache server cooperation for compute-intensive content delivery |
US20220321479A1 (en) * | 2021-04-02 | 2022-10-06 | Microsoft Technology Licensing, Llc | Anycast routing technique for a content delivery network |
US11843682B1 (en) * | 2022-08-31 | 2023-12-12 | Adobe Inc. | Prepopulating an edge server cache |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020147840A1 (en) * | 2001-04-05 | 2002-10-10 | Mutton James Andrew | Distributed link processing system for delivering application and multi-media content on the internet |
US20030079027A1 (en) * | 2001-10-18 | 2003-04-24 | Michael Slocombe | Content request routing and load balancing for content distribution networks |
US20050265321A1 (en) * | 2000-09-25 | 2005-12-01 | Theodore Rappaport | System and method for design, tracking, measurement, prediction and optimization of data communication networks |
US20060229095A1 (en) * | 2005-04-11 | 2006-10-12 | Samsung Electronics Co., Ltd. | Method and system for performing media storage service in push-to-talk over cellular network |
US20060230148A1 (en) * | 2005-04-06 | 2006-10-12 | John Forecast | TCP forwarding of client requests of high-level file and storage access protocols in a network file server system |
US20080080513A1 (en) * | 2006-09-29 | 2008-04-03 | Kang Yoo Hwa | Anycast routing method and apparatus for supporting service flow in internet system |
US20090113057A1 (en) * | 2007-10-26 | 2009-04-30 | Jacobus Van Der Merwe | Proximity Routing For Session Based Applications Using Anycast |
US7574499B1 (en) * | 2000-07-19 | 2009-08-11 | Akamai Technologies, Inc. | Global traffic management system using IP anycast routing and dynamic load-balancing |
US20100121945A1 (en) * | 2008-11-11 | 2010-05-13 | At&T Corp. | Hybrid Unicast/Anycast Content Distribution Network System |
US20110202589A1 (en) * | 2010-02-15 | 2011-08-18 | Openwave Systems Inc. | Scripting/proxy systems, methods and circuit arrangements |
US20120023153A1 (en) * | 2010-07-21 | 2012-01-26 | Anestis Karasaridis | Methods and apparatus to transmit a request to server via domain system forwarding |
US20120117239A1 (en) * | 2010-04-01 | 2012-05-10 | Lee Hahn Holloway | Internet-based proxy service for responding to server offline errors |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6415323B1 (en) * | 1999-09-03 | 2002-07-02 | Fastforward Networks | Proximity-based redirection system for robust and scalable service-node location in an internetwork |
US7565450B2 (en) | 2000-03-16 | 2009-07-21 | Adara Networks Inc. | System and method for using a mapping between client addresses and addresses of caches to support content delivery |
US7908337B2 (en) * | 2000-04-28 | 2011-03-15 | Adara Networks, Inc. | System and method for using network layer uniform resource locator routing to locate the closest server carrying specific content |
JP4054007B2 (en) * | 2004-07-15 | 2008-02-27 | 株式会社東芝 | Communication system, router device, communication method, routing method, communication program, and routing program |
US20070118667A1 (en) | 2005-11-21 | 2007-05-24 | Limelight Networks, Inc. | Domain name resolution based dynamic resource assignment |
US7730187B2 (en) | 2006-10-05 | 2010-06-01 | Limelight Networks, Inc. | Remote domain name service |
US20080123640A1 (en) * | 2006-09-20 | 2008-05-29 | Ravideep Bhatia | Method for discovering outbound sip proxy server |
US7797426B1 (en) | 2008-06-27 | 2010-09-14 | BitGravity, Inc. | Managing TCP anycast requests |
US7925782B2 (en) * | 2008-06-30 | 2011-04-12 | Amazon Technologies, Inc. | Request routing using network computing components |
US8180896B2 (en) * | 2008-08-06 | 2012-05-15 | Edgecast Networks, Inc. | Global load balancing on a content delivery network |
US7930429B2 (en) | 2008-12-18 | 2011-04-19 | At&T Intellectual Property I, Lp | System and method for obtaining content from a content delivery network |
US11323508B2 (en) * | 2009-05-22 | 2022-05-03 | Comcast Interactive Media, Llc | Web service system and method |
US9450804B2 (en) | 2009-09-03 | 2016-09-20 | At&T Intellectual Property I, L.P. | Anycast aware transport for content distribution networks |
US8825820B2 (en) * | 2009-09-18 | 2014-09-02 | At&T Intellectual Property I, Lp | Network aware application management |
US8612622B2 (en) | 2009-10-02 | 2013-12-17 | Limelight Networks, Inc. | Real-time message queuing for a processing ring |
US8745239B2 (en) * | 2010-04-07 | 2014-06-03 | Limelight Networks, Inc. | Edge-based resource spin-up for cloud computing |
US8489724B2 (en) * | 2010-09-14 | 2013-07-16 | Cdnetworks Co., Ltd. | CNAME-based round-trip time measurement in a content delivery network |
-
2012
- 2012-01-05 US US13/344,497 patent/US8621042B2/en active Active
-
2013
- 2013-10-07 US US14/047,824 patent/US20140108674A1/en not_active Abandoned
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7574499B1 (en) * | 2000-07-19 | 2009-08-11 | Akamai Technologies, Inc. | Global traffic management system using IP anycast routing and dynamic load-balancing |
US20050265321A1 (en) * | 2000-09-25 | 2005-12-01 | Theodore Rappaport | System and method for design, tracking, measurement, prediction and optimization of data communication networks |
US20020147840A1 (en) * | 2001-04-05 | 2002-10-10 | Mutton James Andrew | Distributed link processing system for delivering application and multi-media content on the internet |
US20030079027A1 (en) * | 2001-10-18 | 2003-04-24 | Michael Slocombe | Content request routing and load balancing for content distribution networks |
US20060230148A1 (en) * | 2005-04-06 | 2006-10-12 | John Forecast | TCP forwarding of client requests of high-level file and storage access protocols in a network file server system |
US20060229095A1 (en) * | 2005-04-11 | 2006-10-12 | Samsung Electronics Co., Ltd. | Method and system for performing media storage service in push-to-talk over cellular network |
US20080080513A1 (en) * | 2006-09-29 | 2008-04-03 | Kang Yoo Hwa | Anycast routing method and apparatus for supporting service flow in internet system |
US20090113057A1 (en) * | 2007-10-26 | 2009-04-30 | Jacobus Van Der Merwe | Proximity Routing For Session Based Applications Using Anycast |
US20100121945A1 (en) * | 2008-11-11 | 2010-05-13 | At&T Corp. | Hybrid Unicast/Anycast Content Distribution Network System |
US20110202589A1 (en) * | 2010-02-15 | 2011-08-18 | Openwave Systems Inc. | Scripting/proxy systems, methods and circuit arrangements |
US20120117239A1 (en) * | 2010-04-01 | 2012-05-10 | Lee Hahn Holloway | Internet-based proxy service for responding to server offline errors |
US20120023153A1 (en) * | 2010-07-21 | 2012-01-26 | Anestis Karasaridis | Methods and apparatus to transmit a request to server via domain system forwarding |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11601513B2 (en) * | 2014-10-27 | 2023-03-07 | Level 3 Communications, Llc | Content delivery systems and methods |
US20230216930A1 (en) * | 2014-10-27 | 2023-07-06 | Level 3 Communications, Llc | Content delivery systems and methods |
US11805184B2 (en) * | 2014-10-27 | 2023-10-31 | Level 3 Communications, Llc | Content delivery systems and methods |
EP3275138A4 (en) * | 2015-03-27 | 2018-08-01 | Akamai Technologies, Inc. | Traffic delivery using anycast and end user-based mapping in an overlay network |
US10805110B2 (en) | 2015-03-27 | 2020-10-13 | Akamai Technologies, Inc. | Traffic delivery using anycast and end user-based mapping in an overlay network |
WO2021031562A1 (en) * | 2019-08-20 | 2021-02-25 | 华为技术有限公司 | Information obtaining method and device |
WO2021189869A1 (en) * | 2019-08-20 | 2021-09-30 | 华为技术有限公司 | Information acquisition method and apparatus |
US11706292B1 (en) * | 2022-03-15 | 2023-07-18 | Disney Enterprises, Inc. | Local preference in anycast CDN routing |
US20230362240A1 (en) * | 2022-03-15 | 2023-11-09 | Disney Enterprises, Inc. | Local preference in anycast cdn routing |
Also Published As
Publication number | Publication date |
---|---|
US20120166591A1 (en) | 2012-06-28 |
US8621042B2 (en) | 2013-12-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8621042B2 (en) | Anycast redirect to unicast content download | |
US11805184B2 (en) | Content delivery systems and methods | |
US20210021692A1 (en) | Translation of resource identifiers using popularity information upon client request | |
US8984056B2 (en) | Inter point of presence split architecture | |
US8612588B1 (en) | Point of presence to point of presence web page compression | |
US9515980B2 (en) | Scaled domain name service | |
US10264062B2 (en) | Request routing using a popularity identifier to identify a cache component | |
US20150264009A1 (en) | Client-selectable routing using dns requests | |
US20160285961A1 (en) | Delivering managed and unmanaged content across a network | |
WO2012091694A1 (en) | Anycast redirect to unicast content download | |
Yan et al. | Design and implementation of integrated ICN and CDN as a video streaming service | |
AU2011200629B1 (en) | Anycast redirect to unicast content download | |
CN110036607B (en) | Method and request router for dynamic pooling of resources in a content distribution network | |
WO2014025972A2 (en) | Inter point of presence split architecture |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LIMELIGHT NETWORKS, INC., ARIZONA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOKAL, MOHAN I.;HARVELL, BRADLEY B.;EGGLESTON, JASON;SIGNING DATES FROM 20131009 TO 20131017;REEL/FRAME:031581/0571 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |