Local preferences in anycast CDN routing

Abstract

This provides a method for identifying a load balancer to select a cache within a Content Delivery Network (CDN) to use to deliver requested objects to a user. [Solution] The method involves the user device performing a DNS lookup to identify anycast IP addresses of multiple load balancers in the CDN, initiating anycast routing using the anycast IP address, and automatically identifying the nearest load balancer. Once the identified load balancer selects a cache, it closes the anycast connection with the user device and uses an HTTP redirect to provide the user device with a unicast route to the selected cache. The user device then establishes a unicast connection with the cache to retrieve an object (e.g., stream).

Description

background

[0001] A Content Distribution / Delivery Network (CDN) is a large network of geographically distributed caches. These caches deliver video and other web content (commonly referred to as "objects") to viewers. Choosing the best cache to use to deliver an object to a user is a complex task. Most CDNs typically use two methods to determine the best cache to use for delivering an object. First, they can use Domain Name System (DNS) load balancing to select the best cache. Once the DNS server selects the best cache, the CDN uses the IP address of the cache (or cache cluster) to respond to DNS lookups from users. However, DNS load balancing presents several challenges. First, the true client IP address (used for geolocation / mapping) is often not visible to the CDN's DNS servers. Instead, the DNS server recognizes the IP address of the Internet Service Provider (ISP) resolver (or, worse, a cloud-based public DNS resolver) used by the user. Without the true client IP address, cache localization becomes more difficult. Furthermore, DNS lookups do not contain information about the requested content. Therefore, CDNs cannot use asset-level load balancing policies during cache localization. For example, asset-level policies can target specific caches or clusters where the content is known to already be cached. Finally, load balancer responses are cached to some extent, even with very short time-to-live (TTL). This is effective at high loads, but ultimately reduces the DNS server's ability to determine the user's location.

[0002] The second strategy used to select the cache closest to the user is Anycast routing. In Anycast, multiple hosts can advertise the same IP address. A Layer 3 switch or router determines the minimum cost path for a packet at each hop. This localizes the client to the nearest logical CDN cache. However, due to routing changes, if a packet is delivered to a different host, there is a risk that the connection will be reset, potentially interrupting the connection. Anycast has traditionally been used for User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) connections for live streaming. **Brief Description of the Drawings**

[0003] To achieve and understand the above aspects in detail, a more specific description of the embodiments described herein, briefly summarized above, can be provided by referring to the accompanying drawings.

[0004] However, it should be noted that the accompanying drawings illustrate typical embodiments and should not be considered limiting. Other equally valid embodiments are conceivable. [Figure 1] FIG. [FIG NUMBER] is a block diagram of a communication system according to one embodiment. [Figure 2] FIG. [FIG NUMBER] is a timing chart for obtaining an object from a CDN according to one embodiment. [Figure 3] FIG. [FIG NUMBER] is a flowchart of using Anycast routing to identify a load balancer according to one embodiment. [Figure 4] FIG. [FIG NUMBER] shows a CDN having geographically distributed load balancers and caches according to one embodiment. [Figure 5] FIG. [FIG NUMBER] shows a load balancer that provides a unicast path to a CDN cache to a user device using HTTP redirect according to one embodiment. Detailed Description

[0005] Please note that the FIG NUMBER placeholders should be replaced with the actual figure numbers in the original document.Embodiments of this specification describe a CDN, where anycast routing is used to identify a load balancer (also referred to as a traffic router) to select a cache within the CDN to use for delivering an object to the user. In one embodiment, the user performs a DNS lookup to identify the anycast IP addresses of several load balancers within the CDN. The user can then use the anycast IP address to initiate anycast routing, automatically identifying the nearest logical load balancer among several load balancers sharing the anycast IP address. Conveniently, the load balancer can see not only the full path of the object (e.g., a movie, TV show, live performance, etc.) but also the IP address of the user's device. 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 object being requested. Using this information, the load balancer can pinpoint the exact location of the user's device and select the optimal CDN cache using one or more load balancing criteria.

