CN116781613A - 任播cdn路由中的本地偏好 - Google Patents

任播cdn路由中的本地偏好 Download PDF

Info

Publication number
CN116781613A
CN116781613A CN202310269715.6A CN202310269715A CN116781613A CN 116781613 A CN116781613 A CN 116781613A CN 202310269715 A CN202310269715 A CN 202310269715A CN 116781613 A CN116781613 A CN 116781613A
Authority
CN
China
Prior art keywords
anycast
cache
user device
load balancer
connection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310269715.6A
Other languages
English (en)
Inventor
埃里克·C·弗里德里希
罗伯特·G·科兰托尼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Disney Enterprises Inc
Original Assignee
Disney Enterprises Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Disney Enterprises Inc filed Critical Disney Enterprises Inc
Publication of CN116781613A publication Critical patent/CN116781613A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1014—Server selection for load balancing based on the content of a request
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1021—Server selection for load balancing based on client or server locations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开涉及任播CDN路由中的本地偏好。本文的实施例描述了一种CDN，其中，任播路由用于识别负载平衡器，以用于选择CDN中的缓存，来将请求的对象递送给用户。在一个实施例中，用户执行DNS查找以识别CDN中的多个负载平衡器的任播IP地址。然后，用户可以使用任播IP地址发起任播路由，以自动识别最近的负载平衡器。一旦识别的平衡器选择了缓存，负载平衡器就可以关闭与用户设备的任播连接，并且使用HTTP重定向来向用户设备提供去往所选缓存的单播路径。然后，用户设备可以与缓存建立单播连接以获取(例如，流送)对象。

Description

