测试包tcpcopy架构漫谈
查了好多资料，发现还是不全，干脆自己整理吧，最少保证在我的做法正确的，以免误导读者，也是给自己做个记录吧！
基于server的请求回放领域，一般分为离线回放和在线实时复制两大领域，一般研讨者都是从离线回放的角度在苦苦研讨，而在实时复制领域，研讨非常少，最少从sigcomm评审人的评审看法来看，没有看到相关内容。
请求实时复制，据我所知，一般可以分为两类：
1）基于应用层的请求复制
2）基于底层数据包的请求复制
传统的做法一般从应用层面停止复制，比如基于服务器的请求复制，这种复制的好处就是实现起来绝对简单，但也存在着多少缺点：
1）请求复制从应用层出发，穿透全部协议栈，这样就轻易挤占应用的资源，比如宝贵的连接资源
2）测试跟现实应用耦合在一起，轻易导致对在线系统的影响，比如有些基于服务器的复制，会导致用户请求的处理时间取决于最慢的请求处理时间（max(真正的请求处理时间，被复制的请求请求处理时间））
3）很难支持压力大的请求复制（据多少用户反应，这种类型的请求复制，曾经严重影响在线系统）
基于底层数据包的请求复制，可以做到无需穿透全部协议栈，行程最短的，可以从数据链路层抓请求包，从数据链路层发包，行程一般的，可以在IP层抓请求包，从IP层发出去，不管怎么走，只要不走TCP，对在线的影响就会小得多。
因此从数据包的角度去做基于server的请求复制，方向是对的，而且潜力非常伟大，很可惜，tcpreplay的作者做了一点这方面的摸索（flowreplay），就废弃了。这方面的研讨最少我没有看到过（一般都去研讨全部网络了，sigcomm评审人也没有提出类似的研讨方案）。
进入正题，tcpcopy是如何停止架构演变的呢？
tcpcopy架构已历经三代，基本原理都一样，本质是利用在线数据包信息，模拟tcp客户端协议栈，欺骗测试服务器的下层应用服务。
由于tcp交互是互相的，一般情况下须要知道服务器的响应数据包信息，才能利用在线请求数据包，构造出合适测试服务器的请求数据包，
因此只要基于数据包的方式，无论怎么实现（除非是tcp协议改的改头换面），都须要返回响应包信息。
三种架构的差异就在于在什么地方截获响应包
我们先看看tcpcopy最初的架构：
从上图可以看出，tcpcopy是从数据链路层抓请求数据包，发包是从IP层发出去，测试服务器的TCP协议栈没有类似ip queue或者nfqueue的干扰，响应包会直接返回给在线呆板（通过设置路由），tcpcopy可以在数据链路层捕获到这些响应包，这些响应包会到达IP层，一般最终被抛弃失落（除非是客户端IP地址就是这台在线呆板的IP地址，会通过IP层，但会被TCP reset失落）。
这里要特别感谢tcpcopy鼻祖王波同窗（@wbo65），是他在这方面停止了最初摸索。
（2009年设计并代码实现，仅仅300多行代码就支持了网易广告投放系统的最初开辟（上线零失误，解决上线前数百个问题）,当然这个最简单的版本应用范围非常无限，本人也在2010年末在这个架构上面停止了深度改革，扩展到1000多行代码，因此对tcp协议有了最初的认识）。
回到正题，这种架构一般只能任务在同一网段，而且对于外网应用，一般只能复制单台在线流量给测试服务器，无法对网易广告投放系统停止深度问题发现和潜能挖掘。
第一种架构总结如下：
好处：
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到响应包信息，传递给tcpcopy，我们还可以通过verdict告知内核，该如何处理这些响应包，如果没有设置白名单的话，就会在IP层抛弃失落这些响应包，这时候你是无法利用tcpudmp来抓到这些响应包的（tcpdump任务在数据链路层）。
这种设计的好处就是可以支持复制多台在线流量到一台测试服务器中去，我们在intercept保存路由信息，知道响应包该如何返回给哪一个tcpcopy实例。然而这种架构，intercept会不同程度地占用测试服务器的资源，而且ip queue或者nfqueue，并不一定能够高效任务，因而给测试，特别是高压测试和短连接压力测试，带来了很大费事。
这种架构总结如下：
好处：
1）支持复制多台在线流量
2）影响在线呆板更小
不好的地方：
1）较第一种更为复杂
2）性能极限往往在ip queue或者nfqueue
3）intercept扩展性不好，受制于ip queue和nfqueue无法支持多进程停止响应包的捕获操纵
4）intercept影响测试服务器的最终测试结果，特别是压力大的时候
5）无法对测试服务器停止完整测试（没有覆盖到数据链路层的出口）
6）运维不方便
第三种架构，如下图：
上述架构，也即最新架构，是为了极限测试的目的而设计的，把intercept的任务从测试服务器（test server 1）中offload出来，放到另外一台独立的测试服务器（test server 2）上面停止截获，而且把原先从IP层捕获响应数据包的任务转移到从数据链路层抓响应包，这些转变大大降低了对测试呆板的各种干扰（除了路由设置，其它已没有影响了），而且大大扩展了捕获响应包的能力。当然这种测试也更加实在。
详细如下：
在运行下层服务的测试服务器test server 1上面设置路由信息，把待测试应用的须要被捕获的响应数据包信息路由到第二台测试呆板test server 2上面，在测试呆板test server 2上面，我们在数据链路层截获到响应包，再返回给相应的tcpcopy。
为了高效应用，这种架构推荐应用pcap停止抓包，这样就能够在内核态停止过滤，否则只能在用户态停止包的过滤，而且在intercept端或者tcpcopy端设置filter（通过-F参数，类似tcpdump的filter），达到多个实例来共同完成抓包的任务，这样可扩展性就更强，合适于超级高并发的场合。
这种架构须要的呆板资源也更多，而且也变得更加难应用，须要懂得tcp知识，route知识和pcap filter知识（类似于tcpdump过滤条件），因此推荐有条件的并且熟习上述知识的人应用最新的架构。
总结如下：
好处：
1）更加实在
2）可扩展性更强
3）合适高并发场合
4）无ip queue或者nfqueue的各种制约
5）对测试服务器几乎没有任何性能干扰的影响
6）在运行服务的测试服务器，运维更加方便
不好的地方：
1）操纵难度更大
2）须要的呆板数量更多
3）须要的知识也更多
上面三种架构均拥有价值，现在开源出来的仅仅包含第二种架构和第三种架构，tcpcopy默认采取第二种架构，有条件的可以采取第三种架构。
对于如何采取新架构，参考http://blog.csdn.net/wangbin579/article/details/8950282
最后，对于请求复制，要想达到对在线没有影响或者影响尽可能小，可以采取如下对策：
利用高性能的旁路机制，复制请求数据包到另外一个独立的系统，在这个独立的系统，我们采取第三种架构，停止请求的捕获，再复制给测试服务器上面的应用。
文章结束给大家分享下程序员的一些笑话语录：
AdobeFlash拖垮Windows拖垮IE！又拖垮Linux拖垮Ubuntu拖垮FirxEox！还拖垮BSD拖垮MacOS拖垮Safri！简直无所不拖！AdobeFlash滚出网路世界！不要以为市占有率高就可以持续出烂货产品！以后替代品多得是！
