企业官网建设流程全解析

DDoS 攻击这东西，纸上谈兵和真实扛一次完全是两回事。我印象最深的是某个客户项目上线没多久，某天下午监控面板显示入流量带宽只有 5Gbps 左右，看着并不夸张，但线上已经乱成一团：TCP 连接卡在第三次握手，UDP 服务大面积超时，边缘防火墙的并发连接表被打到了极限。把流量镜像拉下来抓包一看，同一个小周期里既有海量 SYN 小包，又有打向随机高位端口的 UDP 小包。这是我第一次直观感受到 SYN Flood 与 UDP Flood 混合攻击的杀伤力，也让我把高防 IP 的防御逻辑重新翻出来研究了一遍。这篇文章就把这次研究与实践的收获完整写出来，目标读者是正在做抗 DDoS 选型、或者已经买了高防 IP 但不确定配置是否靠谱的运维和安全同学。

1. 从单点 Flood 到混合 Flood：攻击者为什么改打法了

1.1 单类型攻击的“黄金时代”已经结束

早期防护产品对纯 SYN Flood 和纯 UDP Flood 都积累了大量成熟对抗手段。SYN Flood 可以用 SYN Proxy、SYN Cookie、半开连接阈值来压制；UDP Flood 可以用带宽冗余、源限速、端口过滤来消解。攻击者很快发现，单拼一种类型，很容易被防护设备的固定算法按在地上摩擦。但防护设备的能力是围绕“单类型”优化出来的，一旦攻击变成组合拳，原有优化逻辑就会互相干扰。

我从多个攻击案例里总结出的规律是：现在的攻击者更倾向于在同一个时间窗口内混入多种协议流量。单个类型的 PPS 可能并不高，SYN 部分只有两三百万 PPS，UDP 部分也就一两 Gbps，叠加起来却让防护系统非常难受。因为防护系统必须同时处理两件互相争夺 CPU 的事情：一边校验 TCP 握手状态，一边对 UDP 流量做高速转发决策。资源分配稍有偏差，某一类攻击就会趁机穿透。

1.2 SYN 和 UDP 消耗的是完全不同的资源

这是理解混合攻击的关键前提。SYN Flood 攻击的是协议状态机和计算资源，目标是让防护设备或源站的半开连接表溢出。SYN 包通常只有 60 字节左右，单包体积小，但每秒新建连接数可以冲得很高，CPU 和内存都会被快速耗尽。

UDP Flood 攻击的是链路带宽和转发能力。攻击者用大量随机载荷填充上行链路，目标端口经常是随机的高位端口，单包可以极小也可以极大，完全取决于攻击者的脚本设定。它的核心目标是让入口带宽、交换设备缓冲、转发队列全部饱和。

这两种资源基本不重叠，但防御端却需要共享同一套清洗资源：同一个 CPU 核、同一块内存、同一条回程链路。这也是混合攻击最麻烦的地方——你没办法用处理 SYN 的思路去处理 UDP，反之亦然。

1.3 混合攻击的深层目的：让防护系统互相打架

我刚开始以为混合攻击只是“量变引起质变”，后来复盘才发现没那么简单。攻击者精心设计混合比例，是为了让防护策略出现矛盾。

举一个最典型的矛盾：清洗节点检测到 UDP 洪流时，最自然的动作是加大丢弃力度，把一部分 UDP 包丢弃以保住带宽。但如果合法业务本身就基于 UDP（比如游戏同步、视频通话），过度丢弃会立刻引发客户端重传和重连，而重传风暴在特征上看起来更接近攻击。与此同时，SYN Flood 还在继续填半开连接表。清洗节点如果分了一部分状态机资源去处理 UDP 的合法性判断，SYN 侧的合法连接就更难建立。

混合攻击真正的目标不是在某一条链路上打死你，而是把防护系统拖进“左右互搏”的困境。理解这一点，再看高防 IP 的防御架构，思路就清晰了。

2. 混合攻击发生时，流量侧到底出现了什么异常

2.1 最先出现异常的往往是这组指标