任播CDN路由中的本地偏好
技术领域
本公开涉及任播CDN路由中的本地偏好。
背景技术
内容分发/交付网络(CDN)是大型的、地理分布广泛的缓存网络。这些缓存将视频和其他web内容(通常称为“对象”)递送给观众。选择用于将对象递送给用户的最佳缓存是一项艰巨的任务。大多数CDN通常使用两种技术来识别用于递送对象的最佳缓存。首先，域名系统(DNS)负载平衡可以用于选择最佳缓存。一旦DNS服务器选择了最佳缓存，CDN就使用缓存(或缓存集群)的IP地址来响应用户的DNS查询。然而，DNS负载平衡存在若干挑战。首先，CDN的DNS服务器通常看不到真正的客户端IP地址(用于地理定位/映射)。相反，DNS服务器看到用户使用的互联网服务提供商(ISP)的解析器(或者更糟糕的是基于云的公共DNS解析器)的IP地址。在没有准确的客户端IP地址的情况下，缓存定位将更加困难。此外，DNS查找不包含有关所请求内容的信息。因此，CDN无法在缓存本地化期间使用资产级负载平衡策略。例如，资产级策略可以允许将已知内容已经在缓存中的特定缓存或集群作为目标。最后，即使使用非常低的生存时间(TTL)，也有一定量的负载平衡器缓存响应。这在高负载的情况下可能很好，但最终会降低DNS服务器识别用户位置的能力。
用于选择最接近用户的缓存的第二种策略是任播路由(anycast routing)。任播允许许多主机通告相同的IP地址。在每一跳，第3层交换机或路由器确定分组的最低成本路径。这将客户端定位到最近的逻辑CDN缓存。然而，由于连接重置的风险，如果数据分组被递送到不同的主机，路由更改可能会导致连接中断。任播在传统上用于用户数据报协议(UDP)或极短时间的传输控制协议(TCP)连接。
发明内容
根据本公开的一个实施例，提供了一种方法，包括：在与内容交付网络(CDN)相关联的负载平衡器和从所述CDN请求对象的用户设备之间建立任播连接；在所述负载平衡器处，基于一个或多个负载平衡标准从所述CDN中的多个缓存中选择第一缓存来满足对所述对象的请求；以及从所述负载平衡器向所述用户设备传输HTTP重定向以关闭所述任播连接，其中，所述HTTP重定向包括用于在所述用户设备和所述第一缓存之间建立单播连接以从所述第一缓存获取所述对象的信息。
根据本公开的一个实施例，提供了一种非暂态计算机可读介质，包括计算机程序代码，所述计算机程序代码在由一个或多个计算机处理器操作执行时，执行以下操作，所述操作包括：在与CDN相关联的负载平衡器和从所述CDN请求对象的用户设备之间建立任播连接；在所述负载平衡器处，基于一个或多个负载平衡标准从所述CDN中的多个缓存中选择第一缓存来满足对所述对象的请求；以及从所述负载平衡器向所述用户设备传输HTTP重定向以关闭所述任播连接，其中，所述HTTP重定向包括用于在所述用户设备和所述第一缓存之间建立单播连接以从所述第一缓存获取所述对象的信息。
根据本公开的一个实施例，提供了一种服务器，包括：处理器；存储器，存储有计算机程序代码，所述计算机程序代码在由所述处理器操作执行时，执行以下操作，所述操作包括：在所述服务器和从CDN请求对象的用户设备之间建立任播连接；基于一个或多个负载平衡标准从所述CDN中的多个缓存中选择第一缓存来满足对所述对象的请求；以及向所述用户设备传输HTTP重定向以关闭所述任播连接，其中，所述HTTP重定向包括用于在所述用户设备和所述第一缓存之间建立单播连接以从所述第一缓存获取所述对象的信息。
附图说明
为了实现上述方面并能够详细理解，可以通过参考附图对本文中描述的实施例(上文简要概述)进行更具体的描述。
然而，要注意的是，附图示出了典型的实施例，因此不应被视为限制性的；可以设想其他同样有效的实施例。
图1是根据一个实施例的通信系统的框图。
图2是根据一个实施例的从CDN获取对象的时序图。
图3是根据一个实施例的使用任播路由来识别负载平衡器的流程图。
图4示出了根据一个实施例的具有地理分布的负载平衡器和缓存的CDN。
图5示出了根据一个实施例的负载平衡器使用HTTP重定向来向用户设备提供去往CDN缓存的单播路径。
具体实施方式
本文的实施例描述了一种CDN，其中使用任播路由来识别负载平衡器(也称为流量路由器)，该负载平衡器用于选择CDN中的缓存以将对象递送给用户。在一个实施例中，用户执行DNS查找以识别CDN中的多个负载平衡器的任播IP地址。然后，用户可以使用任播IP地址发起任播路由，以自动识别共享该任播IP地址的多个负载平衡器中最近的逻辑负载平衡器。有利的是，负载平衡器将看到用户设备的IP地址以及对象(例如，电影、电视节目、现场表演等)的完整路径。这不同于许多类型的DNS查找，在这些类型的DNS查找中，真实的用户IP隐藏在进行DNS请求的解析器后面，并且DNS查找不指示所请求的对象。利用该信息，负载平衡器可以确定用户设备的准确位置，并且使用一个或多个负载平衡标准来选择最佳CDN缓存。
一旦选择了缓存，负载平衡器就可以关闭与用户设备的任播连接，并且使用HTTP重定向(例如，HTTP响应状态代码302)来向用户设备提供去往所选缓存的单播路径。然后，用户设备可以与缓存建立单播连接以获取对象。有利地，去往负载平衡器的任播连接常常非常短(例如，100-300毫秒)，这减轻了网络干扰(例如，切断线路、断开连接的路由器等)将任播路由改变到不同负载平衡器的可能性。一旦负载平衡完成，用户设备使用由HTTP重定向提供的单播路径来获取缓存，这通常是一个更长的连接(例如，5-8秒来传输一个区段)，并且不易受到任播路由所引起的潜在网络干扰。以此方式，本文的实施例可以获得以下益处：任播路由用于自动识别最近的负载平衡器，该任播路由提供比DNS查找更准确的信息，同时使用单播连接从CDN缓存获取对象，这避免了使用任播连接对网络干扰的敏感性。
图1是根据一个实施例的通信系统100的框图。系统100包括用户设备105、DNS服务器130、网络150(例如，诸如互联网之类的公共网络)、边缘服务器155、CDN 170和流式服务器190。用户设备105可以是能够从CDN 170中的缓存180获取对象185的任何设备。在该实施例中，用户设备105包括显示器125，因此它可以显示(例如，输出)来自CDN170的媒体呈现，例如智能手机、平板电脑、膝上型电脑、智能电视等。然而，在其他实施例中，用户设备105可以不包括显示器，而可以是耦合到输出设备(例如，电视)的流式播放器或媒体播放器。
在任何情况下，用户设备105包括处理器110和存储器115。处理器110表示可以包括任何数量的处理核心的任何数量的处理器元件。通常，处理器110获取并执行存储在存储器115中的编程指令。存储器115可以包括易失性存储器元件、非易失性存储器元件及其组合。具体地，存储器115包括能够选择要从CDN 170获取的对象185的流式应用120(例如，软件应用)。例如，流式应用120可以输出图形用户界面(使用显示器125或单独的电子设备，例如电视)，该图形用户界面列出多个不同的媒体呈现，例如电影、实况事件、电视集等。然后，用户可以使用该界面来选择特定的媒体呈现以在用户设备105或连接的输出设备上观看。
响应于用户选择媒体呈现，用户设备105可以向流式服务器190传输对与媒体呈现相对应的统一资源位置(URL)的请求。流式服务器190可以为存储在CDN 170中的每个对象(例如，媒体呈现)存储不同的对象URL 195。对象URL 195可以包括媒体呈现的名称，例如http://...AdventureShowEpisode1Season2...。以此方式，流式服务器190中的URL 195提供用于访问用户请求的媒体呈现(或其他对象)的URL。
然后，用户设备105可以使用对象URL 195来执行DNS查找。DNS查找将对象URL 195转换为IP地址，该IP地址可以在网络150中用于识别用于获取(或流送)所请求的媒体呈现的位置。在这种情况下，系统100包括多个DNS服务器130，但在其他实施例中，可以仅包括一个DNS服务器。用户设备105可以使用单播路由或任播路由来识别DNS服务器130以执行DNS查找。使用任播路由的优点是它可以通过网络150自动识别具有去往用户设备105的最短路径的DNS服务器130，从而潜在地减少用于执行DNS查找的时间。然而，本文的实施例还可以使用单播路由来执行DNS查找。
DNS服务器130响应于DNS查找向用户设备105提供IP地址。然而，在一些实施例中，DNS服务器130向边缘服务器155提供任播IP地址，而不是向用户设备提供用于获取对象的缓存180的IP地址。或者更具体地，DNS服务器130提供任播IP地址以到达托管在边缘服务器155中的负载平衡器160(例如，软件应用)。在一个实施例中，每个边缘服务器155具有相同的任播IP地址。因此，当DNS服务器130向用户设备105提供任播IP地址时，使用该地址执行任播路由会自动识别具有去往用户设备105的最短路径的边缘服务器155和负载平衡器160。也就是说，任播路由使用下层路由协议(例如，边界网关协议(BGP))来识别去往具有相同任播IP地址的多个网络设备(例如，边缘服务器155)中的一者的最短路径。
然后，通过任播路由识别出的边缘服务器155中的负载平衡器160可以使用一个或多个负载平衡标准来确定哪个缓存180最适合递送所请求的媒体呈现(例如，对象185)。本文的实施例不限于任何特定的负载平衡标准。非限制性示例包括：使用与所识别的边缘服务器155位于同一位置(或最接近)的缓存180；确保任何特定缓存180上的负载不超过阈值；确保向每个缓存180发送最小数量的请求；将请求路由离开将很快被关停以进行维护的缓存等等。
使用边缘服务器155中的负载平衡器160(而不是DNS服务器130)来选择缓存180有几个优点。一个优点是用户设备105和负载平衡器160之间的TCP通信具有比用户设备105和负载平衡器160之间的DNS查找更多的信息。例如，到负载平衡器160的通信可以包括到所请求对象185的完整路径，而DNS查找不具有该信息。因此，负载平衡器160知道用户正在请求什么对象185，并且可以相应地选择缓存180，同时该信息对DNS服务器隐藏。例如，CDN 170中的一些缓存180可以具有所请求的对象，而其他缓存没有。
此外，从用户设备105到负载平衡器160的HTTP通信可以包含用户设备105的真实IP地址，而DNS查找可以包括解析器的IP地址(可能不在或接近用户设备105地理位置)。因此，负载平衡器160在选择缓存180时执行的任何地理定位功能可以比DNS服务器130执行的地理定位功能更准确。
如上所述，用户设备105和负载平衡器160之间的通信可以是自动识别最接近用户设备105的负载平衡器160的任播连接。如上所述，任播连接易受网络干扰的影响，网络干扰可能会改变连接。例如，由于电线被切断或路由器被关停以进行维护，最短路径可以从例如负载平衡器160A改变到负载平衡器160B。由于负载平衡器160B将不具有已经由用户设备105提供给负载平衡器160A的任何信息，因此该过程将不得不重复或重置。然而，负载平衡器160和用户设备105之间的通信通常非常短(例如，200-300毫秒)，其中设备交换单个HTTP请求/响应对，其可以包括TCP握手、TLK握手(可选)和HTTP请求/响应本身。负载平衡器160和用户设备可以在5-10个TCP区段之间进行交换。因此，在用户设备105和负载平衡器160之间的任播连接期间发生网络干扰的风险很小。
一旦负载平衡器160为用户设备105选择缓存180以用于获取或流送所请求的对象185(例如，所请求的媒体呈现)，负载平衡器160可以向用户设备105发送HTTP重定向(例如，状态代码为302的HTTP响应)，该HTTP重定向将用户设备105重定向到所选择的缓存180。换句话说，负载平衡器160关闭任播连接并将用户设备105重定向到缓存180。HTTP重定向可以包括到所选缓存180的单播路径，使得用户设备105可以响应于HTTP重定向而建立到缓存180的单播连接。虽然描述了使用302状态码的HTTP重定向，但是实施例不限于此，而是可以使用任何当前或将来的重定向HTTP机制，例如301状态码或Alt-Svc。
因为为了获取对象185，用户设备105和缓存180之间的连接通常比用户设备105和负载平衡器160之间的连接长得多，所以在用户设备105和缓存180之间使用单播连接避免了任播连接的敏感性。也就是说，如果沿着用户设备105和缓存180之间的单播路径发生网络干扰，则尽管使用通过网络150的不同路由或路径，用户设备105仍将连接到同一缓存180。因此，使用用户设备105和负载平衡器160之间的任播连接使得系统100能够比依赖于DNS服务器130来执行地理定位更准确地自动识别最接近用户设备105的负载平衡器160。此外，使用HTTP重定向来关闭或终止与负载平衡器160的任播连接并建立到所选缓存180的单播连接可以避免使用长任播连接来获取或流送对象185的风险。
虽然图1示出了CDN 170中只有缓存180，但在其他实施例中，DNS服务器130和边缘服务器155以及负载平衡器160可以被视为CDN 170的一部分。
此外，流式服务器190、DNS服务器130、边缘服务器155和缓存180可以包括一个或多个处理器、存储器、软件应用、输入/输出接口等，以执行本文所述的功能。
图2是根据一个实施例的用于从CDN获取对象的时序图200。时序图200示出了用户设备105与CDN中的流式服务器190、DNS服务器130、负载平衡器160和缓存180之间的各种通信。箭头205表明用户设备105选择要从CDN获取或流送的对象。该选择被传送到流式服务器190。用户选择可以被称为对流式服务器190的服务调用。作为响应，箭头210示出流式服务器190向所请求的对象提供URL(例如，图1中的对象URL195)。URL可以包括所请求的对象的名称、描述或ID。
为了识别与对象URL对应的IP地址，箭头215示出用户设备105使用DNS服务器130执行DNS查找。用户设备105可以使用单播连接或任播连接来选择与CDN相关联的多个DNS服务器130中的一个。例如，用户设备105可能已经知道使用哪个DNS服务器来执行DNS查找，在这种情况下，用户设备105可以使用单播连接。在相反情况下，用户设备105可以使用任播连接，以使得下层网络协议自动识别具有到用户设备105的最短路径的DNS服务器130。这里的实施例不限于任一情况。
在该示例中，如箭头220所示，DNS服务器130向用户设备105提供任播地址以到达CDN所使用的负载平衡器160之一，而不是DNS服务器130向用户设备提供到缓存180的IP地址以获取对象。在一个实施例中，CDN中的每个负载平衡器160对应于相同的任播IP地址。DNS服务器130可以被配置为通过向用户设备105提供针对负载平衡器160的任播IP地址来响应对CDN中的内容的任何DNS查找。
箭头225示出用户设备105使用任播IP地址来执行任播路由以自动识别具有到用户设备105的最短路径的负载平衡器160(和边缘服务器)。也就是说，任播路由使用网络中的下层路由协议(例如，BGP)来识别网络中的多个负载平衡器中具有到用户设备105的最短路径的负载平衡器160。
然后，负载平衡器160可以使用一个或多个负载平衡标准来从CDN中的多个缓存中选择缓存180。与DNS查找不同，当建立任播连接时，负载平衡器可以接收去往所请求对象的完整路径以及用户的真实IP。因此，该信息使得负载平衡器160能够执行更多种类的负载平衡策略，并且与如果DNS服务器被分派了选择缓存的任务相比，执行对用户设备105的更精确的地理定位。
箭头230示出了负载平衡器160向用户设备105发送HTTP重定向以将用户设备105重定向到所选择的缓存180。在一个实施例中，HTTP重定向关闭或终止用户设备105和负载平衡器160之间的任播连接。此外，HTTP重定向提供信息，以使得用户设备105可以建立与缓存180的单播连接，如箭头235所示。
箭头240示出了缓存180使用单播连接将所请求的对象发送到设备105。因为为了获取对象，用户设备105和缓存180之间的连接通常比用户设备105和负载平衡器160之间的连接长得多，所以在用户设备105和缓存180之间使用单播连接避免了任播连接对网络干扰的敏感性。也就是说，如果网络干扰沿着用户设备105和缓存180之间的单播路径发生，则用户设备105将仍然连接到同一缓存180。使用HTTP重定向来关闭或终止与负载平衡器160的任播连接并建立到所选缓存180的单播连接可以避免使用长任播连接来获取或流送所请求的对象的风险。
时序图200可以用于初始化用户设备105与缓存180之间的连接以获取或流送对象。虽然时序图200示出了对流送对象的初始请求进行初始化，但是图200也可以用于对出于任何原因而被中断的已启动流进行初始化。例如，假设用户设备105已经执行了时序图200中所示的所有任务以开始从缓存180流送对象。然而，用户设备105可能是从使用蜂窝网络切换到使用Wi-Fi网络以进行流送的智能电话。该切换可能导致用户设备105需要重新初始化流。用户设备105然后可以重复由箭头225-240表示的任务以重新初始化该流。由箭头205和220表示的任务不需要重复，因为用户设备105已经知道对象的IP地址(即，负载平衡器160的任播IP地址)。尽管如此，可以重复负载平衡，以确定在考虑到用户设备现在正在使用不同网络的情况下，另一缓存180是否更适于流送对象。或者，先前的缓存180可能发生故障或因维护而停止，这导致重新初始化。在任何情况下，用户设备105可以再次建立与负载平衡器160(或不同的负载平衡器160)的任播连接，以识别用于重启对象的流的最佳缓存180。因此，这里的实施例既可以在以下两种情况下使用：在首次请求对象时初始化流，以及在先前的流已被中断时初始化流。
图3是根据一个实施例的使用任播路由来识别负载平衡器的方法300的流程图。方法300可以响应于用户选择要从CDN获取或流送的对象而开始。在框305，用户设备执行DNS查找以接收多个负载平衡器的任播IP地址。也就是说，负载平衡器共享同一任播IP地址。
框305可以对应于图2中的箭头215，其中用户设备可以使用单播连接或任播连接来选择多个DNS服务器130中与CDN相关联的一个DNS服务器。例如，用户设备可以使用预先选择的DNS服务器以用来使用单播连接执行DNS查找。相反，用户设备可以使用任播连接来识别具有到用户设备的最短路径的DNS服务器。
在框310，用户设备执行任播路由以建立到与CDN相对应的多个负载平衡器中的一个负载平衡器的任播连接。也就是说，用户设备可以使用由DNS服务器提供的任播IP地址来执行任播路由，以识别具有到用户设备的最短路径的负载平衡器。用户设备可以使用任播连接向负载平衡器提供对象的完整路径名。此外，如果需要的话，负载平衡器可以接收用户设备的真实IP地址，从而平衡器可以执行地理位置服务。
在框315，负载平衡器基于负载平衡标准从多个缓存中确定或选择用于从CDN获取对象的缓存。负载平衡标准的非限制性示例包括：使用与负载平衡器共址(或最靠近负载平衡器)的缓存来满足请求；确保任何特定缓存上的负载不超过阈值；确保向每个缓存发送最小量的请求；将请求路由离开将很快被关停以进行维护的缓存，等等。在另一示例中，负载平衡器可以使用对象的路径名来确定哪些CDN缓存已将对象存储在其存储器中。然而，这里的实施例不限于任何特定的负载平衡技术。
在一个实施例中，负载平衡器可以使用非标准信令来指示多个缓存供用户设备尝试连接以获取对象。这些缓存可以被排序、加权、或指定其它具体重试策略。因此，负载平衡器可以从多个缓存中确定或选择几个缓存。
在框320，负载平衡器发起HTTP重定向以关闭任播连接并向用户设备提供到缓存的单播路径。如图2中的箭头230所示，负载平衡器可以将HTTP重定向发送到用户设备，以将用户设备重定向到在框315处标识的缓存。在一个实施例中，HTTP重定向关闭或终止用户设备和负载平衡器之间的任播连接。此外，HTTP重定向提供信息(例如，单播路径)，以使得用户设备可以建立与缓存的单播连接。
在框325，用户设备建立与缓存的单播连接以获取对象。在一些实施例中，在用户设备和CDN缓存之间建立比框310处的用户设备和负载平衡器之间的任播连接得长得多的单播连接。例如，当用户设备流送内容时，任播连接可以持续100-300毫秒，而单播连接可以持续几秒钟，甚至更长。因此，使用单播连接来从缓存流送对象避免了任播连接对网络干扰的敏感性，所述网络干扰可能导致最短路径切换到迫使连接重新初始化的不同缓存。
图4示出了根据一个实施例的具有地理分布式负载平衡器和缓存的CDN。在该示例中，CDN分布在包括区域A、B和C的地理区域400中。每个地理区域包括一个或多个负载平衡器(LB)160和缓存180。例如，每个区域可以具有由CDN在不同城市、州、国家、洲等中运行的不同数据中心。LB 160和缓存180可以在这些数据中心中执行。具有高人口密度或高需求的区域可以具有多个数据中心和多个LB 160和缓存180。在此实例中，LB 160与缓存180一起位于特定区域中(例如，由同一数据中心托管)。
图4还示出了已经使用任播路由来建立与区域B中的LB 160B的任播连接405的用户设备105。也就是说，图4示出了如下时间点，在该时间点处，用户设备105已经选择了要从CDN获取的对象并且已经通过执行DNS查找接收了任播IP地址(例如，图2的箭头205-220和图3的框305)。如图所示，图4中的所有LB 160具有相同的任播IP地址，即，任播地址A。因此，当使用任播地址A执行任播路由时，网络自动地将LB160B识别为具有通过网络到达用户设备105的最短路径。例如，用户设备105也可以位于区域B中。如此一来，用户设备105建立与LB 160B的任播连接405。
在该示例中，LB 160B选择缓存180B作为用户设备105获取或流送所请求对象的最佳缓存。例如，LB 160B可以默认选择与其共址的缓存180B作为用户设备105的最佳缓存，因为该缓存180B也在与用户设备105相同的区域中。作为响应，LB 160B可以向用户设备105发送HTTP重定向(未示出)，用户设备105终止任播连接405并建立与缓存180B的单播连接410A。用户识别105可以使用单播连接410A从缓存180B获取对象。
图4还示出了替换实施例，其中LB 160B可以替代地选择区域C中的缓存180C作为用户设备105的最佳缓存。即使用户设备在区域B中，缓存180C也可以是出于若干原因而使用的最佳缓存，比如，缓存180B将要被关闭以进行维护、当前过载、或者不具有所请求对象。因此，LB 160B可以替代地发送HTTP重定向，该HTTP重定向建立与缓存180C的单播连接410B。
在另一示例中，LB 160B最初可选择缓存180B作为用于流送对象的最佳缓存，但随后可以改变并选择缓存180C作为更好的选择。例如，在从缓存180B流送对象的过程中，缓存180B可能经历中断单播连接410A的错误或失灵。这可以使用户设备105通过与LB 160B建立任播连接405来重复初始化过程。LB 160B可能已经被通知或检测到缓存180B中的错误，而替代地选择缓存180C作为新的缓存。LB 160B可以提供HTTP重定向，该HTTP重定向使得用户设备105建立与缓存180C的单播连接410B并恢复该流。有利地，用户设备105可以在使用缓存180B时流被中断的位置处使用缓存180C恢复流(假设缓存180B和180C都具有所请求对象的副本)。
图5示出了根据一个实施例的负载平衡器160使用HTTP重定向来向用户设备提供到CDN缓存的单播路径。如图所示，用户设备105可以发送HTTP获取请求505以使用对应于负载平衡器160的任播IP地址来执行任播路由。在为用户设备选择了用于获取对象的最佳缓存(例如，缓存180)之后，负载平衡器160可以用HTTP重定向510来回复获取请求505。如上所述，HTTP重定向510可以关闭任播连接，并为用户设备105提供信息以建立与缓存180的单播连接。如图所示，HTTP重定向510包括URL，该URL包括到缓存180的单播路径，即http://<cache unicast>/path。
响应于HTTP重定向510，用户设备105向缓存发送HTTP获取请求515以建立单播连接。然后，用户设备105可以使用该连接从缓存180获取所请求对象。
在本公开中，提及了各种实施例。然而，应当理解，本公开不限于具体描述的实施例。相反，以下特征和元素的任何组合，无论是否涉及不同的实施例，都预期用于实现和实践这里提供的教导。另外，当以“A和B中的至少一个”的形式描述实施例的元素时，应当理解，仅包括元素A、仅包括元素B、以及包括元素A和B的实施例均被设想。此外，尽管一些实施例可以实现优于其他可能的解决方案或优于现有技术的优点，但是无论给定实施例是否实现特定优点都不限制本公开。因此，本文所公开的方面、特征、实施例和优点仅是说明性的，且不被视为所附权利要求的要素或限制，除非在(一项或多项)权利要求中明确记载。同样，对“本发明”的引用不应被解释为对本文所公开的任何发明主题的概括，并且不应被认为是所附权利要求的要素或限制，除非在(一项或多项)权利要求中明确记载。
如本领域技术人员将理解的，本文描述的实施例可以实现为系统、方法或计算机程序产品。因此，实施例可采取完全硬件实施例、完全软件实施例(包括固件、常驻软件、微代码等)或组合软件和硬件方面的实施例的形式，这些实施例在本文中一般可全部被称为“电路”、“模块”或“系统”。此外，本文描述的实施例可以采取体现于一种或多种计算机可读介质中的计算机程序产品的形式，所述计算机可读介质上体现有计算机可读程序代码。
体现在计算机可读介质上的程序代码可以使用任何恰当的介质来传送，包括但不限于无线、有线、光纤缆、射频(RF)等，或前述的任何适当组合。
用于执行本公开的实施例的操作的计算机程序代码可以用一种或多种编程语言的任何组合来编写，包括面向对象的编程语言，比如Java、Smalltalk、C++等，以及常规的过程编程语言，比如“C”编程语言或类似的编程语言。程序代码可以完全在用户的计算机上执行，部分在用户的计算机上执行，作为独立的软件包，部分在用户的计算机上执行，部分在远程计算机上执行，或者完全在远程计算机或服务器上执行。在后一种情形下，远程计算机可以通过任何类型的网络连接到用户的计算机，包括局域网(LAN)或广域网(WAN)，或者连接到外部计算机(例如，通过使用互联网服务提供商的互联网)。
本文参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图图示或框图来描述本公开的各方面。应当理解，流程图图示或框图的每个框以及流程图图示或框图中的框的组合可以由计算机程序指令来实现。这些计算机程序指令可以被提供给通用计算机、专用计算机或其他可编程数据处理设备的处理器以产生机器，以使得经由计算机或其他可编程数据处理设备的处理器执行的指令创建用于实现在流程图图示或框图的(一个或多个)框中指定的功能/动作的装置。
这些计算机程序指令还可以存储在计算机可读介质中，该计算机可读介质可以指示计算机、其他可编程数据处理装置或其他设备以特定方式起作用，以使得存储在计算机可读介质中的指令产生包括实现在流程图图示或框图的(一个或多个)框中指定的功能/动作的指令的制品。
计算机程序指令还可以被加载到计算机、其他可编程数据处理设备或其他设备上，以使得在计算机、其他可编程数据处理设备或其他设备上执行一系列操作步骤，来产生计算机实现的过程，从而在计算机、其他可编程数据处理设备或其他设备上执行的指令提供用于实现在流程图图示或框图的(一个或多个)框中指定的功能/动作的过程。
图中的流程图图示和框图示出了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实现方式的架构、功能和操作。在这方面，流程图图示或框图中的每个框可以表示代码的模块、片段或部分，其包括用于实现(一个或多个)指定逻辑功能的一个或多个可执行指令。还应当示出的是，在一些可替换的实现方式中，框中指出的功能可以不按附图中指出的顺序发生。例如，取决于所涉及的功能，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反的顺序或不按顺序执行。还应指出的是，框图或流程图图示中的每个框以及框图或流程图图示中的框的组合可由执行指定功能或动作的基于专用硬件的系统或专用硬件和计算机指令的组合来实现。
虽然前述内容针对本公开的实施例，但可在不脱离本公开的基本范围的情况下设计本公开的其他和进一步的实施例，且本公开的范围由所附权利要求确定。