[0006] Once a cache is selected, the load balancer can close the anycast connection with the user device and use an HTTP redirect (e.g., an HTTP response status code 302) to provide the user device with a unicast route to the selected cache. The user device can then establish a unicast connection with the cache and retrieve the object. Conveniently, the anycast connection to the load balancer is often very short (e.g., 100-300 milliseconds), reducing the likelihood that the anycast route will be redirected to another load balancer due to network failures (e.g., a broken circuit, a disconnected router, etc.). Once load balancing is complete, the user device retrieves the cache using the unicast route provided by the HTTP redirect. This is typically a much longer connection (e.g., 5-8 seconds to transfer a segment) and is not affected by potential network failures caused by anycast routing. Thus, embodiments of this specification enjoy the benefits of anycast routing, which automatically identifies the nearest load balancer that provides more accurate information than DNS lookups, while retrieving objects from a CDN cache using a unicast connection and avoiding the impact of using an anycast connection on network failures.

[0007] Figure 1 is a block diagram of a communication system 100 according to one embodiment. The system 100 includes a user device 105, a DNS server 130, a network 150 (e.g., a public network such as the Internet), an edge server 155, a CDN 170, and a streaming server 190. The user device 105 may be any device capable of retrieving an object 185 from a cache 180 in the CDN 170. In this embodiment, the user device 105 includes a display 125 that can display (e.g., output) media presentations from the CDN 170 (e.g., a smartphone, tablet, laptop, smart TV, etc.). However, in other embodiments, the user device 105 does not have to include a display and may instead be a streaming player or media player coupled to an output device (such as a television).

[0008] In either case, the user device 105 includes a processor 110 and memory 115. The processor 110 represents any number of process elements, which may include any number of process cores. Generally, the processor 110 retrieves 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) that can select an object 185 and retrieve it from CDN 170. For example, the streaming application 120 may output a graphical user interface (using a display 125 or a separate electronic device (e.g., a television)) listing several different media presentations (e.g., movies, live events, television episodes, etc.). The user can then use the interface to select a specific media presentation and view it on the user device 105 or a connected output device.

[0009] In response to a user selecting a media presentation, the user device 105 can send a request to the streaming server 190 for the Uniform Resource Location (URL) corresponding to the media presentation. The streaming server 190 can store a different object URL 195 for each object (e.g., a media presentation) stored in the CDN 170. The object URL 195 may include the name of the media presentation (e.g., HTTP: / / ...AdventureShowEpisode1Season2...). In this way, the URL 195 in the streaming server 190 provides a URL for accessing the media presentation (or other object) requested by the user.

[0010] Next, the user device 105 can perform a DNS lookup using the object URL 195. The DNS lookup translates the object URL 195 into an IP address that can be used on network 150 to identify the location from which to retrieve (or stream) 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 130. The user device 105 can identify the DNS server 130 to perform the DNS lookup using either unicast routing or anycast routing. The advantage of using anycast routing is that the DNS server 130 can be automatically identified via the shortest route to the user device 105 over network 150, potentially reducing the time used to perform the DNS lookup. However, in embodiments of this specification, it is also possible to perform the DNS lookup using unicast routing.

[0011] DNS server 130 provides an IP address to user device 105 in response to a DNS lookup. However, instead of providing the user device with an IP address to cache 180 to look up an object, in some embodiments, DNS server 130 provides an anycast IP address to edge server 155. More specifically, DNS server 130 provides an anycast IP address to reach a load balancer 160 (e.g., a software application) hosted within edge server 155. In one embodiment, each of the edge servers 155 has the same anycast IP address. Therefore, when DNS server 130 provides an anycast IP address to user device 105, anycast routing using that address automatically identifies the edge servers 155 and load balancer 160 in the shortest path to user device 105. That is, anycast routing uses an underlying routing protocol (e.g., Border Gateway Protocol (BGP)) to identify the shortest path to one of multiple network devices (e.g., edge server 155) with the same anycast IP address.

[0012] Next, the load balancer 160 in the edge server 155 identified by anycast routing can use one or more load balancing criteria to determine the best cache 180 for delivering the requested media presentation (e.g., object 185). Embodiments herein are not limited to specific load balancing criteria. Non-limiting examples include using the cache 180 located in the same location as (or closest to) the identified edge server 155, ensuring that the load on a particular cache 180 does not exceed a threshold, ensuring that a minimum number of requests are sent to each cache 180, and not routing requests from caches 180 that will soon be removed for maintenance.

