1:CC攻击是正常的业务逻辑，大并发让你处理不过来,处理XP SP2，以上的系统都封了RAW格式协议封包自定义,除了基于应用层改协议，之外都是模拟或请求来测试传输层

      2:UDP不会粘包，不会少包，除非缓存区满

      3:TCP主要特征有：

1. 3次握手连接

2. 4次挥手断开

3. 拥塞控制

4. 重传控制

5. 流传输方式，服务端需要额外解析方面有：协议粘包，协议少包，协议丢包、异常协议响应、正常协议响应

      UDP主要特征有：

1. 包传输方式

2. 无粘包错包

3. 且无连接，无拥塞控制，无重传机制

      4:TCP主要特征有：

• 3次握手连接:

      一测试用例：压力机在请求大量握手链接后迅速关闭，需要大并发操作

      一测试逻辑点：测试服务端底层逻辑关闭socket的同时，又来新的socket链接请求，服务端底层逻辑这部分是否处理正常

      我测试的项目BUG：创建ID为5000的socket端口后，由于压力机关闭socket，导致服务端回收这个ID为5000的SOCKET，新来的TCP连接请求，由于5000的释放又使用上这个SOCEKT，这时服务端报错：新的SOCKET无法使用

      二测试用例：压力机在请求大量握手链接，需要大并发操作

      二测试逻辑点：测试服务端最大连接SOCKET数量，以保证服务端有可用的SOCKET资源分配，

      我测试的项目BUG：服务端创建5000个SOCKET后无法创建成功，因配置的JAVA内存不够及系统开放的端口数不够

      上述两点的测试工具实现：只有IOCP和AIO底层测试验证最有效，测试同时观察在 N并发/秒 得出瓶颈拐点

      5:4次挥手断开：

      测试用例：压力机设置SOCKET选项，在请求大量握手链接后迅速关闭，需要大并发操作

//快速关闭socket

::setsockopt(pUsoc, SOL_SOCKET, SO_REUSEADDR, (const char*)&on, sizeof(bool));//复用端口
::setsockopt(pUsoc, SOL_SOCKET, SO_DONTLINGER, (const char*)&off, sizeof(bool));//打开LINGER
::setsockopt(pUsoc, SOL_SOCKET, SO_LINGER, (const char*)&m_sLinger, sizeof(linger));//设置强制关闭SOCKET

      测试逻辑点：测试因压力机器人修改Socket配置，客户端主动断开，服务端无法得到4次挥手的通知包，导致需要N时间节点才关闭Socket/不关闭Socket

      项目测试BUG：因无法得到4次挥手包，服务端存在大量异常长连接，导致拒绝服务

      6:拥塞控制-简单理解为，堵死汽车排气孔，同时踩油门

      测试用例：压力机客户端设置1字节接受协议或1字节缓存区，同时请求需要响应的大数据：例如排行榜

      测试逻辑点：由于拥塞控制特殊性，TCP会开辟内存缓存这部分数据，简单说，服务端产生的协议多，但有效发出的少，系统缓存剩余协议越来越多，硬件监控服务端内存暴涨

      项目测试BUG：同上，设置好SOCKET参数后，请求排行榜数据，服务端内存暴涨，直接崩溃

      7:重传控制

      测试用例：搭建测试代理工具，对包传输顺序/丢包进行参数配置转发

      测试逻辑点：由于重传的特殊性是传输层控制，所以在应用层模拟丢包和乱序请求

      大家常用的kugou音乐的APP通过工具模拟重传控制，在试听音乐的时候，进行丢包和乱序测试，APP崩溃

      8:流传输方式，内容比较多，慢慢看

      测试用例：协议粘包 - 通过代理工具自动*N倍，既123变123123123123123123

      测试逻辑点：1）测试服务端最大可分割的数据包上限，2）测试服务端是否并发执行协议，如领取任务、购买物品、创建角色等等

      项目BUG：创建N个123角色在数据库中，且完整协议分割最大上限为4，后期调至20份/Max缓存区

      测试用例：协议少包 - 通过工具1字节发送，1）高速、2）慢速

      测试逻辑点：1）高速发送1字节，服务端读取处理协议，来消耗CPU资源，2）占用服务端缓存区长时间消耗资源，以上2点测试服务端对协议读取健壮性

      9:测试用例：服务端私有协议 - 构造异常数据及有效数据进行测试

      测试逻辑点：

      1）有效数据

• 包体 - 这里用的有效数据既为超大包体，如喊话等可变协议，超过服务端缓存器上限

• 协议接口 - 对于已知的服务端协议响应接口遍历，遍历测试是否有未开放的或频繁调用

• 协议参数 - A使用B的参数如用户ID、数值类的：0 负数 边界值 正数溢出

      2）异常数据

• 包体 - 修改包体边界值或自定义数据，既包体过短或超长数值

• 协议接口 - 遍历服务端接口，既不存在的接口，自动+N修改

• 协议参数 - 遍历字节既协议自动+N修改

• 特殊协议 - 及发送非正常的协议如1字节 00 11 22 33 - FF

      项目BUG：

1）协议包体：移动协议修改包体数据，包体修改为8字节，既无协议接口的参数，服务端报错崩溃

2）协议参数：1、A用户使用B用户ID登陆，强制踢B下线、2、购买数量*金额超服务端变量上限，数值溢出倒贴钱给玩家、3、负数不用多说，卖东西-1，多送一件给玩家、4、有除法计算的地方使用0数值，服务端崩溃

3）协议接口：1、副本调用怪自爆协议，秒杀所有怪、2、角色在监狱中调用传送接口越狱

4）攻击类，并发N/秒请求大数据的协议接口，服务端内存Cpu暴涨，后期限制请求频率

      10:UDP主要特征有：包传输、无粘包、错包、无连接，无拥塞控制、无重传机制

      测试用例：应用层 - 1)协议测试同TCP 、2）大并发请求（性能测试同TCP）

      测试逻辑点：

      1）由于传输层无特殊处理，即传输层在协议测试上只有丢包、乱序、延迟等3项，测试方案同TCP的测试用例、

      2）应用层的方案延用TCP中测试用例：

• 有效数据、

• 异常数据

      1）有效数据

      包体 - 这里用的有效数据既为超大包体，如喊话等可变协议，超过服务端缓存器上限

      2）异常数据

      包体 - 修改包体边界值或自定义数据，既包体过短或超长数值

作者：咯咯老嫖客

原文链接：https://www.cnblogs.com/gegelaopiaoke/p/10610159.html