SYN Flood 攻击与防范#

• 正常流程：客户端发送 SYN，服务器接收并进入 SYN_RECV 状态，将连接放入半连接队列(SYN Queue)，并回复 SYN-ACK，等待客户端的 ACK。（之后接收到 ACK 报文，从 SYN 队列取出一个半连接对象，然后创建一个新的连接对象放入到全连接队列(Accept Queue)。应用通过调用 accpet() socket 接口，从 Accept 队列取出连接对象。）
• 攻击原理：SYN Flood 是一种典型的 DoS 攻击。攻击者伪造大量源 IP，疯狂发 SYN 报文。服务端每次都回复 SYN-ACK 并分配半连接资源，但永远收不到第三次 ACK，半连接队列被撑爆。
• 防范手段：主要从“队列扩容”、“加速回收”和“不占用队列”三个思路入手

  (1) 开启 syncookies（最有效的方法）#

  这是目前防御 SYN 攻击最主流的手段。

  • 原理：当半连接队列溢出时，服务器不再将连接放入队列。而是根据 (源IP, 目的IP, 源端口, 目的端口, 时间戳) 等信息计算出一个 cookie（特殊的序列号），放到第二次握手报文的序列号字段发给客户端。
  • 效果：服务器不需要在本地分配内存来存储这个半连接。直到客户端回了 ACK，服务器再根据 ACK 里的序列号逆运算，如果合法，才正式建立连接。
  • 内核参数：net.ipv4.tcp_syncookies = 1（默认值）。当半连接队列溢出时启用 syncookies。net.ipv4.tcp_syncookies = 2。无条件启用 syncookies。

  (2) 增大半连接队列(SYN Queue)#

  适当调大内核参数，让队列能容纳更多的连接。

  • 注意：单纯增大队列只是“延缓”死亡，如果攻击流量巨大，队列终究会被填满。
  • 内核参数：net.ipv4.tcp_max_syn_backlog。（默认值 1024）

  (3) 减少 SYN-ACK 重传次数#

  服务器发出的 SYN-ACK 如果收不到回应，默认会进行多次重传（默认值 5）。

  • 原理：每多重传一次，这个半连接就在队列里多占几秒钟。减少重传次数可以加快这些无效连接的关闭。
  • 内核参数：net.ipv4.tcp_synack_retries。调小响应 SYN-ACK 报文的重传次数（如 1 或 2）。（P.S. tcp_syn_retries: 发送 SYN 报文的重传次数（默认值 6）

  (4) 缩短 SYN Timeout 时间#

  • 通过调整内核代码（确信X），缩短半连接在 SYN_RECV 状态下的存活时间，让过期的连接更早地被系统回收。（默认写死了#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))；第 $n$ 次重传的等待时间 = $2^{(n-1)} \times 1$ 秒）

  (5) 配置防火墙或 IPS#

  在服务器前端部署防火墙（如 Linux 的 iptables/nftables）或专业的抗 DDoS 设备：

  • 限制 SYN 包的频率：限制单个 IP 的 SYN 请求速率。

  1
  # 1. 允许平均每秒10个新的SYN连接，突发上限为20个
  2
  iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
  3
  # 2. 超过限制的 SYN 包直接丢弃
  4
  iptables -A INPUT -p tcp --syn -j DROP
  

  • SYN Proxy：硬件防火墙或高级负载均衡器拦截SYN并伪装成服务器回复SYN-ACK，只有当客户端完成了三次握手，防火墙确认这是一个真实合法的连接，才会由防火墙代替客户端与真正的服务器建立连接。
  • 首包丢弃策略(First-Packet Drop)：针对某些固定模式的攻击包进行拦截。（如防火墙记录下每一个新来的 SYN 包的源 IP，但直接丢弃这个首包，利用 TCP 重传机制来识别人机。）

1. 防止“历史报文”被下一个相同四元组的连接错误接收#

在复杂的网络环境中，报文可能会因为路由跳数过多或网络拥堵，导致当报文最终到达目的地时，原来的 TCP 连接可能已经关闭，且恰好有一个相同四元组（源IP、源端口、目的IP、目的端口）的新连接建立了。

• 如果 ISN 相同： 新连接的序列号范围可能与旧连接的序列号范围重叠。如果旧连接的一个“迟到”报文此时到达，且它的序列号刚好落在新连接的接收窗口内，接收方会认为这是合法的数据而接收。这会导致数据篡改或连接错乱。
• 如果 ISN 不同（随时间增加）： 通过让 ISN 随时间变化，可以保证在一个 MSL（最大报文生存时间）内，新老连接的序列号范围大概率是不重叠的。这样，即使旧报文飘到了新连接面前，也会因为序列号校验不通过而被丢弃。

2. 防止黑客伪造的“序列号预测攻击”被错误接收#