[0013] There are several advantages to using the load balancer 160 instead of the DNS server 130 at the edge server 155 in order to select cache 180. One advantage is that TCP communication between the user device 105 and the load balancer 160 has more information than a DNS lookup between the user device 105 and the load balancer 160. For example, communication to the load balancer 160 can include the full path to the requested object 185, which the DNS lookup does not have. Therefore, the load balancer 160 can recognize the object 185 that the user is requesting and select cache 180 accordingly, but this information is hidden from the DNS server. For example, some caches 180 within the CDN 170 may have the requested object, while others may not.

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

[0015] As described above, communication between user device 105 and load balancer 160 can be an anycast connection that automatically identifies the load balancer 160 closest to user device 105. Also, as described above, anycast connections are susceptible to network failures that may change the connection. For example, a line may be disconnected or a router may be shut down for maintenance, causing the shortest path to change from, for example, load balancer 160A to load balancer 160B. In this case, load balancer 160B has none of the information already provided to load balancer 160A by user device 105, and therefore the process must be repeated or reset. However, communication between the load balancer 160 and the user device 105 is typically very short (e.g., 200-300 milliseconds) due to the devices exchanging a single HTTP request / response pair (TCP handshake, TLK handshake (optional), which can include the HTTP request / response itself). The load balancer 160 and the user device can exchange between 5-10 TCP segments. Therefore, the risk of network failure during anycast connection between the user device 105 and the load balancer 160 is small.

[0016] When the load balancer 160 selects a cache 180 to use to retrieve or stream an object 185 (e.g., a requested media presentation) requested by the user device 105, the load balancer 160 can send an HTTP redirect to the user device 105 (e.g., an HTTP response with status code 302). This redirects the user device 105 to the selected cache 180. In other words, the load balancer 160 closes the anycast connection and redirects the user device 105 to the cache 180. The HTTP redirect may include a unicast, which would allow the user device 105 to establish a unicast connection to the cache 180 in response to the HTTP redirect. While an HTTP redirect using a 302 status code has been described, the embodiments are not limited thereto, and any current or future redirect HTTP mechanism (e.g., a 301 status code or Alt-Svc) may be used.

[0017] The connection between user device 105 and cache 180 is typically much longer than the connection between user device 105 and load balancer 160, which uses a unicast connection between user device 105 and cache 180 to retrieve object 185, thus avoiding the vulnerability of anycast connections. That is, if a network failure occurs along the unicast path between user device 105 and cache 180, user device 105 will still connect to the same cache 180, even though it uses a different route or path through network 150. Thus, the 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 to perform geolocation. Furthermore, the risk of using a long anycast connection to retrieve or stream object 185 can be avoided by using HTTP redirects to close or terminate the anycast connection with load balancer 160 and establish a unicast connection to the selected cache 180.

[0018] Figure 1 shows that only the cache 180 resides within the CDN 170, but in other embodiments, the DNS server 130 and edge server 155, along with the load balancer 160, can be considered part of the CDN 170.

[0019] Furthermore, the 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 enumerated herein.

[0020] Figure 2 is a timing chart 200 for retrieving an object from a CDN according to one embodiment. The timing chart 200 shows various communications between a user device 105 and a streaming server 190, a DNS server 130, a load balancer 160, and a cache 180 within the CDN. Arrow 205 indicates that the user device 105 makes a selection of an object to retrieve or stream from the CDN. This selection is communicated to the streaming server 190. The user's selection can be called a service call to the streaming server 190. In response, arrow 210 indicates that the streaming server 190 provides a URL (e.g., the object URL in Figure 1) for the requested object. The URL may include the name, description, or ID of the requested object.

[0021] To identify the IP address corresponding to the object URL, arrow 215 indicates a user device 105 that performs a DNS lookup using DNS server 130. The user device 105 can select one of several DNS servers 130 associated with the CDN using either a unicast or anycast connection. For example, the user device 105 may already know which DNS server to use to perform the DNS lookup, in which case a unicast connection can be used. In contrast, the user device 105 can use an anycast connection, where the underlying network protocol automatically identifies the DNS server 130 with the shortest path to the user device 105. The embodiments herein are not limited to any particular situation.

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

[0023] Arrow 225 indicates user device 105, which performs anycast routing using anycast IP addresses and automatically identifies load balancer 160 (and edge servers) that have the shortest path to user device 105. In other words, anycast routing uses the underlying routing protocol (e.g., BGP) within the network to identify load balancer 160 among multiple load balancers that have the shortest path to user device 105 within the network.

