RockCloud-基石云安全-官方博客
简单说，BGP Anycast 清洗做了三件事：
- 牵引：服务商在多个地区的清洗节点（PoP）上，通过 BGP 同时宣告同一段 IP。各地运营商的路由器按 BGP 选路规则，把访问这段 IP 的流量送到网络上离它最近的节点。攻击流量也一样被分到各个节点，而不是全部压到一个机房。
- 清洗：每个节点在本地过滤流量。三四层处理 SYN Flood、UDP Flood 这类流量型攻击，七层处理 HTTP Flood 和 CC。
- 回注：剩下的正常流量，通过反向代理或 GRE、IPsec 等隧道送回你的源站。
这三步各自决定一类问题：牵引决定总量扛不扛得住、用户延迟高不高；清洗决定拦得准不准、会不会误伤；回注决定源站会不会被绕过、回源链路稳不稳。下面按这个顺序展开，最后给出选型时可以直接拿去问服务商的问题。
先分清：Anycast 清洗和国内常说的“BGP 高防”不是一回事
国内机房说的“BGP 高防”，通常指一个机房里的 IP 同时接入电信、联通、移动等多家运营商，解决的是“不同运营商用户都能顺畅访问”，清洗一般在这一个机房里完成。BGP Anycast 则是把同一段 IP 放到多个地区的节点上同时宣告，重点在于把流量和攻击分散到多处。
两者都用 BGP，但架构不同，评估防御能力的方式也不同。多线 BGP 和单线的取舍可以参考BGP高防和单线高防哪个防御能力强。
第一步：同一段 IP 多地宣告，流量就近进入
正常情况下，一个 IP 前缀只从一个地方宣告到公网。Anycast 的做法是让多个节点的路由器同时宣告相同的前缀。全球各运营商的路由器看到多条可达路径后，按 BGP 规则（比如 AS-Path 更短的优先）各自选一条，于是不同地区的访问者会落到不同的节点。
这里有两点会影响实际体验：
- “最近”指的是网络拓扑上的近，不一定是地理上的近。 用户最终进入哪个节点，取决于所在运营商的路由策略。理论上的就近节点，未必就是用户实际落到的节点。
- 中国大陆用户的落点要实测。 三大运营商对国际路由的选路策略各不相同，访问境外 Anycast 节点时，可能会绕到较远的节点，延迟也可能明显偏高。目前没有可以直接套用的结论，最可靠的办法是从你的主要用户所在地、分运营商实际测试。如果业务用户主要在大陆，线路选择可以参考香港CN2和香港BGP哪个好。
第二步：攻击流量被分摊到多个节点
传统单点防护的问题在于，所有攻击流量都挤向同一个机房，一旦上行链路被打满，清洗设备再强也没用，因为流量根本进不来。
Anycast 改变了这一点。由于各地流量按就近原则进入不同节点，分布式攻击的流量也随之被拆散，每个节点只承受其中一部分峰值，单条链路就不容易饱和。
不过，分摊效果和攻击源的分布有关。攻击源越分散，各节点的压力越平均；如果攻击源集中在某个地区，这部分流量会集中进入当地节点。所以评估容量时，除了总清洗能力，还要了解单个节点能扛多少。容量上限由哪些因素决定、超出后会发生什么，可以参考BGP高防能防多大流量。
第三步：节点内分层清洗
流量进入节点后，会经过串联（Inline）或分流式的清洗系统。不同层面的攻击，处理手段不同：
- 三层、四层：通过协议合规校验、畸形报文过滤、SYN Proxy / SYN Cookie 和限速策略，阻断 SYN Flood、UDP Flood 等流量型攻击。
- 七层：通过反向代理、WAF 规则、客户端指纹识别和人机验证，阻断 HTTP Flood 和 CC 攻击。
七层清洗要求节点能看到 HTTP 请求内容，所以对 HTTPS 业务来说，节点需要终结 TLS 连接，证书要部署在节点上。如果你的主要威胁是 CC，要确认服务商在同一个节点里是否具备七层能力，而不是只做流量型清洗。CC 防护能拦到什么程度、什么情况下会被打穿，可以参考高防CDN能防CC攻击吗。
第四步：干净流量回注源站
清洗完成后，正常流量要送回源站。常见的回注方式有两种：
- 反向代理模式（四层或七层）：节点终结用户连接，再以自己的身份向源站发起新连接，经内部骨干或优化链路回源。源站看到的是节点 IP，真实客户端 IP 需要通过 HTTP 头或代理协议传递，源站的日志和风控规则要相应调整。这是网站、API 和游戏业务最常用的方式。
- 网络层隧道模式：通过 GRE、IPsec 或 MPLS，把原始数据包封装后转发到源站网络，源站收到的仍是原始报文。这种方式多见于拥有自有 IP 段的企业网络。
无论选哪种方式，源站都应该只接受来自清洗节点的流量。一旦源站真实 IP 泄露，攻击者可以直接绕过清洗打源站，前面三步就全部白做了。源站 IP 的常见泄露途径和收口顺序，见高防CDN接入后源站IP还会暴露吗。
和传统集中式清洗相比，差别在哪
传统清洗通常是按需启用：平时流量直达源站，检测到攻击后才调整路由，把流量牵引到少数几个集中清洗中心，洗完再送回。这样做有两个代价：
- 绕路延迟：一个地区的用户流量可能要先绕到远处的清洗中心，再折返回源站，延迟可能增加数十毫秒甚至更多。
- 切换期风险：从发现攻击到路由收敛完成之间有一段空窗期，期间业务可能受影响。另外，流量集中到少数中心，本身也可能形成拥塞点。
BGP Anycast 清洗通常是常态在线（Always-on），流量平时就经过节点，不存在攻击来临时的切换过程，用户也一直从附近节点进入。代价是所有流量长期经过服务商网络，因此节点的线路质量会直接影响日常访问体验。
需要留意的限制：路由抖动可能断开长连接
BGP 路由由各个自治系统独立计算。当网络发生抖动或路由震荡时，同一个客户端的后续报文可能被送到另一个节点。如果清洗或代理是有状态的，而节点之间又没有会话同步，新节点不认识这条连接，TCP 连接就可能中断。
短连接的网页请求受影响较小，断了重连即可。但游戏长连接、WebSocket、直播推流这类业务对此比较敏感。如果你的业务属于这一类，要向服务商问清楚他们如何处理跨节点的会话问题，并在测试期专门观察长连接的断线率。
选型时，把原理变成具体问题
理解了上面四步，评估一家 Anycast 清洗服务时，可以逐项核实：
- 你的用户会落到哪些节点？ 让服务商给出节点分布，再从主要用户地区分运营商实测落点和延迟，不要只看节点数量。
- 单节点容量和总容量各是多少？ 攻击源集中时，单节点能扛多少更关键。
- 是常态在线还是按需牵引？ 按需牵引要问清切换需要多长时间。
- 七层清洗在不在同一条链路上？ 有 CC 风险的业务，要确认 WAF 和人机验证不需要另外接入。
- 采用哪种回注方式，源站如何隐藏？ 问清回源 IP 段，以便在源站设置白名单。
- 长连接如何处理？ 游戏和实时业务要重点测这一项。
如果你在评估 RockCloud，它的加速与防御在同一条链路上完成，一份费用，按峰值计费、不限流量。上面这些问题可以直接拿来问，再用免费测试从你的用户所在地实测落点、延迟和长连接表现，然后再做决定。
评论(0)