被混合攻击的第一时间，直接看“带宽”是最容易误判的。因为 SYN 小包和 UDP 随机小包的带宽占用都不高，真正先爆掉的是另外几个指标：

我们那次故障里，最先发现异常的是连接表占用率从正常的 20% 一路涨到 98%，然后才是交换机上报出入方向的 PPS 异常。带宽反而是在半小时后才明显起来。如果只盯着带宽监控，很容易把这次攻击误判成“小流量波动”，从而错过提前切换高防 IP 清洗的窗口。

2.2 抓包确认阶段的三个关键指标

当你怀疑自己正在被混合攻击时，别急着开清洗，先用镜像流量确认三个关键指标。

第一，每秒新增 SYN 包数量。正常业务高峰期，一个中型站点的每秒新增连接数大概是几千到几万。如果这个数字突然跳到百万级，并且每一个 SYN 包都来自不同源 IP 的随机端口，基本可以断定有 SYN 成分。

第二，UDP 包在总包量中的占比，以及这些包的载荷特征。记录 UDP 包的目的端口和载荷长度分布。如果是随机高位端口 + 零载荷或固定填充字符，攻击概率极高；如果是知名端口如 53/123，则更可能是为了触发协议放大效应。

第三，握手完成率。统计合法客户端的 TCP 三次握手成功率，观察 SYN 发出后能否收到 SYN-ACK、 ACK 之后能否正常进入 ESTABLISHED 状态。这个指标在混合攻击下变化极快，而且很不规律。

具体抓包命令可以用 tcpdump 配合简单统计，例如只抓新建 SYN 包：

tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 5000

抓到样本后，按源 IP 聚合统计，如果前 100 个源 IP 贡献的 SYN 占比极高，并且这些源 IP 之间没有任何业务共性，就可以进一步确认攻击特征。

2.3 混合攻击特有的“症状遮蔽”现象

这是我特别想强调的一点。混合攻击会互相掩盖对方的症状，导致排查方向跑偏。

有一次复盘，我们把攻击分成了几个阶段。第一阶段是 UDP 小包开始占满交换机的缓冲队列，转发延迟变大，TCP 的 SYN 包在排队时被大量丢弃。此时从应用层看，表现特别像纯粹的 TCP 连接失败，很多人第一反应是 SYN Flood。第二阶段才是真正的大规模 SYN 洪流开始打进来，而此刻因为 UDP 已经把设备 CPU 拖高，SYN 包在被处理之前就丢了，观察到的状态依然是“连接失败”。

结果就是：我们对着监控面板查了半天 TCP 问题，最后才发现 UDP 才是那个让设备提前进入亚健康状态的幕后黑手。混合攻击的可怕之处就在这里，它能把排查者的注意力钉在被它掩护的那类流量上。

3. 高防 IP 的缓解架构：SYN 与 UDP 分别在哪个环节接住

3.1 流量进门之后的第一步：引流与清洗路径

高防 IP 本质上是一套边缘清洗网络加回程链路的组合。攻击流量先通过 BGP 路由被引流到清洗节点，由清洗节点决定放行还是丢弃，随后再把放行后的正常流量送回源站。这是目前主流高防 IP 产品的通用做法。

这里有两种模式值得区分：串联清洗和旁路检测。串联清洗指的是所有流量都经过清洗节点，清洗节点实时转发正常流量，优点是响应快，缺点是清洗节点本身成为瓶颈点；旁路检测则是流量镜像到检测引擎，检测引擎发现异常后才通知路由策略进行牵引，优点是日常延迟低，缺点是混合攻击场景下响应偏慢。

对于 SYN+UDP 混合攻击，我更推荐串联清洗模式。原因是混合攻击的应对逻辑需要极短的响应时间。旁路模式从“检测引擎发现问题”到“路由策略生效”之间往往有几秒甚至十几秒的窗口，攻击者完全可以在窗口内打满状态表，等清洗真正启动时，源站已经被打掉了一层皮。

3.2 SYN 侧的核心机制：SYN Proxy 与 SYN Cookie