Claims (10)

1.一种方法，包括：
在与内容交付网络(CDN)相关联的负载平衡器和从所述CDN请求对象的用户设备之间建立任播连接；
在所述负载平衡器处，基于一个或多个负载平衡标准从所述CDN中的多个缓存中选择第一缓存来满足对所述对象的请求；以及
从所述负载平衡器向所述用户设备传输HTTP重定向以关闭所述任播连接，其中，所述HTTP重定向包括用于在所述用户设备和所述第一缓存之间建立单播连接以从所述第一缓存获取所述对象的信息。
2.根据权利要求1所述的方法，其中，所述负载平衡器是与所述CDN相关联的多个负载平衡器中的一个负载平衡器，所述多个负载平衡器中的每个负载平衡器具有相同的任播IP地址。
3.根据权利要求2所述的方法，其中，所述多个负载平衡器和所述多个缓存分布在不同的地理区域中，其中，针对所述地理区域中的每个地理区域，所述多个负载平衡器中的至少一个负载平衡器和所述多个缓存中的至少一个缓存共同位于该地理区域中。
4.根据权利要求2所述的方法，其中，在所述用户设备已经执行域名系统(DNS)查找以识别用于与所述负载平衡器建立所述任播连接的所述任播IP地址之后，执行建立所述任播连接。
5.根据权利要求2所述的方法，其中，所述负载平衡器具有所有所述多个负载平衡器中通过网络到所述用户设备的最短路径。
6.根据权利要求5所述的方法，其中，所述任播连接依赖于所述网络中的下层路由协议来识别所述最短路径。
7.根据权利要求1所述的方法，其中，所述HTTP重定向包括HTTP响应状态代码302。
8.根据权利要求1所述的方法，还包括：
在所述任播连接期间在所述负载平衡器处，接收去往所述对象的完整路径以及所述用户设备的IP地址。
9.一种非暂态计算机可读介质，包括计算机程序代码，所述计算机程序代码在由一个或多个计算机处理器操作执行时，执行根据权利要求1至8中任一项所述的方法。
10.一种服务器，包括：
处理器；
存储器，存储有计算机程序代码，所述计算机程序代码在由所述处理器操作执行时，执行根据权利要求1至8中任一项所述的方法。
CN202310269715.6A 2022-03-15 2023-03-15 任播cdn路由中的本地偏好 Pending CN116781613A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/695,581 2022-03-15
US17/695,581 US11706292B1 (en) 2022-03-15 2022-03-15 Local preference in anycast CDN routing

