Local preference in anycast cdn routing

Abstract

This disclosure relates to local preference in anycast CDN routing. Embodiments herein describe a CDN in which anycast routing is used to identify a load balancer for selecting a cache in the CDN for delivering an object requested by a user. In one embodiment, a user performs a DNS lookup to identify an anycast IP address of a plurality of load balancers in the CDN. The user can then initiate anycast routing using the anycast IP address to automatically identify the closest load balancer. Once a cache is selected by the identified balancer, the load balancer can close the anycast connection with the user device and use HTTP redirection to provide the user device with a unicast path to the selected cache. The user device can then establish a unicast connection with the cache to retrieve (e.g., stream) the object.

Description

Technical Field

[0001] This disclosure relates to local preferences in anycast CDN routing. Background Technology

[0002] Content Delivery Networks (CDNs) are large, geographically distributed caching networks. These caches deliver videos and other web content (often referred to as "objects") to viewers. Choosing the best cache to deliver objects to users is a challenging task. Most CDNs typically use two techniques to identify the best cache for delivering objects. First, Domain Name System (DNS) load balancing can be used to select the best cache. Once the DNS server has selected the best cache, the CDN uses the IP address of the cache (or cache cluster) to respond to the user's DNS queries. However, DNS load balancing presents several challenges. First, CDN DNS servers typically do not see the actual client IP address (used for geolocation / mapping). Instead, the DNS server sees the IP address of the resolver of the Internet Service Provider (ISP) used by the user (or worse, the public DNS resolver based on the cloud). Without the accurate client IP address, cache localization becomes much more difficult. Furthermore, DNS lookups do not contain information about the requested content. Therefore, CDNs cannot use asset-level load balancing strategies during cache localization. For example, asset-level strategies could allow targeting specific caches or clusters where the content is already known to be cached. Finally, even with a very low Time-to-Live (TTL), a certain amount of response is cached by the load balancer. This may work well under high load, but ultimately it reduces the DNS server's ability to identify the user's location.

[0003] The second strategy for selecting the cache closest to the user is anycast routing. Anycast allows many hosts to advertise the same IP address. At each hop, a Layer 3 switch or router determines the lowest-cost path for packets. This directs the client to the nearest logical CDN cache. However, due to the risk of connection resets, routing changes can cause connection interruptions if data packets are delivered to different hosts. Anycast is traditionally used for User Datagram Protocol (UDP) or very short Transmission Control Protocol (TCP) connections. Summary of the Invention

[0004] According to one embodiment of this disclosure, a method is provided, comprising: establishing an anycast connection between a load balancer associated with a content delivery network (CDN) and a user device requesting an object from the CDN; at the load balancer, selecting a first cache from a plurality of caches in the CDN based on one or more load balancing criteria to satisfy the request for the object; and transmitting an HTTP redirect from the load balancer to the user device to close the anycast connection, wherein the HTTP redirect includes information for establishing a unicast connection between the user device and the first cache to retrieve the object from the first cache.

[0005] According to one embodiment of this disclosure, a non-transitory computer-readable medium is provided, including computer program code that, when executed by one or more computer processors, performs the following operations: establishing an anycast connection between a load balancer associated with a CDN and a user device requesting an object from the CDN; at the load balancer, selecting a first cache from a plurality of caches in the CDN based on one or more load balancing criteria to satisfy the request for the object; and transmitting an HTTP redirect from the load balancer to the user device to close the anycast connection, wherein the HTTP redirect includes information for establishing a unicast connection between the user device and the first cache to retrieve the object from the first cache.

[0006] According to one embodiment of this disclosure, a server is provided, comprising: a processor; and a memory storing computer program code, which, when executed by the processor, performs the following operations: establishing an anycast connection between the server and a user device requesting an object from a CDN; selecting a first cache from a plurality of caches in the CDN based on one or more load balancing criteria to satisfy the request for the object; and transmitting an HTTP redirect to the user device to close the anycast connection, wherein the HTTP redirect includes information for establishing a unicast connection between the user device and the first cache to obtain the object from the first cache. Attached Figure Description

[0007] To achieve the above aspects and to gain a detailed understanding, the embodiments described herein (briefly summarized above) can be described in more detail with reference to the accompanying drawings.

[0008] However, it should be noted that the accompanying drawings illustrate typical embodiments and should not be considered limiting; other equally effective embodiments are conceivable.