高防 IP 应对 SYN Flood 的核心是 SYN Proxy。它让清洗节点代替源站完成 TCP 握手的验证，只有验证通过的连接才会被转发到源站。

具体流程是：客户端发送 SYN，清洗节点先响应 SYN-ACK；客户端回复 ACK 后，清洗节点再与源站建立真正的 TCP 连接。整个过程中，攻击者发出的海量半开连接只会停留在清洗节点的代理状态表里，源站完全感知不到。对于不可能完成的握手，清洗节点会在等待超时后清除表项。

SYN Cookie 是 SYN Proxy 的补充。当半开连接表接近满时，清洗节点会切换到 Cookie 模式：不再为每个 SYN 维护状态，而是把关键信息编码进 ISN 序列号中，只有客户端真正发回 ACK 时才校验。这个机制极大降低了状态表压力，但它对 TCP 扩展选项的支持有限，某些长连接场景会产生兼容性问题，所以更适合作紧急降级手段。

联动来看，判断高防 IP 是否防护得当，要看清洗节点是否具备“SYN Proxy → SYN Cookie → 强制丢包”三级递进策略，并且每级触发阈值是否可配置。如果产品只有简单的“SYN 丢弃”开关，大概率会在混合攻击下误伤大量合法连接。

3.3 UDP 侧的缓解路径：从粗过滤到协议代理

UDP 没有连接状态，防护逻辑与 SYN 完全不同。实践中通常分四层来做：

第一层是网络层粗过滤。根据源 IP 信誉、地理位置、目的端口分布进行快速过滤。攻击源若集中在少数 C 段，这一层性价比极高。

第二层是载荷指纹识别。对 UDP 包的前 32 字节做哈希比对，攻击载荷如果带有固定签名（比如固定的 0x00 填充、恶意请求头部），可以直接命中并丢弃。这一步非常考验清洗厂商的威胁情报库更新速度。

第三层是客户端验证。对于疑似攻击的 UDP 流量，清洗节点会先发送验证请求，只有能够正确回应的源 IP 才被放行。这个方法在游戏、即时通讯这类业务型 UDP 场景中很有效，但需要业务协议本身支持验证机制。

第四层是应用层协议代理。针对 DNS、NTP、SSDP 这类容易被 UDP 反射放大的协议，清洗节点直接以代理身份接收请求，再向后端转发。后端永远只与清洗节点通信，攻击者无法直接打击源站。

混合攻击下，这四层策略必须同时开启，并且要按业务特征配置优先级。比如某个业务只有少量 UDP 同步数据，就应该把 UDP 粗过滤优先级调高；如果业务本身重度依赖 UDP，则需要把客户端验证优先级调高，避免误杀正常用户。

3.4 回程链路：决定攻防成败的隐形瓶颈

很多人买高防 IP 只盯着“防护带宽有多大”，却忽略了回程链路。攻击流量经过清洗后，正常流量要原路返回源站，这条回程链路的带宽决定了你能扛住多大清洗后的残余流量。

举个例子，某高防 IP 宣称防护能力 50Gbps，清洗效率 90%。攻击流量达到 50Gbps 时，清洗后仍有 5Gbps 正常流量加少量漏网攻击流量需要回传。如果源站到清洗中心的回程链路只有 2Gbps，那么源站依然会被这 5Gbps 直接打死。这个道理和工业管道完全一样——前端净化能力再强，后段管道细了也是白搭。

所以评估高防 IP 时，一定要问清楚回程链路带宽、是否存在多线 BGP 冗余、以及回程链路是否与清洗节点同机房。很多用户买完高防 IP 发现攻击结束后还是各种抖动，问题往往就出在回程链路上。

4. 从流量海洋里捞真凶：SYN 与 UDP 识别策略的实操差异

4.1 识别 SYN 攻击：不能只数 SYN 包

很多防护规则把“每秒 SYN 包数超过阈值”就判定为攻击，这是典型的误杀之源。正常业务中，客户端断线重连、网络爬虫、扫描器都会产生大量 SYN 包，单看数量完全不够。

