自建CDN应对大流量DDOS的解决方案

流量有个逐步增加的过程(通过脚本监控incoming异常流量，从监控图上也可以看出)触发启动日志分析机制，尽量在第一时间和无人工参与找出异常IP,URL,特征码，从内核层(iptables/ip)，应用层(nginx/444)拦截攻击特点：成本低，现成软件多，对方比较”温柔谨慎”，目的是让网站变慢。适用： 主机性能和带宽有盈余，硬件强劲，可用于文本抽取和正则匹配，攻击持续时间短，次数少缺点： 治标不治本致命的流量攻击流量陡增(IDC机房也会察觉，直接拔线，或者IP入黑自杀)系统根本来不及消化和响应过来，甚至连求救包都发不出攻击特点：成本高，对方下手”快狠准”，目的是让网站死亡适用： 硬防，高防节点，外围CDN分散目标缺点： 防御成本高，没人真心帮你，花钱也只是苟延残喘自建CDN的考量硬件成本双子星服务器（1U机身+支持双路CPU+《48G内存+双网口+H3C S1208八口千兆）= 1.5W带宽成本电信、联通单线资源，独享100M，8个IP，基本在1.6~2.5W之间架构设计为什么这里没有提LVS，因为LVS是个重量级，高效稳定的四层转发，但它不能作七层http协议的识别，但完全可以架设在七层之前，所以，LVS的使用并不会影响网络结构，后续想上就上。反向代理（路由加速，隐藏主节点） 　 haproxy > nginx > varnish > ats > squid缓存加速（静态加速，节省带宽，边缘推送） ats > varnish > squid > nginx > haproxy防御功能（快速解析，过滤匹配） haproxy > nginx > ats > squid > varnish支持读取文件匹配，支持热加载，可插拔式的缓存组件灵活应对业务Haproxy+Varnish的组合：防御型反向代理缓存方案设计要素参数配置注意点        option  forwardfor        option  httplog        option  dontlognull        option  accept-invalid-http-request        #option  nolinger # reduce FIN_WAIT1        option  http-server-close        timeout client 15s        timeout connect 15s        timeout server 15s        timeout http-keep-alive 15s        timeout http-request 15slisten Web_FB 0.0.0.0:80        acl invalid_referer hdr_sub(referer) -i -f /opt/etc/bad_ref.conf        acl invalid_url url_reg -i -f /opt/etc/bad_url.conf        acl invalid_methods method -i -f /opt/etc/bad_method.conf        block if invalid_referer || invalid_url || invalid_methods        acl dyn_host hdr(host) -i -f /opt/etc/notcache_host.conf        acl static_req path_end -i -f /opt/etc/cache_file.conf        use_backend img_srv if static_req !dyn_hostbackend img_srv        mode http        option tcpka        server img_srv 127.0.0.1:88 maxconn 30000 weight 8降低磁盘IO把Haproxy日志刷到内存中，间隔时间内清空，从而保证cpu的高效运行和内存控制。智能脚本PROXY_HOST='53kf.com@127.0.0.1:81:3&127.0.0.1:82:1@w_53kf_com@www|chat|kf'架构改进配置DNS就近匹配CDNBind view+脚本分析分拣中国大区大规模日志分析Haproxy+rsyslog+nosql+hadoop后端管理不直观OpenCDN前端控制