DDoS攻击的底层逻辑从来不是“打穿服务器”，而是“耗尽资源”。无论是带宽、连接表、CPU还是内存，攻击者的目标都是让某个资源池先于业务崩溃。理解这一点，就能明白为什么很多传统的防护思路会失效：单纯堆带宽解决不了连接数耗尽，单纯加服务器解决不了状态表溢出。真正有效的防护必须从资源隔离、流量识别和弹性调度三个维度同时下手。

先看最常见的SYN Flood。TCP三次握手的第一步是客户端发送SYN包，服务器收到后会在内存中创建一个半连接状态，等待客户端回复ACK。攻击者发送大量伪造源IP的SYN包，服务器就会创建大量永远等不到ACK的半连接，直到连接表被塞满，正常用户无法建立新连接。这里的关键资源是“半连接表”，而不是带宽。一个10Mbps的SYN Flood就能打垮一台配置不错的服务器，因为半连接表的大小通常只有几万到几十万条。

针对SYN Flood，最有效的技术是SYN Cookie。它的核心思路是：服务器收到SYN包后，不立即分配连接资源，而是根据源IP、端口、时间戳和一个密钥计算出一个Cookie值，放在SYN-ACK包中发回。当客户端回复ACK时，服务器验证Cookie的合法性，验证通过才真正创建连接。这样攻击者只发SYN包不回复ACK，就永远不会占用服务器的连接资源。Linux内核自带SYN Cookie机制，通过sysctl参数net.ipv4.tcp_syncookies=1即可开启。但要注意，SYN Cookie会丢失TCP的一些扩展选项，比如窗口缩放和选择性确认，在高并发场景下可能影响性能。更精细的做法是在负载均衡层做SYN Proxy，由代理设备先完成三次握手，验证客户端是真实的之后，再与后端服务器建立连接。

UDP Flood是另一种常见攻击。UDP协议无连接、无状态，攻击者可以向任意端口发送大量UDP包。如果目标端口上没有服务监听，服务器会回复ICMP端口不可达；如果有服务监听，应用层就要处理这些垃圾数据。UDP Flood的可怕之处在于它几乎不需要攻击者维持任何状态，伪造源IP极其容易，追踪难度大。防护UDP Flood的核心思路是限速和丢弃。在边界设备上对UDP流量做速率限制，超过阈值的直接丢弃。对于不需要UDP服务的业务，直接在防火墙层面关闭所有UDP端口。对于必须开放UDP的业务，比如DNS，需要部署专门的DNS防护策略，包括源IP信誉库、请求速率限制和响应速率限制。

HTTP Flood，也就是通常说的CC攻击，是应用层攻击中最难防的一种。它模拟真实用户的HTTP请求，每个请求本身都是合法的，但请求频率极高，或者请求的URL特别消耗服务器资源，比如搜索接口、数据库查询接口、动态页面生成等。攻击者不需要伪造IP，甚至可以用真实的浏览器指纹和完整的Cookie来绕过简单的防护规则。防护HTTP Flood的关键在于行为分析。正常的用户访问有节奏、有停顿、有页面跳转逻辑，而攻击工具的请求模式往往是机械的、均匀的、高频率的。通过分析请求间隔、URL分布、User-Agent多样性、Cookie有效性等维度，可以识别出大部分自动化攻击。更进阶的做法是引入JavaScript挑战，要求客户端执行一段JS代码并返回计算结果，这能有效过滤掉不支持JS的简单攻击脚本。但要注意，JS挑战对搜索引擎爬虫和部分合法客户端不友好，需要配置白名单。

DNS反射放大攻击是近年来增长最快的攻击类型之一。攻击者向互联网上开放的DNS服务器发送小体积的查询请求，伪造源IP为受害者的IP地址。DNS服务器收到查询后，会向受害者返回大得多的响应数据。攻击者只需要很小的带宽，就能撬动几十倍甚至上百倍的流量打向目标。防护DNS反射攻击，首先要确认自己的DNS服务器没有对外开放递归查询功能。如果必须开放，要限制递归查询的源IP范围，只允许内部网络使用。对于被攻击的目标来说，防护难度较大，因为攻击流量来自大量合法的DNS服务器，源IP无法简单封禁。此时需要依靠上游运营商或专业的DDoS清洗服务，通过流量牵引和清洗来过滤攻击流量。

NTP、SSDP、Memcached等协议也存在类似的反射放大问题。Memcached的放大倍数尤其惊人，最高可达5万倍。一个几百字节的请求可以触发几兆字节的响应。防护思路与DNS类似：关闭不必要的服务暴露，限制UDP端口，使用访问控制列表。对于必须暴露的服务，启用源IP验证和速率限制。很多反射攻击之所以成功，就是因为互联网上存在大量配置不当的开放服务，攻击者可以轻易利用它们作为“弹药库”。

从实操层面看，一个完整的DDoS防护体系应该包含以下几个层次。第一层是网络边界防护，包括防火墙、入侵检测系统和流量清洗设备。这一层负责过滤掉明显的攻击流量，比如伪造源IP、异常协议包、超大数据包等。第二层是应用层防护，部署在负载均衡器或反向代理上，负责识别和拦截HTTP Flood、慢速攻击等应用层威胁。第三层是业务层防护，在应用代码中实现限流、降级和熔断机制，确保即使攻击穿透了前两层，核心业务也不会完全崩溃。第四层是弹性资源层，利用云服务的弹性扩容能力，在攻击发生时快速增加带宽和计算资源，为清洗争取时间。

很多人忽视了一个关键点：DDoS防护不是纯技术问题，而是资源对抗问题。攻击者的成本远低于防御者的成本。攻击者租用一个僵尸网络，几百块钱就能发起一场中等规模的攻击，而防御方需要投入数倍甚至数十倍的成本来购买清洗服务、增加带宽、部署设备。因此，防护策略必须考虑成本效益。对于大多数企业来说，自建完整的DDoS防护体系是不现实的，更合理的做法是混合防护：日常流量走自己的服务器，检测到攻击时自动切换到大流量清洗服务商，利用云服务商的带宽资源来吸收攻击。这种方案的关键在于切换速度。攻击流量可能在几分钟内就打满带宽，如果切换需要人工介入，业务早就中断了。必须通过BGP宣告或DNS切换实现自动化，检测到异常后几十秒内完成流量牵引。

还有一个容易被忽略的环节是日志和监控。没有准确的流量基线，就无法判断什么是“异常”。很多企业直到业务完全不可用才发现被攻击，就是因为平时没有建立流量模型。建议对入口流量、连接数、请求速率、响应时间等指标做持续的监控和记录，建立不同时间段的基线数据。当指标偏离基线超过一定阈值时，触发告警并自动启动防护策略。监控的粒度越细，响应越及时，业务受损就越小。

最后要强调的是，DDoS防护没有一劳永逸的方案。攻击手法在不断演化，防护策略也要持续迭代。定期进行攻防演练，模拟不同类型的攻击，检验防护体系的有效性，是保持防护能力的关键。同时，关注安全社区和厂商发布的威胁情报，了解最新的攻击趋势和工具特征，及时更新防护规则。DDoS防护是一场持续的对抗，只有保持警惕和迭代，才能在攻击来临时从容应对。