Yanjiasen4's Blog

远古Paper: CDN Broker读后感想以及对CDN的一些想法

  因为要做毕设,最近在关注CDN方面的技术。前不久,导师给我推荐了一篇“远古”论文:发表在第六次国际网络缓存与内容分发讨论会(International Workshop on Web Caching and Content Distribution)上的《CDN Broker》,
而这次会议的时间是2001年。十几年过去,这篇论文里的一些设想已经被实现,而一些设计仍旧有借鉴之处。

论文简析

这篇论文是由AT&T公司研究的题目。2001世界互联网处在高速发展的阶段,爆发式增长的用户让当时的网络内容提供商ICP(Internet Content Provider)感到亚历山大,于是就有了最早的内容分发网络(Content Distribution Network),
本文试图为CDN提供一种管理层,就像经纪人(Broker)一样让网络内容能够更自由灵活地被分发。

摘要

描述了CDN的作用,并且提出了CDN Broker系统,可以将用户的请求智能重定向到其他CDN,以获得最佳的用户体验和达到负载均衡

简介

介绍了CDN出现的原因和局限性,并且提到国际互联网工程任务组(IETF)正在完善相关协议,让CDN之间的信息交互更迅速及时。
让CDN Broker的完善成为可能。为了完成Broker,论文中设计了一种智能DNS - Intelligent DNS,可以根据用户的IP信息自动为其进行域名解析服务。
这一想法如今已经成为广泛应用的技术。

背景与动机

进一步解释了CDN的局限性:CDN不是均等的,有些很庞大,有些只在很小的区域内能高效工作。不同CDN之间难以完成之前良好的连接,
除非使用昂贵的BGP协议连接(BGP定义了不同自治系统AS互相连接的规范,但是通常需要较好的网络和路由支持)。
而且想要让CDN覆盖区域的每个主机非常难;论文接着说,他们认为CDN之间互相交换请求在经济利益上也有很大的好处,因为这样就可以防止单独一个CDN在面对请求高峰时的负载过高而无法正常提供服务。
CDN Broker提供了一种让CDN可以将自己的锅甩给别人的机制,并且根据一些请求和CDN提供的信息达到服务高效率和负载均衡。

Brokering组成

这一部分介绍了CDN Broker的构成。

选择CDN

如何选择一个CDN作为当前请求的重定向目标,这需要实现两个功能:

  1. 识别请求从哪里来
  2. 知道这个请求被重地位到哪里能获得最好的效果

重定向

介绍了CDN Broker的重定向机制,如下图所示:
CDN Broker重定向
其中红色的圆角矩形是CDN,粉红色的圆角矩形是CDN服务器。
一个客户的请求,例如你打开一个网站,我们假设没有缓存,请求将先被发送给你的网络所在ISP的DNS进行解析,然后由ISP的DNS选择一个带有Broker的CDN进行进一步解析。
一个使用CDN Broker的CDN系统应对一个请求的典型行为分为两种情况:

  • 内部服务: Broker发现当前请求能够依靠自己本身的CDN系统完成(缓存、自己的DNS存在目标的A记录等)
  • 外部服务: Broker将请求重定向给外部的CDN

本文着重介绍外部服务的情况。

命名

这一节描述了提供内容的服务器是如何被选择,让请求转发后,新的接受请求的CDN如何知道应该提供什么内容的。

DNS映射

当CDN Broker将一个请求重定向给一个外部的CND时,如果是根据NS记录,那么新的DNS知道请求的原地址,可以继续进行解析;
如果是根据CNAME记录,新的CDN将对一个别名进行解析,CDN Broker需要将自己的域加在请求里,使得新的CDN知道请求是被谁发来的。

1
a.example.com -> a.example.com.B.G.com

内容获取

新的CDN拿到请求后,如何得到内容呢?正常情况下,CDN会去缓存里查找请求url,文中提到可以静态地把目标服务器的IP与其域名映射起来,绕过DNS这一步,防止循环重定向。

计费

CDN需要为它的用户计费,当前(2001年)主要根据流量计费。但是不同CDN之间的信息交互尚未有一个标准,
这将导致Broker缺乏信息从费用方面做优化。文中说有许多组织正在努力标准化CDN信息交互,这部分工作希望能在以后完成。

IDNS架构

IDNS是本论文提出的一套系统,后面也说到AT&A已经把这一系统申请为专利。

