自建 CDN 防御 DDoS（2）：架构设计、成本与部署细节

在本系列的第一篇文章中，我们介绍了我们客服系统遇到DDoS 攻击的情况，以及我们为什么决定采用自建CDN 的方式来解决这个问题的原因。

下面，我们将介绍自建CDN 的具体建设规划，主要从以下几个方面进行考量：硬件成本、带宽成本、架构设计、实际部署。

硬件成本

在硬件上，我们选型的需求是在1U 的基础上具有强劲的性能，同时性价比要高。

我们选择了（强氧）双子星服务器，其硬件规格为：1U 机身+ 支持双路至强CPU+ 最大支持48G 内存+ 双千兆网口x2+H3C S1208 八口千兆，提供三年质保服务，总价约1.5 万。

带宽成本

单线机房的机房和带宽资源，由于不需要经过第三方拉线撮合，直接从运营代理商购买，因此选择余地大，性价比高。以租用电信、联通单线资源为例，每条线独享100M 带宽，提供8 个IP，有些机房自带硬防，能够防御5G-10G 流量。

平均费用，每个节点带宽成本基本在1.6~2.5 万/ 年。

架构设计

CDN 架构上要充分体现出抗攻击能力和灵活应变的原则。因此，我们将 CDN 节点分解成反向代理 + 缓存加速 + 攻击防御这三个不同层次的功能结构。

• 反向代理功能（作用：路由加速，隐藏主节点，负载均衡）
• 缓存加速功能（作用：静态推送，节省后端主节点带宽）
• 攻击防御功能（作用：快速解析，匹配过滤恶意攻击）

开源世界里能够担当反向代理及缓存的软件不少，而且各有优劣。作为架构师，要考虑如何选型，我们从性能、功能、配置上来进行比较筛选。

软件名称 性能 功能 过滤规则配置 Squid 不能多核是硬伤，磁盘缓存容量有优势，性能中等 多，支持 ACL 角色控制，也支持 ICP 缓存协议 支持外部规则文件读取及热加载，支持热启动 Varnish 多核支持，内存缓存，性能强 够用，不支持集群，支持后端存活检查 不支持外部文件读取，需要转义，支持热启动 Nginx 多核支持，支持代理插件，性能较强 多，通过插件可以充当多角色服务器 不支持外部文件读取，需要转义，支持热启动 ATS 多核支持，磁盘 / 内存缓存，性能强 够用，支持插件开发，也支持 ICP 协议 支持外部规则文件读取及热加载，支持热启动，但缺乏文档 HAProxy 多核支持，无缓存，HTTP 头支持语法操作，性能强 少，只专注 HTTP 头部解析和转发功能，支持 ACL 角色控制，支持后端存活检查 支持外部规则文件读取及热加载，支持热启动，支持会话粘滞和长连接我们对这三层功能结构分别进行了测试调优及生产线的实践检验，从以下方面评估：

• HTTP 防御性能：HAProxy 在应对大流量 CC 攻击时，做正则匹配及头部过滤时，CPU 消耗只占 10%~20%。其它软件均狂占 CPU 资源约 90% 以上，容易成瓶颈导致整个系统无响应。
• 反向代理性能：单纯转发效率以内存缓存型的 Varnish 性能最强，ATS 和 Nginx 次之，考虑大容量缓存因素，ATS 也是个不错的选择，但文档缺乏，需要持续关注。Nginx 是专门针对 C10K 的产物，性能不错，配合众多插件，改造性很强。
• 过滤规则的可配置性：HAProxy，ATS，Squid 均支持规则文件读取、ACL 定制和热加载、热启动。Nginx 则不支持外部文件正则匹配，略差一点，但可塑性强。

因此，综合上述考虑，最终我们采用的架构是 HAProxy+Varnish/ATS/Nginx 的组合，即防御型反向代理缓存方案，功能角色如下：

• 前面由 HAProxy 全力负责动静资源分离，实现会话粘滞，节点负载均衡，故障转移，遇到危急时承担基于 Http 协议的 CC 类型攻击防御。
• 后面为可插拔替换的反向代理缓存引擎：根据生产线上的实际应用场景及缓存对象的容量来决定使用内存型的 varnish 或者是磁盘型的 ats，如果需要定制功能很强（防盗链）的反向代理如 Nginx+plugins。

这个组合最大的特点是：

• 支持外部过滤规则的读取，尤其是关键字符串无需转义，可直接追加到文件中。
• 支持配置文件热加载生效，都支持 reload，服务平滑生效。
• 可插拔式的缓存组件灵活应对各种业务需求。
• 部署简单，节点失效 / 生效切换方便。

LVS 缺席：为什么这里没有提及 LVS，因为 LVS 是个重量级、高效稳定的四层转发，不能作七层 HTTP 协议的识别，但完全可以架设在七层之前。所以，LVS 的使用并不会影响网络结构，后续仍然可以想上就上，只是前提要兼顾到 LVS 的单点故障。

实际部署