如果 ISN 是固定的（比如每次都从 0 开始）或者是非常容易预测的（比如线性递增），黑客就可以利用这个漏洞进行攻击。

• 攻击原理（TCP序列号预测攻击）： 黑客可以伪造发送方的 IP 地址，并预测出接收方（服务器）当前的序列号。由于黑客知道序列号，他可以不需要真正接收到服务器的响应包，就能直接构造出一个合法的 ACK 报文（甚至带有恶意载荷的数据包）发给服务器。
• 后果： 黑客可以借此建立伪装连接、篡改数据或者进行会话劫持(Session Hijacking)，从而跳过身份验证。
• 解决方案： 现代操作系统通常采用伪随机算法来生成 ISN。通常结合了：四元组的哈希值 + 一个随时间递增的计时器 + 系统的一个随机密钥。
  这样生成的 ISN 对于每个连接都是独立且不可预测的，极大地增加了黑客伪造包的难度。

1. IP 分片的致命缺陷：一损俱损#

如果 TCP 不限制发送大小（比如一次性发 5000 字节），那么 IP 层就会根据 MTU 进行(被动)分片（分成 4 个片段）。 致命问题在于：IP 层本身没有重传机制。

• 场景：假设一个 IP 报文被分成了 4 个分片（Fragment 1~4）。
• 意外：在传输过程中，Fragment 2 丢了。
• 结果：
  1. 接收方的 IP 层由于收不齐所有的分片，无法组装出完整的 IP 报文。
  2. 接收方的 IP 层会直接丢弃已经收到的 Fragment 1, 3, 4。
  3. 发送方的 TCP 层因为迟迟收不到确认，会触发超时重传，重新发送那整个 5000 字节的 TCP 段。
  4. 这导致了极大的带宽浪费和重传开销。

2. TCP MSS 的解决方案：源头切分，精准补发#

为了避免 IP 分片带来的低效，TCP 协议在握手阶段会通过 MSS 字段协商出一个“安全大小”。

• 策略：TCP 在发送数据前，就按照 MSS 把应用层数据主动切分成一个个小的报文段。
• 效果：
  1. 经过 TCP 封装后的整个 IP 报文大小小于等于 MTU。
  2. 这样到了 IP 层，IP 发现：“哎呀，这个包正好能装进以太网帧里，不用分片了，直接发！”
• 优势： 如果网络中丢了一个 TCP 报文段，TCP 只需要重传这一个报文段即可。其他顺利到达的报文段会被接收方暂存在缓冲区，不需要像 IP 分片那样全盘重来。

net.ipv4.tcp_tw_reuse = 1 通过 TCP Timestamps时间戳 代替 “等待 2MSL”#

• 第四次挥手ACK丢失问题： ACK丢失，并复用了端口来请求同一个服务器。服务器服务器会根据新 SYN 包的时间戳，知晓上一个连接最后的ACK丢失了，然后直接释放掉之前那个处于 LAST_ACK 的旧Socket对象，创建一个处于 SYN_RECV 状态的新Socket对象。
• 旧报文问题：PAWS(Protection Against Wrapped Sequence Numbers): 内核会记录来自同一IP的连接上一次收到的报文的时间戳。TCP 协议栈一旦发现收到的报文时间戳“过期”了，就会直接丢弃该报文。

1. 发送方的滑动窗口#

1
窗口大小 = 8 时：
2
    已确认   已发未确认  未发可发   未发不可发
3
  ┌───────┬───────────┬─────────┬─────────────┐
4
  │ 1 2 3 │ 4 5 6 7 8 │ 9 10 11 │ 12 13 14 ...│
5
  └───────┴───────────┴─────────┴─────────────┘
6
            ↑           ↑     ↑
7
         SND.UNA     SND.NXT  窗口右边界

• SND.UNA(Send Unacknowledged)：指向已发送但未收到确认的第一个字节（窗口左边界的绝对指针）
• SND.NXT(Send Next)：指向下一个待发送字节的序列号的绝对指针
• SND.WND(Send Window)：发送窗口的大小（它由接收方在 ACK 中通告，同时也受自身拥塞窗口cwnd的制约）
• 窗口右边界：计算公式为 SND.UNA + SND.WND（即 4 + 8 = 12，指向 12 号字节） 收到 ACK 后，窗口向右滑动，释放新的可用空间。

2. 接收方的滑动窗口#

已收且确认 + 未收但可收 + 未收且不可收

• RCV.NXT(Receive Next)：指向期望从发送方收到的下一个字节的序列号
• RCV.WND(Receive Window)：接收窗口的大小，通告给发送方
• 窗口右边界：计算公式为 RCV.NXT + RCV.WND

滑动窗口与缓冲区的关系#

滑动窗口是基于操作系统缓冲区实现的，而操作系统的缓冲区大小是有限的且动态变化的。