更可靠的维度是“半开连接的来源特征”。把每个源 IP 发出的 SYN 数量以及重传间隔拉出来看，攻击者为了最大化效率，重传间隔往往极短，甚至小于 100ms，而正常客户端的 TCP 重传遵循指数退避。此外，攻击源的 TTL 集合非常单一，普遍来自同一种内核/设备终端；正常用户的 TTL 会有明显差异。

我常用的一个思路：统计每个源 IP 的 SYN 发送频率分布，取出最高 1% 的源 IP，看它们是否存在“只发 SYN、从不完成握手”的共同特征。如果在正常业务中没有这类行为，就可以高置信度地判定为攻击来源，然后交付清洗节点自动处置。

4.2 识别 UDP 攻击：没有状态，就拼特征

UDP 协议本身无连接，想识别攻击流量，必须看四个维度的分布规律。

一是目的端口分布。攻击者打随机高位端口时，端口分布接近均匀；正常业务通常集中在少数几个固定端口。二是载荷长度分布。大数据传输类业务（视频、文件传输）载荷长度集中且偏大；攻击脚本产生的载荷要么是固定长度，要么是随机长度均匀分布。三是载荷内容特征。很多 UDP 反射放大攻击会携带特定协议头，比如 NTP 的 monlist 请求、SSDP 的 M-SEARCH 请求，这些特征非常明确。四是“请求响应比”。正常 UDP 业务中，请求与响应的比例是稳定的；攻击利用服务器做反射时，请求量和反射响应量之间会出现极端失衡。

把这四个维度做成规则引擎，比任何单一的“UDP 流量超限”都实用。实际部署中，我们的规则引擎就是按端口分布异常、载荷指纹命中、请求响应比失衡三个条件加权打分，超过阈值才触发清洗。

4.3 合法业务躲误杀：动手清洗前先想清楚这几点

混合攻击清洗最大的尴尬是：攻击流量里混着真实用户的 UDP 音视频流，或者合法客户端的 TCP 重传。简单粗暴丢弃会将误杀率推到不可接受的水平。

我的经验是至少做三手准备。第一，为已建连的合法 IP 建立动态白名单，定期过期重校验。第二，对 UDP 业务型协议单独配置“验证放行”策略，不直接丢包。第三，清洗策略的阈值设置要有缓冲：从“可能异常”到“确认攻击”之间，先采取限速措施，限速无效再升级为丢弃。

还有一点很容易被忽略：清洗节点与源站的时钟偏差。清洗节点生成的验证响应如果带着时间戳，而源站校验时两者时间不一致，会把正常用户拒之门外。检查高防 IP 是否支持 NTP 自动同步，以及验证机制是否对时间偏差有容错，这在真实攻击时很关键。

5. 落地时最容易翻车的五个工程细节

5.1 只看带宽不看 PPS 的漏判

第一个坑几乎每个团队都踩过。监控面板只看入带宽，攻击流量以 64 字节小包为主时，带宽数值非常“温和”，但 PPS 已经高到让交换芯片持续丢包。64 字节包在 1Gbps 链路上大约对应 148 万 PPS，实际测试中，一台普通边缘设备可能不到 80 万 PPS 就出现转发明显延迟。

应对方案很简单：在所有流量监控大盘上，同时展示bps、pps、新建连接数三项指标，告警阈值也分别设置。只要 pps 告警先于带宽告警触发，就该立刻进入防御预案。

5.2 防住了攻击，却打出了重传风暴

清洗节点如果对攻击流量的判定不够精准，会把部分合法流量也当成攻击丢包。合法客户端发现丢包后会启动 TCP 重传，并且快速重传数量会指数级上升。这就产生了一个诡异的局面：攻击流量已经被压住了，但清洗节点和源站的负载依然很高，因为大家都在疯狂处理重传包。

我吃过一次亏之后，在清洗策略里专门加了一条：重传包比例超过总包量 20% 时，自动降低丢包强度，转为限速模式。宁可让少量攻击流量漏过，也要保合法业务能正常完成传输，否则清洗本身就成了另一种 DDoS。

