软件测试管理

当前位置:首页 > 软件测试管理

《计算机网络:自顶向下方法》第七章 续2

7.2.4内容分发网


今天,许多因特网视频公司日复一日地向数以百万计的用户按需分发每秒数兆比特的流。例如,YouTube的视频库藏有几亿个,每天向全世界的用户分发几亿条流[ Ding2011]。向位于全世界的所有用户流式传输所有流量同时提供连续播放和高交互性显然是一项有挑战性的任务。


对于一个因特网视频公司,或许提供流式视频服务最为直接的方法是建立单一的大规模数据中心,在数据中心中存储其所有视频,并直接从该数据中心向世界范围的客户传输流式视频。但是这种方法存在三个问题。首先,如果客户远离数据中心,服务器到客户的分组将跨越许多通信链路并很可能通过许多ISP,其中某些ISP可能位于不同的大洲。如果这些链路之一提供的吞吐量小于视频消耗速率,端到端吞吐量也将小于该消耗速率,给用户带来恼人的停滞时延。(第1章讲过,一条流的端到端吞吐量由瓶颈链路的吞吐量所决定。)出现这种事件的可能性随着端到端路径中链路数量的增加而增加。第二个缺陷是流行的视频很可能经过相同的通信链路发送许多次。这不仅浪费了网络带宽,因特网视频公司自已也将为向因特网反复发送相同的字节而向其ISP运营商(连接到数据中心)支付费用。这种解决方案的第三个问题是单个数据中心代表一个单点故障,如果数据中心或其通向因特网的链路崩溃,它将不能够分发任何视频流了。


为了应对向分布于全世界的用户分发巨量视频数据的挑战,几乎所有主要的视频流公司都利用内容分发网( Content Distribution Network, CDN)。CDN管理分布在多个地理位置上的服务器,在它的服务器中存储视烦(和其他类型的Web内容,包括文档、图片和音频)的副本,并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN ( private CDN),即它由内容提供商自己所拥有;例如,谷歌的CDN分发YouTube视频和其他类型的内容。另一种CDN可以是第三方CDN ( third- partyCDN),它代表多个内容提供商分发内容;例如,Akamia 的CDN是一个第三方CDN,在其他用户中分发Netlix和Hulu。现代CDN的一个可读性强的展望见[ Leighton 2009]。



学习案例


谷歌的网络基础设施


为了支持谷歌的巨量云服务阵列,包括搜索、gmail、 日程表、YouTube视频、地图、文档和社交网络,谷歌已经部署了一个广泛的专用网和CDN基础设施。谷歌的CDN基础设施具有三个等级的服务器集群:


●8个“大型数据中心”,其中6个位于美国,2个位于欧洲[ Google Locations2012],每个数据中心具有10万台左右的服务器。这些“大型数据中心”负责服务于动态的(并且经常是个性化的)内容,包括搜索结果和gmail报文。


●大约30个“邀请做客( bring home)服务器”集群(参见7.2.4节),其中每个集群大约由100~500台服务器组成[ Adhikari 2011a]。这些集群位置分布于全球,每个位置通常靠近多个第一层ISP PoP。这些集群负责服务于静态内容,包括YouTube视频[ Adhikari 2011a]。


●数以百计的“深入(enter-deep) 服务器”集群(参见7.2.4节),每个集群位于一个接入ISP中。这里一个集群通常由位于一个机架上的数十台服务器组成。这些“深入服务器”执行TCP分岔(参见3.7节)并服务于静态内容[ Chen2011],包括体现搜索结果的Web网页的静态部分。


所有这些数据中心和集群位置与谷歌自己的专用网连接在一起,作为一个巨大的AS (AS 15169) 的一部分。当某用户进行搜索请求时,该请求常常先经过本地ISP发送到邻近的“深入服务器”缓存中,从这里检索静态内容;同时将该静态内容提供给客户,邻近的缓存也经谷歌的专用网将请求转发给“大型数据中心”,从这里检索个性化的搜索结果。对于某YouTube视频,该视频本身可能来自一个“邀请坐客服务器”缓存,而围绕该视频的Web网页部分可能来自邻近的“深入服务器”缓存,围绕该视频的广告来自数据中心。总的来说,除了本地ISP,谷歌云服务在很大程度上是由独立于公共因特网的网络基础设施提供的。



CDN通常采用两种不同的服务器安置原则[Huang2008]:


