Routing for origin-facing points of presence

Abstract

Systems and methods are described to enable and manage the use of origin-facing points of presence (“POPs”) within a content delivery network (“CDN”). Origin-facing POPs can provide a second-tier caching mechanisms in a CDN, such that cache misses occurring at first-tier POPs may be processed by using information maintained at the origin-facing POPs, rather than requiring interaction with an origin server. Associations between origin-facing POPs and origin servers may be automatically created based on a distance between the respective origin-facing POPs and origin servers, such that an operator of the origin server is not required to specify a location of an origin facing POP. First-tier POPs may selectively retrieve content from origin-facing POPs in instances where the origin-facing POP is expected to provide the content more rapidly than the origin server.

Description

BACKGROUND

Generally described, computing devices utilize a communication network, or a series of communication networks, to exchange data. Companies and organizations operate computer networks that interconnect a number of computing devices to support operations or provide services to third parties. The computing systems can be located in a single geographic location or located in multiple, distinct geographic locations (e.g., interconnected via private or public communication networks). Specifically, data centers or data processing centers, herein generally referred to as “data centers,” may include a number of interconnected computing systems to provide computing resources to users of the data center. The data centers may be private data centers operated on behalf of an organization or public data centers operated on behalf, or for the benefit of, the general public.

Content providers (such as businesses, artists, media distribution services, etc.) can employ a series of interconnected data centers to deliver content (such as web sites, web content, or other digital data) to users or clients. These interconnected data centers are sometimes referred to as “content delivery networks” (CDNs) or content delivery systems. Existing routing and addressing technologies can enable multiple data centers associated with a content delivery system to provide similar or identical content to client computing devices. In some instances, each data center providing a set of content may be referred to as a point-of-presence (“POP”). A content delivery system can maintain POPs over a wide area (or worldwide) to enable the system to efficiently service requests from clients in a variety of locations.

To utilize a CDN, a content provider generally designates one or more computing devices or data centers to maintain primary copies of content, which are sometimes referred to as “origin servers.” Each POP within the CDN can maintain all or a portion of the content maintained on the origin server (e.g., within a data cache of the CDN). When a client requests a content item from a POP, the POP can determine whether that the requested content item is maintained at the POP. If so, the POP can provide the requested content item to the client directly. If not, the POP may first retrieve the content item from the origin server, and thereafter provide the content item to the client. This process of returning content not presently maintained at a POP is sometimes referred to as a “cache miss.” Cache misses are generally undesirable, in that they result in delays to fulfill client requests (e.g., due to the time required to retrieve content from the origin server) as well as increased load on the origin server itself.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting an illustrative logical network 100 including multiple client computing devices and origin servers, as well as a content delivery network (“CDN”) including a point of presence (“POP”) manager, multiple edge POPs, and multiple mid-tier POPs;

FIG. 2 is a block diagram depicting an illustrative configuration of one embodiment of a server implementing an edge POP of FIG. 1;

FIG. 3 is a block diagram depicting interactions between an edge POP and other components of FIG. 1 to generate mid-tier POP and origin server routing information, which may be used by the edge POP to route client requests for content received at the CDN;

FIG. 4 is a block diagram depicting interactions between a content provider and other components of FIG. 1 to assign a mid-tier POP, within the CDN, to content associated with an origin server;

FIG. 5 is a block diagram depicting interactions for routing a client request, at an edge POP within the CDN of FIG. 1, for content that is not maintained at the edge POP; and

FIG. 6 is a flow chart depicting an illustrative routine for routing client requests, at an edge POP within the CDN of FIG. 1, for content that is not maintained at the edge POP.

DETAILED DESCRIPTION

Generally described, aspects of the present disclosure relate to implementing and managing second-level points of presence (“POPs”) within a content delivery network (“CDN”). Second-level POPs can generally refer to a computing device or collection of computing devices that may act as intermediary sources for various sets of content (each of which can be generally referred to as a content “distribution”), between edge POPs of a CDN (e.g., those POPs that receive and process client requests for content on the CDN, which may also be referred to as “client-facing” POPs) and origin servers (e.g., those devices that serve as primary sources for content distributed via the CDN). Specifically, second-level POPs, which may also be referred to herein as “mid-tier POPs” or “origin-facing POPs” may enable cache misses to be handled on the CDN without requiring interaction with the origin server. Thus, the use of second-level POPs can substantially improve the performance of the CDN in handling cache misses, both by reducing the time required to provide content to a client and by reducing the computing resources needed at the origin server. The present disclosure further describes systems and methods for automatically determining locations for placement of second-level POPs based on the location of an origin server for a specific distribution (e.g., a specific set of content). Specifically, aspects of the present disclosure enable a second-level POP to be established in close geographic or network proximity to an origin server. Such placement of a second-level POP can improve the ability of the second-level POP and origin server to rapidly communicate, thus further reducing the computing resources required by the origin server. Still further, the present disclosure describes systems and methods for routing requests within a CDN utilizing second-level POPs. Specifically, aspects of the present disclosure enable edge POPs to selectively retrieve uncached content (e.g., content corresponding to a cache miss) from either second-level POPs or from origin servers, based at least partly on a geographic or network distance between the edge POP and the second-level POPs or origin servers. In this manner, retrieval of uncached content can occur via second-level POPs only when such retrieval is expected to improve the performance of the CDN (e.g., with respect to time required to service client requests, reduction of computing resources needed at an origin server, or both).

Content providers may generally maintain one or more primary sources for a distribution, such as web servers operated by the content providers, which are generally referred to as “origin servers.” Because a content provider may not wish to maintain an extensive network of origin servers, these servers are often located in one geographical location, and associated with limited computing resources. This configuration can lead to large geographic and network distance existing between the origin server and the various client devices that are provided content. To reduce the time required to provide content to client devices, and to reduce the computing resources required at an origin server, a content provider may utilize a CDN, which includes a set of edge POPs distributed at various geographical locations, each of can maintain at least a portion of the content of the distribution (e.g., as initially provided to the edge POP by the origin server). These edge POPs may receive client requests for content of the distribution, and respond to these requests utilizing versions of the content stored at the edge POP. However, the storage capabilities of edge POPs are generally also limited, such that not all content of all content of all distributions associated with the edge POP can be maintained concurrently. To address this issue, when a client requests content of a distribution, and that content is not maintained at the edge POP (sometimes referred to as a “cache miss”), the edge POP may first retrieve the content from an origin server associated with the distribution. The process of retrieving content from an origin server can increase the time required to service the request as well as increasing the load on the origin server, thus negating a portion of the benefit provided by the CDN.