5.3 SYN Cookie 开启后，合法长连接进不来

SYN Cookie 是紧急降级的好工具，但不适合长时间开启。它对 TCP 选项的支持有限，客户端与源站之间如果协商了时间戳、SACK 等扩展项，在 Cookie 模式下可能直接失败。实际表现是短连接能通，长连接和文件传输大量失败。

经验是：SYN Proxy 表项占用超过 80% 时，先扩容半开连接表上限，而不是立即切 Cookie；只有扩容后仍然溢出，才启用 Cookie 作为保底。攻击结束后要尽快切回 Proxy 模式，并核对长连接状态。

5.4 清洗节点单点过载：一个容易高估的环节

有些高防 IP 产品只是把清洗能力部署在一个机房、一条链路上，混合攻击一打，节点自身可能先过载。原因在于清洗节点既要维持 SYN Proxy 状态表，又要执行 UDP 特征匹配，CPU 消耗极高。如果周边链路也较小，清洗节点本身的转发带宽会先到上限。

选型时要求服务方明确：清洗节点是否多集群部署、是否支持按区域自动切换、单节点过载后的引流策略是什么。真打起来才发现单点过载，那就是花钱买了个显示器，只看得见指标却救不了业务。

5.5 回切源站的瞬间抖动

攻击结束后的回切阶段，同样会引发业务抖动。流量从清洗节点切回源站的过程中，BGP 路由收敛需要时间，源站又要重新建立大量连接，这个窗口内会出现秒级超时和连接重置。

我的处理方式是设置回切冷却时间：确认攻击流量下降到阈值以下后，先持续清洗 15 到 30 分钟，给攻击者一个“息兵”窗口，再进行平滑切换。同时，回切过程要手动触发，不要用自动化直接切，避免攻击在切换瞬间回马枪。

6. 怎么验收一套能打的高防 IP：我的实战标准清单

6.1 硬指标先过一遍

这些指标建议写进采购合同或服务级别协议。口头承诺的“无限防”基本都是营销话术。

6.2 业务功能层面的验收细节

除了硬指标，还要验收几个直接影响业务的功能点。动态白名单是否支持按源 IP 和按端口分别配置；UDP 验证机制是否支持自定义协议字段；清洗策略是否允许按时间段调整优先级；报警和切换 API 是否能与你的监控平台打通。

混合攻击场景下最容易被忽略的是“清洗策略优先级”。一个完备的高防 IP 平台，应该允许你设置：当 SYN 和 UDP 同时超阈值时，先保哪个业务。没有这个能力，一次混合攻击就可能让你在“保支付通道”和“保视频流”之间被迫手动切换。

6.3 上线前的混合攻击演练

验收的最终方式是演练。挑一个业务低峰期，用三组流量依次测试：

第一组单独打 SYN Flood，持续 15 分钟，观察合法 TCP 连接的成功率；第二组单独打 UDP Flood，持续 15 分钟，观察 UDP 业务是否正常；第三组混合攻击，SYN 和 UDP 同时打 30 分钟，观察清洗节点是否出现状态表溢出、合法流量是否稳定。

演练期间，源站要同步盯四个指标：回程带宽占用、新建连接成功率、UDP 请求响应延迟、清洗节点是否触发限速。演练结束后，把清洗节点切换回正常模式，观察回切诱发的抖动时长。经历过至少一轮完整演练，你才对这套高防 IP 的真实能力心中有数。

在这几轮演练里，我学到的最大教训是：高防 IP 不是买完就完了，它和业务配置、阈值调优、回切节奏全都强相关。平时不演练，真被混合攻击打进来，所有参数都会在你眼前逐渐失控。我的个人习惯是每个季度固定做一次混合攻击演练，把清洗策略的每个阈值都回看一遍，确认它们还符合当前业务模型，再顺手更新动态白名单。这一步看起来不起眼，但往往就是它在关键时刻保住了你的业务。