自建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）：架构的后续改进