In accordance with aspects of the present disclosure, the negative effects of cache misses on a CDN may be eliminated or reduced by use of one or more mid-tier POPs within the CDN. Each mid-tier POP may serve as a potential intermediary source of content for edge POPs, such that when a cache miss occurs at the edge POP, the requested content can be retrieved from a mid-tier POP, rather than an origin server providing that content. Because edge POPs and mid-tier POPs may communicate with one another via specialized communication protocols or via a private computing network, retrieval of content from a mid-tier POP may occur more rapidly than would be possible from an origin server. Moreover, retrieval of content from a mid-tier POP can reduce the use of computing resources at the origin server. Thus, the use of mid-tier POPs can enable the CDN to rapidly provide content to clients even in the instance that a cache miss occurs at an edge POP.

The CDN may provide multiple mid-tier POPs, each associated with specific distributions. In one embodiment, each mid-tier POP may be assigned to act as an intermediary content source for distributions with origin servers nearby to the mid-tier POP, either in geographical or network terms, to enable rapid communication between the mid-tier POP and the assigned origin servers. Thus, when a content provider requests the use of a mid-tier POP on the CDN for a distribution of content, the CDN may locate a mid-tier POP nearby to an origin server acting as a primary source for that distribution of content, and assign the origin server to that mid-tier POP, such that the mid-tier POP acts as an intermediary content source for the distribution. Such automatic location of mid-tier POPs may eliminate the need for content providers to manually specify desired mid-tier POPs within the CDN. As will be described in more detail below, the CDN may utilize passively obtained network data, actively obtained network data, or both to determine the proximity of mid-tier POPs to origin servers. In another embodiment, each mid-tier POP may be assigned to act as an intermediary content source for all distributions associated with the CDN. This may reduce the need to assign mid-tier POPs to specific distributions, but may also increase the computing resources utilized by each mid-tier POP.

In some instances, the use of mid-tier POPs may not be expected to increase the performance of the CDN. For example, where an origin server has excess unused computing resources, and where the origin server is closer (e.g., in geographic or network distance) to an edge POP than is an assigned mid-tier POP, it may be more beneficial for the edge POP to communicate directly with the origin server than to utilize the mid-tier POP as an intermediary content source. Thus, embodiments of the present application further enable an edge POP to selectively retrieve content of a distribution from either an origin server associated with that distribution or a mid-tier POP of the CDN storing content of the distribution, based on an expected performance of communications with the origin server and mid-tier POP. To enable such selective retrieval, the edge POP can maintain routing information for individual origin servers associated with each distribution, as well as for the mid-tier POPs provided by a CDN that are associated with one or more distributions. When a request for uncached content of a given distribution is processed at the edge POP, the edge POP can dynamically generate a routing table indicating a preferred source for the uncached content, and retrieve the uncached content from the preferred source. In this manner, edge POPs can be configured to utilize mid-tier POPs only in instances where use of mid-tier POPs is expected to increase the performance of the CDN (e.g., by reducing the time required to service client requests, by reducing the computing resources needed at the origin server, or both).

As will be appreciated by one of skill in the art in light of the description above, the embodiments disclosed herein substantially increase the ability of computing systems, such as CDNs, to rapidly and effectively distribute content to client computing devices, even in instances of cache misses. Thus, the presently disclosed embodiments represent an improvement in the functioning of such computing systems. Moreover, the presently disclosed embodiments address technical problems inherent within computing systems; specifically, the limited capacity of computing systems to store information, as well as the limited ability of such systems to process network-based requests. These technical problems are addressed by the various technical solutions described herein, including the utilization of mid-tier POPs, the assignment of mid-tier POPs to distributions based on geographic or network proximity to origin servers associated with those distributions, and the selective routing of requests for content to mid-tier POPs or origin servers (e.g., based on a dynamically created routing table related to the mid-tier POPs or origin servers). Thus, the present application represents a substantial improvement on existing network systems and computing systems in general.

The foregoing aspects and many of the attendant advantages of the present disclosure will become more readily appreciated as the same become better understood by reference to the following, when taken in conjunction with the accompanying drawings.

FIG. 1 is a block diagram depicting an illustrative logical network 100 including multiple client computing devices 102 and origin servers 104 in communication with a CDN 110 via a network 106. As shown in FIG. 1, the CDN 110 includes a plurality of edge POPs 112, a plurality of mid-tier POPs 112, and a POP manager 116 in communication via a private network. The various elements of the CDN 110 are described in more detail below.

While the client computing devices 102 and the origin servers 104 are shown as a group within FIG. 1, the client computing devices 102 and origin servers 104 may be geographically distant, and independently owned or operated. For example, the client computing devices 102 could represent a multitude of users in various global, continental, or regional locations accessing the CDN 110. Further, the origin servers 104 could represent a multitude of related or distinct parties that have associated with the CDN 110 to provide sets of content, such as web sites, multimedia, or other digital, network-deliverable content (each generally referred to as a “distribution”) to the client computing devices 102. Accordingly, the groupings of client computing devices 102 and origin servers 104 within FIG. 1 is intended to represent a logical, rather than physical, grouping. Similarly, each of the components of the CDN 110 may be located within geographically diverse areas. For example, the edge POPs 112 and mid-tier POPs 114 within the CDN 110 (described in more detail below) may be globally, continentally, or regionally disparate, in order to provide a wide geographical presence for the CDN 110.

Network 106 may be any wired network, wireless network, or combination thereof. In addition, the network 106 may be a personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, or combination thereof. In the example environment of FIG. 1, network 106 is a global area network (GAN), such as the Internet. Protocols and components for communicating via the other aforementioned types of communication networks are well known to those skilled in the art of computer communications and thus, need not be described in more detail herein. While each of the client computing devices 102, origin servers 104, and CDN 110 is depicted as having a single connection to the network 106, individual components of the client computing devices 102, origin servers 104, and CDN 110 may be connected to the network 106 at disparate points. Accordingly, communication times and capabilities may vary between the components of FIG. 1.