[0024] Next, load balancer 160 can select cache 180 from multiple caches within the CDN using one or more load balancing criteria. Unlike DNS lookups, once an anycast connection is established, the load balancer can receive the full path to the requested object and the user's true IP address. This information then allows load balancer 160 to implement a wider range of load balancing strategies and perform more accurate geolocation of user devices 105 than would be possible if the DNS server were tasked with selecting the cache.

[0025] Arrow 230 indicates that the load balancer 160 sends an HTTP redirect to the user device 105 to redirect the user device 105 to the selected cache 180. In one embodiment, the HTTP redirect closes or terminates the anycast connection between the user device 105 and the load balancer. Further, the HTTP redirect provides information so that the user device 105 can establish a unicast connection with the cache 180, as shown by arrow 235.

[0026] Arrow 240 indicates the cache 180 that uses a unicast connection to send the requested object to the device 105. The connection between the user device 105 and the cache 180 is usually much longer than the connection between the user device 105 and the load balancer 160 for retrieving the object. Therefore, the unicast connection between the user device 105 and the cache 180 is used to avoid the impact that the anycast connection suffers from network failures. That is, if a network failure occurs along the unicast path between the user device 105 and the cache 180, the user device 105 still connects to the same cache 180. By using the HTTP redirect to close or terminate the anycast connection with the load balancer and establish a unicast connection to the selected cache 180, the risk of acquiring or streaming the requested object using a long anycast connection can be avoided.

[0027] Using the timing chart 200, the connection between the user device 105 and the cache 180 can be initialized to search for or stream an object. The timing chart 200 shows the initialization of the first request to stream an object, but the chart 200 can also be used to initialize an already started stream that has been interrupted for some reason. For example, assume that the user device 150 has already executed all the tasks shown in the timing chart 200 and has started streaming an object from the cache 180. However, the user device 150 is a smartphone that has been switched from using the cellular network for streaming to using the Wi-Fi network. This switch may cause the user device 105 to need to re-initialize the stream. Next, the user device 105 can repeat the tasks represented by the arrows 225-240 to resume the stream. Since the user device 105 already knows the IP address of the object (i.e., the anycast IP address of the load balancer 160), it is not necessary to repeat the tasks represented by the arrows 205 and 220. Nevertheless, if the user device is currently using a different network, load balancing can be repeated to determine whether another cache 180 is more suitable for streaming the object. Also, re-initialization may occur because a failure has occurred in the previous cache 180 or it has been stopped for maintenance. In either case, the user device 105 can re-establish the anycast connection with the load balancer 160 (or a different load balancer 160) and identify the optimal cache 180 to use to resume the stream of the object. Therefore, the embodiments herein can be used both when initializing a stream when first requesting an object and when initializing a stream when a previous stream has been interrupted.

[0028] Figure 3 is a flowchart of Method 300, according to one embodiment, which uses anycast routing to identify a load balancer. Method 300 can be initiated in response to a user selecting an object to retrieve or stream from a CDN. In block 305, the user device performs a DNS lookup and receives anycast IP addresses for multiple load balancers, i.e., the load balancers share the same anycast IP address.

[0029] Block 305 can correspond to arrow 215 in Figure 2, allowing the user device to select one of several DNS servers 130 associated with the CDN using either a unicast or anycast connection. For example, the user device can use a pre-selected DNS server and perform a DNS lookup using a unicast connection. In contrast, the user device can use an anycast connection to identify the DNS server with the shortest path to the user device.

[0030] In block 310, the user device performs anycast routing and establishes an anycast connection to one of several load balancers that support the CDN. That is, the user device can use the anycast IP address provided by the DNS server to perform anycast routing and identify the load balancer with the shortest path to the user device. The user device can use the anycast connection to provide the load balancer with the full path name of an object. The load balancer can also receive the true IP address of the user device, and therefore can perform geolocation services as needed.

[0031] In block 315, the load balancer determines or selects a cache from multiple caches and retrieves objects from the CDN based on load balancing criteria. Non-exclusive examples of load balancing criteria include using a cache to satisfy requests located in the same place (or closest to) the load balancer, ensuring that the load on any particular cache does not exceed a threshold, ensuring that a minimum amount of requests is sent to each cache, and not routing requests from caches that are immediately removed for maintenance. In other examples, the load balancer may use the route name of an object to determine which CDN cache object is already stored in memory. However, the embodiments herein are not limited to any particular load balancing technique.

