线下的传统压力测试，难以模拟真实流量，尤其难以模拟正常流量混杂着各色异常流量。所以，线下压得好好的系统，上线后可能某天突然雪崩，说好能支撑 5 倍流量的系统重构，也许流量一翻倍就彻底挂了。
但办法总比问题多。
系统重构或重要变更上线前，可以拷贝线上真实流量，实时模拟线上流量，甚至可以放大真实流量，进行压力测试，以评估系统承载能力。
反过来也可以这样，如果线上跑着跑着发现有性能瓶颈，但线下环境难以复现，还不如把真实流量拷贝到线下重放，毕竟线下环境便于上各种排查手段，重放几遍都行，直到找到问题。
如何实时拷贝线上真实流量呢？TCPCopy
2010年，网易技术部的王斌在王波的工作基础上开发了 TCPCopy - A TCP Stream Replay Tool。2011年9月开源。当前版本号是 1.0.0。很多公司的模拟在线测试都是基于 TCPCopy 做的，如一淘。
TCPCopy 是一种请求复制（复制基于 TCP 的 packets）工具 ，通过复制在线数据包，修改 TCP/IP 头部信息，发送给测试服务器，达到欺骗测试服务器的TCP 程序的目的，从而为欺骗上层应用打下坚实基础。
TCPCopy是如何工作的
基于 Server 的请求回放领域，一般分为离线回放和在线实时复制两种。
其中请求实时复制，一般可以分为两类：
1）基于应用层的请求复制 ，
2）基于底层数据包的请求复制。
如果从应用层面进行复制，比如基于服务器的请求复制，实现起来相对简单，但也存在着若干缺点：
1）请求复制从应用层出发，穿透整个协议栈，这样就容易挤占应用的资源，比如宝贵的连接资源
2）测试跟实际应用耦合在一起，容易影响在线系统，
3）也因此很难支撑压力大的请求复制，
4）很难控制网络延迟。
而基于底层数据包的请求复制，可以做到无需穿透整个协议栈，路程最短的，可以从数据链路层抓请求包，从数据链路层发包，路程一般的，可以在IP层抓请求包，从IP层发出去，不管怎么走，只要不走TCP，对在线的影响就会小得多。这也就是 TCPCopy 的基本思路。
从传统架构的 rawsocket+iptable+netlink，到新架构的 pacp+route，它经历了三次架构调整，现如今的 TCPCopy 分为三个角色：
Online Server(OS)：上面要部署 TCPCopy，从数据链路层(pcap 接口)抓请求数据包，发包是从IP层发出去；
Test Server(TS)：最新的架构调整把 intercept 的工作从 TS 中 offload 出来。TS 设置路由信息，把 被测应用 的需要被捕获的响应数据包信息路由到 AS；
Assistant Server(AS)：这是一台独立的辅助服务器，原则上一定要用同网段的一台闲置服务器来充当辅助服务器。AS 在数据链路层截获到响应包，从中抽取出有用的信息，再返回给相应的 OS 上的 tcpcopy 进程。
tcpcopy项目地址：https://github.com/session-replay-tools/tcpcopy
Online Server 上的抓包：
tcpcopy 的新架构在 OS 上抓请求数据包默认采用 raw socket input 接口抓包。王斌则推荐采用 pcap 抓包，安装命令如下：
yum install libpcap-devel
git clone git://github.com/session-replay-tools/tcpcopy.git
cd tcpcopy
./configure
make
make install
这样就可以在内核态进行过滤，否则只能在用户态进行包的过滤，而且在 intercept 端或者 tcpcopy 端设置 filter（通过 -F 参数，类似 tcpdump 的 filter），达到起多个实例来共同完成抓包的工作，这样可扩展性就更强，适合于超级高并发的场合。
为了便于理解 pcap 抓包，下面简单描述一下 libpcap 的工作原理。
一个包的捕捉分为三个主要部分：
面向底层包捕获，
面向中间层的数据包过滤，
面向应用层的用户接口。
这与 Linux 操作系统对数据包的处理流程是相同的（网卡->网卡驱动->数据链路层->IP层->传输层->应用程序）。包捕获机制是在数据链路层增加一个旁路处理（并不干扰系统自身的网络协议栈的处理），对发送和接收的数据包通过Linux内核做过滤和缓冲处理，最后直接传递给上层应用程序。如下图2所示：
Online Server 上的发包：
如图1所示，新架构和传统架构一样，OS 默认使用 raw socket output 接口发包，此时发包命令如下：
./tcpcopy -x 80-测试机IP:测试机应用端口 -s 服务器IP -i eth0
其中 -i 参数指定 pcap 从哪个网卡抓取请求包。
此外，新架构还支持通过 pcap_inject（编译时候增加--enable-dlinject）来发包。
Test Server 上的响应包路由：
需要在 Test Server 上添加静态路由，确保被测试应用程序的响应包路由到辅助测试服务器，而不是回包给 Online Server。
Assistant Server 上的捕获响应包：
辅助服务器要确保没有开启路由模式 cat /proc/sys/net/ipv4/ip_forward，为0表示没有开启。
辅助服务器上的 intercept 进程通过 pcap 抓取测试机应用程序的响应包，将头部抽取后发送给 Online Server 上的 tcpcopy 进程，从而完成一次请求的复制。
实验
1.机器别表
192.168.0.11 -- onlie server
192.168.0.12 -- test server
192.168.0.13 -- Assistant server
2.online server操作
安装tcpcopy
yum install libpcap-devel
git clone git://github.com/session-replay-tools/tcpcopy.git
cd tcpcopy
./configure
make
make install
启动TCPCOPY
./sbin/tcpcopy -x 80-192.168.0.12:80 -s 192.168.0.13 -c 192.168.0.11
-x 参数指定本机哪个端口的流量转发到哪台机器的哪个端口，格式为localip:80-targetip:port
-s 参数指定Assistant server -c 指定本机
可以添加-n参数来放大流量，比如说 -n 2 代表放大2倍流量
可以添加-r参数来复制一部分流量。比如说，-r 20 代表复制20%的流量
可以添加-d参数来让tcpcopy后台运行
3.test server操作
route add host 192.168.0.11 gw 192.168.0.13
这一步很重要，之前我就是因为这个路由设置不正确，一直没搭建成功
4.Assistant server操作
安装intercept
yum install libpcap-devel
git clone git://github.com/session-replay-tools/intercept.git
cd intercept
./configure
make
make install
启动intercept
./sbin/intercept -i eth0 -F tcp and src port 80 -d
-i 指定网卡
-F 指定copy的是tcp还是udp
-d 代表后台运行
我这里默认online server还有test server都启动了nginx。当你访问online server上的http服务的时候。你会发现test server上也有访问log存在。可以通过监控test server上的负载，来判断机器的运行情况
转自：路飞
PHP后端学习https://mp.weixin.qq.com/s/ycx5XhehhdDVWCgVnROVOg