●深入。第一个原则由Akamai首创,该原则是通过在遍及全球的接人ISP中部署服务器集群来深入到ISP的接人网中。(在1.3节中描述了接入网。) Akamai 在大约1700个位置采用这种方法部署集群。其目标是靠近端用户,通过减少端用户和CDN集群之间(内容从这里收到)链路和路由器的数量,从而改善了用户感受的时延和吞吐量。因为这种高度分布式设计,维护和管理集群的任务成为挑战。


●邀请做客。第二个设计原则由Limelight和许多其他CDN公司所采用,该原则是通过在少量(例如10个)关键位置建造大集群并使用专用高速网络连接这些集群来邀请到ISP做客。不是将集群放在接入ISP中,这些CDN通常将每个集群放置在这样的位置上,即同时靠近许多第一层ISP的PoP的位置(参见1.3节),例如,一个大城市中同时靠近AT&T PoP和Verizon PoP的几英里范围内。与深人设计原则相比,邀请做客设计通常产生较低的维护和管理开销,可能以对端用户的较高时延和较低吞吐量为代价。


一旦CDN的集群准备就绪,它就可以跨集群复制内容。CDN可能不希望将每个视频的副本放置在每个集群中,因为某些视频很少观看或仅在某些国家中流行,事实上,许多CDN没有将视频推人它们的集群,而是使用一种简单的拉策略:如果客户向一个未存储该视频的集群请求某视频,则该集群检索该视频( 从某中心仓库或者从另一个集群),向客户流式传输视频时的同时在本地存储一个副本。 类似于因特网缓存(参见第2章),当某集群存储器变满时,它删除不经常请求的视频。


1. CDN操作


在讨论过这两种部署CDN的重要方法后,我们现在深入看看CDN操作的细节。当用户主机中的一个浏览器指令检索一个特定的视频 (由URL标识)时,CDN必须截获该请求,以便能够:①确定此时适合用于该客户的CDN服务器集群;②将客户的请求重定向到该集群的某台服务器。我们很快将讨论CDN是如何能够确定一个适当的集群的。但是我们首先考察截获和重定向请求所依赖的机制。


大多数CDN利用DNS来截获和重定向请求;这种使用DNS的一个有趣讨论见[ Vixie2009]。我们考虑用一个简单的例子来说明通常是怎样涉及DNS的。假定一个内容提供商NetCinema,雇佣了第三方CDN公司KingCDN来向其客户分发视频。在NetCinema的Web网页上,它的每个视频都被指派了一个URL, 该URL 包括了字符串 “video" 以及该视频本身的独特标识符;例如,转换器7可以指派为http:// video. netcinema. com/6Y7B23V。接下来出现如图7-4所示的6个步骤:


1)用户访问位于NetCinema的Web网页。


2)当用户点击链接http://video. netcinema. com/6Y7B23V时,该用户主机发送了一个对于video. netcinema. com的DNS请求。


3)用户的本地DNS服务器(LDNS)中继该DNS请求到一台用于NetCinema的权威DNS服务器,该服务器观察到主机名video. netcinema. com中的字符串“ video"。为了将该DNS请求移交给KingCDN, NetCinema 权威DNS服务器并不返回一个IP地址,而是向LDNS返回一个KingCDN域的主机名,如al 105. kingedn. com。


4)从这时起,DNS请求进人了KingCDN专用DNS基础设施。用户的LDNS则发送第二个请求,此时是对al 105. kingedn. com的DNS请求,KingCDN 的DNS系统最终向LDNS返回KingCDN内容服务器的IP地址。所以正是在这里,在KingCDN的DNS系统中,指定了CDN服务器,客户将能够从这台服务器接收到它的内容。


5) LDNS向用户主机转发内容服务CDN结点的IP地址。


6)一旦客户收到KingCDN内容服务器的IP地址,它与具有该IP地址的服务器创建了一条直接的TCP连接,并且发出对该视频的HTTP GET请求。如果使用了DASH, 服务器将首先向客户发送具有URL列表的告示文件,每个URL对应视频的每个版本,并且客户将动态地选择来自不同版本的块。


《计算机网络:自顶向下方法》第七章 续1


2.集群选择策略


任何CDN部署,其核心是集群选择策略( cluster selection strategy),即动态地将客户定向到CDN中服务器集群或数据中心的机制。如我们刚才所见,CDN经过客户的DNS查找得知了该客户的LDNS服务器的IP地址。在得知该IP地址之后,CDN需要基于该IP地址选择一个适当的集群。CDN一般采用专用的集群选择策略。我们现在简单地介绍一些自然的策略,每种策略都有其优点和缺点。


