课程名称：计算机网络应用 核心摘要：本讲围绕 DDoS（分布式拒绝服务）攻击展开，讲解其利用底层协议漏洞、通过僵尸网络放大请求耗尽服务器资源的攻击原理；重点剖析基于 TCP 三步握手的 SYN Flood 攻击机制、半连接耗尽过程及重试时间开销，并介绍 Cookie 源认证与 Reset 重置认证两种主流防护方案，最后说明 DDoS 防护的产业现状与局限。
- DDoS（Distributed Denial of Service，分布式拒绝服务）：将正常的请求放大若干倍，通过若干个网络节点同时发起攻击，使目标服务器承受不住而拒绝服务。
- DoS（Denial of Service，拒绝服务）：单点发起的拒绝服务攻击；DDoS 是其分布式升级版，依靠规模效应。
- 本质：利用看似合理、实则不合理的请求，借助底层协议漏洞造成服务器资源过载 / 资源耗尽，导致服务不可用。
- 任何服务器的并发连接数、CPU、内存都是有限的，攻击者以海量合法请求占满资源后，正常用户请求将被拒绝。
| 类比对象 | 对应含义 |
|---|
| 停车场 100 个车位 | 服务器有限的连接资源 |
| 车位停满 | 资源耗尽 |
| 后续车辆无法进入 | 正常请求被拒绝服务（DoS） |
- 黑客通过木马程序入侵大量主机，将其控制为肉鸡。
- 由大量肉鸡组成僵尸网络（Botnet），大型僵尸网络可达数万至数十万台设备。
- 黑客操控僵尸网络中所有设备，以最大负荷报文同时向目标服务器发送请求。
- 服务器资源在极短时间内被耗尽，无法再处理正常请求。
历史案例：2000 年代初期，百度曾遭受僵尸网络攻击，连续数小时无法对外提供服务。该方法原始但有效，直接耗尽资源，难以彻底处理。
DDoS 是一个大类，按所利用的底层协议不同细分为：
| 攻击类型 | 所属协议 | 说明 |
|---|
| SYN Flood | TCP | 历史上影响最严重，利用 TCP 三步握手漏洞，防护困难 |
| UDP Flood | UDP | 基于 UDP 协议发起的洪水攻击 |
| ICMP Flood | ICMP | 基于 ICMP 协议发起的洪水攻击 |
重点：基于 TCP 的 SYN Flood 是影响最严重、最典型的 DDoS 攻击方式，本讲重点剖析。
| 握手步骤 | 正常流程 | SYN Flood 攻击流程 |
|---|
| 第一步 | 客户端发送 SYN, SEQ=X | 攻击者伪造源 IP 发送 SYN 请求建立连接 |
| 第二步 | 服务端回复 SYN+ACK, SEQ=Y, ACK=X+1 | 服务端回复 SYN+ACK，等待客户端确认 |
| 第三步 | 客户端回复 ACK, ACK=Y+1，连接建立 | 伪造源 IP 不做任何回复，连接停留在半连接状态 |
- 半连接：未完成三步握手的连接。攻击者发送大量伪造源地址的 SYN 请求，服务器为每个半连接消耗 CPU、内存、时间 资源。
- 重试机制：TCP 作为可靠协议，服务端未收到响应会自动重试，默认重试 5 次。
- 重试时间间隔：每次间隔为上一次的 2 倍（指数退避）。
| 重试次数 | 等待时间 |
|---|
| 第 1 次 | 1 秒 |
| 第 2 次 | 2 秒 |
| 第 3 次 | 4 秒 |
| 第 4 次 | 8 秒 |
| 第 5 次 | 16 秒 |
| 第 5 次发出后额外等待 | 32 秒 |
| 合计 | 约 63 秒 |
- 半连接总数上限：1024 个。在极短时间内，服务器的半连接资源即被完全耗尽。
- 后果：半连接资源耗尽后，服务器无法再对正常请求发起三步握手，新的合法请求被直接拒绝 → 拒绝服务。
- 漏洞源于 TCP 协议本身，属于协议级漏洞，无法通过单方面修补解决。
- TCP 是整个互联网的基础协议，牵一发动全身；市场上几乎所有互联网设备均已支持现有 TCP 协议，升级修补是一个缓慢过程。
- 仅靠单一企业之力难以彻底解决，但防护思路是存在的。
主流防护思路：在客户端与目标服务器之间插入 DDoS 防护系统（中间层），由防护系统代理完成握手验证，验证通过的真实客户端加入白名单后才能与 Server 通信。
[客户端/攻击者] <--> [DDoS 防护系统] <--> [目标 Server]
| 步骤 | 报文 | 字段值 |
|---|
| ① 客户端发起握手 | SYN, SEQ=X | — |
| ② 防护系统回复 | SYN+ACK | SEQ=cookie，ACK=X+1 |
| ③ 正常客户端回复 | ACK | ACK=cookie+1（正确响应） |
| ③' 伪造源地址 | 无任何回复 | — |
| ④ 验证结果 | 回复正确 → 加入白名单，允许访问 Server | 不回复 → 丢弃，不加白名单 |
| 步骤 | 报文 | 字段值 |
|---|
| ① 客户端发起握手 | SYN, SEQ=X | — |
| ② 防护系统回复（故意错误） | SYN+ACK | SEQ=Y，ACK=cookie（ACK 应为 X+1，此处故意错误） |
| ③ 正常客户端发现确认号错误 | 发送 RST（Reset） 重置报文 | SEQ=cookie+1 |
| ③' 伪造源地址 | 无任何回复 | — |
| ④ 验证结果 | 发送 RST → 说明是真实客户端 → 加入白名单 | 不回复 → 丢弃 |
| 对比项 | Cookie 源认证 | Reset 重置认证 |
|---|
| 验证方式 | 期望客户端回复正确的 ACK | 期望客户端发现错误并回复 RST |
| 第二步 SEQ 值 | cookie | Y |
| 第二步 ACK 值 | X+1（正确） | cookie（故意错误） |
| 客户端预期响应 | ACK = cookie+1 | RST, SEQ = cookie+1 |
| 核心思想 | 验证客户端是否为真实有效客户端 | 同左 |
| 通过验证后 | 加入白名单，可与 Server 通信 | 同左 |
共同本质：无论哪种方案，都是验证客户端是否为真实有效的客户端；真实客户端加入白名单后与 Server 通信，否则丢弃。等同于在 Server 外层加了一道防火墙 / 防护层。
- 阿里云等云厂商推出抗 DDoS 产品，本质是在服务前置入防火墙/防护层。
- 对抗 DDoS 产品中一般综合使用多种算法，结合攻击情况对流量进行流量清洗——清洗目的即洗掉攻击者流量。
| 现状 | 说明 |
|---|
| 仍是业内难题 | 当攻击流量超出网络设备（含 DDoS 防护系统）承载上限时，防护系统本身崩溃，Server 随之瘫痪 |
| 大厂"能扛"的真相 | 阿里、京东级别站点靠充足带宽和海量集群分散压力，并非协议层面真正解决 |
| 攻击流量规模 | 实际 DDoS 攻击流量可达 G 级甚至数十 G，若无硬件负载均衡则直接崩溃 |
| 终极应对 | 仅靠自身无法防御，需与网络运营商合作，共同完成 DDoS 流量清洗与牵引 |
学习定位：DDoS 底层攻防属复杂课题，本讲仅限理论层面讨论。实际防护方案多采购现成产品，企业几乎不可能自行实现协议级防护。本讲是为后续 CC 攻击（应用层 DDoS） 做铺垫，同时拓宽安全防护（安防）知识储备。
- 考点 1：DDoS 与 DoS 的区别——分布式与规模效应；DDoS 依赖僵尸网络 / 肉鸡。
- 考点 2：DDoS 本质——利用看似合理实则不合理的请求，借助底层协议漏洞造成资源耗尽。
- 考点 3：SYN Flood 利用 TCP 三步握手，伪造源 IP 制造半连接，半连接上限 1024。
- 考点 4：TCP 重试机制——默认 5 次，间隔指数退避（1+2+4+8+16 秒 + 末次等待 32 秒 ≈ 63 秒）。
- 考点 5：两种防护方案的核心区别——Cookie 源认证回复正确 ACK 期待正确回应；Reset 重置认证故意发错误 ACK，期待客户端回 RST。
- 易错点：防护系统的 SEQ 与 ACK 取值在两种方案中正好相反，勿混淆。
- 难点：为何 SYN Flood 难根治——协议级漏洞，TCP 是互联网基石，升级牵一发动全身。
- 面试题：简述 SYN Flood 攻击原理及两种主流防护方案的差异。
- UDP Flood 与 ICMP Flood 的攻击原理与防护方案分别是什么？（本讲未展开，待补充）
- 反射放大攻击（如 NTP 放大、DNS 放大）与 SYN Flood 的区别与联系是什么？
- 黑洞路由作为 DDoS 应急手段是如何工作的？与流量清洗的差别？
- CDN 防护 / 云防护如何缓解 DDoS？其与本地 DDoS 防护系统的分工边界？
- 后续课程将进入 CC 攻击（应用层 DDoS） 与 IP 黑白名单 防护方案，注意其与本讲网络层 DDoS 的层次差异。