Client computing devices 102 may include any number of different computing devices capable of communicating with the CDN 110. For example, individual accessing computing devices may correspond to a laptop or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, electronic book reader, set-top box, camera, digital media player, and the like. Using client computing devices 102, clients may interact with and access distributions of content on the CDN 110 originating from or otherwise associated with origin servers 104 of various content providers. For example, after requesting content associated with a specific distribution (e.g., a specific web site, video file, etc.), the client computing devices 102 may be routed to an edge POP 112 configured to provide content of that distribution on behalf of the origin server 104. Various mechanisms for routing of client computing devices 102 to edge POPs 112 within a CDN 110 are known within the art, and thus will not be described in detail herein.

Origin servers 104 may include any computing device owned or operated by an entity that has provided one or more sets of content (“distributions”) to the CDN 110 for subsequent transmission to client computing devices 102. For example, origin servers 104 may include servers hosting web sites, streaming audio, video, or multimedia services, data analytics services, or other network-accessible services. The origin servers 104 may include primary versions of content within various distributions, which may be retrieved by various POPs of the CDN 110 for subsequent transmission to the client computing devices 102.

To receive and handle requests for content from client computing devices 102, the CDN 110 can include a plurality of edge POPs 112A through 112N. Each edge POP 112 may include a variety of computing devices collectively configured to maintain all or a portion of the content associated with the various distributions provided by origin servers 104. As will be discussed in more detail below with respect to FIG. 2, each edge POP 112 may include any number of processors, data stores, or networking components operating in conjunction to facilitate retrieval of content. Each edge POP 112 includes a cache of content from a variety of distributions. Because size of the cache may be limited (e.g., due to the limited size of a data store on which the cache is implemented), the edge POP 112 may implement various algorithms or procedures for determining what content should be maintained within the cache. Illustratively, each edge POP 112 may implement a cache eviction policy, which maintains within the cache a set of content items most recently requested by client computing devices 102, and evicts less recently used content.

Because the cache of an edge POP 112 is limited, it is possible for a client computing device 102 to transmit a request to an edge POP 112 for content that is not cached at the edge POP 112. Requests for uncached content can generally be referred to as “cache misses.” Traditionally, an edge POP 112 can handle a cache miss by initiating a request for the content to an origin server 104 associated with the content. However, as noted above, such processing is often undesirable, as it increases the time (e.g., latency) required to provide the requested content to the client computing device 102, and may increase the computing resources needed at the origin server 104. In instances were cache misses cause the edge POPs 112 to transmit a high volume of requests to the origin servers 104, the origin server 104 may fail to respond to all requests, thus resulting in errors at the client computing devices 102.

To reduce or eliminate the negative effects of cache misses, the illustrative CDN 110 of FIG. 1 also includes a plurality of mid-tier POPs 114. Each mid-tier POP 114 may function similarly to an edge POP 112, by receiving and processing requests for content associated with the origin servers 104. As in the case of an edge POP 112, each mid-tier POP 114 may maintain a limited cache of content associated with the origin servers 104, which can be utilized to service requests for that content. In the instance that a mid-tier POP 114 receives a request for content not available in the mid-tier POP 114's cache, the mid-tier POP 114 may retrieve the content from the origin server 104 before servicing the request.

The caches of edge POPs 112 and mid-tier POPs 114 may be configured according to both the desired speed and size of the cache. In some instances, cache size and speed are at least partially interchangeable, such that the same or similar hardware can provide either a high-speed, low-size cache or a low-speed, high-size cache. For example, where a cache is implemented by a set of hard disk drives (HDDs), a small set of content can be replicated across the drives, such that the drives can work in parallel to provide high-speed access to the content. Conversely, the set of hard disk drives may provide little or no replication of content, such that a higher amount of content can be stored, but that retrieval of the content is slowed due to the limited availability of that content. In other instances, the speed and size of a cache may be varied based on the hardware utilized to implement the cache. For example, a high-speed, low-sized cache may be implemented in a set of solid-state drives (SSDs), while a low-speed, large-sized cache may be implemented in magnetic HDDs. Accordingly, by modifying the configuration or hardware utilized, the edge POPs 112 may be configured to implement a high-speed, low-size cache when compared to the cache of the mid-tier POPs 114. This configuration can enable the edge POPs 112 to facilitate most content requests rapidly, while also ensuring that a substantial portion of requested uncached at the edge POP 112 are stored within the cache of the mid-tier POP 114, and thus may be serviced without interaction with a corresponding origin server 104.

In one embodiment, each mid-tier POP 114 may be associated with all distributions (e.g., sets of content made available by the origin servers 104), such that content of any distribution may be retrieved from each mid-tier POP 114. In this manner, each distribution's content may be highly replicated across the mid-tier POPs 114, reducing the requests made to the origin servers 104, especially for highly popular content. In another embodiment, a mid-tier POP 114 may be assigned to cache content only of specific distributions. For example, the mid-tier POP 114A may be assigned to cache content of a first distribution (e.g., associated with a first origin server 104), but not of a second distribution (e.g., associated with a second origin server 104). Such assignment may, for example, prevent the mid-tier POP 114A from evicting content of the first distribution based on the popularity of other distributions.

The components of the CDN 110, including the edge POPs 112, mid-tier POPs 114, and POP manager 116 may communicate via a private network 118. The private network 118 may include any combination of various network types described above operated on behalf of the CDN 110, alone or in conjunction with other services. While shown as distinct from the network 106, the private network 118 in some instances may be physically co-mingled with the network 106. For example, the private network 118 may be formed by one or more leased lines on the network 106 that provide dedicated communications to the CDN 110. Because the private network 118 is operated on behalf of the CDN 110 (e.g., independently or in conjunction with other services associated with the CDN 110), the number of delays and errors caused by transmission of data across the private network 118 may generally be less than the number of delays and errors caused by transmission of data across the network 106. Moreover, because the private network 118 is operated on behalf of the CDN 110, the functionality of the private network 118 (e.g., the protocols used therein or the configuration of network devices operating as part of the private network 118) may be modified by the CDN 110 without reducing the ability of the CDN 110 to interact with the network 106.

To facilitate assignment of mid-tier POPs 114 to origin servers 104, the CDN 110 can further include a POP manager 116 device. As will be described in more detail below, the POP manager 116 may obtain information regarding proximities of mid-tier POPs 114 and origin servers 104, and utilize that information to assign mid-tier POPs 114 to distributions originating from those origin servers 104. For example, where a content provider associated with a distribution initially provided by a first origin server 104 wishes to utilize the mid-tier POPs 114, the POP manger 116 may determine which mid-tier POP 114 of the CDN 110 is proximate to the first origin server 104, and assign that mid-tier POP 114 as a second-level cache for the distribution initially provided by the first origin server 104. Frequently, transmission times between computing devices over a network are dependent, at least in part, on the distance between the devices. Thus, assignment of mid-tier POPs 114 that are proximate to an origin server 104 can beneficially reduce the computing resources necessary to retrieve content from the origin server 104, increasing the performance of the CDN 110.

