在公司项目经历过DDoS攻击后,选用了一些比较成熟的DDoS防护厂商,在学习过程中,发现,许多DDoS厂商的防护技术都离不开 Anycast网络。
所以在这里整理一下AnyCast的相关资料。
在讲解任播 (AnyCast) 前,我们先来说说 TCP/IP 协议里常见的几种数据传输方式单播、组播、广播。
单播(Unicast)是指封包在计算机网络的传输过程中,目的地址为单一目标的一种传输方式。每次只有两个实体相互通信,发送端和接收端都是唯一确定的。它是现今网络应用最为广泛,通常所使用的网络协议或服务大多采用单播传输,例如一切基于 TCP 的协议。
单播地址范围:在 IPv4 网络中,0.0.0.0 到 223.255.255.255 属于单播地址。
单播地址优点:
单播地址缺点:
多播(Multicast,台湾又译作多点发送、多点广播或群播,中国大陆又译作组播)是指把信息同时传递给一组目的地址。它使用策略是最高效的,因为消息在每条网络链路上只需传递一次,而且只有在链路分叉的时候,消息才会被复制。
与多播相比,常规的点到点的传递被称作单播。当以单播的形式把消息传递给多个接收方时,必须向每个接收者都发送一份数据副本。由此产生的多余副本将导致发送方效率低下,且缺乏可扩展性。不过,许多流行的协议用限制接收者数量的方法弥补了这一不足(例如:XMPP)。
多播组可以是永久的也可以是临时的。多播组地址中,有一部分由官方分配的,称为永久多播组。永久多播组保持不变的是它的 IP 地址,组中的成员构成可以发生变化。永久多播组中成员的数量都可以是任意的,甚至可以为零。那些没有保留下来供永久组播组使用的 IP 多播地址,可以被临时多播组利用。
以太网传输单播 IP 报文的时候,目的 MAC 地址使用的是接收者的 MAC 地址。但是在传输多播报文时,传输目的不再是一个具体的接收者,而是一个成员不确定的组。所以使用的是多播 MAC 地址。
多播 MAC 地址是和多播 IP 地址对应的。IANA 规定,多播 MAC 地址的高 24 位为 0x01005e,低 23 位的 MAC 地址为多播 IP 地址的低 23 位。
由于 IP 多播地址的后 28 位中只有 23 位被映射到 MAC 地址,这样就会有 32 个 IP多播地址映射到同一 MAC 地址上。
多播地址分配情况:
224.0.0.0 - 224.0.0.255 为预留的多播地址(永久组地址),地址 224.0.0.0 保留不做分配,其它地址供路由协议使用。
224.0.1.0 - 224.0.1.255 是公用多播地址。
224.0.2.0 - 238.255.255.255 为用户可用的多播地址(临时组地址),全网范围内有效。
239.0.0.0 - 239.255.255.255 为本地管理组播地址,仅在特定的本地范围内有效。
永久的多播地址分配情况:
224.0.0.0 基准地址(保留)
224.0.0.1 所有主机的地址 (包括所有路由器地址)
224.0.0.2 所有多播路由器的地址
224.0.0.3 不分配
224.0.0.4 DVMRP 路由器
224.0.0.5 所有 OSPF 路由器
224.0.0.6 OSPF DR/BDR
224.0.0.7 ST 路由器
224.0.0.8 ST 主机
224.0.0.9 RIP-2 路由器
224.0.0.10 Eigrp 路由器
224.0.0.11 活动代理
224.0.0.12 DHCP 服务器/中继代理
224.0.0.13 所有 PIM 路由器
224.0.0.14 RSVP 封装
224.0.0.15 所有 CBT 路由器
224.0.0.16 指定 SBM
224.0.0.17 所有 SBMS
224.0.0.18 VRRP
多播优点:
需要相同数据流的客户端加入相同的组共享一条数据流,节省了服务器的负载。
由于多播协议是根据接受者的需要对数据流进行复制转发,所以服务端的服务总带宽不受客户接入端带宽的限制。IP 协议允许有 2 亿 6 千多万个(268435456)组播,所以其提供的服务可以非常丰富。
此协议和单播协议一样允许在 Internet 宽带网上传输。
多播缺点:
与单播协议相比没有纠错机制,发生丢包错包后难以弥补,但可以通过一定的容错机制和 QOS 加以弥补。
现行网络虽然都支持组播的传输,但在客户认证、QOS(指一个网络中能够利用各种基础技术,为指定的网络通信提供更好的服务能力。QOS 是网络的一种安全机制,用来解决网络延迟和阻塞等问题的一种技术。)等方面还需要完善。
尽管 IP 多播是一个非常令人满意的概念模型,但它对于网络内部的状态需求要比仅提供尽力而为服务的 IP 单播模型大得多,在这一点上已经遭到了一些人的批评。更糟的是,到目前为止还没有一种机制能保证 IP 多播模型可以被扩展到足以容纳数以百万计的发送者和多播组的地步,而这往往又是使完全通用的多播应用成为商用互联网中的实际应用的必要条件。
广播(Broadcast)是指封包在计算机网络中传输时,目的地址为网络中所有设备的一种传输方式。实际上,这里所说的所有设备也是限定在一个范围之中,称为广播域。
并非所有的计算机网络都支持广播,例如 X.25 网络和帧中继都不支持广播,而且也没有在整个互联网范围中的广播。IPv6 亦不支持广播,广播相应的功能由多播代替。
通常,广播都是限制在局域网中的。比如:以太网或令牌环网络,因为广播在局域网中造成的影响远比在广域网中小得多。
广播地址范围:以太网和 IPv4 网都用全 1 的地址表示广播,分别是 ff:ff:ff:ff:ff:ff 和 255.255.255.255。
广播优点:
网络设备简单,维护简单,布网成本低廉。
由于服务器不用向每个客户机单独发送数据,所以服务器流量负载极低。
广播缺点:
无法针对每个客户的要求和时间及时提供个性化服务。
网络允许服务器提供数据的带宽有限,客户端的最大带宽=服务总带宽。例如有线电视的客户端的线路支持 100 个频道(如果采用数字压缩技术,理论上可以提供 500 个频道),即使服务商有更大的财力配置更多的发送设备、改成光纤主干,也无法超过此极限。也就是说无法向众多客户提供更多样化、更加个性化的服务。
广播禁止在 Internet 宽带网上传输。
Anycast IP,则是集Multicast和Unicast特性于一身的特殊IP地址类型
从宏观上来说,Anycast类似于Multicast,同一种类型的数据流同时存在多个接收者。
而从微观上来说,Anycast又有着Unicast的唯一性。每一个单独的IP会话都能够找到唯一的源主机和目标主机。
咋看之下很矛盾,其实不然.
以DNS请求为例,假设全国人民同一时间发送1百万个DNS请求,他们都是发送给1.1.1.1的Anycast DNS服务器地址。
宏观上来说,所有数据包都送达给了分布在全国各地的DNS服务器。处于各地的DNS服务器分别接收到了一定数量的DNS请求,并作出回复。这体现了Multicast的特性。
微观上,某一个特定的DNS请求数据包,一定是发送给了某一台DNS主机,而不是同时又多台DNS主机接收到了此数据包。此为Unicast特性。
在Anycast 环境下,总的来说,同时存在多个有效的数据包接收端,但是就某一个特定IP数据包而言,仅有一个接收端主机收到了此数据包。
Anycast 最初是在 RFC1546 中提出并定义的,根据 RFC1546 的说明 IPv4 的任播地址不同于 IPv4 的单播地址,它建议从 IPv4 的地址空间分配出一块独立的地址空间作为任播地址空间。
Anycast 提供的是一种无状态的、尽力而为的服务,目前对于 Anycast 的中文译称主要有任播、泛播、选播等。任播的基本概念是从物理主机设备中分离出的逻辑服务标识符,任播地址可以根据服务类型来分配,使得网络服务担当一个逻辑主机的角色。
RFC1546 定义的这种任播没有得到广泛的使用,在 1998 年的 RFC2373 规定了 IPv6 寻址体系结构。在这个文档中改进了任播的定义:发送到一个任播地址的报文被传送到由该地址标识的接口之一(根据路由协议的距离量度最近的一个)。RFC2373 定义的 IPv6 的任播模型没有限制路由选择的下部结构,也没有限制可使用该服务的上部协议。
RFC3513 (废弃了 RFC 2373)中,进一步对任播进行了定义:任播地址被分配给两个以上的接口 (一般指不同 IP 地址的节点) ,而发送到这个地址上的分组被路由到最近的接口。这里最近可以是指路由器 跳数、服务器负载、服务器吞吐量、客户和服务器之间的往返时间 (RTT,round trip time)、链路的可用带宽等特征值 (metric) 决定。
在实际应用中,任播 (Anycast) 是一种网络寻址和路由的策略。Anycast 采用将一个单播地址分配到处于 Internet 中多个不同物理位置的主机上,发送到这个主机的报文被网络路由到路由协议度量的最近的目标主机上。
例如:在 IP 网络上通过一个 Anycast 地址标识一组提供特定服务的主机,同时服务访问方并不关心提供服务的具体是哪一台主机(比如:DNS 或者镜像服务),访问该地址的报文可以被 IP 网络路由到这一组目标中的任何一台主机上。
任播与单播、广播和组播区别:
在单播中,在网络地址和网络节点之间存在一一对应的关系。
在广播和多播中,网络地址和网络节点之间存在一对多的关系。每一个目的地址对应一群接收可以复制信息的节点。
在任播中,网络地址和网络节点之间存在一对多的关系。每一个地址对应一群接收节点,但在任何给定时间,只有其中之一可以接收到传送端来的信息。
在互联网中,通常使用边界网关协议来实现任播。
任播优点:
不同客户端将访问不同目的主机,此过程对客户端透明,从而实现了目的主机的负载均衡。
当任意目的主机接入的网络出现故障,导致该目的主机不可达时,客户端请求可以在无人为干预的情况下自动被路由到目前可达的最近目的主机,在一定程度上为目标主机提供了冗余性。
当目的主机受到 DoS 攻击而无法到达时,由于网络不可到达,客户端请求也将路由到其它目的主机上。而在 DDoS 攻击时,由于任播的负载均衡效应,避免了单台目的主机承受所有攻击流量,因此在一定程度上为目的主机提高了安全性。
因为任播利用路由度量到最近的目的主机,提高了客户端响应速度。
任播缺点:
使用任播中的共享单播地址不能作为客户端发起请求,因为请求的响应不一定能返回到发起的任播单播地址。因此,目前任播仅适合一些特定的上层协议。从目前的实际应用来看,任播最广泛的应用是 DNS 的部署。
BGP anycast就是利用一个(多个) as号码在不同的地区广播相同的一个ip段。利用bgp的寻路原则,短的as path 会选成最优路径(bgp寻路原则之n),从而优化了访问速度。
其实bgp anycast是不同服务器用了相同的ip地址。阿里的DNS 就是使用了BGP AnyCast。"其实bgp anycast是不同服务器用了相同的ip地址。" 言简意赅啊!
"DNS多点部署IP Anycast+BGP实战分析", 根据这个网页资料,BGP anycast 的理解是IP anycast + bgp, ip anycast(ip任播) 本身就是多个主机使用同一个IP地址(该地址即这一组主机的共享单播地址)的一种技术,当发送方发送报文给这个共享单播地址时,报文会根据路由协议路由到这一组主机中离发送方最近的一台,所以这个技术也可以用来做负载均衡。
这里为什么提到BGP?因为在一些场合下AnyCast与BGP的应用是密不可分的?主要看下章,AnyCast的应用场景。
在企业网络环境中,Anycast不太常见,其主要应用于大范围的DNS部署,CDN数据缓存,数据中心等。
自然而然,很多做企业网络维护的朋友会有疑问。怎么能让互联网的多个主机用同一个IP,这岂不是IP地址冲突了?
首先,每一个服务器主机处在不同的地理位置,他们之间不在同一个广播域内。所以把所有主机配置成相同的IP地址并不会引起我们日常所见的IP地址冲突。
其次,光靠配置相同的IP地址时不够的,我们还需要借助强大的BGP帮忙。
通过BGP,各个站点向Internet宣告相同的Anycast IP地址。
自然而然,Internet 就会接收到不同目标路径,但是具有相同IP地址段的prefix。那数据包是如何在这种环境下路由的呢?
为了让大家有更深刻的理解和认识,下面将详细描述Anycast的主要优势和用途
用途一:Load-balancing 负载均衡以及系统冗余性
为了阐明使用Anycast和负载均衡,以及冗余性的关系,特举例如下:
假设我们现在有三个DNS服务器站点,地点分别在北京,上海,广州。他们服务了全国的DNS解析服务。
按照一般的解决方案,为了实现三个DNS服务器负载均衡,可能有人会考虑到使用硬件负载均衡设备,例如常见的F5负载均衡设备等。
但若使用硬件负载均衡,随之带来的问题有:
网络流量瓶颈,所有有流量都需要先通过负载均衡设备,而硬件设备本身的吞吐量决定了整个网络环境的吞吐量。
高昂的硬件成本,为了实现全国的流量负载均衡,试想需要多大吞吐量的硬件设备。硬件吞吐量越大,购买成本就越高。
而通过Anycast技术,无需要借助任何第三方负载均衡器,就可以轻松达到负载均衡的效果,同时还提供了冗余和高可靠性。
实施方案如下:
通过配置三个DNS站点的服务器IP为相同IP,例如1.1.1.1/32。然后通过各个站点的BGP对互联网宣告1.1.1.0/24的网段。
(注:为什么要宣告/24,而不是/32? 。因为在Internet里面,为了减小全球Internet路由表尺寸,默认情况下运营商只接受小于等于/8,而大于等于/24的网段宣告进入互联网。)
以上步骤完成以后,互联网路由表针对1.1.1.1/24会有三个不同的出口路由器,分别是北京,上海,广州。
重点来了,因为所有用户都使用1.1.1.1作为他们的DNS服务器。
以东北的用户来说,哪一台DNS服务器会给东北的用户提供解析呢?
答案就是:就近原则!
数据包在网络中的路由细节:
当用户的DNS请求到达运营商的宽带路由器以后,运营商的路由器会根据BGP的选路原则选择到达1.1.1.1的最优路径。
例如,在用户宽带运营商和DNS服务器Internet运营商相同的情况下,最终会以IGP metric为关键因素来决定哪个DNS服务器给用户提供服务。
而IGP的 Metric某种程度上就是物理距离的代表。
四川的宽带路由器通过查看BGP路由,发现1.1.1.1出口最优路由是在广州。那么四川用户的DNS数据包将被发送给广州的DNS服务器。
同理,东北的用户DNS解析将会被发往北京的DNS服务器,而江南一带的则是上海DNS服务器负责。
万一出现故障怎么办?
如果三台DNS服务器中某一台出现故障,例如广东DNS服务宕机。BGP协议会立即停止通告此1.1.1.0/24的网段。Internet 路由表将会只有北京和上海的DNS可供选择。
此时原广东DNS服务的用户将再次根据"就近原则"选择其他DNS服务器,例如上海DNS。
从而达到业务的平滑迁移和服务的高可用性。
基于以上的分析,我们很容易就得出如下结论:
全国用户最终会根据距离DNS服务器的远近来判断使用哪个DNS服务器做域名解析。
从DNS角度来说,正因为不同的地理位置用户会根据就近路由判断,从而选择不同的DNS服务器,最终会使三台DNS服务器达到负载均衡的效果。
若其中某一个节点出现故障以后,业务会立即迁移到其他可用的节点上,从而避免网路服务故障。完全不需要人工干预。
以上就是Anycast在负载均衡中的用途说明。
用途二:防范DDOS攻击
相信很多在运营商工作的朋友都非常讨厌DDOS攻击。
当DDOS发生时,10G或100Gbps的流量突然蜂拥而来,占用运营商核心MPLS网路带宽不说,这种洪泛攻击会给客户网络造成短时间的瘫痪。造成的损失极大。
在阐述Anycast防范DDOS攻击细节之前,让我们先来看看DDOS是如何产生的。
以NTP协议为例,NTP协议是client-server模式,客户发起NTP时间查询申请,服务器响应NTP查询。看似正常的NTP数据流量有时候及其容易被玩坏。
假设某个黑客控制了成千上万的僵尸主机,这些僵尸主机纷纷伪造如下数据包并发送给全球NTP服务器:
源地址:1.2.3.4 (伪造源地址为 被攻击者的IP地址)
目标地址:全球各个NTP服务器地址。(越多越好)
当全世界各地的NTP服务器收到此查询以后,它会把查询结果发送回给真正的受害者1.2.3.4。
这时IP地址为1.2.3.4 的受害者收到全世界的NTP服务器发过来的数据包时,其有限的带宽链路就很容易产生拥塞并造成服务中断。
假设这些僵尸不只是发送一次虚假数据包,而是上万次。
那么受害者接收到的NTP回复数据包量将如下:
虚假数据包发送数量 x 全世界NTP服务器的数量= 最终DDOS攻击的流量。
Anycast如何防范DDOS攻击?
DDOS攻击最关键一点,是需要把所有地理位置分散的小流量最终汇集到一个点。从而形成涛涛洪水。
正所谓以彼之道,还施彼身。
在Anycast环境下,由于多个地理位置不同的主机同时使用同一个IP地址。正因为如此,DDOS流量在穿越运营商路由器时,路由器会根据地理位置远近把数据包路由到距离源地址最近的受害者主机站点。从而分散掉整个DDOS流量。
还是以上述NTP协议DDOS为例。
假设IP为1.2.3.4的受害者恰巧布局了Anycast协议。其服务器分布在全国各地。
当DDOS来临时,不同的NTP服务器根据路由选择,把流量发送到距离NTP服务器最近的受害者服务器上。
最终,原本10Gbps-100Gbps的汇总流量被各个目标服务器以1Gbps不足的DDOS攻击消化掉。
既然Anycast好处多多,有多少企业部署了呢?
据我了解,包括Microsoft,Cloudflare,LinkedIn以及其他企业都在全球范围内使用了Anycast技术。
Cloudflare
Cloudflare作为CDN网络佼佼者,其主要采用了Anycast技术为用户提供距离用户最近的Cache服务器。从而大大提高了用户的服务体验满意度。
Cloudflare全球建设了118个数据中心,凭借于Anycast的高冗余性,正如本文开头提到的,任何一个数据中心出现网络、系统故障。均不会影响客户体验度,所有当地的客户流量会自动路由到其他就近的数据中心。
包括DeNA公司也在使用Cloudflare的防护服务来防范DDoS攻击
Anycast是挺不错,但是看起来都是例如DNS,或者CDN在使用。
而且,无论是DNS服务提供商还是CDN服务提供商,他们最大的特点在于:每个Pop站点的服务器内容完全一样,所以客户无论访问站点A或者站点B,均能获取到相同的内容。
那让我们来看一个不一样的例子
LinkedIn大家最熟悉不过了,找工作攀人脉LinkedIn是经常去的地方。
但是你可知道LinkedIn同样使用了Anycast技术。可是LinkedIn是纯粹的网页内容服务提供商。他与CDN,DNS提供商等性质不太相同。
而且大家需要注意的是,LinkedIn的流量可全是HTTPS,TCP流量。并非一般大家部署的DNS UDP流量。
那为什么LinkedIn也对Anycast如此感兴趣呢?
故事要从几年前说起。
话说当LinkedIn业务急速扩展以后,出现了用户体验度差的问题,原因在于"时延"两个字。
因为数据中心地理位置固定,而用户位置可能是全世界各地。很自然,地理位置遥远的用户访问LinkedIn时会产生高时延问题。加上HTTP,HTTPS协议采用了话痨型的TCP协议
这TCP几次握手来回以后,加上后续HTTP数据流。本来时延就高的链接加上TCP信令数据包一来二去。用户体验度非常糟糕。
为了解决以上问题,LinkedIn引入小型数据中心站点(Pops)。在全世界有业务的地方构架小型DC。同时小型DC与美国总部的数据中心之间长期维持着稳定的TCP会话链接。
当远端用户访问LinkedIn后,TCP链接其实是发送给了当地的小型DC,小型DC再通过已有的TCP链接访问总部DC。从而大大减少了中间TCP信令会话的数量,变相降低了访问延时,提高了用户体验度。
但是?这和Anycast有半点关系么?
当LinkedIn在全世界范围内大批量部署小型DC以后,摆在他们面前的问题是,如何让用户能够就近访问当地的小型DC,而不是选择远端的数据中心总部?
这不就是Anycast擅长的么?
对,LinkedIn也是这么想的,于是乎他们把整个美国的小型DC的IP地址修改为相同的IP,并通过BGP发布到Internet。
当用户访问LinkedIn时,DNS解析会返回此小型DC 的IP,然后用户运营商会根据就近原则路由用户数据到最近的小型DC。从而达到了上面所述的优化延迟的目的。
通过使用Anycast技术以后,LinkedIn小型DC访问命中率大大提高。
总结
今天我们一起研究了什么是Anycast,以及Anycast的妙用。正如开头所说,Anycast并不是一个新技术,可谓是旧瓶装新酒。但是通过结合BGP协议,变相提高了Anycast的使用广度和深度。
最后,针对Anycast 做如下总结:
优点:
Anycast可以零成本实现负载均衡,无视流量大小。
Anycast是天然的DDOS防御措施,体现了大事化小,小事化了的解决方法。
部署Anycast可以获得设备的高冗余性和可用性。
Anycast适用于无连接的UDP,以及有连接的TCP协议。
缺点:
Anycast严重依赖于BGP的选路原则,在整个Internet网络拓扑复杂的情况下,会导致次优路由选择。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章