tcpcopy架构漫谈

基于server的请求回放领域，一般分为离线回放和在线实时复制两大领域，一般研究者都是从离线回放的角度在苦苦研究，而在实时复制领域，研究非常少，至少从sigcomm评审人的评审意见来看，没有看到相关内容。

请求实时复制，据我所知，一般可以分为两类：

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

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

基于底层数据包的请求复制，可以做到无需穿透整个协议栈，路程最短的，可以从数据链路层抓请求包，从数据链路层发包，路程一般的，可以在IP层抓请求包，从IP层发出去，不管怎么走，只要不走TCP，对在线的影响就会小得多。

因此从数据包的角度去做基于server的请求复制，方向是对的，而且潜力非常巨大，很可惜，tcpreplay的作者做了一点这方面的探索（flowreplay），就放弃了。这方面的研究至少我没有看到过（一般都去研究整个网络了，sigcomm评审人也没有提出类似的研究方案）。

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

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

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