In one embodiment, proximity between mid-tier POPs 114 and origin servers 104 may be determined based at least in part on geographic distance. For example, the geographic location of each mid-tier POP 114 and origin server 104 may be provided to the CDN by an administrator of the respective mid-tier POPs 114 and servers 104, or may be determined by the POP manager 116 based on a network address of the respective mid-tier POPs 114 and servers 104 (e.g., utilizing internet protocol [“IP”] geo-location techniques that are known in the art). Thereafter, the POP manager 116 may determine a mid-tier POP 114 that is proximate to an origin server 104 by computing the distance between these geographic locations. In another embodiment, proximity between mid-tier POPs 114 and origin servers 104 may be determined based at least in part on passively gathered network information. For example, each mid-tier POP 114 may function to monitor the round trip communication time needed to communicate with various origin servers 104, or other computing devices that are similar to the origin servers 104 (e.g., computing devices that exist within the same subnet as the origin servers 104). This round trip communication time can then be utilized (exclusively or in connection with additional information) as a network distance between the mid-tier POP 114 and origin servers 104. In yet another embodiment, proximity between mid-tier POPs 114 and origin servers 104 may be determined based at least in part on actively gathered information, such as network probes (e.g., Internet Control Message Protocol [“ICMP”] packets) transmitted from the mid-tier POPs 114 to the origin servers 104 (or computing devices sharing a subnet with the origin servers 104).

In accordance with embodiments of the present disclosure, proximity information may also be utilized by edge POPs 112 to determine whether the use of a mid-tier POP 114 is preferable to direct communication with an origin server 104. Illustratively, each edge POP 112 may be configured to communicate with a mid-tier POP 114 assigned to a distribution only when that mid-tier POP 114 is nearer to the edge POP 112 than an origin server 104 associated with that distribution. In this manner, an edge POP 112 can be prevented from requesting content of a distribution from a distant mid-tier POP 114, when an origin server 104 of the distribution is nearby and available to service the request. To enable the selective routing of requests to either a mid-tier POP 114 of an origin server 104, each edge POP 112 may maintain routing information for both mid-tier POPs 114 and origin servers 104. This routing information may designate, for example, a distance (e.g., geographical or network) to each of the mid-tier POPs 114 and origin servers 104. Similarly to above, distances between the edge POPs 112 and the mid-tier POPs 114 and servers 104 may be determined based on geographic data, passively gathered network information, or actively gathered network information.

In one embodiment, an edge POP 112 can maintain routing information for mid-tier POPs 114 separately from routing information for origin servers 114, and can dynamically combine the information in order to service requests for content associated with an individual origin server 104. Utilization of separate routing information may be beneficial, for example, because while the number of origin servers 104 associated with the CDN 110 may be large, only one or a few of these origin servers 104 may be associated with content required at the edge POP 112. Thus, combination of routing information for both mid-tier POPs 112 and origin servers 104 would likely result in a routing table that includes substantial irrelevant information. However, by maintaining separate routing information for the mid-tier POPs 114 and the origin servers 112, an edge POP 112 may combine only those portions of each set of routing information that are relevant to a current request. For example, the edge POP 112 may retrieve, from the routing information for all origin servers 104, routing information for a set of origin servers 104 associated with a distribution including the required content. The edge POP 112 may further retrieve, from the routing information for all mid-tier POPs 104, routing information for a set of mid-tier POPs 104 assigned to the distribution. The edge POP 112 may then combine this routing information to determine a nearest mid-tier POP 114 or origin server 104 associated with the requested information. The edge POP 112 can then retrieve the required information from the nearest mid-tier POP 114 or origin server 104, and fulfill the request.

It will be appreciated by those skilled in the art that the CDN 110 may have fewer or greater components than are illustrated in FIG. 1. For example, while shown as distinct in FIG. 1, in some embodiments, POPs within the CDN 110 may operate as both edge POPs 112 and mid-tier POPs 114. As a further example, in some instances, each of the components of the CDN 110 may communicate with one another directly via the network 106, and thus, the private network 118 may be omitted. In addition, the CDN 110 could include various web services and/or peer-to-peer network configurations. Thus, the depiction of the CDN 110 in FIG. 1 should be taken as illustrative. For example, in some embodiments, components of the CDN 110, such as the POP manager 116, may be executed by one more virtual machines implemented within one or more of the edge POPs 112 or mid-tier POPs 114. In other embodiments, the POP manager 116 may be implemented collectively by the edge POPs 112 or mid-tier POPs 114 (e.g., as a peer-to-peer service). Further, any one or more of the edge POPs 112, mid-tier POPs 112, and POP manager 116 may be embodied in a plurality of components, each executing an instance of the respective edge POPs 112, mid-tier POPs 112, and POP manager 116. A server or other computing component implementing any one of the respective edge POPs 112, mid-tier POPs 112, and POP manager 116 may include a network interface, memory, processing unit, and computer readable medium drive, all of which may communicate with each other by way of a communication bus. The network interface may provide connectivity over the network 106, private network 118, and/or other networks or computer systems. The processing unit may communicate to and from memory containing program instructions that the processing unit executes in order to operate the respective edge POPs 112, mid-tier POPs 112, and/or POP manager 116. The memory may generally include RAM, ROM, other persistent and auxiliary memory, and/or any non-transitory computer-readable media.

FIG. 2 depicts one embodiment of an architecture of a server 200 that may implement all or a portion of an edge POP 112 described herein. The general architecture of server 200 depicted in FIG. 2 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As illustrated, the server 200 includes a processing unit 204, a network interface 306, a computer readable medium drive 207, an input/output device interface 220, a display 302, and an input device 224, all of which may communicate with one another by way of a communication bus. The network interface 206 may provide connectivity to one or more networks or computing systems, such as the networks 106 and 118 of FIG. 1. The processing unit 204 may thus receive information and instructions from other computing systems or services via a network. The processing unit 204 may also communicate to and from memory 210 and further provide output information for an optional display 202 via the input/output device interface 220. The input/output device interface 220 may also accept input from the optional input device 224, such as a keyboard, mouse, digital pen, etc. In some embodiments, the server 200 may include more (or fewer) components than those shown in FIG. 2. For example, some embodiments of the server 200 may omit the display 202 and input device 224, while providing input/output capabilities through one or more alternative communication channels (e.g., via the network interface 206). While shown as a single device, each edge POP 112 may be implemented by a set of distinct servers 200 collectively operating to implement the functionality described herein.