[0032] In one embodiment, a load balancer may use non-standard signaling to indicate multiple caches that a user device attempts to connect to in order to retrieve an object. These caches may be ordered, weighted, or otherwise specified with particular retry policies. Thus, the load balancer may determine or select multiple caches from among the multiple caches.

[0033] In block 320, the load balancer initiates an HTTP redirect, closing the anycast connection and providing the user device with a unicast path to the cache. As shown by arrow 230 in Figure 2, the load balancer can send an HTTP redirect to the user device, redirecting the user device to the cache identified in block 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) so that the user device can establish a unicast connection to the cache.

[0034] In block 325, the user device establishes a unicast connection with the cache and retrieves the object. In some embodiments, in block 310, the unicast connection between the user device and the CDN cache is established for a much longer period than the anycast connection between the user device and the load balancer. For example, when the user device is streaming content, the anycast connection may last for 100-300 milliseconds, while the unicast connection may last for several seconds (if not longer). Thus, streaming objects from the cache using a unicast connection avoids the vulnerability of anycast connections to network failures where the shortest path might switch to another cache, forcing a connection reinitialization.

[0035] Figure 4 shows a CDN with geographically distributed load balancers and caches according to one embodiment. In this example, the CDN is distributed across 400 geographical areas, including areas A, B, and C. Each geographical area contains more load balancers (LBs) 160 and caches 180. For example, each area may have different data centers operated by the CDN in different towns, states, countries, continents, etc. The LBs 160 and caches 180 can run in these data centers. Areas with high population density or high demand may have multiple data centers, multiple LBs 160 and caches 180. In this example, the LBs 160 are located in the same place as the caches 180 in a particular region (e.g., hosted by the same data center).

[0036] Furthermore, Figure 4 shows a user device 105 using anycast routing to establish an anycast connection 405 with LB160B in area B. That is, Figure 4 shows the point at which user device 105 selects an object to retrieve from the CDN and performs a DNS lookup to receive an anycast IP address (e.g., arrows 205-220 in Figure 2 and block 305 in Figure 3). As illustrated, all LB160s in Figure 4 have the same anycast IP address, i.e., anycast address A. When anycast routing is performed using anycast address A, the network identifies LB160 as having the shortest path to reach user device 105 through the network. For example, user device 105 could also be located in area B. Thus, user device 105 establishes an anycast connection 405 with LB160B.

[0037] In this example, LB160B selects cache 180B as the optimal cache for user device 105 to retrieve or stream the requested object. For example, by default, LB160B can select cache 180B, located in the same location as LB160B, as the optimal cache for user device 105. This is because cache 180B is also in the same area as user device 105. In response, LB160B can send an HTTP redirect (not shown) to user device 105 to terminate the anycast connection 405 and establish a unicast connection 410A with cache 180B. User device 105 can then use the unicast connection 410A to retrieve the object from cache 180B.

[0038] Figure 4 also shows an alternative embodiment in which LB160B can instead select cache 180C in region C as the optimal cache for user device 105. Even if the user device is in region B, cache 180C may be the optimal cache to use (for example, for several reasons such as cache 180B being about to be shut down for maintenance, being currently overloaded, or not having the requested object). Therefore, LB160B can instead send an HTTP redirect to establish a unicast connection 410B with cache 180C.

[0039] In another example, LB160B might initially select cache 180B as the best cache for streaming an object, but then change its mind and select cache 180C as a better option. For example, while streaming an object from cache 180B, cache 180B might encounter an error or malfunction that interrupts the unicast connection 410A. In this case, user device 105 can repeat the initialization process by establishing an anycast connection 405 with LB160B. LB160B may have been notified of or detected an error in cache 180B and instead select cache 180C as the new cache. LB160B can provide an HTTP redirect that allows user device 105 to establish a unicast connection 410B with cache 180C and resume the stream. Conveniently, user device 105 can resume the stream using cache 180C where the stream using cache 180B was interrupted (assuming both caches 180B and 180C have copies of the requested object).