最终我们在主节点周围一共部署了 8 个 CDN 节点（节点数量根据自身公司实力及实际生产环境要求而灵活调整，此数字仅作参考），这些节点又按照地域划分成了四个大区：北方（以山东，河北为主）、西南（以四川为主）、华东（以宁波，嘉兴为主） 华南（以福建，湖南为主 ）兼顾全国各个省份。

总体成本情况

8 个单线加速节点，每个节点 100Mx8，8 台双子星服务器，总共投资约 30W（后续费用只考虑带宽支出，约 15W/ 年），我们应急拨款为 10W，每个月 CDN 预算为 2W。

项目进度安排：

1～4 个月抓进度：特点是快速部点。这里有个诀窍，前期可以先跟 IDC 按月或者季度签约，然后通过监控看连续的节点质量，如果节点质量不佳，更换提供商，这样损失不会太大，如果节点质量好，就半年付或者年付，这样就可以保证质量和性价比最高；

5～8 个月为完善期：根据预算，有节奏的加点，加带宽，保证带宽的冗余度；

8 个月以后为稳定期：根据实际情况保证节点的最大可用性，同时也提升了整体防御能力。

如何做防护策略

开启 HAProxy 的 httplog 功能，记录日志。

HAProxy 的配置策略：

 
global
   nbproc 24
   pidfile /var/run/haproxy.pid
   daemon
   quiet
   user nobody
   group nobody
   chroot /opt/haproxy
   spread-checks 2
 
defaults
   log 127.0.0.1   local5
   mode    http
   option  forwardfor
   option  httplog
   option  dontlognull
   option  nolinger # reduce FIN_WAIT1
   option  redispatch
   retries 3
   option  http-pretend-keepalive
   option  http-server-close
   option  accept-invalid-http-request
   timeout client 15s
   timeout connect 15s
   timeout server 15s
   timeout http-keep-alive 15s
   timeout http-request 15s
 
   stats enable
   stats uri /stats
   stats realm 53KF\ Proxy\ Status
   stats refresh 60s
   stats auth admin:adminxxx
 
listen Web_FB 0.0.0.0:80
   option httpchk GET /alive.php HTTP/1.0
 
   acl invalid_referer hdr_sub(referer) -i -f /opt/haproxy/etc/bad_ref.conf
   acl invalid_url url_sub -i -f /opt/haproxy/etc/bad_url.conf
   acl invalid_methods method -i -f /opt/haproxy/etc/bad_method.conf
   block if invalid_referer || invalid_url || invalid_methods
 
   acl dyn_host hdr(host) -i -f /opt/haproxy/etc/notcache_host.conf
   acl static_req path_end -i -f /opt/haproxy/etc/allow_cache_file.conf
   use_backend img_srv if static_req !dyn_host
 
# acl shaohy
   acl geek hdr_dom(host) -i 17geek.com
   use_backend geek if geek
 
# backend shaohy
backend geek
   mode http
   balance source
   cookie SESSION_COOKIE insert indirect nocache
   option tcpka
   server geek_1 127.0.0.1:81 cookie geek_1 maxconn 10000 weight 8
 
backend img_srv
   mode http
   option tcpka
   server img_srv 127.0.0.1:88 maxconn 30000 weight 8

Varnish 的配置策略：

 
backend h_17geek_com_1 {        
   .host="127.0.0.1";      
   .port="81";         
   .connect_timeout=300s;      
   .first_byte_timeout=300s;   
   .between_bytes_timeout=300s;    
}                  
 
director geek srv {         
   { .backend=h_17geek_com_1; .weight=3;}
}                  
 
sub vcl_recv {
   if (req.http.host~"^(www).?17geek.com$"){
       set req.backend=geek_srv;       
       if (req.request != "GET" && req.request != "HEAD") {
           return (pipe);              
       }                       
       if(req.url ~ "\.(php|jsp)($|\?)") {         
           return (pass);              
       }                       
       else {                      
           return (lookup);            
       }                   
   }                       
}

对于 CC 类型的 DDoS 攻击，通过第一篇当中介绍的监控异常流量的方法依然适用，而且优势更明显，因为：

• 节点各自承担相应的日志记录，分析日志的系统开销，发现异常请求后直接在 haproxy 前端做 ACL 规则 过滤，因此，攻击压力不会传递给后端服务器，保证后端安全。
• 节点受到的攻击流量过大，机房可以拉黑 IP 或者引流，后端智能 DNS 会自动把这个节点剔除，后续请求不要通过此节点。

在本系列的下一篇文章中，我们会介绍这个 CDN 架构的一些后续改进工作，包括智能 DNS、大规模日志分析、利用 OpenCDN 改善后台管理等。

作者简介

邵海杨（个人页面），来自杭州 Linux 用户组。网名“海洋之心”，系统架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。

张磊（微博，博客），来自杭州谷歌开发者社区。专注于信息安全技术领域，曾主导多项银行 / 证券行业网站安全测试和入侵取证分析项目，为四大银行提供安全防护技术支持。目前创业做互联网安全防护。

相关阅读

1. 自建 CDN 防御 DDoS（1）：知己知彼，建设持久防线
2. 自建 CDN 防御 DDoS（3）：架构的后续改进