The memory 210 may include computer program instructions that the processing unit 204 executes in order to implement one or more embodiments of the present disclosure. The memory 210 generally includes RAM, ROM and/or persistent or non-transitory memory. The memory 210 may store an operating system 214 that provides computer program instructions for use by the processing unit 204 in the general administration and operation of the server 200. The memory 210 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 210 includes user interface software 212 that generates user interfaces (and/or instructions therefor) for display upon a computing device, e.g., via a navigation interface such as a web browser installed on the computing device. In addition, memory 210 may include or communicate with one or more auxiliary data stores, such as the data stores 230 and 232.

The data stores 230 and 232 may be any persistent or substantially persistent storage device (e.g., a hard disk drive, solid state disk drive, flash memory, etc.) utilized to store information utilized by the server 200. Specifically, the data store 230 may be utilized to store content associated with various distributions (e.g., as a cache of the content of those distributions). The routing information data store 232 may be utilized to store routing information associated with other components of the CDN 110, such as mid-tier POP 114, as well as routing information associated with the various origin servers 104.

In addition to the user interface module 212, the memory 210 may include content delivery software 216 that may be executed by the processing unit 204. In one embodiment, the content delivery software 216 implements various aspects of the present disclosure, including processing requests for content cached at the edge POP server 200 (e.g., by use of the content stored within the content data store 230), and the selective routing of requests for uncached content to nearby mid-tier POPs 114 or origin servers 104 (e.g., utilizing the routing information within the routing information data store 232).

With reference to FIG. 3, an illustrative set of interactions are depicted for generating routing information at an edge POP 112A. As discussed above, this routing information may be utilized by the edge POP 112A to determine, in instances where requested content is not available at the edge POP 112A, whether the content should be retrieved from a mid-tier POP 114 or an origin server 104 associated with the content. The interactions begin at (1), where the edge POP 112A exchanges network information with the various mid-tier POPs 114. In one embodiment, this exchange of network information may include transmission, from the edge POP 112A, of network probes (e.g., ICMP packets). In another embodiment, this exchange of network information may occur during normal operating of the edge POP 112A (e.g., based on requests to retrieve content from the mid-tier POP 114).

Thereafter, at (2), the edge POP 112A utilizes information regarding communication with the mid-tier POPs 114 to generate routing information for each mid-tier POP 114. Illustratively, the edge POP 112A may record a round-trip time of communications with the mid-tier POPs 114, as well as a network bandwidth available between the edge POP 112A and the mid-tier POPs 114 and a number of intermediary devices between the edge POP 112A and the mid-tier POPs 114. These metrics may be utilized (e.g., individually or in combination) by the edge POP 112A to determine a network distance between the edge POP 112A and each mid-tier POP 114, which may be stored as mid-tier POP routing information.

At (3), the edge POP 112A further communicates with some or all of the origin servers 104. Similarly to the communication with the mid-tier POPs 114, communication with the origin servers 104 may include transmission of network probes as well as communications that occur during normal operation of the edge POP 112 (e.g., requests for content from the origin servers 104). At (4), the edge POP 112A may utilize information regarding communication with the origin servers 104 to generate routing information for some or all of the origin servers 114.

At (5), the edge POP 112A may communicate with the POP manager 116 to exchange routing information. Illustratively, the edge POP 112A may transmit to the POP manager 116 all or a portion of the mid-tier POP routing information or the origin server routing information to the POP manager 116. The POP manager 116, in turn, may notify the edge POP 112A of assignments between the mid-tier POPs 114 and the origin servers 104. In some embodiments, the POP manager 116 may further notify the edge POP 112A of additional information regarding the mid-tier POPs 114 or origin servers 104, such as load or capacity information of the mid-tier POPs 114 or origin servers 104. The edge POP 112A may incorporate some or all information received by the POP manager 116 into the mid-tier POPPOP routing information and/or the origin server routing information.

One illustrative example of mid-tier POP routing information that may be generated by the edge POP 112A in accordance with the present disclosure is shown below, as TABLE 1.

	TABLE 1
			Network	Allowed cache
	Mid-tier	Served	distance	misses per
	POP	distributions	(latency)	second
	114A	D1, D4	25 ms	800
	114B	D2	10 ms	1000
	114C	D1, D5, D6	60 ms	2500

One of skill in the art will appreciate that the information of TABLE 1 may be modified to address the specific implementation of the CDN 110. For example, the reference numbers of the various mid-tier POPs 114 may be replaced with network identifiers (e.g., IP addresses or domain names) of the mid-tier POPs 114, while the reference numbers for various distributions (e.g., D1-D6) may be replaced with identifiers of the distributions. As a further example, the network distance of TABLE 1 may incorporate other network metrics in addition to or alternatively to latency, such as bandwidth or numbers of hops. As yet another example, alternatively or in addition to an amount of allowed cache misses per second, load information for each mid-tier POP may be represented in a variety of manners, such as a real-time load on the mid-tier POPs 114 (e.g., as reported by the POP manager 116). In some embodiments, information shown in TABLE 1 may be omitted from routing information generated by the edge POP 112A. For example, where each mid-tier POP 114 is assigned to cache content from each distribution, information regarding distributions served by mid-tier POPs 114 may be omitted from the routing information.

One illustrative example of origin server routing information that may be generated by the edge POP 112A in accordance with the present disclosure is shown below, as TABLE 2.

	TABLE 2
			Network	Allowed cache
	Origin	Served	distance	misses per
	server	distributions	(latency)	second
	104A	D1	155 ms	100
	104B	D2	70 ms	70
	104C	D1	225 ms	300

As in Table 1, the information of TABLE 2 may be modified to address the specific implementation of the CDN 110. For example, the reference numbers of the various origin servers 104 may be replaced with network identifiers (e.g., IP addresses or domain names) of the origin servers 104, or network distance information may incorporate other network metrics in addition or alternatively to latency, such as bandwidth or number of hops. Alternatively or in addition to an amount of allowed cache misses per second, load information for each origin server may be represented in a variety of manners, such as a real-time load on the origin servers 104 (e.g., as reported by the POP manager 116).