[0009] Figure 1 This is a block diagram of a communication system according to one embodiment.

[0010] Figure 2 This is a timing diagram for retrieving objects from a CDN according to one embodiment.

[0011] Figure 3 This is a flowchart illustrating the use of anycast routing to identify a load balancer according to one embodiment.

[0012] Figure 4 A CDN with geographically distributed load balancers and caches is illustrated according to one embodiment.

[0013] Figure 5 The diagram illustrates a load balancer according to one embodiment using HTTP redirection to provide a unicast path to a CDN cache to a user device. Detailed Implementation

[0014] This document describes an embodiment of a CDN in which anycast routing is used to identify load balancers (also known as traffic routers) that select caches within the CDN to deliver objects to users. In one embodiment, a user performs a DNS lookup to identify the anycast IP addresses of multiple load balancers within the CDN. The user can then initiate anycast routing using the anycast IP address to automatically identify the nearest logical load balancer among the multiple load balancers sharing that anycast IP address. Advantageously, the load balancer will see the user's device's IP address along with the complete path to the object (e.g., a movie, TV show, live performance, etc.). This differs from many types of DNS lookups where the actual user IP is hidden behind the resolver making the DNS request, and the DNS lookup does not indicate the requested object. Using this information, the load balancer can determine the precise location of the user's device and select the optimal CDN cache using one or more load balancing criteria.

[0015] Once a cache is selected, the load balancer can close anycast connections to the user device and use HTTP redirection (e.g., HTTP response status code 302) to provide the user device with a unicast path to the selected cache. The user device can then establish a unicast connection with the cache to retrieve the object. Advantageously, anycast connections to the load balancer are often very short (e.g., 100-300 milliseconds), which mitigates the possibility of network interference (e.g., line drops, disconnected routers, etc.) changing the anycast route to a different load balancer. Once load balancing is complete, the user device uses the unicast path provided by the HTTP redirection to retrieve the cache, which is typically a longer connection (e.g., 5-8 seconds to transmit a segment) and is less susceptible to potential network interference caused by anycast routing. In this way, the embodiments described herein offer the following benefits: the anycast route is used to automatically identify the nearest load balancer, providing more accurate information than a DNS lookup, while retrieving objects from the CDN cache using a unicast connection avoids the sensitivity to network interference associated with using anycast connections.

[0016] Figure 1 This is a block diagram of a communication system 100 according to one embodiment. System 100 includes user equipment 105, DNS server 130, network 150 (e.g., a public network such as the Internet), edge server 155, CDN 170, and streaming server 190. User equipment 105 can be any device capable of retrieving object 185 from cache 180 in CDN 170. In this embodiment, user equipment 105 includes a display 125, so it can display (e.g., output) media presentations from CDN 170, such as smartphones, tablets, laptops, smart TVs, etc. However, in other embodiments, user equipment 105 may not include a display and may be a streaming player or media player coupled to an output device (e.g., a television).

[0017] In any case, user equipment 105 includes a processor 110 and memory 115. Processor 110 represents any number of processor elements that may include any number of processing cores. Typically, processor 110 fetches and executes programming instructions stored in memory 115. Memory 115 may include volatile memory elements, non-volatile memory elements, and combinations thereof. Specifically, memory 115 includes a streaming application 120 (e.g., a software application) capable of selecting objects 185 to be retrieved from CDN 170. For example, streaming application 120 may output a graphical user interface (using display 125 or a separate electronic device, such as a television) listing multiple different media presentations, such as movies, live events, television episodes, etc. The user can then use the interface to select a specific media presentation to watch on user equipment 105 or a connected output device.

[0018] In response to a user's selection of a media presentation, user device 105 may transmit a request to streaming server 190 for a Uniform Resource Location (URL) corresponding to the media presentation. Streaming server 190 may store a different object URL 195 for each object (e.g., a media presentation) stored in CDN 170. The object URL 195 may include the name of the media presentation, such as http: / / ...AdventureShowEpisode1Season2... In this way, URL 195 in streaming server 190 provides a URL for accessing the media presentation (or other object) requested by the user.

