JP-2026076323-A - Local preferences in anycast CDN routing

Abstract

[Problem] To provide a method for identifying a load balancer to select a cache within a content delivery network (CDN) to use for delivering 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 HTTP redirection 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). [Selection Diagram] Figure 3

Inventors

• エリック シー フレデリック
• ロバート ジー コラントゥオーニ

Assignees

• ディズニー エンタープライゼス インコーポレイテッド

Dates

Publication Date

20260511

Application Date

20260216

Priority Date

20220315

Claims (1)

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.

Description

background 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. Selecting 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 has several challenges. First, the true client IP address (used for geolocation/mapping) is often not visible to the CDN's DNS server. 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 a 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, even with a very short Time To Live (TTL), load balancer responses are cached to some extent. While this is effective under high loads, it ultimately reduces the DNS server's ability to determine the user's location. A second strategy used to select the cache closest to the user is anycast routing. In anycast, many hosts can advertise the same IP address. A Layer 3 switch or router determines the minimum cost path for the packet hop by hop. This localizes the client to the nearest logical CDN cache. However, a change in routing can cause the packet to be delivered to a different host, potentially resetting the connection and potentially interrupting it. Anycast has traditionally been used for User Datagram Protocol (UDP) or Extreme Short Lived Transmission Control Protocol (TCP) connections. To enable a detailed understanding of the embodiments described herein, which are briefly summarized above, a more specific description of these embodiments can be provided by referring to the accompanying drawings. However, it should be noted that the attached drawings illustrate a typical embodiment and should therefore not be considered limiting. Other equally effective embodiments are conceivable. This is a block diagram of a communication system according to one embodiment. This is a timing chart for retrieving objects from a CDN according to one embodiment. This is a flowchart illustrating the use of anycast routing to identify a load balancer, according to one embodiment. This document describes a CDN having geographically distributed load balancers and cache according to one embodiment. This describes a load balancer according to one embodiment that uses HTTP redirection to provide a unicast route to a CDN cache for user devices. Detailed explanation 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 objects 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 initiate anycast routing using the anycast IP address, automatically identifying the nearest logical load balancer among the several load balancers sharing the anycast IP address. Conveniently, the load balancer can see not only the full path of the object (e.g., movies, TV shows, live performances, etc.) but also the IP address of the user 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 device and select the optimal CDN cache using one or more load balancing criteria. 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 network failures (e.g., a broken circuit, a disconnected router, etc.) will cause the anycast route to be redirected to another load balancer. 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