In operation of the edge POP 112A, the routing information for the origin servers 104 and the mid-tier POPs 114 (e.g., as represented by TABLES 1 and 2, above) can be combined in order to selectively route requests for uncached content between the origin servers 104 and the mid-tier POPs 114. For example, where uncached content associated with distribution ‘D1’ is requested at the edge POP 112A, the edge POP 112A may extract routing information for origin servers associated with the distribution ‘D1’ from the maintained origin server routing information (shown above in TABLE 2). The edge POP 112A may further extractinformation for all mid-tier POPs 114 associated with the distribution ‘D1’ from maintained mid-tier POP routing information (shown above as TABLE 1). The edge POP 112A may then dynamically create a routing table for the distribution ‘D1’. One example of such a routing table is shown below as TABLE 3.

	TABLE 3
		Network	Allowed cache
		distance	misses per
	D1 Content Source	(latency)	second
	Origin Server 104A	155 ms	100
	Origin Server 104C	225 ms	300
	Mid-tier POP 114A	25 ms	800
	Mid-tier POP 114C	60 ms	2500

Utilizing the information of TABLE 3, the edge POP 112A may selectively route requests for content associated with distribution ‘D1’ to one of the origin server 104A, the origin server 104C, the mid-tier POP 114A, or the mid-tier POP 114C. For example, based on the information above, the edge POP 112 may determine that a first 800 cache misses per second associated with origin server 104A should be routed to mid-tier POP 114A, a next 2500 cache misses per second should be routed to mid-tier POP 114C thereafter, that a next 100 cache misses should be routed to the origin server 104A, and that a next 300 cache misses should be routed to the origin server 104C. In instances where the number of cache misses per second exceeds the total allowed cache misses per second of all content sources, the edge server 112A may attempt to balance the cache misses between potential content sources, or may return an error. Thus, by utilizing the information of TABLE 3, the edge server 112A may selectively route cache misses to various content sources according to the proximity of those sources to the edge server 112A, the load on the content sources, or a combination thereof.

In some embodiments, an edge server 112 may maintain a set of information mapping one or more distributions to potential content sources for that distribution (e.g., one or more origin servers 104 or mid-tier POPs 114), as well as distinct routing information for each potential content source (e.g., origin servers 104 or mid-tier POPs 114). For example, an edge server 112 may maintain a first table correlating or mapping each distribution to one or more potential content sources, a second table indicating routing information for various origin servers 104 (with or without reference to distribution), and a third table indicating routing information for various mid-tier POPs 114 (with or without reference to distribution). On receiving a request for uncached content, the edge server 112 may determine a specific distribution which includes the content (e.g., based on a URI of the requested content), and reference the first table to determine potential sources for the content (e.g., one or more origin servers 104 and/or one or more mid-tier POPs 114). The edge server 112 may then extract routing information for each potential content source from the second and third tables, and dynamically combine this routing information to create a routing table for the distribution. The edge server 112 can thereafter utilize the routing table to retrieve the uncached content from a preferred content source.

While shown as an ordered series of operations, various interactions of FIG. 3 may occur at various different times, or may occur simultaneously. Illustratively, the edge POP 112A may function to continuously update its routing information based on communications to the mid-tier POPs 114 and origin servers 104, such that the routing information is repeatedly revised during operation of the edge POP 112. Furthermore, where no exchange of information occurs between the edge POP 112A and an individual mid-tier POP 114 or origin server 104, the edge server 112A may generate routing information for that mid-tier POP 114 or origin server 104 based on estimated metrics, such as an estimated geographic distance between the edge POP 112A and the individual mid-tier POP 114 or origin server 104.

Further, while the interactions of FIG. 3 are shown as occurring at an edge POP 112, similar interactions may additionally or alternatively be carried out by mid-tier POPs 114. For example, each mid-tier POP 114 may actively or passively monitor a network connection with various origin servers 104 to determine network distances between the mid-tier POP 114 and the origin servers 104. In some instances, this information may be transmitted to the POP manager 116 for use in assigning mid-tier POPs 114 to various origin servers 104.

With reference to FIG. 4, a set of illustrative interactions are depicted for assigning a mid-tier POP 114 to a distribution of content associated with an origin server 104A, in accordance with aspects of the present disclosure. The interactions begin at (1), where an origin server 104A associated with a specific distribution of content, submits a request to utilize mid-tier POP caching on the CDN 110. While the request, in FIG. 4, is illustrative shown as originating from the origin server 104A, the request may be transmitted to the CDN 110 by any computing device associated with the distribution of content, such as a computing device (not shown in FIG. 4) of an administrator or operator of the origin server 104A. The request is illustratively routed, within the CDN 110, to the POP manager 116. At (2), the POP manager 116 assigns a mid-tier POP 114 to the distribution based at least partly on a proximity between the mid-tier POP 114 and the origin server 104A. In one embodiment, the POP manager 116 may utilize network distance information gathered by the mid-tier POPs 114A to determine a specific mid-tier POP 114 that is proximate to the origin server 104A. In another embodiment, the POP manager 116 estimates distances between the mid-tier POPs 114 and the origin server 104A (e.g., using network address geolocation techniques, which are known within the art, and utilize a database of information mapping network addresses to specific geographic locations) to determine a specific mid-tier POP 114 that is proximate to the origin server 104A. In some instances, the POP manager 116 may utilize additional or alternative criteria to assign a mid-tier POP 114 to the distribution. For example, the POP manager 116A may utilize capacity information of the various mid-tier POPs 114 (e.g., as monitored based on operation of the mid-tier POPs 114, inferred based on the number of origin servers 104 associated with each mid-tier POP 114, etc.) to determine a closest mid-tier POP 114A to the origin server 104A that has capacity to be assigned to the distribution provided by the origin server 104A. For the purposes of FIG. 4, it will be assumed that the POP manager 116 assigns mid-tier POP 114A to maintain a distribution associated with the origin server 104A.

At (3), the POP manager 116 notifies the origin server 104A of the assigned mid-tier POP 114A. For example, POP manager 116 may return a network identifier of the mid-tier POP 114A, such as an internet protocol (“IP”) address or uniform resource identifier (“URI”), to the origin server 104A. Thereafter, at (4), the origin server 104A and the assigned mid-tier POP 114A may communicate in order to synchronize content of a distribution associated with the origin server 104A. In one embodiment, this synchronization may occur independently from other operations of the origin server 104A, such that the origin server 104A provides the mid-tier POP 114A an initial set of content to be cached. In other embodiments, the synchronization may occur during normal operation of the origin server 104A and the mid-tier POP 114A (e.g., in response to cache misses occurring at the mid-tier POP 114A subsequent to assignment to the origin server 104A).