Publications (1)

Publication Number Publication Date
CN116781613A true CN116781613A (zh) 2023-09-19

Family

ID=85703883

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310269715.6A Pending CN116781613A (zh) 2022-03-15 2023-03-15 任播cdn路由中的本地偏好

Country Status (4)

Country Link
US (2) US11706292B1 (zh)
EP (1) EP4246929A1 (zh)
JP (1) JP2023135657A (zh)
CN (1) CN116781613A (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12040978B2 (en) * 2021-04-02 2024-07-16 Microsoft Technology Licensing, Llc Anycast routing technique for a content delivery network
US20240297842A1 (en) * 2023-03-04 2024-09-05 Charter Communications Operating, Llc Dynamic anycast client routing and health management

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
US6785704B1 (en) * 1999-12-20 2004-08-31 Fastforward Networks Content distribution system for operation over an internetwork including content peering arrangements
US6754699B2 (en) * 2000-07-19 2004-06-22 Speedera Networks, Inc. Content delivery and global traffic management network system
US7725596B2 (en) * 2000-04-28 2010-05-25 Adara Networks, Inc. System and method for resolving network layer anycast addresses to network layer unicast addresses
US20030079027A1 (en) * 2001-10-18 2003-04-24 Michael Slocombe Content request routing and load balancing for content distribution networks
US20060112170A1 (en) * 2004-05-03 2006-05-25 Craig Sirkin Geo-locating load balancing
US8180896B2 (en) * 2008-08-06 2012-05-15 Edgecast Networks, Inc. Global load balancing on a content delivery network
EP2159983A1 (en) * 2008-08-26 2010-03-03 BRITISH TELECOMMUNICATIONS public limited company Content distribution network
US9426213B2 (en) * 2008-11-11 2016-08-23 At&T Intellectual Property Ii, L.P. Hybrid unicast/anycast content distribution network system
US8966033B2 (en) * 2009-08-17 2015-02-24 At&T Intellectual Property I, L.P. Integrated proximity routing for content distribution
US9450804B2 (en) * 2009-09-03 2016-09-20 At&T Intellectual Property I, L.P. Anycast aware transport for content distribution networks
US8560598B2 (en) * 2009-12-22 2013-10-15 At&T Intellectual Property I, L.P. Integrated adaptive anycast for content distribution
US9495338B1 (en) * 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US8621042B2 (en) * 2010-12-27 2013-12-31 Limelight Networks, Inc. Anycast redirect to unicast content download
US8745177B1 (en) * 2011-11-01 2014-06-03 Edgecast Networks, Inc. End-to-end monitoring and optimization of a content delivery network using anycast routing
US9141669B2 (en) * 2013-01-22 2015-09-22 Go Daddy Operating Company, LLC Configuring an origin server content delivery using a pulled data list
US10560509B2 (en) * 2013-07-05 2020-02-11 Qualcomm Incorporated Method and apparatus for using HTTP redirection to mediate content access via policy execution
US20150172354A1 (en) * 2013-12-17 2015-06-18 Limelight Networks, Inc. Content-delivery transfer for cooperative delivery systems
US9467506B2 (en) * 2014-01-27 2016-10-11 Google Inc. Anycast based, wide area distributed mapping and load balancing system
EP3213222B1 (en) * 2014-10-27 2021-03-24 Level 3 Communications, LLC Content delivery systems and methods
US10735528B1 (en) * 2015-12-14 2020-08-04 Amazon Technologies, Inc. Geographic relocation of content source in a content delivery network
US10341849B2 (en) * 2016-08-31 2019-07-02 Level 3 Communications, Llc Anycast manifest retrieval, unicast content retrieval
WO2018188073A1 (zh) * 2017-04-14 2018-10-18 华为技术有限公司 内容部署方法及分发控制器
US11075987B1 (en) * 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10104039B1 (en) * 2017-09-28 2018-10-16 Cloudflare, Inc. Establishing and using a tunnel from an origin server in a distributed edge compute and routing service
WO2019125483A1 (en) * 2017-12-22 2019-06-27 Nokia Technologies Oy Designs of an mptcp-aware load balancer and load balancer using the designs
US10531130B2 (en) * 2018-01-23 2020-01-07 Charter Communications Operating, Llc Protocol and architecture for the decentralization of content delivery
CN114270312A (zh) * 2019-06-21 2022-04-01 奇跃公司 经由模态窗口的安全授权
US11178433B2 (en) * 2019-11-21 2021-11-16 Pluto Inc. Methods and systems for dynamic routing of content using a static playlist manifest
US11831707B2 (en) * 2022-03-08 2023-11-28 Charter Communications Operating, Llc Redirect processing for content delivery networks

Also Published As

Publication number Publication date
JP2023135657A (ja) 2023-09-28
US11706292B1 (en) 2023-07-18
EP4246929A1 (en) 2023-09-20
US20230362240A1 (en) 2023-11-09

Similar Documents

Publication Publication Date Title
EP2897340B1 (en) Routing proxy for adaptive streaming
EP3014855B1 (en) Dynamic content distribution network selection based on context from transient criteria
US20150264009A1 (en) Client-selectable routing using dns requests
US10848427B2 (en) Load balanced access to distributed endpoints using global network addresses and connection-oriented communication session handoff
US11277341B2 (en) Resilient segment routing service hunting with TCP session stickiness
CN116781613A (zh) 任播cdn路由中的本地偏好
US9363313B2 (en) Reducing virtual IP-address (VIP) failure detection time
CN113826363A (zh) 全局网络接入点中冗余控制器之间的一致路由公告
US11711293B2 (en) Per-provider origin pull
US10848586B2 (en) Content delivery network (CDN) for uploading, caching and delivering user content
US11750718B2 (en) Accelerating dynamic content delivery in a content delivery network
US11895009B2 (en) Intelligently routing internet traffic
US11863655B2 (en) Method and system for reliable application layer data transmission through unreliable transport layer connections in a network
US20160285961A1 (en) Delivering managed and unmanaged content across a network
US20190037044A1 (en) Content distribution and delivery optimization in a content delivery network (cdn)
JP5726302B2 (ja) トポロジサーバを用いた、通信アーキテクチャにわたって分散されたノードのネットワークに対する秘密または保護されたアクセス
JP2003152785A (ja) コンテンツ配信ネットワーク、アドレス通知端末、および通信制御装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination