在负载均衡场景中,有时虚拟服务是以服务整个网段的, 比如IP:PORT有可能是 10.1.1.0:80 而不是10.1.1.1:80, 10.1.1.0:80 掩码如果是255.255.255.0, 那么10.1.1.0:80 就包括服务10.1.1.1:80 到10.1.1.254:80, 整个子网. 那么当虚拟服务为10.1.1.0:80, tcp syncookie 如何工作呢. 这个情况就比较复杂那, 一般的syn cookie硬件加速不能涵盖这种应用情况,因此会导致绝大部分的syncookie在软件中处理,导致CPU过高,服务会受到影响. 在最新一代的硬件加速器里,已经提供那针对网断虚拟服务器的syncookie处理功能,这样会极大地减少syncookie软件处理,减少CPU使用率,提高服务性能. 那么如何来测试这个新的硬件加速syncookie功能呢? 首先我们学要这个测试能够针对多个服务器同时并发TCP SYN packet, 而且以线速极的速度发包. 这里基于mTCP ewget应用,做出以下改进,设计出高速并发synflood应用
1, 增加静态连接库 libcidr 来处理命令行参数为网络子网的目标地址如: 10.1.1.0/24
2, 修改 mTCP mtcp_init_rss, 增加目标地址数参数,使mtcp_init_rss能够提前初始化基于源地址,目标地址,源端口,目标端口的地址池address_pool
3, 去掉 RSS CPU affinity check, 因为这会导致 GetRSSHash high CPU cycles, 因为mtcp_connect每次都会调用这个函数 mtcp_connect->FetchAddress->GetRSSCPUCore->GetRSSHash
4, 修改 mtcp/src/ip_out.c to 生成 随机源地址, 注意不要用 rand() 因为 rand() 不 thread-safe 会导致spin lock contention(_raw_spin_lock high cpu cycles from perf top and low packet rate also see make your program slower with threads )
http://ickernel.blogspot.com/2016/01/syn-flood-network-virtual-server-in.html
1, 增加静态连接库 libcidr 来处理命令行参数为网络子网的目标地址如: 10.1.1.0/24
2, 修改 mTCP mtcp_init_rss, 增加目标地址数参数,使mtcp_init_rss能够提前初始化基于源地址,目标地址,源端口,目标端口的地址池address_pool
3, 去掉 RSS CPU affinity check, 因为这会导致 GetRSSHash high CPU cycles, 因为mtcp_connect每次都会调用这个函数 mtcp_connect->FetchAddress->GetRSSCPUCore->GetRSSHash
4, 修改 mtcp/src/ip_out.c to 生成 随机源地址, 注意不要用 rand() 因为 rand() 不 thread-safe 会导致spin lock contention(_raw_spin_lock high cpu cycles from perf top and low packet rate also see make your program slower with threads )
http://ickernel.blogspot.com/2016/01/syn-flood-network-virtual-server-in.html