一种简单的策略是指派客户到地理上最为邻近( geographically closest) 的集群。使用商用地理位置数据库(例如Quova [ Quova 2012]和Max- Mind [ MaxMind 2012]),每个LDNS IP地址都映射到一个地理位置。当从一个特殊的LDNS接收到一个DNS请求时,CDN选择地理上最为接近的集群,即离LDNS几千米远的集群,“就像鸟飞-样”。这样的解决方案对于众多用户来说能够工作得相当好[ Agarwal 2009]。但对于某些客户,该解决方案可能执行的效果差,因为地理最邻近的集群可能并不是沿着网络路径最近的集群。此外,一种所有基于DNS的方法都内在具有的问题是某些端用户配置使用位于远地的LDNS[ Shaikh 2001; Mao 2002],在这种情况下,LDNS 位置可能远离客户的位置。此外,这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化,总是为特定的客户指派相同的集群。


为了基于当前流量条件为客户决定最好的集群,CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量( real- time measurement)。例如,CDN能够让它的每个集群周期性地向位于全世界的所有LDNS发送探测分组(例如,ping 报文或DNS请求)。这种方法的一个缺点是许多LDNS配置为不会对这些探测进行响应。


发送测量路径性质的外部流量的另一种方法是,使用客户与CDN服务器之间近期和进行中的流量特点。例如,客户与集群之间的时延能够通过观察TCP三次握手过程中服务器到客户SYNACK和客户到服务器ACK之间的间隙进行估计。然而,这种解决方案为了测量到这些集群路径的性质,时不时地需要将客户重定向到(可能的)次优化集群。尽管仅有少量的请求需要作为探测分组而工作,但选择的客户在接收内容( 视频或其他)时可能经受很大的性能下降[ Andrews 2002; Krishan 2009]。对于集群到客户路径的另一种探测方法是使用DNS请求流量来测量客户和集群之间的时延。具体而言,在DNS阶段(在图7-4步骤4中),客户的LDNS能够偶尔地定向到不同的权威DNS服务器,这些服务器可以安装在各个集群位置,产生DNS流量,这些流量则能够在LDNS和这些集群位置之间测量到。使用这种方案,DNS服务器继续向该客户返回优化的集群,使得交付视频和其他Web对象不会受到损害[ Huang 2010]。


使客户与CDN服务器匹配的一种非常不同的方法是使用IP任播(IP anyeast) [ RFC1546]。IP任播基于的思想是让因特网中的路由器将客户的分组路由到“最近的”集群,就像由BGP决定的那样。具体而言,如图7-5 中所示,在IP任播配置阶段,CDN公司为它的每个集群指派相同的IP地址,并且使用标准的BCP从每个不同的集群位置来通告该IP地址。当一个BCP路由器接收到对这个相同的IP地址的多个路由通告时,它对待这些通告就像对相同的物理位置提供了不同的路径(事实上,在这个时候,这些通告对不同的物理位置用了不同的路径)。遵循标准的操作过程,则BGP路由器将根据其本地路由选择机制,对该IP地址选择“最好的”(例如最近的,就像AS跳计数所决定的那样)路由。例如,如果一个BGP路由(对应于一个位置)离该路由器仅一个AS跳的距离,并且所有其他BGP路由(对应于其他位置)是两个或更多AS跳,则BGP路由器将通常选择使分组路由到需要仅通过一个AS的位置(参见4.6节)。在这个初始配置阶段后,CDN能够从事内容分发的主要工作。当任何客户要观看任何视频时,CDN的DNS返回该任播地址,而无论该客户位于何处。当客户向该IP地址发送分组时,该分组被路由到“最近的”集群,如同由预先配置的转发表决定的那样,该转发表用BGP进行配置,如刚才描述的那样。这种方法具有如下优点,发现的集群最靠近客户而不是最靠近该客户的LDNS。然而,IP任播策略仍未顾及因特网在短时间范围内的动态性质[ Ballani 2006]。


除了诸如时延、丢包和带宽性能等网络相关考虑外,在设计集群选择策略时还有许多要考虑的重要因素。集群上的负载就是一个这样的因素,即客户不应当定向到过载的集群。ISP交付成本是另外一个因素,即可以选择特定的集群,使得用特定的ISP承载CDN到客户的流量,兼顾到ISP和集群操作者之间的契约关系中的不同的成本结构。


《计算机网络:自顶向下方法》第七章 续2


相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~