This article introduces the following netease open source traffic replay (TCPCopy) tool, is a simple introduction, absolutely not modest, because I do not know much. Why not? Check out TCPCopy’s official repository at github.com/session-rep… The official documentation of this product is all in English. I don’t know why, it is very difficult to read. OK, that’s the end of the joke, and it’s time for real time.
Due to changes to TCPCopy, much of the material on the web is not applicable to the latest version of TCPCopy, which is V1.0.0 and on which this document is based.
First, TCPCopy related attempts
TCPCopy is used for TCP replay. The common scenario is to copy online traffic to the test environment to troubleshoot problems that are not easy to reproduce offline, or to perform stress tests on the test environment. TCPCopy is divided into two parts, TCPCopy and Intercept, and most documentation won’t tell you what an Intercept is. In a scenario where traffic is replicated from online servers to offline servers, tcpCopy runs on an online server, while Intercept runs on a secondary server rather than on the server used for testing. I’ll tell you what this server does later. At this point, you notice that there seems to be nothing to do with the test server, because the test server really does not need to do any configuration, just need to start a test program, refers to a route. Popular science here, behind is the deployment link.
Two, actual TCPCopy
1. Configure the environment
TCPCopy --> TCPCopy V1.0.0 online server --> 192.168.124.105 Test server --> 192.168.124.68 secondary server --> 192.168.124.180Copy the code
I have three servers in this configuration, one for simulation, one for test, and one for secondary. The process is as follows:
- The tcpCopy server replays the traffic received by the online server to the test server. During the replays, the tcpCopy server changes the source IP address of the IP packet (for example, 192.168.2.254). Therefore, the same service should be deployed on the online server and the test server.
- Tcpcopy sends forged packets with the source IP address 192.168.2.254 to the test server. In this way, after the test server processes the data sent by tcpCopy, the test server sends these packets back to the client with forged IP address 192.168.2.254.
- Since there is no 192.168.2.254 address, we add a special route on the test server to forward all packets destined for 192.168.2.0/24 to the secondary server.
- Intercept deployed on a secondary server comes into play in order to ensure that the secondary server accepts what is not theirs. The secondary server can also be used to return client requests to tcpCopy, but by default only the response header is returned to tcpCopy. Secondary servers should be like black holes.
2. Install tcpCopy on online machines
Download tcpCopy online on the server, then compile and install the package as follows:
?
One, two, three, four, five, six | wget https: / / github.com / session - replay - tools / tcpcopy / archive / 1.0 . 0.tar .gz tar xvf 1.0 . 0.tar .gz cd tcpcopy - 1.0 . 0 . / configure - - prefix = / opt / tcpcopy / make make install |
3. Assist the machine to install Intercept
Installing Intercept has some additional dependencies that need to be installed, and then compiled and installed in the same manner as tcpCopy.
?
One, two, three, four, five, six, seven | # yum -y install libpcap-devel # https://github.com/session-replay-tools/intercept/archive/1.0.0.tar.gz # tar XVF 1.0.0. Tar. Gz # CD intercept - 1.0.0 # ./configure --prefix=/opt/tcpcopy/ # make # make install |
This is the end of the installation process, very Easy!
4, deployment,
To keep things simple, we have a simple HTTP server running online and a simple HTTP server running on the test server. The easiest way is to use python modules instead of Apache and Nginx. The following commands are used to start the HTTP service:
?
1 | # python -m SimpleHTTPServer |
The online server and the test server run this command simultaneously to start a simple HTTP server listening on port 8000.
Start Intercept on the secondary server first, the steps should be correct, without Intercept, tcpCopy will not start:
?
1 | # /opt/tcpcopy/sbin/intercept -i eth0 -F 'tcp and src port 8000' -d |
- -i indicates that the intercept listens on the port and communicates with tcpCopy. -i specifies the port to listen on. When tcpCopy starts, it connects to this port. If it fails to connect to this port, it will fail to start.
- -f: indicates the filter rule. The syntax is the same as pCAP.
- -d: runs in daemon mode
There are other parameters that can be used, and -h can be viewed without further explanation.
Then, on the server, tcpCopy is turned on:
?
1 | # / opt/tcpcopy/sbin/tcpcopy - 8000 - x 192.168.124.68:192.168.2.254 192.168.124.180 - c - 8000 - s n 2 - d |
- -x indicates that traffic is copied from port 8000 of the local host to port 8000 of 192.168.124.68
- -s: specifies the address of the Intercept machine to which tcpCopy connects
- -c Camouflaged IP address. When the traffic is copied to the test server, the source IP address of the data packet is changed to 192.168.2.254, which facilitates the routing. It can also be written as 192.168.2.x, so that the source address is the address in the specified network segment.
- -n Indicates the traffic magnification factor. This parameter is not required for the purpose of pressure measurement. -d Runs in daemon mode.
Finally, enable routing on the test server (remember that the secondary server is in the same subnet as the test server) :
?
1 | # route add-net 192.168.2.0 netmask 255.255.255.0 gw 192.168.124.180 |
Routing means that all packets destined for 192.168.2.0/24 are forwarded to the secondary server.
Test the effect on another machine, make a request to the online server, and then view the real-time log of the two HTTP servers, the online server result:
Two requests were made, and HTTP Code 404 was returned because the URL did not exist. Now look at the test server:
On the test server, the requests became four times, and you could see the traffic magnify by a factor of two. The effect was as expected. In addition, you can also see that the client IP in the log is different. In the original request, the host name is resolved to Matrix3, while on the test machine, the client IP is 192.168.2.254, which is the fabricated IP. Note that when you forge the IP, you must avoid the existing IP and common IP in the environment. Pay attention to
- The secondary server acts as a black hole, so ip_forward cannot be turned on
- Where requests modify data, such as database changes, they can result in data being modified multiple times if incorrectly configured.
OK, that’s all for TCPCopy! Enjoy using it.