玩转tcpcopy在线压力测试--原理、使用(下)

9、无法复制请求，如何诊断？

9.1 方法

9.2 案例

大部分案例可以从github issue查看，这里抽取出几个案例进行讲述。

9.2.1 案例1

上述案例中，可以看到测试服务器已经接收到了第一次握手数据包，但没有第二次握手数据包。

这时建议用户采用如下方法来解决：

采用上述方法后，查看能否复制请求过来，如果可以复制，那说明之前复制失败是因为测试服务器IP层有anti-spoof技术在干扰。

9.2.2 案例2

如何分析具体可以参考""。

10、采用传统架构，如何复制？

tcpcopy方式不变，intercept编译和运行都不一样。

intercept 选项采用如下方式：

 ./configure --traditional

intercept将采用iptables的方式来获取响应包，并干掉响应包

根据内核不同，具体运行方式有两种：

如果采用IP Queue模块（内核<3.5，默认采用IP Queue）:

1) # modprobe ip_queue # if not running

2) # iptables -I OUTPUT -p tcp --sport port -j QUEUE

3) # ./intercept

如果采用 NFQueue模块（内核>=3.5，默认采用NFQueue）:

1) # iptables -I OUTPUT -p tcp --sport port -j NFQUEUE

2) # ./intercept

这里需要注意，iptables命令中的port是变量，应根据具体应用项目而定。

11、无法设置路由，怎么办？

方案有如下三种：

12、常见问题

12.1 云环境

由于云环境存在安全方面的考虑，会采取多种措施来保证安全，例如采用anti-spoof来干掉认为非法的数据包，导致这种环境部署tcpcopy比较困难。

具体采用的策略参考下面内容：

其中阿里云环境参考如下内容：

12.2 物理机环境

在物理机环境安装tcpcopy相对比较容易，没有这样那样的干扰。建议能够在物理机就在物理机，或者刚开始试验的时候选择物理机环境，方便轻松入门。

12.3 大流量环境

由于tcpcopy采用了事件处理机制，如果流量大，则读事件就比较多，tcpcopy就会忙于抓包，很少有机会去处理intercept返回的响应，导致复制效果大打折扣。

这种情况下可以采用交换机镜像的方式来做。先用交换机镜像把海量数据包镜像到某一台测试机器，然后通过负载均衡器把流量分而治之到其它测试机器中去，在那些测试机器利用tcpcopy（--pcap-capture）来捕获请求。

采用交换机镜像方式有下面几个好处：

12.4 非Linux环境

12.5 特殊环境

特殊环境，需要特殊处理。

在NAT转换的场景，tcpcopy可以采用如下方式进行支持。

具体可以参考：

13、总结

TCPCopy应用广泛，如果合理利用，可以给服务器开发/运维/测试/DBA人员带来实实在在的好处，例如规避线上风险。合理利用TCPCopy，需要懂得抓包分析和一些基本的TCP知识。