[0019] User equipment 105 can then perform a DNS lookup using object URL 195. The DNS lookup translates object URL 195 into an IP address, which can be used within network 150 to identify the location for retrieving (or streaming) the requested media presentation. In this case, system 100 includes multiple DNS servers 130, but in other embodiments, it may include only one DNS server. User equipment 105 can use unicast routing or anycast routing to identify DNS server 130 for performing a DNS lookup. The advantage of using anycast routing is that it can automatically identify the DNS server 130 with the shortest path to user equipment 105 via network 150, potentially reducing the time spent performing DNS lookups. However, embodiments herein may also use unicast routing to perform DNS lookups.

[0020] DNS server 130 provides an IP address to user equipment 105 in response to a DNS lookup. However, in some embodiments, DNS server 130 provides an anycast IP address to edge server 155 instead of providing the IP address of cache 180 used by the user equipment to retrieve objects. Or more specifically, DNS server 130 provides an anycast IP address to reach load balancer 160 (e.g., a software application) hosted on edge server 155. In one embodiment, each edge server 155 has the same anycast IP address. Therefore, when DNS server 130 provides an anycast IP address to user equipment 105, anycast routing using that address automatically identifies the edge server 155 and load balancer 160 with the shortest path to user equipment 105. That is, anycast routing uses a lower-layer routing protocol (e.g., Border Gateway Protocol (BGP)) to identify the shortest path to one of the multiple network devices (e.g., edge server 155) with the same anycast IP address.

[0021] Then, the load balancer 160 in the edge server 155 identified via anycast routing can use one or more load balancing criteria to determine which cache 180 is best suited for delivering the requested media rendering (e.g., object 185). The embodiments described herein are not limited to any particular load balancing criterion. Non-limiting examples include: using a cache 180 located in the same (or closest to) the identified edge server 155; ensuring that the load on any particular cache 180 does not exceed a threshold; ensuring that a minimum number of requests are sent to each cache 180; routing requests away from caches that will soon be shut down for maintenance, etc.

[0022] Using a load balancer 160 in edge server 155 (instead of DNS server 130) to select cache 180 has several advantages. One advantage is that TCP communication between user device 105 and load balancer 160 contains more information than DNS lookups between user device 105 and load balancer 160. For example, communication to load balancer 160 can include the full path to the requested object 185, which a DNS lookup does not contain. Therefore, load balancer 160 knows what object 185 the user is requesting and can select cache 180 accordingly, while this information is hidden from the DNS server. For example, some caches 180 in CDN 170 may have the requested object, while others may not.

[0023] Furthermore, HTTP communication from user device 105 to load balancer 160 can include the real IP address of user device 105, while DNS lookups can include the IP address of the resolver (which may be geographically located either near or outside user device 105). Therefore, any geolocation function performed by load balancer 160 when selecting cache 180 can be more accurate than the geolocation function performed by DNS server 130.

[0024] As described above, communication between User Equipment 105 and Load Balancer 160 can be an anycast connection that automatically identifies the Load Balancer 160 closest to User Equipment 105. As mentioned above, anycast connections are susceptible to network interference, which can alter the connection. For example, the shortest path may change from, for example, Load Balancer 160A to Load Balancer 160B due to a power outage or router shutdown for maintenance. Since Load Balancer 160B will not have any information already provided by User Equipment 105 to Load Balancer 160A, this process will have to be repeated or reset. However, communication between Load Balancer 160 and User Equipment 105 is typically very short (e.g., 200-300 milliseconds), where the devices exchange a single HTTP request / response pair, which may include a TCP handshake, TLK handshake (optional), and the HTTP request / response itself. Load Balancer 160 and User Equipment can exchange 5-10 TCP segments. Therefore, the risk of network interference during anycast connections between User Equipment 105 and Load Balancer 160 is minimal.

[0025] Once load balancer 160 selects cache 180 for user device 105 to retrieve or stream a requested object 185 (e.g., requested media rendering), load balancer 160 may send an HTTP redirect (e.g., an HTTP response with status code 302) to user device 105, redirecting user device 105 to the selected cache 180. In other words, load balancer 160 closes anycast connections and redirects user device 105 to cache 180. The HTTP redirect may include a unicast path to the selected cache 180, allowing user device 105 to establish a unicast connection to cache 180 in response to the HTTP redirect. While an HTTP redirect using the 302 status code has been described, the embodiment is not limited thereto, and any current or future HTTP redirection mechanism, such as the 301 status code or Alt-SVC, may be used.