[0040] Figure 5 shows a load balancer 160 according to one embodiment, which provides a unicast route to a CDN cache to a user device using an HTTP redirect. As shown in the figure, the user device 105 can send an HTTP GET request 505 and perform anycast routing using the anycast IP address corresponding to the load balancer 160. After the user device has selected the best cache (e.g., cache 180) to retrieve the object, the load balancer 160 can respond to the GET request 505 with an HTTP redirect 510. As described above, the HTTP redirect 510 can close the anycast connection and provide information for the user device 105 to establish a unicast connection with cache 180. As shown in the figure, the HTTP redirect 510 provides a URL containing the unicast route to cache 180, i.e., HTTP: / / <cache unicast> Includes / path.

[0041] In response to the HTTP redirect 510, user device 105 sends an HTTP GET request 515 to the cache to establish a unicast connection. User device 105 can then use this connection to retrieve the requested object from the cache 180.

[0042] This disclosure references various embodiments. However, it should be understood that this disclosure is not limited to any specific embodiment described. Instead, any combination of the following features and elements, whether related to a different embodiment or not, is intended to implement and perform the teachings provided herein. Furthermore, where an element of an embodiment is described in the form of “at least one of A and B,” it should be understood that embodiments comprising only element A, embodiments comprising only element B, and embodiments comprising elements A and B are intended, respectively. Furthermore, while some embodiments may achieve advantages over other possible solutions or the prior art, whether a particular advantage is achieved by a given embodiment is not a limitation of this disclosure. Accordingly, the aspects, features, embodiments, and advantages disclosed herein are merely illustrative and should not be construed as elements or limitations of the claims unless expressly stated in the appended claims. Similarly, references to “invention” should not be construed as a generalization of the subject matter of the invention disclosed herein and should not be construed as elements or limitations of the appended claims unless expressly stated in the claims.

[0043] As those skilled in the art will understand, the embodiments described herein can be embodied as systems, methods, or computer program products. Accordingly, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments that combine software and hardware aspects, as referred to herein as “circuits,” “modules,” or “systems.” Furthermore, embodiments described herein can take the form of computer program products embedded in one or more computer-readable media containing computer-readable program code.

[0044] Program code embodied in a computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or any suitable combination thereof.

[0045] Computer program code for performing the operations of embodiments of this disclosure can be written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, and traditional procedural programming languages ​​such as the C programming language or similar languages. The program code can run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, such as a local area network (LAN) or wide area network (WAN), or to an external computer (e.g., via the Internet using an Internet service provider).

[0046] Aspects of the present disclosure are described herein with reference to flowcharts or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. Each block of a flowchart or block diagram, and any combination of blocks in a flowchart or block diagram, is understood to be executable by computer program instructions. These computer program instructions are provided to a processor of a general-purpose computer, a dedicated computer, or any other programmable data processing device forming another machine, and instructions executed through the processor of the computer or other programmable data processing device can create means for performing the actions / operations specified in the blocks of the flowchart or block diagram.

[0047] Furthermore, these computer program instructions can be stored in a computer-readable medium that enables a computer, another programmable data processing device, or other device to function in a specific way, thereby generating a product in which the instructions stored in the computer-readable medium include instructions that perform functions / actions identified in the blocks of a flowchart or block diagram.

[0048] Furthermore, computer program instructions are loaded into a computer, another programmable data processing device, or another device, and a series of operational steps are executed on the computer, another programmable device, or another device, generating a process executed by the computer. Thus, the instructions executed on the computer, another programmable data processing device, or another device provide a process for performing the functions / actions specified in the blocks of a flowchart or block diagram.

[0049] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram represents a module, segment, or portion of code, which may contain one or more executable instructions for performing a specified logical function. It should also be noted that in some alternative embodiments, the functions described in a block may differ from the order shown in the figure. For example, two blocks shown consecutively may actually be executed substantially simultaneously depending on their function, and blocks may also be executed in reverse order or out of order. It should also be noted that each block in a block diagram or flowchart, and any combination of blocks in a block diagram or flowchart, may be executed by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to perform a specified function or action.

[0050] While the above applies to embodiments of the present disclosure, other and further embodiments of the present disclosure may be created without departing from its basic scope, the scope of which is defined by the following claims.

Claims

[Claim 1] The process involves 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, In a load balancer, the process involves selecting a first cache from multiple caches within a CDN and fulfilling requests for objects based on one or more load balancing criteria. A method comprising the steps of sending an HTTP redirect from a load balancer to a user device and closing anycast connection, wherein the HTTP redirect includes information for establishing a unicast connection between the user device and a first cache and retrieving an object from the first cache.

Images