摘要：# 当HTTPS洪水来袭，你的自建高防CDN算力够用吗？ 说真的，这两年我见过不少自己搭高防CDN的团队，PPT上写得天花乱坠，什么“百万级QPS轻松应对”、“智能调度无死角”。结果真碰上HTTPS洪水攻击，后台监控曲线直接拉成心电图，运维群里一片哀嚎。…

当HTTPS洪水来袭，你的自建高防CDN算力够用吗？

说真的，这两年我见过不少自己搭高防CDN的团队，PPT上写得天花乱坠，什么“百万级QPS轻松应对”、“智能调度无死角”。结果真碰上HTTPS洪水攻击，后台监控曲线直接拉成心电图，运维群里一片哀嚎。

这种场景你应该不陌生吧？尤其是做游戏、电商、金融这些业务的，HTTPS洪水简直就是家常便饭。攻击者现在也学精了，知道普通HTTP攻击容易被识别，全都转向了更“烧钱”的HTTPS——说白了，就是用你的规则来打你，每个请求都带着完整的TLS握手，加密解密全都要走一遍，摆明了就是要耗光你的CPU算力。

一、HTTPS洪水攻击，到底狠在哪里？

很多人觉得，不就是HTTPS嘛，我服务器配置高点不就行了？

问题就出在这儿。

我前两天刚帮一个做海外电商的朋友看他们的自建高防CDN。配置单拿出来挺唬人：几十个节点，每个节点都是16核32G的机器，带宽也够用。结果上个月大促，被一波看起来并不算大的HTTPS CC攻击直接打瘫了。

事后一分析，好家伙，问题出在TLS握手环节。

普通的HTTP攻击，你的CDN节点可能只需要解析个包头，判断下是不是恶意IP，就决定是放行还是丢弃。但HTTPS洪水攻击，每个请求过来，你的服务器都得先完成一次完整的TLS握手——这玩意儿包括密钥交换、证书验证、对称密钥生成等等一系列加密操作。

全是CPU密集型运算。

我那朋友用的还是RSA 2048的证书，一次完整握手，单核CPU大概能处理200-300次/秒。听起来不少对吧？但攻击者可不会跟你客气，他们用僵尸网络发起攻击，每秒几十万甚至上百万个握手请求涌过来，你那几十个核的CPU瞬间就被握手过程给占满了。

真正的业务请求？根本排不上队。

（这里插句私货：有些安全厂商吹嘘自己的硬件加速多厉害，但实际测试下来，很多所谓的“SSL加速卡”在真正的洪水攻击面前，表现也就那么回事儿，尤其是当攻击流量混杂在正常业务里的时候。）

二、自建高防CDN，算力分配最容易踩的坑

我自己看过不少自建方案，发现大家最容易在三个地方掉链子：

1. “平均主义”害死人

很多团队搭建节点时，喜欢搞“统一配置”——所有节点都用一样的CPU型号、一样的内存、一样的带宽。美其名曰“方便管理”。

但现实是，你的流量分布根本不均匀。

北上广深的节点，可能承担了70%的业务流量；某些偏远地区的节点，平时就闲着。HTTPS洪水攻击一来，攻击者往往盯着你的核心节点打，那些配置一样的边缘节点根本帮不上忙，核心节点的CPU却已经烧到冒烟了。

2. 忽略了“隐性成本”

你以为HTTPS洪水攻击只消耗CPU？太天真了。

TLS握手过程中，服务器需要为每个连接分配内存来维护会话状态。一个连接可能占几KB到几十KB不等，看起来不多吧？但百万级并发涌过来，光是内存占用就能把你的机器拖垮。

更别说那些需要维护会话复用的场景了——为了提升性能，你肯定开了会话复用（Session Resumption），但这意味着你得在内存里存一堆会话票据。攻击者如果故意发起大量新会话，又不完成握手，这些半吊子连接就会一直占着你的内存不放。

3. 调度策略“太老实”

很多自建CDN的调度逻辑，还停留在“哪个节点延迟低就往哪导”的原始阶段。

HTTPS洪水攻击最擅长利用这种“老实”的调度。攻击者通过遍布各地的僵尸主机发起请求，你的DNS调度或者Anycast路由一看，哎，这个请求从上海来的，那就分配到上海的节点吧——得，攻击流量被完美地引导到了你的核心业务节点上。

三、算力优化，得有点“流氓思维”

想要扛住HTTPS洪水，你得比攻击者更懂“耍流氓”。

1. 分层防御，别让HTTPS请求直接怼到计算层

这是最核心的一招。我在给一些金融客户设计架构时，一定会坚持一个原则：在HTTPS流量接触到你的业务服务器之前，先剥掉几层皮。

具体怎么做？

• 第一层：TCP协议栈优化 在流量进入你的TLS解密环节之前，先做一次TCP层的过滤。很多HTTPS洪水攻击，其实在TCP层面就有特征——比如SYN包的比例异常、源IP的分布异常、握手的节奏太规律等等。

  用DPDK或者XDP（eXpress Data Path）这种内核旁路技术，在网卡驱动层就把明显异常的连接给掐了。这玩意儿不消耗你的业务CPU，用的是网卡自己的处理能力或者专门的数据面CPU。