[0026] Because the connection between user device 105 and cache 180 is typically much longer than the connection between user device 105 and load balancer 160 in order to retrieve object 185, using a unicast connection between user device 105 and cache 180 avoids the sensitivity of anycast connections. That is, if network interference occurs along the unicast path between user device 105 and cache 180, user device 105 will still connect to the same cache 180, even if a different route or path is used through network 150. Therefore, using an anycast connection between user device 105 and load balancer 160 allows system 100 to automatically identify the load balancer 160 closest to user device 105 more accurately than relying on DNS server 130 for geolocation. Furthermore, using HTTP redirection to close or terminate the anycast connection with load balancer 160 and establish a unicast connection to the selected cache 180 avoids the risks of using long anycast connections to retrieve or stream object 185.

[0027] Although Figure 1 The example shown shows only cache 180 in CDN 170, but in other embodiments, DNS server 130, edge server 155, and load balancer 160 can be considered as part of CDN 170.

[0028] In addition, streaming server 190, DNS server 130, edge server 155 and cache 180 may include one or more processors, memory, software applications, input / output interfaces, etc., to perform the functions described herein.

[0029] Figure 2 This is a timing diagram 200 for retrieving objects from a CDN according to one embodiment. Timing diagram 200 illustrates various communications between user device 105 and streaming server 190, DNS server 130, load balancer 160, and cache 180 in the CDN. Arrow 205 indicates that user device 105 selects an object to retrieve or stream from the CDN. This selection is relayed to streaming server 190. The user selection may be referred to as a service invocation to streaming server 190. In response, arrow 210 indicates that streaming server 190 provides a URL (e.g., ...) to the requested object. Figure 1 The URL of the object in the URL (195) can include the name, description, or ID of the requested object.

[0030] To identify the IP address corresponding to the object URL, arrow 215 indicates that user equipment 105 performs a DNS lookup using DNS server 130. User equipment 105 can use either a unicast connection or an anycast connection to select one of the multiple DNS servers 130 associated with the CDN. For example, user equipment 105 may already know which DNS server to use for the DNS lookup, in which case user equipment 105 can use a unicast connection. Conversely, user equipment 105 can use an anycast connection so that the underlying network protocol automatically identifies the DNS server 130 with the shortest path to user equipment 105. The embodiments described herein are not limited to either case.

[0031] In this example, as indicated by arrow 220, DNS server 130 provides user device 105 with an anycast address to reach one of the load balancers 160 used by the CDN, rather than providing the user device with an IP address to cache 180 to retrieve the object. In one embodiment, each load balancer 160 in the CDN corresponds to the same anycast IP address. DNS server 130 can be configured to respond to any DNS lookup for content in the CDN by providing user device 105 with an anycast IP address for the load balancer 160.

[0032] Arrow 225 indicates that user equipment 105 uses anycast IP addresses to perform anycast routing to automatically identify load balancer 160 (and edge servers) with the shortest path to user equipment 105. In other words, anycast routing uses a lower-level routing protocol (e.g., BGP) in the network to identify load balancer 160 among multiple load balancers in the network with the shortest path to user equipment 105.

[0033] Then, load balancer 160 can use one or more load balancing criteria to select cache 180 from multiple caches in the CDN. Unlike DNS lookups, when an anycast connection is established, the load balancer can receive the full path to the requested object and the user's real IP address. Therefore, this information enables load balancer 160 to execute a wider variety of load balancing strategies and to perform more precise geolocation of user device 105 compared to if the DNS server were assigned the task of selecting a cache.

[0034] Arrow 230 illustrates load balancer 160 sending an HTTP redirect to user device 105 to redirect user device 105 to a selected cache 180. In one embodiment, the HTTP redirect closes or terminates the anycast connection between user device 105 and load balancer 160. Furthermore, the HTTP redirect provides information to enable user device 105 to establish a unicast connection with cache 180, as shown by arrow 235.

[0035] Arrow 240 illustrates that cache 180 uses a unicast connection to send the requested object to device 105. Because the connection between user device 105 and cache 180 is typically much longer to retrieve the object than the connection between user device 105 and load balancer 160, using a unicast connection between user device 105 and cache 180 avoids the sensitivity of anycast connections to network interference. That is, if network interference occurs along the unicast path between user device 105 and cache 180, user device 105 will still be connected to the same cache 180. Using HTTP redirection to close or terminate the anycast connection with load balancer 160 and establish a unicast connection to the selected cache 180 avoids the risk of using long anycast connections to retrieve or stream the requested object.

