TCPCopy 应用

时间 2019-11-17

标签 tcpcopy 应用繁體版

原文原文链接

TCPCopy 使用方法

TCPCopy是一种请求复制（全部基于tcp的packets）工具，能够把在线请求导入到测试系统中去。目前此工具已经普遍应用于国内各大互联网公司。mysql

TCPCopy七大功能
1）分布式压力测试工具，利用在线数据，能够测试系统可以承受的压力大小（远比ab压力测试工具真实地多）,也能够提早发现一些bug
2）普通上线测试，能够发现新系统是否稳定，提早发现上线过程当中会出现的诸多问题，让开发者有信心上线
3）对比试验，一样请求，针对不一样或不一样版本程序，能够作性能对比等试验
4）流量放大功能
5）利用TCPCopy转发传统压力测试工具发出的请求，能够增长网络延迟，使其压力测试更加真实
6）热备份
7）实战演习（架构师必备）git

TCPCopy的特色
1）实时（离线经过configure --enable-offline)
2）效果然实
3）低负载，不影响在线
4）操做简单
5）分布式
6）零成本github

TCPCopy使用方法
TCPCopy分为TCPCopy client(即tcpcopy)和TCPCopy server(即intercept)两部分。sql

其中TCPCopy client运行在在线服务器上面，用来捕获在线请求数据包；服务器

TCPCopy server（默认监听端口为36524）运行在测试机器上面，用来截获响应包，并传递响应包头信息给TCPCopy client,以完成TCP交互。网络

TCPCopy使用分为传统使用方式和高级使用方式：session

传统使用方法：架构

TCPCopy server （root用户执行）
采用IP Queue 模块（内核<3.5，默认采用IP Queue）:
1）启动内核模块ip_queue 并发

modprobe ip_queue

2）设置要截获的端口，而且设置对output截获运维

iptables -I OUTPUT -p tcp --sport port -j QUEUE

3）运行intercept程序：

./intercept

intercept 经常使用参数：

-d 参数：能够设置 tcpcopy，intercept 以 daemon 运行；

注意，测试完毕须要在测试设备上执行:

iptables -L --line
iptables -D OUTPUT 1 #删掉 刚才加入的规则

或者采用NFQueue 模块（内核>=3.5，默认采用NFQueue）:
1）设置iptables：

 iptables -I OUTPUT -p tcp --sport port -j NFQUEUE

2）运行intercept程序：

./intercept

TCPCopy client （root用户执行）

./tcpcopy -x 服务器应用端口号-测试服务器ip地址:测试服务器应用端口

tcpcopy 经常使用参数：

-x <transfer,>
Transfer 具体格式以下：
服务器对外IP地址 : 服务器应用端口号 - 测试服务器 IP 地址 : 测试服务器应用端口 tcpcopy -x 80-42.62.30.205:80

-n 参数：

若是你要进行多重复制，那么此参数的值就是表明复制过去的流量是在线的n倍，倍数小，效果越好，由于多重复制的原理是修改端口号，所以复制的倍数越大，端口冲突的概越大，特别是源IP地址很是少，短链接的的内网应用场合。系统默认最大值为 1023 倍。
举例：

./tcpcopy -x 80-192.168.0.2:8080 -n 3

-r 参数：
若是你想复制在线服务器应用的部分流量，能够采用-r参数来实现，参数范围是1～99 ，其它值都是全流量复制。
举例：

./tcpcopy -x 80-192.168.0.2:8080 -r 20    #复制20%的量

传统使用方式注意事项：

（源代码转移到了github，敬请注意）

1）Linux平台，内核2.6+，目前tcpcopy传统架构须要支持netlink机制或者nfqueue(0.6.5版本+支持
nfqueue,在./configure指定nfqueue便可或者对于0.7.0+版本，若是内核为3.5+,则自动采用nfqueue模式)

2）TCPCopy中的tcpcopy和intercept程序运行须要root权限

3）intercept在同一台机器只须要运行一个实例就能支持多个应用的复制（设置多条iptables命令）

4）TCPCopy client须要链接测试服务器（默认36524端口），因此要对外开放相应端口

5）TCPCopy因为依赖于抓包函数，压力大的时候，抓包函数自己不可靠，因此会丢包，进而丢失请求

6）若是采用的是IP Queue模块来截获响应包，则intercept程序密切跟ip queue内核模块相关，
因此当压力很大的时候请求丢失率很高，须要优化sysctl系统参数才能达到好的效果
（经过cat /proc/net/ip_queue，查看ip queue运行状况，若是Queue dropped的数值不断增大，
则须要修改ip_queue_maxlen参数，好比echo 4096 > /proc/sys/net/ipv4/ip_queue_maxlen；
若是Netlink dropped的数值不断增大，修改net.core.rmem_max和net.core.wmem_max参数,
好比sysctl -w net.core.rmem_max=16777216和sysctl -w net.core.wmem_max=16777216）

