重思想

TCPCopy是一款十分优秀的开源项目，但因为笔者能力有限，本文只介绍了TCPCopy的核心技术原理，很多细节并未涉及。不过还是希望通过本文的介绍，能够对TCPCopy和流量回放技术感兴趣的同学有所启发！

tcpcopy0.1.2版本对团购测试，请求丢失率在5%左右经过分析，tcpcopy0.1.2版本对于长response处理不是很好，针对此情况，我拿开源项目来测试，开源项目列表如下：1）geoserver2）jetspeed3）struts2-showcase4）resin-doc反复分析丢失请求原因，不断迭代，最终在有限访问情况下，无一例请求丢失（880个请求）。

从上午10：41分开始试验，一直到18：17，7个半小时左右。从4台nginx服务器拷贝流量到测试服务器，由于lvs有两个虚拟ip，在在线服务器执行命令如下：[root@bgp176-141 work]# ./tcpcopy xxx.xxx.xxx.140 80 xxx.xxx.xxx.148 18080root@bgp176-142 work]# ./tcpcopy xxx.xx

mysql 非skip-grant-tables方式请求复制工具如下（0.5版本以下版本）：      1）必须保证线上和测试机的用户名和用户名对应的权限要一样，密码可以不一样，这样做的目的就是保证在线和测试校验过程一样，简化tcpcopy。      2）启动方法在原先基础上，增加用户名密码对 -p 用户名1@密码1:用户名2@密码2:...          ./tcpco

还有一些细节需要完善，等稳定运行一阵，我就发布出来。让你们久等了以下评论内容所采用的tcpcopy版本为0.5以下的老版本

0.5以上版本：https://github.com/wangbin579/tcpcopy，最好用最新版本0.5以下老版本：http://code.google.com/p/tcpcopy/downloads/list希望大家多多测试，毕竟我对mysql不是很熟悉。测试注意事项：1、测试mysql机器，开启了skip-grant-tables，在线mysql没有2、