[0036] Sequence diagram 200 can be used to initialize the connection between user equipment 105 and cache 180 to retrieve or stream objects. While sequence diagram 200 illustrates the initialization of an initial request for streaming an object, it can also be used to initialize an already started stream that has been interrupted for any reason. For example, suppose user equipment 105 has performed all the tasks shown in sequence diagram 200 to begin streaming an object from cache 180. However, user equipment 105 may be a smartphone switching from using a cellular network to using a Wi-Fi network for streaming. This switch may cause user equipment 105 to need to reinitialize the stream. User equipment 105 can then repeat the tasks indicated by arrows 225-240 to reinitialize the stream. The tasks indicated by arrows 205 and 220 do not need to be repeated because user equipment 105 already knows the IP address of the object (i.e., the anycast IP address of load balancer 160). Nevertheless, load balancing can be repeated to determine whether another cache 180 is more suitable for streaming objects, taking into account that the user equipment is now using a different network. Alternatively, the previous cache 180 may fail or stop due to maintenance, resulting in reinitialization. In either case, user equipment 105 can re-establish an anycast connection with load balancer 160 (or a different load balancer 160) to identify the optimal cache 180 for restarting the object's stream. Therefore, the embodiments described herein can be used in both cases: initializing the stream when the object is first requested, and initializing the stream when a previous stream has been interrupted.

[0037] Figure 3 This is a flowchart of a method 300 for identifying a load balancer using anycast routing according to one embodiment. Method 300 may begin in response to a user selecting an object to retrieve or stream from a CDN. In block 305, the user equipment performs a DNS lookup to receive the anycast IP addresses of multiple load balancers. That is, the load balancers share the same anycast IP address.

[0038] Box 305 can correspond to Figure 2 Arrow 215 indicates that the user equipment can use either a unicast connection or an anycast connection to select one of the multiple DNS servers 130 associated with the CDN. For example, the user equipment can use a pre-selected DNS server to perform a DNS lookup using a unicast connection. Conversely, the user equipment can use an anycast connection to identify the DNS server with the shortest path to the user equipment.

[0039] In box 310, the user equipment performs anycast routing to establish an anycast connection to one of the multiple load balancers corresponding to the CDN. That is, the user equipment can use the anycast IP address provided by the DNS server to perform anycast routing to identify the load balancer with the shortest path to the user equipment. The user equipment can use the anycast connection to provide the load balancer with the full pathname of the object. Furthermore, if needed, the load balancer can receive the user equipment's real IP address, allowing the balancer to perform geolocation services.

[0040] In box 315, the load balancer determines or selects a cache from multiple caches for fetching objects from the CDN based on load balancing criteria. Non-limiting examples of load balancing criteria include: using a cache co-located with (or closest to) the load balancer to fulfill requests; ensuring that the load on any particular cache does not exceed a threshold; ensuring that a minimum number of requests are sent to each cache; routing requests away from caches that will soon be shut down for maintenance, and so on. In another example, the load balancer may use the object's pathname to determine which CDN caches have the object stored in their memory. However, the embodiments described herein are not limited to any particular load balancing technique.

[0041] In one embodiment, a load balancer can use non-standard signaling to instruct multiple caches for user devices to attempt connections to acquire objects. These caches can be ordered, weighted, or have other specific retry policies specified. Therefore, the load balancer can determine or select several caches from a pool of caches.

[0042] In box 320, the load balancer initiates an HTTP redirect to close the anycast connection and provide the user device with a cached unicast path. For example... Figure 2 As indicated by arrow 230, the load balancer can send an HTTP redirect to the user device to redirect it to the cache identified at box 315. In one embodiment, the HTTP redirect closes or terminates the anycast connection between the user device and the load balancer. Furthermore, the HTTP redirect provides information (e.g., a unicast path) to enable the user device to establish a unicast connection with the cache.