7）若是要复制127.0.0.1发出的请求到另一台机器，须要设置-c参数

8）测试环境最好和在线环境一致，好比链接都保持keepalive

9）TCPCopy只与ip、tcp层的数据有关，若是请求验证与tcp层以上的协议有关，则系统不能正常运行。
例如：mysql链接协议，因为权限认证与tcp层上面的mysql协议有关，因此复制过去的请求会被目标测试
服务器认为非法请求，这个时候须要针对mysql协议做具体针对性的处理，tcpcopy程序才能正常运行

10）多层架构环境下，测试系统必定要独立，与在线系统没有业务关联，不然会影响在线

11）丢失请求率跟网络情况有关，最好在内网内复制请求

12）本系统不支持域名，只支持ip地址

13）更多信息参考以下文档
(http://tcpcopy.googlecode.com/files/TCPCopy_Manual_v0.9.6%28Chinese%29.pdf.pdf)

高级使用方式：
参考：
http://blog.csdn.net/wangbin579/article/details/8950282
http://blog.csdn.net/wangbin579/article/details/8994601
http://blog.csdn.net/wangbin579/article/details/10148247

TCPCopy架构和工做原理

基于server的请求回放领域，通常分为离线回放和在线实时复制两大领域，通常研究者都是从离线回放的角度在苦苦研究，而在实时复制领域，研究很是少。

请求实时复制，通常能够分为两类：

1）基于应用层的请求复制
2）基于底层数据包的请求复制

传统的作法通常从应用层面进行复制，好比基于服务器的请求复制，这种复制的好处就是实现起来相对简单，但也存在着若干缺点：
1）请求复制从应用层出发，穿透整个协议栈，这样就容易挤占应用的资源，好比宝贵的链接资源；
2）测试跟实际应用耦合在一块儿，容易致使对在线系统的影响，好比有些基于服务器的复制，会致使用户请求的处理时间取决于最慢的请求处理时间（max(真正的请求处理时间，被复制的请求请求处理时间））；
3）很难支撑压力大的请求复制（据若干用户反映，这种类型的请求复制，曾经严重影响在线系统）；
4）很难控制网络延迟；

基于底层数据包的请求复制，能够作到无需穿透整个协议栈：

路程最短的，能够从数据链路层抓请求包，从数据链路层发包，

路程通常的，能够在IP层抓请求包，从IP层发出去；

无论怎么走，只要不走TCP，对在线的影响就会小得多。

进入正题，tcpcopy是如何进行架构演化的呢？

tcpcopy架构已历经三代，基本原理都同样，本质是利用在线数据包信息，模拟tcp客户端协议栈，欺骗测试服务器的上层应用服务。因为tcp交互是相互的，通常状况下须要知道测试服务器的响应数据包信息，才能利用在线请求数据包，构造出适合测试服务器的请求数据包，所以只要基于数据包的方式，不管怎么实现（除非是tcp协议改的面目全非），都须要返回响应包的相关信息。

三种架构的差异就在于在什么地方截获响应包

咱们先看看tcpcopy最初的架构：

从上图能够看出，tcpcopy是从数据链路层(pcap接口)抓请求数据包，发包是从IP层发出去，测试服务器的TCP协议栈没有相似ip queue或者nfqueue的干扰，响应包会直接返回给在线机器（经过设置路由），tcpcopy能够在数据链路层捕获到这些响应包，这些响应包会到达IP层，通常最终被丢弃掉（除非是客户端IP地址就是这台在线机器的IP地址，会经过IP层，但会被TCP reset掉）。

回到正题，这种架构通常只能工做在同一网段，并且对于外网应用，通常只能复制单台在线流量给测试服务器，没法对网易广告投放系统进行深度问题发现和潜能挖掘。

第一种架构总结以下：
好处：
1）简单，粗暴
2）适合冒烟测试
3）测试结果比较真实

很差的地方：
1）相对而言，会更加影响在线，由于响应包信息所有回给在线机器了（固然这种仍是比应用层面的请求复制，影响更小）
2）同一网段限制
3）对于外网应用，没法充分利用或者很难充分利用多台在线流量，从而没法为压力测试提供技术支持
4）内网应用严重受限制，因请求的客户端IP地址不能是被复制的在线机器的IP地址

第二种架构，也就是目前开源的架构，设计也是tcpcopy鼻祖王波同窗设计（2010年设计出来，2011.6月设计移交给多人,包括我），大体架构以下：

从上面图中咱们能够看出，tcpcopy默认从IP层抓包，从IP层发包，与第一种架构不一样的是，咱们在测试服务器进行响应包的截获，并经过intercept程序返回响应包的必要信息给tcpcopy。这种架构为分布式压力测试提供了可能性，相比第一种架构，大大推进了tcpcopy的进化。

咱们先从响应包的截获来分析，理论上，能够在测试服务器的IP层或者数据链路层进行截获响应包，咱们具体分析以下：

1）在数据链路层抓，正常状况下，其响应数据包会返回给真正发起请求的客户端，这会或多或少影响到客户端的TCP（频繁地reset）模块，并且在压力大的时候，会给交换机、路由器甚至整个网络，带来没必要要的干扰。

2）在测试服务器的IP抓响应包，正好有netlink技术来解决上面的问题，netlink是一种用户态进程与内核进行交互的技术，具体地咱们能够利用内核模块ip queue（内核3.5如下版本）或者nfqueue（内核3.5或者以上版本）来达到捕获响应包的目的。

咱们采用了第二种方式，也即上图中的IP层来截获响应包，当响应包传递给intercept后，咱们就能copy到响应包信息的必要信息（通常为TCP/IP头部信息），传递给tcpcopy，咱们还能够经过verdict告诉内核，该如何处理这些响应包，若是没有设置白名单的话，就会在IP层丢弃掉这些响应包，这时候你是没法利用tcpudmp来抓到这些响应包的（tcpdump工做在数据链路层）。

这种设计的好处就是能够支持复制多台在线流量到一台测试服务器中去，咱们在intercept保留路由信息，知道响应包的相关信息该如何返回给哪个tcpcopy实例。然而这种架构，intercept会不一样程度地占用测试服务器的资源，并且ip queue或者nfqueue，并不必定可以高效工做，于是给测试，特别是高压测试和短链接压力测试，带来了很大麻烦。

这种架构总结以下：
好处：
1）支持复制多台在线流量
2）影响在线机器更小，由于通常只须要返回TCP/IP头部信息

很差的地方：
1）较第一种更为复杂
2）性能极限每每在ip queue或者nfqueue
3）intercept扩展性很差，受制于ip queue和nfqueue没法支持多进程进行响应包的捕获操做
4）intercept影响测试服务器的最终测试结果，特别是压力大的时候
5）没法对测试服务器进行完整测试（没有覆盖到数据链路层的出口）
6）运维不方便

第三种架构，以下图：

上述架构，也即最新架构，是为了极限测试的目的而设计的，把intercept的工做从测试服务器（test server）中offload出来，放到另一台独立的辅助服务器（assistant server，原则上必定要用同网段的一台闲置的服务器来充当辅助服务器）上面进行截获响应包，并且把原先从IP层捕获响应数据包的工做转移到从数据链路层抓响应包，这些改变大大下降了对测试机器的各类干扰（除了路由设置，其它已经没有影响了），并且大大扩大了捕获响应包的能力。固然这种测试也更加真实。

具体以下：

在运行上层服务的测试服务器test server上面设置路由信息，把待测试应用的须要被捕获的响应数据包信息路由到辅助服务器assistant server 上面，在assistant server上面，咱们在数据链路层截获到响应包，从中抽取出有用的信息，再返回给相应的tcpcopy。

为了高效使用，这种架构推荐使用pcap进行抓包，这样就能够在内核态进行过滤，不然只能在用户态进行包的过滤，并且在intercept端或者tcpcopy端设置filter（经过-F参数，相似tcpdump的filter），达到多个实例来共同完成抓包的工做，这样可扩展性就更强，适合于超级高并发的场合。

这种架构须要的机器资源也更多，并且也变得更加难使用，须要了解tcp知识，route知识和pcap filter知识（相似于tcpdump过滤条件），所以推荐有条件的而且熟悉上述知识的人使用最新的架构。

须要注意的是，在某些场景，pcap抓包丢包率会远高于raw socket抓包，所以tcpcopy出现大量“unsend:too many packets”的报警，请采用raw socket方式来抓包（tcpcopy采用./configure --enable-advanced，而intercept 采用./configure --enable-advanced --enable-pcap）。

总结以下：
好处：
1）更加真实
2）可扩展性更强
3）适合高并发场合
4）无ip queue或者nfqueue的各类限制
5）对测试服务器几乎没有任何性能干扰的影响
6）在运行服务的测试服务器，运维更加方便
7）不会随运行服务的服务器崩溃而崩溃

很差的地方：
1）操做难度更大
2）须要的机器数量更多
3）须要的知识也更多
4）assistant server（运行intercept的机器）原则上必需要和测试服务器（test server）在同一个网段

上面三种架构均具备价值，目前开源出来的仅仅包括第二种架构和第三种架构，tcpcopy默认采用第二种架构，有条件的能够采用第三种架构。

对于如何采用新架构，参考http://blog.csdn.net/wangbin579/article/details/8950282

最后，对于请求复制，要想达到对在线没有影响或者影响尽量小，能够采用以下对策：

利用高性能的旁路机制（若是采用镜像，须要改客户端数据包的目的地址），复制请求数据包到另一个独立的系统，在这个独立的系统，咱们采用第三种架构，进行请求的捕获，再复制给测试服务器上面的应用。