TCPCopy is a TCP stream replay tool to support real testing of Internet server applications.
Although the real live flow is important for the test of Internet server applications, it is hard to simulate it as online environments are too complex. To support more realistic testing of Internet server applications, we develop a live flow reproduction tool - TCPCopy, which could generate the test workload that is similar to the production workload. Currently, TCPCopy has been widely used by companies in China.
TCPCopy has little influence on the production system except occupying additional CPU, memory and bandwidth. Moreover, the reproduced workload is similar to the production workload in request diversity, network latency and resource occupation.
As shown in Figure 1, TCPCopy consists of two parts: tcpcopy and intercept. While tcpcopy runs on the online server and captures the online requests, intercept runs on the assistant server and does some assistant work, such as passing response info to tcpcopy. It should be noted that the test application runs on the target server.
tcpcopy utilizes raw socket input technique by default to capture the online packets at the network layer and does the necessary processing (including TCP interaction simulation, network latency control, and common upper-layer interaction simulation), and uses raw socket output technique by default to send packets to the target server (shown by pink arrows in the figure).
The only operation needed on the target server for TCPCopy is setting appropriate route commands to route response packets (shown by green arrows in the figure) to the assistant server.
intercept is responsible for passing the response header(by default) to tcpcopy. By capturing the reponse packets, intercept will extract response header information and send the response header to tcpcopy using a special channel(shown by purple arrows in the figure). When tcpcopy receives the response header, it utilizes the header information to modify the attributes of online packets and continues to send another packet. It should be noticed that the responses from the target server are routed to the assistant server which should act as a black hole.
Two quick start options are available for intercept:
git clone git://github.com/session-replay-tools/intercept.git.
Two quick start options are available for tcpcopy:
git clone git://github.com/session-replay-tools/tcpcopy.git.
--single run intercept at non-distributed mode --with-pfring=PATH set path to PF_RING library sources --with-debug compile intercept with debug support (saved in a log file)
--offline replay TCP streams from the pcap file --pcap-capture capture packets at the data link --pcap-send send packets at the data link layer instead of the IP layer --with-pfring=PATH set path to PF_RING library sources --set-protocol-module=PATH set tcpcopy to work for an external protocol module --single if intercept and tcpcopy are both configured with "--single" option, only one tcpcopy works together with intercept, and better performance is achieved. --with-tcmalloc use tcmalloc instead of malloc --with-debug compile tcpcopy with debug support (saved in a log file)
Assume tcpcopy and intercept are both configured with "./configure".
Set route commands appropriately to route response packets to the assistant server For example: Assume 126.96.36.199 is the IP address of the assistant server. We set the following route command to route all responses to the 62.135.200.x's clients to the assistant server. route add -net 188.8.131.52 netmask 255.255.255.0 gw 184.108.40.206
./intercept -F <filter> -i <device,> Note that the filter format is the same as the pcap filter. For example: ./intercept -i eth0 -F 'tcp and src port 8080' -d intercept will capture response packets of the TCP based application which listens on port 8080 from device eth0
./tcpcopy -x localServerPort-targetServerIP:targetServerPort -s <intercept server,> [-c <ip range,>] For example(assume 220.127.116.11 is the IP address of the target server): ./tcpcopy -x 80-18.104.22.168:8080 -s 22.214.171.124 -c 62.135.200.x tcpcopy would capture port '80' packets on current server, change client IP address to one of 62.135.200.x series, send these packets to the target port '8080' of the target server '126.96.36.199', and connect 188.8.131.52 for asking intercept to pass response packets to it. Although "-c" parameter is optional, it is set here in order to simplify route commands.
There are several factors that could influence TCPCopy, which will be introduced in detail in the following sections.
tcpcopy utilizes raw socket input interface by default to capture packets at the network layer on the online server. The system kernel may lose some packets when the system is busy.
If you configure tcpcopy with "--pcap-capture", then tcpcopy could capture packets at the data link layer and could also filter packets in the kernel. With PF_RING, tcpcopy would lose less packets when using pcap capturing.
Maybe the best way to capture requests is to mirror ingress packets by switch and then divide the huge traffic to several machines by load balancer.
tcpcopy utilizes raw socket output interface by default to send packets at the network layer to a target server. If you want to avoid ip_conntrack problems or get better performance, configure tcpcopy with "--pcap-send", then with appropriate parameters tcpcopy could send packets at the data link layer to a target server.
When a packet is sent by tcpcopy, it may encounter many challenges before reaching the target server. As the source IP address in the packet is still the end-user's IP address(by default) other than the online server's, some security devices may take it for an invalid or forged packet and drop it. In this case, when you use tcpdump to capture packets on the target server, no packets from the expected end-users will be captured. To know whether you are under such circumstances, you can choose a target server in the same network segment to do a test. If packets could be sent to the target server successfully in the same network segment but unsuccessfully across network segments, your packets may be dropped halfway.
To solve this problem, we suggest deploying tcpcopy, target applications and intercept on servers in the same network segment. There's also another solution with the help of a proxy in the same network segment. tcpcopy could send packets to the proxy and then the proxy would send the corresponding requests to the target server in another network segment.
Note that deploying the target server's application on one virtual machine in the same segment may face the above problems.
The target server may set rpfilter, which would check whether the source IP address in the packet is forged. If yes, the packet will be dropped at the network layer.
If the target server could not receive any requests although packets can be captured by tcpdump on the target server, you should check if you have any corresponding rpfilter settings. If set, you have to remove the related settings to let the packets pass through the network layer.
There are also other reasons that cause tcpcopy not working, such as iptables setting problems.
It is likely that the application on the target server could not process all the requests in time. On the one hand, bugs in the application may make the request not be responded for a long time. On the other hand, some protocols above TCP layer may only process the first request in the socket buffer and leave the remaining requests in the socket buffer unprocessed.
You should not set ip_forward true or the assistant server can't act as a black hole.
Have a bug or a feature request? Please open a new issue. Before opening any issue, please search for existing issues.
Copyright 2016 under the BSD license.
：Code submit frequency
：React/respond to issue & PR etc.
：Well-balanced team members and collaboration
：Recent popularity of project
：Star counts, download counts etc.