场景是这样的：公司原来是利用nginx-->apache-->resin(hmux 6800）来做的。现在已经书写了nginx hmux模块，完全可以这样nginx--->resin(hmux 6800)，把系统架构简化了。那么是不是直接替换呢，这样做有很大的风险，万一上线全面崩溃，怎么办，公司损失不说，个人在公司的职业生涯也结束了。怎么办，怎么办？有人说，我们逐步逐步上线

在12，13，14，15 在线服务器部署tcpcopy client，集中向148测试148机器：20663 root      15   0 39080  25m  764 S 90.9  1.3 108:12.37 asyn_server  22727 root      15   0  5756 4348  288 S 29.3  0.2  12:52.36 intercepti

https://github.com/wangbin579/tcpcopy 或者http://code.google.com/p/tcpcopy/downloads/list经过多个项目的实践，tcpcopy表现越来越好，特别是压力测试这个功能，在多个项目中起到了很重要的作用。希望大家多多支持，多多提出宝贵建议

从目前多年使用效果来看，效果比在线测试更好，一般通过了tcpcopy压力测试，在线往往更加没有问题。tcpcopy的特点就是即具备网络复杂多变的环境，又具备瞬间破坏力，是一种理想的压力测试工具。因此自从有了tcpcopy，开发更加轻松了,也不担心上线会不会崩溃，总之开发高并发程序，是一种乐趣，而不是一种痛苦或者担忧。

我们做一个实验，在这个实验中，我们有四台机器，208，217，148，161，其中208和217在北京，148和161在杭州。我们在208中利用压力测试工具发起压力请求到217中去，在217上利用tcpcopy把请求复制到148中去，再在148复制请求到161中去。我们先准备准备:161上,我们设置如下:[root@bgp176_161 bin]# iptables -I OUTP

有人写信问：测试环境：lvs 192.168.1.1vip 192.168.1.2rs1 192.168.1.21rs2 192.168.1.22线上业务：单独服务器，实ip一个。在lvs上运行./interception & （0.5以下版本用法）在线上服务器上运行./tcpcopy 实ip 80 192.168.1.2 80 （0.5以下版本用法）

tcpcopy 1.0系列用法

采用pcap发送数据包，不仅不影响在线系统的IP层，而且可以使tcpcopy发包的性能达到最高。这里讲述的是tcpcopy如何使用pcap来发送数据包和实战中需要注意的若干事项。

多使用tcpcopy -h和intercept -h来查看tcpcopy 0.5版本+的用法，tcpcopy 0.4以下的老版本不推荐使用了

基于server的请求回放领域，一般分为离线回放和在线实时复制两大领域，一般研究者都是从离线回放的角度在苦苦研究，而在实时复制领域，研究非常少，至少从sigcomm评审人的评审意见来看，没有看到相关内容。请求实时复制，据我所知，一般可以分为两类：1）基于应用层的请求复制2）基于底层数据包的请求复制传统的做法一般从应用层面进行复制，比如基于服务器的请求复制，这种复制的好处就是

经过一年的努力，目前国内大量互联网公司已经使用tcpcopy进行流量的复制，目的是提前解决上线过程中的问题。目前最新代码在如下地址：https://github.com/wangbin579/tcpcopy最新文档在docs目录

由于1.0系列已经不建议使用传统iptables的方式来截获响应包，因此只书写route的使用方式使用方式和其它应用类似，但需要注意的是：1）一定要让lvs监控程序能够访问lvs的real servers，其它响应路由到运行intercept的机器上面2）辅助服务器，压力比较大的时候，interept可以采用多个实例甚至采用多台服务器来承担应答包的截获工作

tcpcopy是一种请求复制（所有基于tcp的packets）工具，其应用领域较广，我们曾经应用于网易的广告投放系统，urs系统，nginx hmux协议开发等系统，避免了上线带来的很多问题。总体说来，tcpcopy主要有如下功能：1）分布式压力测试工具，利用在线数据，可以测试系统能够承受的压力大小（远比ab压力测试工具真实地多）,也可以提前发现一些bug2）对于后端的短连接，请求

说明一下：以下试验所采用的tcpcopy为 0.5以下的版本，仅供参考，如果要使用mysqlcopy，请下载最新的代码（https://github.com/wangbin579/tcpcopy）从208远程发起大量mysql请求，命令如下：[root@yz250-208 ~]# sysbench --debug=off --test=oltp --mysql-table-

在线系统介绍：假设我们有在线机器A，在线机器B，在线机器C三台服务器，其中在线机器A，上面运行nginx（80端口）的业务系统，供最终用户访问，同时nginx还会内网访问在线机器B上面的adserver(端口11311)业务，在线机器C运行着伪在线业务msyql(利用sysbench模拟的）测试系统：我们有测试服务器a，b。其中a上面运行如下几个系统：1）nginx业务系统

我们可以在执行intercept命令的时候，增加ip地址列表，tcpcopy 0.5版本及其以后版本运行如下：./intercept -x 61.135.250.86,61.135.250.87后面的ip地址列表代表了这些ip地址的访问，将不会被iptables设置的命令drop，直接会返回客户端。这里需要注意的是这些ip地址的访问，一定要直接访问测试服务器，而不能

tcpcopy,很有应用价值的在线应用请求复制工具，具有五大功能：1）分布式压力测试工具，利用在线数据，可以测试系统能够承受的压力大小（远比ab压力测试工具真实地多）,也可以提前发现一些bug2）对于后端的短连接，请求丢失率非常低(1/10万)，可以应用于热备份3）普通上线测试，可以发现新系统是否稳定，提前发现上线过程中会出现的诸多问题，让开发者有信心上线4

tcpcopy针对nginx某个模块进行长期测试，从11月15号下午2点开始运行，到今天29号18点，一直运行稳定，相关数据如下：[wangbin@bgp176-141 ~]$ ps aux|grep tcpcopyroot      5492 22.6  7.3 306696 293876 ?       Rl   Nov15 4500:30 ./tcpcopy xxx.xx

这周进行了一定程度的测试，由于测试样本比较少，希望大家多来测试测试，myql在线请求复制工具开源靠各位的支持才能成功https://github.com/wangbin579/tcpcopy以下评论内容，所用tcpcopy为0.5以下的老版本，敬请注意

1.利用tcpcopy复制在线请求给测试系统,试验在多层架构中,各个层次的机器崩溃的情况下,测试系统会如何反映,测试的目的是验证架构是否和预期相符2.在公司所用的流行开源软件中,进行tcpcopy压力测试,力争发现开源软件的bug3.对开源软件进行各种对比试验,给出可靠的结论.

今年打算的任务：1）完善去年的两个开源 2）书写udpcopy开源 3）研究淘宝开源Tengine,特别是ngx_lua模块，从中吸取营养4）解决部门内出现的高难度问题

为了解决mysql的主从问题，打算支持非skip-grant-table，以支持mysql多方面的需求。希望大家多多支持。

博客主要记录测试样例。微博：http://weibo.com/tcpcopy

开源写了一年，匆匆忙忙，结果到头来一无所获，还得解决未来的生存问题。开源确实应该是富人干的事情，不是穷人应该考虑的。为自己写的开源担忧，还能持续改进否？

iconv-nginx-module模块测试结果：利用tcpcopy复制在线一台服务器流量，1.5台在线服务器流量，2台服务器在线流量，进行持续不断的测试，到目前为止运行了3天，运行稳定，加这个模块和不加这个模块性能对比，负载大概提升一倍左右。虽然agentzh说这个模块在淘宝运行了一年多，但出于谨慎，不敢直接上线，打算利用tcpcopy测试1周，如果运行稳定，就打算上线此模块。

为了加强理论基础，也为了更加完善tcpcopy，重新看一遍这本经典书。这本书需要反复看，每次看都有收获。

借助在线的流量数据，来很好地完成自动化测试的目的，这也是tcpcopy一个很重要的功能。最近打算重新写自动化测试ppt，打算创新一把，改变以前的老土测试方法，也算为部门做点贡献。

文档:http://code.google.com/p/tcpcopy/downloads/list代码:https://github.com/wangbin579/tcpcopy欢迎对这方面感兴趣.

nginx -->apache -->resin其中nginx -->apache在同一台机器我们需要复制到apache的请求。首先设置lo MTU=15001、发现apache性能瓶颈先后复制4台在线流量，时间间隔比较长，由于请求比较平稳过度，系统没有崩溃。再复制2台在线流量，apache error.log报max clients达到limit。2、发现re

经过长达6个工作日的开发，终于攻克了若干mysql协议方面的问题，由于预期没有料到mysql协议是有状态的，所以复杂度远比之前的版本复杂。今天测试进行了一个小时，mysql记录的log如下：[root@bgp176-148 tmp]# wc -l access.log 734803 access.log[wangbin@bgp176_161 tmp]$ wc -l

请问为啥有第8和9行数据？1    61.135.250.208    0.000000    123.58.176.161    TCP    58529 > mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=1882700093 TSER=0 WS=92    123.58.176.161    0.000008

google code感觉太差了,很难合作编程.大家如果对这两个开源感兴趣的话,欢迎参与到github中去.明白了nginx hmux模块原理,对nginx也应该感觉到不太难了.明白了tcpcopy程序原理,对于黑客的原理也感觉不太难了,至少向前进了一步.最后希望大家多多支持

经过1个多月的开源，下载量比预期好了不少，特别是在google code中被37人评为star，真的很感谢csdn和水木，特别是sohu畅游达人的帮助支持。我会继续努力，增加其功能，改进其代码，也希望各位达人多多支持。

方法有四种，这里讲述效果较好的两种，比较适合于中小网站，方法如下：针对0.5版本及其以后版本./tcpcopy -x 服务器应用端口号-测试服务器ip地址:测试服务器应用端口 -n xx -f yy举例如下：1）在在线服务器上执行多个tcpcopy实例，但命令稍微不同，在原有命令基础上会增加 -f参数     比如你想复制3倍的在线流量或者逐步增加流量，你可以执行如