• 接收方：接收窗口rwnd = 接收缓冲区大小 - 已接收但未被应用进程读取的数据。
• 发送方：发送窗口swnd = min(接收窗口rwnd, 拥塞窗口cwnd)。 P.S. 发送窗口和接收窗口并不完全相等。由于网络传输存在时延RTT，发送方接收到的“窗口通告”是接收方过去某一时刻的状态快照。此外，发送方还要考虑网络拥塞程度cwnd。

1. 流量控制的实现：窗口通告#

TCP 利用滑动窗口实现流量控制。在 TCP 首部中有一个16位的 Window 字段，接收方在每次 ACK 中都会填入自己当前接收窗口rwnd大小的这个信息，告诉发送方：“我这儿还有多少空位，你最多还能发这么多。”

2. 内核缓冲区缩减#

若接收方操作系统压力过大，决定把缓冲区缩减，TCP 规定不允许同时收缩窗口(窗口右边界左移)和减少缓存，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了 收缩窗口的ACK报文还在路上飞的时候，发送方的大包已经发出来，最终接收方因存不下而丢弃包情况。（若发送方收到收缩窗口ACK后发现发送窗口为负数，视为零窗口Block阻塞）

3. 零窗口(Zero Window)死锁与窗口探测(Window Probe)#

若接收方处理极其缓慢，导致接收方缓冲区被填满时，会通告窗口为 0。此时发送方Block阻塞，停止发送数据。 死锁风险： 若随后接收方应用处理了数据，空出了窗口并向发送方发送了「窗口更新」报文(ACK确认号没变但窗口变大[TCP Window Update])，但如果这个报文在网络中丢失了，则：发送方在等窗口更新；接收方在等新数据。双方陷入无限等待，即死锁。

解决方案：窗口探测(Window Probe)

• 当发送方收到零窗口通告时，会启动持续计时器(Persist Timer)。（指数退避上限120s）
• 计时器超时后，发送方会主动发送一个1字节的窗口探测报文。
• 接收方必须对此报文给出 ACK，并通告当前最新的窗口大小。
• 如果窗口仍为 0，发送方会重置计时器并重复此过程；如果窗口大于 0，则死锁解除，恢复传输。

如果没收到回复的ACK，重传次数计数器++，等待重传时间指数退避上限120s。 sysctl net.ipv4.tcp_retries1 (= 3): 重传达到tcp_retries1次后，内核会尝试更新路由缓存，但不会断开连接。 sysctl net.ipv4.tcp_retries2 (= 15): 重传达到tcp_retries2次后，内核会直接释放连接。

4. 糊涂窗口综合征(Silly Window Syndrome)#

如果接收方处理太慢，或者发送方发送的数据太碎，会导致网络中充斥着大量“小包”（40字节首部 + 只传几个字节数据），这种现象叫糊涂窗口综合征。 A. 接收方的策略（延迟窗口通告）：

• Clark 策略：如果空掉的缓冲区小于 min(MSS, 接收缓冲区/2)，接收方就继续通告 窗口为 0。等攒够了大的空位，再一次性开放窗口。 B. 发送方的策略（Nagle 算法）：
• Nagle 算法的核心是：(窗口大小和数据量均达到MSS || 收到了之前发出所有的数据的ACK)，在网络中没收到确认之前，先把应用层的小数据攒在发送缓存里。

Nagle 算法虽然能减少小包、保护网络，但会带来额外的延迟（因为在等 ACK 或等数据攒够）。 对于网游、SSH远程登录、实时交互等对延迟敏感的应用，必须通过设置 TCP_NODELAY 选项来禁用 Nagle 算法。

1
// 在 Socket 层面禁用 Nagle 算法，实现高实时性
2
int on = 1;
3
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on));

慢启动(Slow Start)#

• 初始 cwnd = 1 MSS
• 每收到一个 ACK: cwnd += MSS （等价于 cwnd 翻倍）
• 1 → 2 → 4 → 8 → 16 → … （指数增长）
• 当 cwnd 达到 ssthresh 慢启动门限(slow start threshold =65535)后，转入拥塞避免。

拥塞避免(Congestion Avoidance)#

• 每收到一个 ACK: cwnd += 1/cwnd MSS （等价于增加 1 MSS）
• 16 → 17 → 18 → 19 → 20 → …（线性增长）

拥塞发生#

快速恢复(Fast Recovery)#

• 快速重传丢失的包
• 每收到一个重复 ACK：cwnd += 1 (因为 每多收到一个重复 ACK，其本质意味着是一个包离开了网络。我们要维持网络的负载平衡，所以每离开一个包，就把 cwnd 膨胀 1，让发送方能继续“挤”出新数据，保持管道的吞吐。)
• 收到新数据的 ACK 后：cwnd = ssthresh，回到拥塞避免