With reference to FIG. 5, an illustrative set of interactions are depicted for utilizing a mid-tier POP 114A to process cache misses at an edge POP 112A without requiring interaction with an origin server 104A associated with the uncached content. The interactions of FIG. 5 begin at (1), where a client computing device 102A transmits a request for content to the edge POP 112A. As noted above, various algorithms and mechanisms for distribution of request from client computing devices 102 to edge POPs 112 are known in the art, and thus will not be described in detail herein.

Thereafter, at (2), the edge POP 112 detects that the requested content is not cached at the edge POP 112A (e.g., that a cache miss has occurred). To determine a content source from which to request the uncached content, the edge POP 112, at (3), generates a content routing table. One example of such a content routing table is shown above, as TABLE 3. As discussed above, the content routing table may be dynamically generated utilizing routing information for maintained at the edge POP 112A for a plurality of origin servers, as well as routing information for a plurality of mid-tier POPs 114A. Accordingly, the content routing table may reflect a variety of potential content sources for the uncached information, as well as information enabling the edge POP 112A to determine which content source to request the content from (e.g., network distance information, capacity information, etc.).

At (4), the edge POP 112A selects a content source from the generated content routing table. In the interactions of FIG. 5, it will be assumed that the edge POP 112A has selected mid-tier POP 114A. However, selection of other content sources, including the origin server 104A serving as a primary source for the content, are possible.

Thereafter, at (5), the edge POP 112A transmits a request for the uncached content to the mid-tier POP 114A. The mid-tier POP 114A, in turn, retrieves the content from its own cache, and returns the content to the edge POP 112, at (6). The content can then be cached at the edge POP 112A, at (7), and returned to the client computing device 102A, at (8). Thus, even in the instance of a cache miss at an edge server 112A, the client computing device 102A can be provided with requested content without interaction with the origin server 104A, and at a higher speed than such content would likely be provided if interaction with the origin server 104A were to occur.

In some instances, the edge POP 112A may communicate with the POP manager 116 to exchange information regarding processing of cache misses. For example, the edge POP 112A may, at (9), notify the POP manager 116 of each cache miss (e.g., immediately after a cache miss, or periodically). The POP manager 116, in turn, may generate new routing information, such as new capacity information for a content source utilized to process the cache miss, and return that new routing information to the edge POP 112A, at (10). Illustratively, such communication may enable the edge POP 112A to maintain real time availability information for the various content sources (e.g., mid-tier POPs 114 and origin servers 104) to ensure such content sources are not overwhelmed with content requests.

One of skill in the art will appreciate that FIG. 5 may include various additional or alternative interactions than are described above. For example, it is assumed for the purposes of FIG. 5 that the mid-tier POP 114A contains a version of the content requested by the client computing device 102A. However, in instances where the mid-tier POP 114A does not contain the requested information, the mid-tier POP 114A may communicate with the origin server 104A to retrieve the requested information before returning such information to the edge POP 112A. Further, in instances where a content source (such as the mid-tier POP 114A) fails to timely respond to requests from the edge POP 112a (e.g., within a threshold period of time), the edge POP 112A may request the content from an alternative content source, such as the origin server 104A. Thus, the interactions of FIG. 5 are intended to be illustrative in nature.

With reference to FIG. 6, one illustrative routine 600 for routing of requests for uncached content at an edge POP, such as an edge POP 112 of FIG. 1, is described. The routine 600 begins at block 602, where the edge POP obtains routing information corresponding to the origin servers and mid-tier POPs associated with the CDN. In one embodiment, the routing information may be generated at the edge POP itself, based on active or passive monitoring of network paths between the edge POP and the respective origin servers and mid-tier POPs. In another embodiment, the routing information is received at least from other components of the CDN, such as a POP manager. Illustrative representations of the routing information are shown above as TABLES 1 and 2.

At block 604, the edge POP receives a request from a client computing device for content not cached or maintained at the edge POP. Illustratively, the request may correspond to a request for content that is not frequently requested at the edge POP, and that therefore has been evicted from (or has never existed within) a cache of the edge POP. Thus, in order to service the request, the edge POP may determine that the content should be retrieved from an external content source.

To determine a content source from which to request the uncached content, the edge POP, at block 606, generates a routing table for the content based on the obtained routing information for mid-tier POPs and origin sources. Specifically, the edge POP may determine at a set of potential content sources associated with the requested information (e.g., based on a URL or other identifier of the information provided by a request client computing device). The edge POP may further extract routing information from each potential content source from the obtained origin server and origin routing information. The edge POP can thereafter combine the routing information into a content source routing table. One example of such a routing table is shown above as TABLE 3.

Thereafter, at block 608, the edge POP determines a preferred content source utilizing the content source routing table. A preferred content source may be based on any individual metric within the content routing table, such as a network distance to each potential content source, or on a combination of metrics, such as a combination of network distance to each potential content source and current load on each potential content source. For example, the edge POP may be configured to utilize the nearest potential content source (e.g., in terms of network distance), so long as the load on that content source does not exceed a threshold amount.

At block 610, the edge POP can retrieve the content from the preferred content source (e.g., an origin server of the content or a mid-tier POP assigned to the origin server). While not shown in FIG. 6, if the preferred content source fails to return the content in a threshold period of time, the edge POP may attempt to retrieve the content from a less preferred content source (e.g., the 2nd preferred content source) until the content source is retrieved or potential content sources are exhausted (resulting in an error).

In the instance that the content is retrieved, the routine 600 proceeds to block 612, where the content is returned to the requesting computing device. While not shown in FIG. 6, the edge POP may further place the content within its local cache, such that subsequent requests for the content may be serviced from that local cache.

Thus, by utilization of the routine 600, an edge POP may selectively retrieve uncached content from either origin servers for the content or mid-tier POPs assigned to cache that content. In this manner, edge POPs may utilize mid-tier POPs as second-tier caches for content only when such use is expected to increase the performance of the CDN (e.g., by reducing the time required to provide content, reducing the load on origin servers, or both).

