C++编写的TCP Flood代码发送量异常，求助排查问题

1. TCP Flood函数的套接字类型与系统调用开销 #

你的tcp_flood如果使用标准TCP套接字（SOCK_STREAM），和SYN Flood依赖的原始套接字（SOCK_RAW）逻辑完全不同：

• SYN Flood仅发送SYN包，无需建立完整TCP连接，系统开销极低；
• 标准TCP套接字会强制尝试完成三次握手，发送数据前要等待连接建立，失败后还要处理超时、重传逻辑，这些系统级阻塞直接限制了发包速率；
• hping3用的是原始套接字构造SYN包，和你的syn_flood逻辑一致，因此速率正常。

2. 原始套接字数据包的构造完整性 #

若原始TCP套接字发送的数据包未在dstat.cc显示，大概率是数据包格式不合法：

• 必须手动构造完整的IP头+TCP头，包括正确的校验和（IP校验和、TCP校验和）、随机序列号、随机源端口、目的端口22、SYN标志位；
• 系统默认会校验原始套接字发送的数据包，校验和错误会直接被丢弃，无法发往网络；
• 可用tcpdump抓包验证：sudo tcpdump -i any host 168.119.255.140 and port 22，查看是否存在你发送的包，以及包结构是否符合规范。

3. 系统限制与权限问题 #

• 标准TCP套接字的发包速率受限于系统文件描述符上限、TCP连接队列长度、本地端口范围：默认本地端口范围是32768-60999，约2.8万个端口，快速创建连接会耗尽端口，导致后续连接失败；
• 原始套接字需要root权限，若C++程序未以sudo运行，发包请求会被系统拦截；
• 可检查系统TCP参数：比如net.ipv4.tcp_syncookies是否开启（仅缓解SYN Flood，不影响合法发包），net.ipv4.ip_local_port_range是否足够大。

4. 代码逻辑的阻塞点 #

• 检查tcp_flood函数是否存在不必要的sleep、确认等待、同步锁等逻辑，这些会大幅降低发包速率；
• 对比SYN Flood代码，确认是否采用多线程/异步发包，而TCP Flood为单线程同步执行；
• 本地检测发送量低时，先查看程序CPU占用率：若CPU未跑满，说明代码逻辑存在阻塞；若CPU跑满，可能是系统调用开销过大，需改用原始套接字构造TCP包（跳过三次握手）。

5. dstat.cc的统计逻辑 #

dstat.cc的图表可能仅统计完成三次握手的TCP连接或合法TCP流量，而你用原始套接字发送的半连接包（仅SYN）或格式错误的包，可能不会被统计；hping3的--flood -S是标准SYN Flood（半连接攻击），若dstat.cc统计半连接，你的原始套接字包必须是正确的SYN包才会被纳入统计。

内容的提问来源于stack exchange，提问作者Debug