这里描述的只是纯粹的攻击行为，因此不提供代码，也不做深入介绍。

来自P2P网络的攻击

前面的攻击方式，多多少少都需要一些傀儡机，即使是HTTP Flood也需要搜索大量的匿名代理。如果有一种攻击，只需要发出一些指令，就有机器自动上来执行，才是完美的方案。这种攻击已经出现了，那就是来自P2P网络的攻击。

大家都知道，互联网上的P2P用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据，使成千上万的真实IP地址连接过来，没有哪个设备能够支撑住。拿BT下载来说，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但这只是基础攻击。

应对篇 ——DDoS防御方案

防御基础

攻击流量到底多大

谈到DDoS防御，首先就是要知道到底遭受了多大的攻击。这个问题看似简单，实际上却有很多不为人知的细节在里面。

以SYN Flood为例，为了提高发送效率在服务端产生更多的SYN等待队列，攻击程序在填充包头时，IP首部和TCP首部都不填充可选的字段，因此IP首部长度恰好是20字节，TCP首部也是20字节，共40字节。

对于以太网来说，最小的包长度数据段必须达到46字节，而攻击报文只有40字节，因此，网卡在发送时，会做一些处理，在TCP首部的末尾，填充6个0来满足最小包的长度要求。这个时候，整个数据包的长度为14字节的以太网头，20字节的IP头，20字节的TCP头，再加上因为最小包长度要求而填充的6个字节的0，一共是60字节。

但这还没有结束。以太网在传输数据时，还有CRC检验的要求。网卡会在发送数据之前对数据包进行CRC检验，将4字节的CRC值附加到包头的最后面。这个时候，数据包长度已不再是40字节，而是变成64字节了，这就是常说的SYN小包攻击，数据包结构如下：

|14字节以太网头部|20字节IP头部|20字节TCP|6字节填充|4字节检验|

|目的MAC|源MAC|协议类型| IP头 |TCP头|以太网填充 | CRC检验 |

到64字节时，SYN数据包已经填充完成，准备开始传输了。攻击数据包很小，远远不够最大传输单元（MTU）的1500字节，因此不会被分片。那么这些数据包就像生产流水线上的罐头一样，一个包连着一个包紧密地挤在一起传输吗？事实上不是这样的。

以太网在传输时，还有前导码（preamble）和帧间距（inter-frame gap）。其中前导码占8字节（byte），即64比特位。前导码前面的7字节都是10101010，1和0间隔而成。但第八个字节就变成了10101011，当主机监测到连续的两个1时，就知道后面开始是数据了。在网络传输时，数据的结构如下：

|8字节前导码|6字节目的MAC地址|6字节源MAC地址|2字节上层协议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC检验|12字节帧间距|

也就是说，一个本来只有40字节的SYN包，在网络上传输时占的带宽，其实是84字节。

有了上面的基础，现在可以开始计算攻击流量和网络设备的线速问题了。当只填充IP头和TCP头的最小SYN包跑在以太网络上时，100Mbit的网络，能支持的最大PPS（Packet Per Second）是100×106 / （8 * （64+8+12）） = 148809，1000Mbit的网络，能支持的最大PPS是1488090。

SYN Flood防御

前文描述过，SYN Flood攻击大量消耗服务器的CPU、内存资源，并占满SYN等待队列。相应的，我们修改内核参数即可有效缓解。主要参数如下：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_synack_retries = 2

分别为启用SYN Cookie、设置SYN最大队列长度以及设置SYN+ACK最大重试次数。

SYN Cookie的作用是缓解服务器资源压力。启用之前，服务器在接到SYN数据包后，立即分配存储空间，并随机化一个数字作为SYN号发送SYN+ACK数据包。然后保存连接的状态信息等待客户端确认。启用SYN Cookie之后，服务器不再分配存储空间，而且通过基于时间种子的随机数算法设置一个SYN号，替代完全随机的SYN号。发送完SYN+ACK确认报文之后，清空资源不保存任何状态信息。直到服务器接到客户端的最终ACK包，通过Cookie检验算法鉴定是否与发出去的SYN+ACK报文序列号匹配，匹配则通过完成握手，失败则丢弃。当然，前文的高级攻击中有SYN混合ACK的攻击方法，则是对此种防御方法的反击，其中优劣由双方的硬件配置决定。tcp_max_syn_backlog则是使用服务器的内存资源，换取更大的等待队列长度，让攻击数据包不至于占满所有连接而导致正常用户无法完成握手。net.ipv4.tcp_synack_retries是降低服务器SYN+ACK报文重试次数，尽快释放等待资源。这三种措施与攻击的三种危害一一对应，完完全全地对症下药。但这些措施也是双刃剑，可能消耗服务器更多的内存资源，甚至影响正常用户建立TCP连接，需要评估服务器硬件资源和攻击大小谨慎设置。