TCP三次握手被攻击者利用的核心方式有三类：SYN Flood耗尽服务器资源、TCP连接劫持与RST切断、握手完成后的慢速应用层占用，每类攻击的切入点不同，但目标都是让正常用户无法完成握手。SYN Flood是流传最久、影响范围最广的手段，至今仍是DDoS攻击的主要构成部分，要理解攻击者为什么盯着三次握手不放,得先看看握手阶段服务器付出了什么代价。
攻击者盯上三次握手：问题出在资源分配机制
TCP三次握手的过程，本质上是一个“验证双方都在线”的协商流程，客户端发SYN，服务器回SYN-ACK，客户端再回ACK，连接建立，问题在于，服务器在收到第一个SYN时，就必须立刻分配一块内存来记录这个半连接状态，这块内存叫传输控制块,同时还要启动一个定时器等待客户端回应。
攻击者利用的就是这个“先分配、后验证”的机制。伪造一个源IP地址几乎零成本，而服务器为每个假SYN付出的资源却是实打实的，伪造的SYN源源不断涌来，服务器的内存、CPU、连接表被占满，后续正常用户的SYN包排队都排不上，表现为网站无法访问、App无法登录。
抓包看一次正常握手会更直观,在一台Linux服务器上执行：
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'
正常业务时，你会看到三个包的序列：SYN、SYN-ACK、ACK，一来一回节奏紧凑，如果抓包结果里SYN包铺天盖地，但SYN-ACK发出后几乎无人回应，那基本可以断定正在被SYN Flood攻击。
为什么握手阶段比数据阶段更易被利用
原因有三点,层层递进：
- 验证缺位：SYN包不携带任何身份凭证,源IP可以随意伪造。
- 成本不对称：攻击者发一个几十字节的SYN包只需极低带宽,服务器却要动用内存和CPU。
- 状态残留：半连接会驻留一段时间，默认在Linux下是60秒左右,攻击者可以持续施压让旧连接来不及释放。
这三点叠加起来，让握手阶段成了天然的“资源绞肉机”。
三种被高频利用的握手攻击方式
不同攻击者打握手阶段的主意，手法各不相同，有的是为了瘫痪目标，有的是为了切断特定用户的连接,有的则是为了长期占用资源。
SYN Flood：只敲门不进门，让门口堆满半连接
这是最典型的握手攻击，攻击者发送大量SYN包到目标服务器，但收到SYN-ACK后故意不回ACK，甚至源IP本身就是伪造的,根本没有设备会回复。
服务器端的表现非常明确：netstat命令里出现大量SYN_RECV状态的连接，数量从几十飙涨到几万，连接表被塞满后，新来的SYN包直接被丢弃，行业共识认为，SYN Flood的防御难点不在“抵不抵得住第一波”，而在“如何区分恶意SYN与正常SYN”,因为两者的包格式完全一致。
近年来，DDoS攻击报告中相当一部分攻击峰值事件都包含了SYN Flood成分，它经常与UDP Flood混合使用,干扰防御设备的清洗策略。
TCP连接劫持与RST切断：冒充一方，直接砍断连接
三次握手不只是建立连接的过程，它还确定了初始序列号，如果攻击者能猜出或窃取到通信双方的序列号，就可以伪造一个RST包发送给服务器或客户端，让双方误以为连接出错,强制断开。
实操中攻击者常配合中间人手段，先监听拿到序列号，再伪造RST包，效果上，用户表现为“刷一下网页就断了，重新加载又能打开，但过几秒又断”，这种攻击的隐蔽性比SYN Flood高很多，因为流量层面看不出洪峰，更像是网络抖动，业内专家指出，多数WAF设备对这类攻击的感知能力偏弱，需要在网络层开启TCP异常检测,比如监控单位时间内RST包数量是否异常飙升。
慢速应用层攻击：握手完成后赖着不办事
这类攻击不像SYN Flood那样狂轰滥炸，反而走“细水长流”路线，攻击者正常完成三次握手，建立连接后，不发完整请求,而是每隔几十秒发一个字节维持连接不超时。
服务器为每个连接分配的线程、文件描述符、内存都被长期占用，连接池耗尽后，新用户的三次握手虽然能建立，但应用层没有资源处理请求，表现为“页面一直转圈，浏览器左下角显示正在等待响应”，Slowloris经典工具就是利用这个思路,单个攻击者用几百条连接就能拖垮一个小型Web服务器。
tcp三次握手和四次挥手区别：攻击者的侧重点完全不同
很多人会困惑：TCP四次挥手同样有状态转换，攻击者为什么更爱打三次握手的主意？核心区别在于资源消耗的位置不同。
| 阶段 | 资源消耗类型 | 攻击后果 | 伪造难度 |
|---|---|---|---|
| 三次握手 | 内存、CPU、连接表 | 新连接无法建立，服务整体瘫痪 | 低，SYN包无需验证 |
| 四次挥手 | 几乎没有额外资源开销 | 连接被提前切断，但可自动重连 | 中，需要猜测序列号 |
三次握手消耗的是服务器“接纳新客人”的能力，四次挥手消耗的只是拆除连接时的状态转换，攻击者想要的是让对方无法服务，当然优先攻击接纳入口，握手阶段的SYN包可以伪造源IP，而四次挥手中的RST包要生效必须在正确的序列号范围内,技术门槛高了一截。
这也解释了为什么企业安全团队在做防护时，通常把80%的精力放在握手阶段的防护上。
tcp握手攻击如何防御：从配置到架构的实操路径
防御握手指类攻击没有银弹，需要从单机内核参数、网络层清洗、商业防护三个层面层层设防。
第一步：调整服务器内核参数
Linux服务器默认的内核参数是为通用场景优化的，需要针对性调整，修改/etc/sysctl.conf：
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_abort_on_overflow = 1
tcp_syncookies：开启SYN Cookie，当半连接队列满时，不再分配内存，而是通过计算返回一个Cookie作为SYN-ACK，这是抵御SYN Flood的第一道防线。tcp_max_syn_backlog：增大半连接队列长度,给正常用户的SYN包更多排队空间。tcp_syn_retries：减少系统重发SYN-ACK的次数,尽快释放无响应的半连接。tcp_abort_on_overflow：当应用程序的accept队列满时，直接丢弃新连接,避免连接陷入僵持。
调整完成后执行sysctl -p生效，这套配置对中小型攻击有明显效果,但扛不住大流量洪峰。
第二步：在网络层做流量清洗
当攻击流量超过服务器带宽上限时，内核参数也无济于事，此时需要将流量引流到清洗设备或云清洗节点,流程通常是：
- 将域名解析切换到高防IP,或通过BGP宣告将被攻击的IP路由指向清洗机房。
- 清洗设备基于源IP行为、SYN重传频率、连接速率等维度过滤恶意流量。
- 清洗后的干净流量通过隧道回注到源站。
云平台也提供原生防护能力，在简米云、酷番云的控制台里，可以开启DDoS基础防护和原生防护,设置清洗阈值和黑洞触发值。
第三步：选择商业防护产品时，ddos攻击防护价格一般多少？
商业防护的价格不是固定值，取决于防护峰值、计费方式和地域节点。目前主流云厂商的高防IP产品按“保底峰值+弹性流量”计费，保底10Gbps的包年费用大致在数千元到万元区间，百Gbps级别的保底套餐年费普遍在数万元以上
，具体到“ddos攻击防护价格一般多少”“高防IP多少钱一年”这类问题，建议直接询问云厂商销售获取实时报价,因为各家策略随时在调整。
华东地区一家做跨境电商的中型公司曾遇到持续一周的SYN Flood攻击，峰值约30Gbps，对比下来，选择了某云厂商的30Gbps保底高防包，年费不到五万元，攻击期间业务中断时间控制在分钟级，这个投入换来的是线上店铺的持续转化收入,划算与否一目了然。
检测与自愈：防御不是一次性配置
部署完防护手段后要持续监控,几个关键指标必须盯紧：
- 半连接数：
ss -s输出的SYN_RECV数量，一旦持续超过队列容量的70%就需预警。 - CPU使用率：SYN Flood会导致内核软中断和哈希表操作剧增,CPU使用率被异常拉高。
- 可用性探测：从外部视角定时发起真实TCP连接测试,确保握手成功率保持在正常水平。
结合云监控告警和自动扩容策略,可以在攻击升级时自动提升防护能力。
Q&A：关于TCP握手攻击的高频疑问
SYN Flood攻击能完全防御吗？
无法做到100%完全防御，但可以通过多层措施将影响降到可接受范围，开启SYN Cookie、部署流量清洗、使用高防IP，三者叠加后，大多数SYN Flood攻击对正常用户的影响可以从“完全无法访问”降低到“响应延迟小幅增加”。
TCP三次握手为什么是三次？两次不行吗？
三次握手的核心目的不是确认双方“能通”，而是确保双方都掌握正确的初始序列号，两次握手会导致服务器无法确认客户端是否收到了自己的SYN-ACK，从而出现半开连接，历史上的一些早期协议曾尝试过两次握手,但最终都因无法防止历史重复SYN包导致的连接混乱而放弃。
被SYN Flood攻击后，如何区分是攻击还是正常业务高峰？
查看SYN_RECV状态连接数的占比、源IP的分布特征以及SYN包的到达速率，正常业务高峰时，SYN包会伴随着大量的ACK包和后续数据包，连接会快速完成三次握手进入ESTABLISHED状态，而攻击发生时，SYN_RECV状态连接数占比可能超过90%，源IP集中在少数网段且没有后续数据包，tcpdump抓包结果呈现大量重传的SYN-ACK，检查CPU软中断占用率,异常飙升也说明大概率正在被攻击。