3月3日， CloudFlare经历了过去四年间第三次严重的事故。UTC时间9：47(北京时间3月3日17：47)，CloudFlare的边缘路由器发生故障，这导致使用CDN和安全服务的785000多个网站受到影响。约30分钟后故障被排除，事故持续影响了一个多小时。
CloudFlare的联合创始人及CEO Matthew Prince在事故当天就通过 blog对事故进行了分析，并向用户道歉。从广泛的评论来看，主流舆论对于此次事故还是报以宽容和理解，对CloudFlare的勇于认错的态度和快速的行动进行了肯定。
图：CloudFlare的实现原理
据TechCrunch 报道，中国是除美国本土外CloudFlare的最大市场，尽管此次事故在国内也引起了大量讨论，但还没有商业用户的抱怨声音(企业用户每月需支付3000美元)。
去年四月，CloudFlare的月PV达到400亿，目前这个数据已经达到1000亿。CloudFlare帮助网站节省带宽、提高访问速度，并过滤恶意攻击。
什么引起了事故?
Matthew Prince在blog上表示：
CloudFlare 的管理团队发现一处DDoS攻击，监测工具显示攻击包大小在 99971 ~ 99985 bytes 左右(正常包大小是 1500 bytes，通常都在 500 ~ 600 bytes)，于是将其规则加入 Juniper 的 Junos 防火墙设置中，不过预期大小的包并没有被拦截，因为实际上并不存在这么大的数据包，取而代之的是匹配规则的数据包冲刷到内存中，直到内存耗尽，系统崩溃。
通常系统崩溃会自动重启而恢复工作，但这次例外了。由于系统没有正常启动，管理端口没有响应控制，于是CloufFlare的管理中心只能电话通知全球 14 个国家的 23 个数据中心的管理员硬启动机器，这个过程大概花费了 30 分钟。最早恢复的数据中心由于负荷了最多了访问流量，仍然导致了 CloudFlare 服务的不稳定性，加上等待 DNS 缓存更新等，服务恢复时已经影响已持续超过 1 小时。
我们学到了什么?
网络技术工程师 IKE123在微博上评论：
1、主因：flowspec的bug引起的加载filter的时候导致的内存泄露。
2、Crash以后未能自动重启，所有收到该flowspec路由的边缘设备全玩完。
3、非架构问题，所以SDN/Openflow不会更好。
4、软件都有bug，这只是flowspec用的少，才有低级错误，不过换SDN估计更差(使用案例更少)。
5、ISP玩PCEP(路径计算单元通信协议)。
他特意向CSDN澄清：SDN和这次事故无关，只是有人提出来说SDN能有帮助。他认为：ISP骨干应该用PCEP，而不是Openflow。 PCEP是集中计算RSVP TE(基于流量工程扩展的资源预留协议)，下发到设备上。Google是大驱动因素。
蓝盾股份是国内提供类CloudFlare服务的公司之一，该公司负责应用安全产品线研发总监 余志刚告诉CSDN：
我最近研发的产品是 云防线，技术架构与CloudFlare类似。
CloudFlare 这种技术架构中DNS服务集群充当的是全局负载均衡、智能路由的角色，而其他的分数据中心的运作都将依赖全局的DNS智能集群，如果这个中心集群宕机，将导致整个系统瘫痪，哪怕分中心无任何问题，数据流量也将路由不到。
通过分析官方blog的内容，我猜测CloudFlare 的DNS应该是有热备的，但可能这两套系统都在这个核心路由器后面。路由器出问题后导致两套系统都无法访问。
余志刚认为，这次事故反映出这种基于SaaS概念的安全系统需要完善一下几个方面：
1、加强全局负载均衡，也就是DNS智能集群的安全防护及运营水平。
2、在财力允许的情况下，尽量建立DNS智能集群的备份系统，两套系统做到热备。
3、将用户管理系统也就是www.cloudflare.com这个网站管理系统和核心系统分开，当DNS智能集群宕机，无法为用户网站提供加速、防护服务后，保证管理系统能正常使用，然后给用户提供快速切换到原有DNS解析服务器的选项。
陈利人认为：
CloudFlare CDN加速的原理：当用户访问已经启用CloudFlare CDN加速网站时，首先通过DNS重定向技术确定最接近用户的最佳CDN节点，同时将用户的请求指向该节点。当用户的请求到达指定节点 时，CloudFlare的服务器(节点上的高速缓存)负责将用户请求的内容提供给用户。说白了，就是基于DNS的负载均衡。
在Hacker News上对此次事故有着疯狂的 讨论：
“如果你将Juniper和Cisco的设备放在一起，那么就会产生很多奇怪的问题。”
“最好不用只使用一家供应商。”
“Junos的更新速度显然慢了。”
“任何设备都不能保证网络万无一失。”
敏捷开发者、趴猫网 创始人 王龙：
自己运营的主打产品不要用任何第三方的产品，金窝银窝不如自己的草窝，所有东西自己来搭建，框架用自己开发的，平台用自己运维的，服务器用自己的，插件自己来写，CDN自己搭建，云架构自己部署，就不会出现这种由于第三方问题出现的问题，起码问题是可控的。
行人23：
电话14个国家23个数据中心管理员只需要30分钟，放到国内厂商需要多久呢?
wanght1979：
作为刚刚从机房出来的苦逼，深刻理解其困扰。
如果你有任何观点，不妨在评论中告诉我们。
国内的类CloudFlare市场
在国内， 安全宝、 知道创宇和云防线都提供类CloudFlare的服务。国内两大CDN 服务商网宿和蓝汛这块业务跃跃欲试，电信运营商已经参与这个市场。尽管市场竞争非常激烈，但和所有其它云计算服务一样，用户的 接受程度还很低，“目前来说用户对这种SaaS概念的安全服务接受程度还比较有限。随着发展，SaaS服务慢慢被大家接受，这肯定是未 来安全行业发展的方向”，余志刚表示。