Name:
 tcpcopy
 It is an online TCP duplication tool and can be used for performance testing, regression testing, real tesing, etc.
Description:
 It can help you find bugs without deploying your server software on your production servers. It can also be used to do smoke testing against your products.
 For example, when you want to migrate from Apache to Nginx, tcpcopy can help you test it. Apache is running online, while tcpcopy can copy the TCP flows from Apache to Nginx. To Nginx, the TCP flows are just forwarding to it. This will not affect Apache at all except cost a little network bandwidth and CPU load.
Scenarios:
 1) Distributed stress testing
 Use tcpcopy to copy real-world data to stress test your server software. Bugs that only can be produced in high-stress situations can be found.
 2) live testing
 Prove the new system is stable and find bugs that only occur in the real world.
 3) Benchmark
 Do performance benchmark. For instance, you can use tcpcopy to compare the performance of Apache and Nginx.
Usage:
 1) Install
 a) git clone http://github.com/wangbin579/tcpcopy
 b) cd tcpcopy
 c) sh autogen.sh
 d) ./configure
 e) make
 f) make install
 2) Run:
 a) on the target host (root privilege is required):
 using ip queue (kernel < 3.5):
 modprobe ip_queue # if not running
 iptables -I OUTPUT -p tcp --sport port -j QUEUE # if not set
 ./intercept 
 or
 using nfqueue (kernel >= 3.5):
 iptables -I OUTPUT -p tcp --sport port -j NFQUEUE # if not set
 ./intercept
 b) on the source host (root privilege is required):
 sudo ./tcpcopy -x localServerPort-targetServerIP:targetServerPort
 
Example:
 Suppose there are two online hosts, 1.2.3.25 and 1.2.3.26. And 1.2.3.161 is the target host. Port 11311 is used as local server port and port 11511 is used as remote target server port. We use tcpcopy to test if 1.2.3.161 can process 2X requests than a host can serve.
 Here we use tcpcopy to perform the above test task.
 
 1) on the target host (1.2.3.161, kernel 2.6.18)
 # modprobe ip_queue 
 # iptables -I OUTPUT -p tcp --sport 11511 -j QUEUE 
 # ./intercept
 2) online host (1.2.3.25)
 # ./tcpcopy -x 11311-1.2.3.161:11511
 3) online host(1.2.3.26)
 # ./tcpcopy -x 11311-1.2.3.161:11511
 CPU load and memory usage is as follows:
 1.2.3.25:
 21158 appuser 15 0 271m 226m 756 S 24.2 0.9 16410:57 asyn_server
 9168 root 15 0 18436 12m 380 S 8.9 0.1 40:59.15 tcpcopy
 1.2.3.26:
 16708 appuser 15 0 268m 225m 756 S 25.8 0.9 17066:19 asyn_server
 11662 root 15 0 17048 10m 372 S 9.3 0.0 53:51.49 tcpcopy
 1.2.3.161:
 27954 root 15 0 284m 57m 828 S 58.6 1.4 409:18.94 asyn_server
 1476 root 15 0 14784 11m 308 S 7.7 0.3 49:36.93 intercept
 Access log analysis:
 1.2.3.25:
 $ wc -l access_1109_09.log
 7867867, 2185 reqs/sec
 1.2.3.26:
 $ wc -l access_1109_09.log
 7843259, 2178 reqs/sec
 1.2.3.161:
 $ wc -l access_1109_09.log
 15705229, 4362 reqs/sec
 request loss ratio:
 (7867867 + 7843259 - 15705229) / (7867867 + 7843259) = 0.0375%
 Clearly, the target host can process 2X of requests a source host can serve.
 How is the CPU load? Well, tcpcopy on online host 1.2.3.25 used 8.9%, host 1.2.3.26 used 9.3%, while intercept on the target host consumed about 7.7%. We can see that the CPU load is low here, and so is the memory usage.
Note:
 1) It is tested on Linux only (kernal 2.6 or above).
 2) Tcpcopy may lose packets hence lose requests.
 3) Root privilege is required.
 4) Modified version for a scientific paper (with more accurate latency control) is now available in the paper branch.
 5) To know more about tcpcopy, refer to the documents in the docs directory.
 6) Check log files if you encounter some problems and feel free to report them to us(wangbin579@gmail.com).