初识TcpCopy架构

1）基于应用层的请求复制

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

传统的做法一般从应用层面进行复制，比如基于服务器的请求复制，这种复制的好处就是实现起来相对简单，但也存在着若干缺点：

1）请求复制从应用层出发，穿透整个协议栈，这样就容易挤占应用的资源，比如宝贵的连接资源
2）测试跟实际应用耦合在一起，容易导致对在线系统的影响，比如有些基于服务器的复制，会导致用户请求的处理时间取决于最慢的请求处理时间（max(真正的请求处理时间，被复制的请求请求处理时间））
3）很难支撑压力大的请求复制（据若干用户反映，这种类型的请求复制，曾经严重影响在线系统）
4）很难控制网络延迟

基于底层数据包的请求复制，可以做到无需穿透整个协议栈，路程最短的，可以从数据链路层抓请求包，从数据链路层发包，路程一般的，可以在IP层抓请求包，从IP层发出去，不管怎么走，只要不走TCP，对在线的影响就会小得多。 因此从数据包的角度去做基于server的请求复制，方向是对的，而且潜力非常巨大，很可惜，tcpreplay的作者做了一点这方面的探索（flowreplay），就放弃了。

随之而来的就是TcpCopy是现在应用最为广泛的一种方式，它的 架构已历经三代，基本原理都一样，本质是利用在线数据包信息，模拟tcp客户端协议栈，欺骗测试服务器的上层应用服务。由于tcp交互是相互的，一般情况下需要知道测试服务器的响应数据包信息，才能利用在线请求数据包，构造出适合测试服务器的请求数据包，因此只要基于数据包的方式，无论怎么实现（除非是tcp协议改的面目全非），都需要返回响应包的相关信息。下面就讲讲TcpCopy架构的三代演变：

1. 第一种架构

 

从上图可以看出，tcpcopy是从数据链路层(pcap接口)抓请求数据包，发包是从IP层发出去，测试服务器的TCP协议栈没有类似ip queue或者nfqueue的干扰，响应包会直接返回给在线机器（通过设置路由），tcpcopy可以在数据链路层捕获到这些响应包，这些响应包会到达IP层，一般最终被丢弃掉（除非是客户端IP地址就是这台在线机器的IP地址，会通过IP层，但会被TCP reset掉）。这个是TcpCopy的鼻祖 王波同学在 2009年设计并代码实现，仅仅300多行代码就支撑了网易广告投放系统的最初开发，并且上线零失误，解决上线前数百个问题，当然这个最简单的版本应用范围非常有限。 这种架构一般只能工作在同一网段，而且对于外网应用，一般只能复制单台在线流量给测试服务器，无法对网易广告投放系统进行深度问题发现和潜能挖掘。

第一种架构总结如下：

好处：
1）简单，粗暴
2）适合冒烟测试
3）测试结果比较真实

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

2. 第二种架构

从上面图中我们可以看出，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过滤条件），因此推荐有条件的并且熟悉上述知识的人使用最新的架构。

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

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

目前项目中用到的引流架构就是第三种架构，需要额外的辅助服务器，当然这也可以更加真实的模拟线上的情况。