All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.

Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to present that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Disjunctive language such as the phrase “at least one of X, Y or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y or Z, or any combination thereof (e.g., X, Y and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as ‘a’ or ‘an’ should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

Any routine descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the routine. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, or executed out of order from that shown or discussed, including substantially synchronously or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

1. A content delivery system comprising: a client-facing point of presence (“POP”) comprising at least one computing device associated with a first non-transitory data store, the client-facing POP configured to receive requests for content associated with an origin server, and when the content is cached within the first non-transitory data store, return the content; andan origin-facing POP comprising at least one computing device associated with a second non-transitory data store, the origin-facing POP assigned to maintain the content associated with the origin server within the second non-transitory data store, the origin-facing POP configured to receive requests for the content associated with the origin server, and when the content is cached within the second non-transitory data store, return the content;wherein the client-facing POP is further configured to: obtain routing information identifying a network distance between the client-facing POP and the origin-facing POP and a network distance between the client-facing POP and the origin server;receive a request for content not cached within the first non-transitory data store of the client-facing POP;select either the origin-facing POP or the origin server as a content source for the requested content that is not cached within the first non-transitory data store of the client-facing POP, wherein either the origin-facing POP or the origin server is selected as the content source based at least in part on a comparison of the network distance between the client-facing POP and the origin-facing POP and the network distance between the client-facing POP and the origin server;retrieve the requested content from the content source; andreturn the requested content in response to the request.

2. The content delivery system of claim 1, wherein the origin-facing POP is further configured, when requested content is not cached within the second non-transitory data store, to retrieve the requested content from the origin server.

3. The content delivery system of claim 1 further comprising a POP manager including one or more computing devices configured with computer-executable instructions to assign the origin-facing POP to maintain the content associated with the origin server based at least in part on a network distance between the origin-facing POP and the origin server.

4. The content delivery system of claim 1, wherein the client-facing POP is configured to obtain the routing information at least partly by monitoring communications between the client-facing POP and the origin-facing POP.

5. The content delivery system of claim 1, wherein the client-facing POP is configured to obtain the routing information at least partly by transmitting a network probe to the origin-facing POP.

6. The content delivery system of claim 1, wherein the routing information comprises a first set of routing information identifying network distances between the client-facing POP and a plurality of origin-facing POPs on the content delivery system and a second set of routing information identifying network distances between the client-facing POP and a plurality of origin servers.

7. The content delivery system of claim 1, wherein the client-facing POP is configured to generate a routing table for the requested content at least partly by combining the first and second sets of routing information, and wherein the comparison of the network distance between the client-facing POP and the origin-facing POP and a network distance between the client-facing POP and the origin server is conducted by selecting a lowest network distance identified within the routing table.

8. A computer-implemented method comprising: at a client-facing point of presence (“POP”) within a content delivery network: obtaining a request for content associated with an origin server;determining that the content is not maintained at the client-facing POP;obtaining first routing information identifying a network distance between the client-facing POP and the origin server;obtaining second routing information identifying a network distance between the client-facing POP and an origin-facing POP on the content delivery network associated with the origin server;selecting either the origin-facing POP or the origin server as a content source for the requested content that is not maintained at the client-facing POP based at least in part on a comparison of the network distance between the client-facing POP and the origin server, as identified in the first routing information, and a network distance between the client-facing POP and the origin-facing POP, as identified in the second routing information;retrieving the requested content from the content source; andreturning the requested content in response to the request.

9. The computer-implemented method of claim 8 further comprising: receiving a request from a user associated with the origin server to utilize a secondary POP on the content delivery network; andselecting the origin-facing POP as the secondary POP based at least in part on a network distance between the origin-facing POP and the origin server.

10. The computer-implemented method of claim 8, wherein the origin-facing POP is one of a plurality of origin-facing POPs associated with the origin server, and wherein the second routing information identifies a network distance between the client-facing POP and individual origin-facing POPs of the plurality of origin-facing POPs.

11. The computer-implemented method of claim 8, wherein the first routing information further indicates a capacity of the origin server, and wherein selecting either the secondary POP or the origin server as a preferred content source for the requested content is further based at least in part on the capacity of the origin server.

12. The computer-implemented method of claim 8, wherein selecting either the origin-facing POP or the origin server as a preferred content source for the requested content comprises combining at least a portion of the first and second routing information to form a routing table for the requested content, and wherein the preferred content source is selected based at least partly on the routing table.

13. The computer-implemented method of claim 8, wherein the content source corresponds to the origin-facing POP, and wherein the method further comprises: determining that the requested content is not available at the origin-facing POP;retrieving, at the origin-facing POP, the requested content from the origin server; andreturning the requested content from the origin-facing POP to the client-facing POP.

14. A client-facing point of presence (“POP”) associated with a content delivery network, the client-facing POP comprising: a non-transitory data store implementing a cache of content, wherein the content is associated with an origin server that acts as an primary source for the content; andone or more computing devices in communication with the non-transitory data store, the one or more computing devices configured with computer-executable instructions that, when executed, cause the one or more computing devices to: receive a request for content that is not included within the cache;obtain routing information identifying a network distance between the client-facing POP and the origin server and a network distance between the client-facing POP and an origin-facing POP associated with the origin server;select either the origin-facing POP or the origin server as a content source for the requested content that is not included within the cache of the client-facing POP based at least in part on the network distance between the client-facing POP and the origin server and the network distance between the client-facing POP and the origin-facing POP;retrieve the requested content from the content source; andreturn the requested content in response to the request.

15. The system of claim 14 further comprising a POP manager including one or more computing devices configured with specific computer-executable instructions to: receive a request from a user associated with the origin server to utilize a secondary POP on the content delivery network; andselect the origin-facing POP as the secondary POP based at least in part on a network distance between the origin-facing POP and the origin server.

16. The system of claim 15, wherein the network distance between the origin-facing POP and the origin server is estimated based at least in part on a geographic distance between the origin-facing POP and the origin server.

17. The system of claim 16, wherein the geographic distance between the origin-facing POP and the origin server is determined based at least in part on network address geolocation techniques.

18. The system of claim 15, wherein the network distance between the origin-facing POP and the origin server is estimated based at least in part on monitoring between communications between the origin-facing POP and at least one of the origin server or an additional computing device associated with the origin server.

19. The system of claim 14, wherein the obtained routing information comprises a first set of routing information identifying the network distance between the client-facing POP and the origin server and a second set of routing information identifying the network distance between the client-facing POP and the origin-facing POP.

20. The system of claim 19, wherein the computer-executable instructions cause the one or more computing devices to select either the origin-facing POP or the origin server as the content source for the requested content at least partly by combining the first and second sets of routing information.