• 第二层：非对称算力分配 别再把所有节点都当成“全能战士”了。把你的CDN节点分成两类：

  边缘计算节点：部署在离用户近的地方，配置可以低一些，主要承担流量接入和初步过滤。这些节点上跑轻量级的TLS代理，只做最必要的验证，然后把“疑似干净”的流量通过内网专线转发到……

  中心清洗集群：放在你的核心机房，配置拉满——最新代的CPU、大内存、甚至专门的加解密加速卡。所有需要深度处理的HTTPS流量都到这里来。

  这样就算边缘节点被打了，你损失的也只是几台廉价机器，核心业务不受影响。

2. 证书和加密算法的“小心机”

这里有个反直觉的点：有时候，用“更安全”的证书反而更危险。

我见过一个案例，某公司为了“安全合规”，把所有证书都换成了ECC 256（椭圆曲线加密）。理论上ECC比RSA更安全、性能更好对吧？

但在HTTPS洪水攻击下，ECC证书的握手过程虽然计算量小，但对CPU的指令集优化不如RSA成熟。尤其是在一些老型号的CPU上，ECC的性能反而可能不如RSA。

我的建议是：别一刀切。

• 对核心业务、高价值用户，用ECC证书，享受更好的安全性和性能。
• 对普通浏览、静态资源，继续用RSA证书，利用好CPU的AES-NI等硬件加速指令。
• 甚至可以考虑在遭受攻击时，动态降级非关键业务的加密强度——比如从TLS 1.3降到1.2，或者临时关闭某些加密套件。当然，这需要精细化的控制，别把自己搞出安全漏洞。

3. 智能调度，学会“欺软怕硬”

你的调度系统得有点“势利眼”。

• 基于算力负载的动态调度 别再用静态的DNS轮询或者地理就近了。每个CDN节点实时上报自己的CPU使用率、内存使用率、TLS握手队列长度。调度中心根据这些数据，把新请求导到当前最“闲”的节点上。

  听起来简单，但很多自建系统就是没做这个。为啥？因为要改架构，要加监控，要写调度算法——麻烦。

• 客户端指纹+挑战响应 对于一些特别敏感的业务，可以上更狠的招。

  当检测到某个IP的HTTPS握手频率异常时，不直接拒绝，而是给它返回一个JavaScript挑战。正常的浏览器会执行这段JS，计算出结果后再发起请求；而大多数攻击脚本（尤其是那些直接用socket库伪造的）根本不会解析JS。

  这招的代价是会增加正常用户的延迟（大概100-200毫秒），但能过滤掉90%以上的简单攻击脚本。属于用体验换安全的权衡之策。

四、几个实操中的“土办法”

有时候，最有效的反而是那些上不了台面的土办法。

1. 故意制造“瓶颈”

没错，就是主动制造瓶颈。在流量入口的地方，故意设置一个比后端处理能力稍低的连接数限制。比如你后端集群能处理10万并发，就在入口限制到8万。

这样当攻击来临时，多余的连接会在入口就被丢弃，不会冲击到后端的TLS握手队列。虽然会误伤一些正常用户，但至少保证了系统不崩盘——这就像地铁限流，虽然排队难受，但总比站台挤死人强。

2. “慢启动”应对突发流量

很多HTTPS洪水攻击喜欢在短时间内发起海量连接，打的就是你资源分配跟不上。

可以在系统层面做个“慢启动”机制：当某个IP或某个地域的流量在1秒内增长超过阈值时，自动进入慢启动模式——这个来源的新连接，每秒只放行固定数量，其他的排队等待。

真正的用户刷网页，1秒点不了几次；但攻击脚本可等不了，超时了它们自己就放弃了。

3. 准备好“降级开关”

别等到被打瘫了才想起来要降级。提前在架构里埋好降级开关：

• 非核心业务的HTTPS强制降级到HTTP（当然要配合HSTS等机制，别影响SEO）
• 静态资源临时走第三方CDN（比如阿里云、腾讯云的按量计费CDN，虽然贵，但临时扛一下攻击）

• 关键API接口临时启用更简单的认证方式，绕过复杂的TLS握手

  这些开关平时关着，真到危急时刻，运维点一下就能生效，比临时改代码靠谱多了。

五、最后说点大实话

自建高防CDN应对HTTPS洪水，本质上是一场“算力经济战”。

攻击者的成本是控制的僵尸主机和带宽，你的成本是服务器、电费和运维人力。如果你的防护方案，让攻击者用1块钱的成本就能消耗掉你10块钱的算力，那这仗根本没法打——人家可以24小时不间断地打，你能24小时不间断地烧钱吗？

所以，真正有效的防护方案，一定是极大提升攻击者成本，同时尽量降低自己成本的。

那些号称“无限防护”、“永不宕机”的商业高防服务，其实也是这个逻辑——他们通过规模效应把单次防护的成本压到极低，通过智能调度把攻击流量稀释到庞大的资源池里。你自己搭，如果做不到这个规模，那就得在策略上更聪明。

哦对了，还有个很多人不愿意承认的事实：如果你的业务真的重要到天天被HTTPS洪水盯着打，那自建高防CDN可能本来就不是最优解。

专业的事交给专业的人，有时候租用成熟的高防服务，比你养一个运维团队折腾自建方案，反而更便宜、更可靠。当然，这话很多做自建的同行不爱听——但这是实话。

行了，不废话了。如果你的源站还在裸奔，或者你的自建高防CDN从没做过HTTPS洪水压测，我建议你今晚就试试。

模拟攻击工具现成的，找个低峰期，对自己打一波试试。别等真被打了，才手忙脚乱地看监控图——那时候，你的用户可不会给你调试优化的时间。