[0043] In box 325, the user equipment establishes a unicast connection with the cache to retrieve the object. In some embodiments, a much longer unicast connection is established between the user equipment and the CDN cache than the anycast connection between the user equipment and the load balancer in box 310. For example, while an anycast connection can last 100-300 milliseconds when the user equipment is streaming content, a unicast connection can last for several seconds or even longer. Therefore, using a unicast connection to stream objects from the cache avoids the sensitivity of anycast connections to network interference that could cause the shortest path to switch to a different cache that forces the connection to be reinitialized.

[0044] Figure 4 A CDN with geographically distributed load balancers and caches is illustrated according to one embodiment. In this example, the CDN is distributed across geographical regions 400, including regions A, B, and C. Each geographical region includes one or more load balancers (LBs) 160 and caches 180. For example, each region may have different data centers operated by the CDN in different cities, states, countries, continents, etc. The LBs 160 and caches 180 may operate in these data centers. Regions with high population density or high demand may have multiple data centers and multiple LBs 160 and caches 180. In this example, the LBs 160 and caches 180 reside together in a specific region (e.g., hosted by the same data center).

[0045] Figure 4 It also shows user equipment 105 that has used anycast routing to establish an anycast connection 405 with LB 160B in area B. That is, Figure 4 The following time point is shown, at which user equipment 105 has selected the object to be retrieved from the CDN and has received the anycast IP address by performing a DNS lookup (e.g., Figure 2 Arrows 205-220 and Figure 3 (Box 305). As shown in the figure. Figure 4 All LB 160s have the same anycast IP address, namely anycast address A. Therefore, when anycast routing is performed using anycast address A, the network automatically identifies LB160B as having the shortest path to user equipment 105 over the network. For example, user equipment 105 could also be located in area B. In this way, user equipment 105 establishes an anycast connection 405 with LB 160B.

[0046] In this example, LB 160B selects cache 180B as the best cache for user equipment 105 to retrieve or stream the requested object. For example, LB 160B may default to selecting cache 180B, which is co-located with it, as the best cache for user equipment 105 because cache 180B is also in the same region as user equipment 105. In response, LB 160B may send an HTTP redirect (not shown) to user equipment 105, which terminates anycast connection 405 and establishes a unicast connection 410A with cache 180B. User equipment 105 can then use unicast connection 410A to retrieve the object from cache 180B.

[0047] Figure 4 An alternative embodiment is also shown, in which LB 160B can alternatively select cache 180C in region C as the best cache for user equipment 105. Even if the user equipment is in region B, cache 180C may be the best cache for several reasons, such as cache 180B being shut down for maintenance, currently overloaded, or not having the requested object. Therefore, LB 160B can alternatively send an HTTP redirect that establishes a unicast connection 410B with cache 180C.

[0048] In another example, LB 160B may initially select cache 180B as the best cache for streaming objects, but can subsequently change and select cache 180C as a better choice. For example, during the streaming of an object from cache 180B, cache 180B may experience an error or failure that interrupts the unicast connection 410A. This can be repeated by user device 105 establishing an anycast connection 405 with LB 160B. LB 160B may have been notified or detected of an error in cache 180B and instead selected cache 180C as the new cache. LB 160B can provide an HTTP redirect that allows user device 105 to establish a unicast connection 410B with cache 180C and resume the streaming. Advantageously, user device 105 can resume the streaming using cache 180C at the point where the streaming was interrupted while using cache 180B (assuming both caches 180B and 180C have copies of the requested object).

[0049] Figure 5A load balancer 160 according to one embodiment is illustrated using an HTTP redirect to provide a unicast path to a CDN cache to a user device. As shown, user device 105 can send an HTTP fetch request 505 to perform anycast routing using an anycast IP address corresponding to load balancer 160. After selecting the best cache (e.g., cache 180) for the user device to fetch the object, load balancer 160 can respond to fetch request 505 with an HTTP redirect 510. As described above, HTTP redirect 510 can close the anycast connection and provide information to user device 105 to establish a unicast connection with cache 180. As shown, HTTP redirect 510 includes a URL that includes the unicast path to cache 180, i.e., http: / / <cache unicast> / path.

[0050] In response to HTTP redirection 510, user equipment 105 sends an HTTP retrieval request 515 to the cache to establish a unicast connection. User equipment 105 can then use this connection to retrieve the requested object from cache 180.

[0051] Various embodiments are mentioned in this disclosure. However, it should be understood that this disclosure is not limited to the specifically described embodiments. Rather, any combination of the following features and elements, whether or not they relate to different embodiments, is contemplated for implementing and practicing the teachings provided herein. Furthermore, when elements of an embodiment are described in the form of "at least one of A and B," it should be understood that embodiments including only element A, only element B, and including both elements A and B are contemplated. Moreover, while some embodiments may achieve advantages over other possible solutions or over the prior art, this disclosure is not limited regardless of whether a given embodiment achieves a particular advantage. Therefore, the aspects, features, embodiments, and advantages disclosed herein are illustrative only and should not be considered elements or limitations of the appended claims unless expressly recited in one or more claims. Similarly, references to "the invention" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered elements or limitations of the appended claims unless expressly recited in one or more claims.

[0052] As those skilled in the art will understand, the embodiments described herein can be implemented as a system, method, or computer program product. Therefore, embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which are generally referred to herein as “circuit,” “module,” or “system.” Furthermore, the embodiments described herein may take the form of a computer program product embodied in one or more computer-readable media, on which computer-readable program code is embodied.

[0053] Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, fiber optic, radio frequency (RF), or any suitable combination thereof.

[0054] Computer program code used to perform the operations of embodiments of this disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., via the Internet through an Internet service provider).