智能DNS包括两个部分:DNS引擎和控制中心。控制中心接收各种有用的信息来动态更新配置——三张表(接下来会讲到),DNS引擎根据当前的配置对请求做智能解析。
IDNS架构
IDNS会将请求按照地区进行分类,这里论文引用了另外一片论文中的方法,大致就是根据CIDR对IP地址做最长前缀匹配然后把匹配结果相同的归为同一地区。

DNS元素

DNS引擎里的DNS必须要高可靠性,并且能够保证在数据库进行原子性更新时,仍能正常进行DNS解析。这个特性可以使用UNIX的copy-on-write实现。

DNS引擎操作

DNS开始时初始化配置表,然后打开对UDP DNS解析请求和接受DNS控制端更新指令的两个socket。

配置表的管理

DNS元素维护三种配置表:

  1. 地区表:将请求IP转化为地区

    1
    (IP, region)
  2. 分发表:每个DNS维护多张分发表,表被按照下面的用户进行分类,每张表里都记录着一组CDNs对各个地区的适用概率。

    1
    CustomerID (region, CDNs, probability)
  3. 用户表
    用户表根据请求的DNS名字将用户进行区分。设计这一层的目的是让在分发表里的查询更快更准确,因为分发表受到CDNs配置的影响,而一些特定CDN又常常为一些特定区域的用户服务(同一个ISP出口的DNS)。

    1
    (DNS name, CustomerID)

DNS引擎解析过程

首先根据地区表得到请求的地区,再根据用户表确定分发表,最后到分发表中根据地区找到可以转发请求的一个或多个CDNs

整个过程只需要一次最长前缀匹配进行地区匹配,一次哈希表查询得到用户对应的分发表,一次数组查询在分发表中得到可以进行转发的CDN集和概率,和一次随机数生成决定转发请求的对象。

控制元素

控制元素主要负责上面几个配置表的管理和更新

控制数据结构

控制元素需要运行上面提到的算法,对IP进行地区分类;根据请求DNS的名字对用户进行分类;最关键的是需要获取CDN的负载状况和对地区的覆盖情况来决定其对应的分发概率。

负载均衡

为了防止flash crowds(突发的大量访问),控制元素需要对CDN做负载均衡控制。由于当时的CDN信息交换同步规范较差,文中没有给出很好的解法,只是含糊地介绍了一下大致思路。

代理器

几个具体的进程分别用来配置、管理、读取信息。

性能

文章分析CDN Broker跟普通的CDN相比,可能存在三个方面的性能差异:

  1. CDN Broker的DNS——IDNS的性能
  2. 请求多次转发中间产生的延迟
  3. CDN Broker产生的潜在性能提升,包括:CDN容量的提升、费用降低、容错率和响应速率的提升

实验

然后作者针对IDNS的性能、重定向的延迟和总体性能做了三个实验。其实很多地方都没有实现,而是采取模拟的方式,这里不再赘述。无非就是证实自己的方法确实有提升。

相关工作

  1. 相关组织正在加快制定代理平台间相互合作的规范
  2. 基于DNS的负载均衡技术被广泛应用,但只是针对一组相关的CDNs。而CDN Broker是针对全体CDNs。
  3. Shaikh和Tewari认为对网络的测量接近于对对HTTP请求DNS解析服务的测量,所以CDN Broker在这个假设下是很有价值的。

结论

CDN是个很新而又很重要的领域,作者试图让多个网络能够良好地互相协作,而不是建立一个大而全的网络覆盖所有地区。IDNS已经申请成为专利,并且已经有部分AT&T的用户用上了IDNS。

想法

2001我们家应该还没装上网。而深受摩尔定律等概念的熏陶,从现在往回看,总感觉那个时候的网络还是“蛮荒时代”。
但是读了这篇论文,才发现那个时候网络的许多技术和想法已经十分成熟,并且有些被沿用至今而难以被取代。

这个时代,网络内容和计算量的需求量更是远超2001年。云计算和大数据等概念的兴起,对CDN技术提出了新的要求。
前几年的中国,CDN市场被网宿、蓝汛等传统CDN公司垄断。而近几年,随着需求的提升和业内技术的提升,许多网络公司都开启了自己的云服务器服务,开始进军CDN领域。
其中包括:阿里云、百度云、腾讯云等知名ICP,还有迅雷的星域、快播倒塌后创立的云帆等。

CDN百家齐放,服务速度和容量跟过去比都有了长足的提升。
但是人类永远是贪婪的,超高清、大数据分析、云计算、直播等新需求又纷纷出现。
也许我们确实需要一个Broker,将这些CDN或是其他的代理网络有机地连接在一起,为全世界分发精彩纷呈的内容。

坚持原创技术分享,您的支持将鼓励我继续创作!