wangbin

压力大的时候，一般丢包会非常严重，导致session无法回放。

运行一个tcpcopy实例？ 重复记录，也得tcp seq配合才行，单个tcpcopy没有碰到过，多个实例因为lvs的问题出现过

抓包看看吧 按道理是不可能的

响应包需要被干掉的，要是回到了真正的客户端，会立即回送reset数据包的，这就是问题的所在。 路由设置是黑洞掉响应包的方式之一 当然如果在云平台，你也可以在tcpcopy设置-c参数成tcpcopy所在机器的ip地址，然后在tcpcopy所在的机器设置iptables来黑洞掉测试服务器回来的响应包

如果要在测试服务器iptables drop掉，请参考：https://github.com/session-replay-tools/tcpcopy/issues/279

丢包的原因有很多，这里只讲相关的 1、放大倍数越大，效果越差，这是因为tcpcopy只是随机改变客户端的端口号（简单处理），端口号是有限的，倍数越大，冲突的概率越大。 2、增加连接数量，如果是同一个ip地址来访问线上，放大倍数后，冲突的概率就会越大 解决策略： 1、从不同机器来访问online机器，增加客户端的ip数量，放大倍数后，可以降低冲突概率 2、启动多个tcpcopy实例，修改-c 参数（修改客户端的ip地址），达到同样降低冲突的概率 3、尽量用长连接，不要用短链接，因为短链接占用端口数量巨多，很容易导致冲突

1.0版本不需要ip queue了

intercept和target在一台机器，路由设置不能路由给自己吧。 临时解决方案也可以，我经常这样用，一方面可以规避syn数据包被干掉，另外一方面需要的资源比较少，不足之处就是ip地址只能用online机器。

需要二次开发才能支持类似wbsocket协议

同一个网段，只是容易一些，跨网段，一般比较麻烦，具体还得看情况。 解决方案之一通过vps