[0055] This document describes aspects of the disclosure with reference to flowchart illustrations or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It should be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of the flowchart illustrations or block diagrams.

[0056] These computer program instructions may also be stored in a computer-readable medium that may instruct a computer, other programmable data processing apparatus or other device to function in a particular manner such that the instructions stored in the computer-readable medium produce an article of writing including instructions that implement the functions / actions specified in one or more boxes in a flowchart or block diagram.

[0057] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus or other apparatus to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable data processing apparatus or other apparatus, provide for implementing the process specified in one or more boxes in a flowchart or block diagram.

[0058] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, including one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a non-sequential order as shown in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order or out of order. It should also be noted that each block in the block diagram or flowchart, and combinations of blocks in the block diagram or flowchart, may be implemented by a system based on dedicated hardware or a combination of dedicated hardware and computer instructions that performs the specified functions or actions.

[0059] While the foregoing describes embodiments of this disclosure, other and further embodiments of this disclosure may be devised without departing from the basic scope of this disclosure, the scope of which is defined by the appended claims.

Claims

1. A method for identifying caches using anycast routing, comprising: An anycast connection is established between a load balancer associated with a content delivery network (CDN) and a user device requesting an object from the CDN, wherein the anycast connection is established using an anycast address identified via a lookup. During the anycast connection, the full pathname of the object and the Internet Protocol (IP) address of the user equipment are received from the user equipment at the load balancer, and the full pathname of the object and the IP address of the user equipment are not transmitted via the lookup; At the load balancer, a first cache is selected from multiple caches in the CDN based on one or more load balancing criteria to satisfy the request for the object, including selecting the first cache closest to the load balancer from the multiple caches; and An HTTP redirect is transmitted from the load balancer to the user equipment to close the anycast connection, wherein the HTTP redirect includes information for establishing a unicast connection between the user equipment and the first cache to retrieve the object from the first cache.

2. The method according to claim 1, wherein, The load balancer is one of a plurality of load balancers associated with the CDN, each of the plurality of load balancers having the anycast address.

3. The method according to claim 2, wherein, The plurality of load balancers and the plurality of caches are distributed in different geographical regions, wherein, for each geographical region, at least one load balancer and at least one cache are located in that geographical region.

4. The method according to claim 2, wherein, The lookup includes a Domain Name System (DNS) lookup.

5. The method according to claim 2, wherein, The load balancer has the shortest path from the network to the user equipment among all the plurality of load balancers.

6. The method according to claim 5, wherein, The anycast connection relies on the lower-level routing protocol in the network to identify the shortest path.

7. The method according to claim 1, wherein, The HTTP redirection includes HTTP response status code 302.

8. The method according to claim 1, further comprising: At the first buffer, the object is transmitted to the user equipment using the unicast connection instead of the anycast connection to avoid the sensitivity of the anycast connection to network interference.

9. A non-transitory computer-readable medium comprising computer program code, which, when executed by one or more computer processors, performs the method according to any one of claims 1 to 8.

10. A server, comprising: processor; A memory storing computer program code, which, when executed by the processor, performs the method according to any one of claims 1 to 8.

Images