TCP流量复制工具,另一个tcpcopy

很多年以前,网易推了一个tcp流量复制工具叫tcpcopy。2013年07月我入职新公司,大概10月份接触到tcpcopy,为tcpcopy修了两个bug,一个是由于公司内网的IP tunnel的问题tcpcopy无法正常工作;另一个是一个严重的性能bug。两个bug都用邮件方式向原作者反馈了,尤其第二个bug原作者在博客上发文感谢。在接下来的二次开发中,由于没办法看懂tcpcopy的tcp会话部分的代码,当时建议作者按照tcp的11个状态写成状态机,作者拒绝了。于是,我根据当时的业务情况重写了一个新的TCPCOPY叫TCPGO。技术原理和tcpcopy是一样的,但tcp会话部分写成了标准 的11个tcp状态的状态机(见源代码中的tcpsession类,漂亮的运行在应用空间而不是内核态的精简的tcp状态机)。另部署方式很不一样,要简单很多。为了开发效率,开发语言用了C++,用了boost库还加了lua帮助写业务代码。

最近腾讯云技术开发者论坛的产品经理邀请各位同事多写技术文章,确信可以把以前内网上发的文章脱敏后发出。于是,就把这个4年多以前(2013年12月--2014年4月,达到预期研发目标后就再也没更新过了)的项目的技术文档贴出来了。

以下是正文,重点在“原理”小结,结尾有关键代码:

//////////////////////

TCPGO:基于真实TCP流量的测试工具

for version 0.8.2

Document Version v0.1.3

April 15 2014

Contents

1 介绍

1.1 TCPGO是什么,能做什么

1.2 使用简单,易扩展,对线上机几乎无影响

1.3 开发背景和意义

1.4 基于真实流量的测试工具的缺陷

2 详细使用说明

2.1 编译TCPGO

2.2 TCPGO的命令行选项

2.3 TCPGO的配置选项

2.4 部署TCPGO

2.5 TCPGO的Lua插件系统

2.6 TCPGO的调试控制台

3 TCPGO的原理

4 TCPGO的源代码

4.1 源文件

4.2 服务器模型

5 已知严重问题

致谢

1 介绍

1.1TCPGO是什么,能做什么

TCPGO是一个基于TCP欺骗技术的伪造TCP会话的工具。内部开发时的工程项目名为Horos,是占星术Horoscope的缩写,喻意使用本工具可以占卜未来。

TCPGO从线上机上复制用户的真实请求,并把这些请求实时播放给测试服务器;或者把请求保存下来,以后再离线播放给测试服务器。从测试服务器的视角来来,它如同在和真实的用户交互。一个简单的示意图如下:

举例来说,TCPGO大概能做以下几件事情:

1.能够把线上机的真实用户的TCP请求实时复制到测试环境的机器上,使测试环境的TCP服务器误以为和真实的用户通信,观察测试服务器的运行情况。使得TCP服务器在正式灰度前暴露出更多的问题。

2.先把真实用户的TCP请求保存在PCAP抓包文件中,TCPGO可以以这些抓包文件为素材,把流量重放给服务器。

3.TCPGO也是一个TCP准压力测试工具。它可以设定并发的用户连接数,模拟大量用户并发,测试TCP服务器的性能。单个TCPGO,无串联,关闭Lua插件功能,同网段,针对nginx部署时TCPGO每秒完成TCP会话的峰值为近10K个TCP会话,15分钟内的平均指标为:每秒完成6K个TCP会话。TCPGO的配置文件配置选项设定不同时,会有不同的性能表现。另TCPGO本身还有优化的空间,但目前TCPGO已经基本够用了,暂时未有继续开发的计划。

4.TCPGO还可以是一个自动化功能测试工具。通过TCPGO的Lua插件功能,可以快编写针对真实流量的测试用例。其实,可以用Lua插件功能做测试之外的更多事情。

5.TCPGO为能服务器开发工程师搭建一个开发用模拟环境,让码农们可以像写桌面应用一样边写边调。

6.TCPGO可以作为学习TCP/IP的一个非常简单的参考实现。TCPGO在用户空间实现了一个简单可用的TCP/IP栈的IP层和TCP层。TCP层实现了一个粗糙的滑动窗口,有包重传机制,标准的11个TCP状态转换。

1.2使用简单,易扩展,对线上机几乎无影响

使用TCPGO,不需要在线上生产服务器运行消耗大量资源的程序,只需在生产服务器运行两个准标准化UNIX工具:tcpdump负责抓包,和netcat(有些发行版名nc或ncat)负责建立和维持一个TCP链接,向TCPGO供应流量。如果TCPGO播放离线流量包*.pcap,而非实时的生产机流量,则可略去生产机上的操作。

在运行TCPGO的机器上,按照配置模板更改几个简单的配置选项即可使用。如指定测试服务器的IP,监听端口;模拟用户的并发数;以及高级一点的调整TCP会话的一些选项。

在测试服务器上需要更改路由表,使得发往外网的IP包不能去到外网。这些发往外网的IP包需要被最终发到运行TCPGO的机器,参见下文详细解释。

对于单台TCPGO模拟用户数还不能满足测试服务器压力要求的情况下,TCPGO还设计了串联的方式,让多个TCPGO实例在多台机器上工作,并同时为同一台测试服务器模拟用户。

1.3开发背景和意义

TCPCOPY是类似的一个开源的TCP流量复制工具。在使用TCPCOPY,以及在TCPCOPY的基础上进行二次开发的过程中,遇到了很多问题。最主要的问题是调试时很难追踪,调试效率很低。TCPCOPY的代码的最核心部分:TCP状态机的实现并不严格遵守TCP的工业标准。TCP标准指定的11个标准状态很难和TCPCOPY的代码对应起来。在和TCPCOPY的作者的沟通中,笔者提出按照TCP的11个标准状态实现TCP会话相关代码,以方便理解和调试。作者认为这样做使得代码太复杂,而笔者认为按照标准做事是让代码变得简单。截止本文档撰写的时间2014年04月11号,TCPCOPY的最新版本0.9.8的实现中,最核心的TCP状态机部分,仍然晦涩难懂。

2013年12月初准备在TCPCOPY的基础上二次开发个性定制的TCP流量回放工具时,再一次迷失在TCPCOPY的TCP会话状态的代码中。与其再投入时间去理解这些复杂的不遵守标准的代码,不如按照TCP标准的11个状态写一个小巧的TCP流量复制和回放工具。

在研发层面上, TCPGO的研发成功使得在TCP流量复制和重放相关的领域继续二次开发,调试定位错误变得得心应手。

在使用部署层面上,TCPGO更易于安装和部署。而且,当都工作在实时流量复制状态时,TCPGO对线上机的性能影响要比TCPCOPY小。另外,TCPGO还支持TCPGO和测试服务器跨网段部署,TCPGO支持Lua插件,TCPGO的日志和调试控制台工具简单易懂。

1.4基于真实流量的测试工具的缺陷

对于不依赖会话上下文的请求,TCPGO把客户请求回放给测试用服务器,确实能给测试服务器提供了一个接近在线实际情况的运行环境。特殊地,对于TCP一问一答就立即关闭的短连接,可以被认为是不依赖上下文的特例。这种情况下,TCPGO完美支持。如果是长连接,TCPGO支持得不够好,它在TCP会话正常结束四挥手后才发送流量。所以,如果是一个持续很久的长链接,TCPGO不适用。需要改源代码,添加实时发送TCP流量的功能。

如果请求依赖上下文,生产服务器和测试服务器的回复有逻辑上的区别。那么,回放线上机上录制的客户请求给测试服务器,会让测试服务器发觉这并不是来自真实的用户的请求。

2详细使用说明

2.1编译TCPGO

TCPGO预计以二进制包形式发布的计划因时间原因被无限期推后了。编译安装是唯一官方途径。

2.1.1 TCPGO依赖的库

BOOST:

TCPGO依赖BOOST库中的filesystem,regex,thread三个需要编译(NOT header only)的库。实际上filesystem是C++ TR2的一部分,较新的gcc和msvc都支持filesystem;而regex和thread则进入了C++11标准。但考虑到生产环境和开发环境中的旧编译系统,需要先编译BOOST的这三个库文件。另外,为提高代码生产效率和代码质量,为了快速开发和编写安全C++代码,TCPGO还非常广泛的使用了BOOST的大量基础设施。实际上这些设施的大部分都已经进入C++11标准。

libpcap 和 libpcap-dev:

TCPGO依赖libpcap抓包。大部分机器上都有这两个库。如果编译时提示没有找到pcap.h头文件,请确定libpcap-dev开发包是否已经安装。大多数linux发行版取libpcap-dev类似的名字。

Lua:

TCPGO的插件系统和调试控制台基于Lua技术。TCPGO在编译期会静态链接liblua.a。如果需要自已编译lua,可能会碰到缺少libreadline的问题。TCPGO目前的makefile会编译搭载的lua源文件,如果已经有lua静态库或者动态库,需要自行修改makefile。

libreadline:

TCPGO并不直接依赖libreadline,但lua虚拟机依赖libreadline以提供一个相对友好的控制台。

2.1.2 编译BOOST

开发TCPGO时用的是1.5.5版的BOOST库,未试验其它版本。推荐在官网http://www.boost.org/users/download/ 下载1.5.5版。

需要编译filesystem, regex, thread三个库。

参考安装步骤:

1.解压boost.1.55压缩包,cd到 boost_1_55_0 目录。

2../bootstrap.sh –with-libraries= filesystem,regex,thread --prefix=/usr/local

3../b2 install

4.ldconfig

对于有包管理的Linux发行版,可用各自的包管理工具更快捷安装。

2.1.3 编译Lua

TCPGO目前版本0.8.2(2014年4月11号止),搭载了Lua 5.2.3的源代码。TCPGO的根目录下的makefile会编译搭载的Lua代码。按照Lua5.2.3官方的说法:如果编译Lua失败,请先确认已经安装libreadline库,如果链接Lua失败,请用make linux MYLIBS=-ltermcap。

如果想使用自行编译的Lua,需要适当修改TCPGO的makefile文件。为了节省时间,不建议这么做。

2.1.4 编译TCPGO

准备好BOOST以后,编译TCPGO实际上非常简单。只需要一个make命令。make成功后,在bins目录下得到生成的二进制文件,horos或者tcpgo。Tcpgo是horos的硬链接,horos是tcpgo项目最开始的名字。Bins目录下还有一个my.conf文件,和一个my.conf.template文件,提供了供参考的配置文件。配置文件的说明可参见下文。

如果make失败,报链接时找不到boost相关的库文件,请确认boost库是否安装,是否运行了ldconfig更新系统的动态链接库缓存。

2.2TCPGO的命令行选项

TCPGO有配置文件,更为方便,而且可配置的字段更多。如果配置好了配置文件,则可以不指定任何命令行选项,运行TCPGO。对于在命令行和配置文件中同时指定的字段,命令行覆盖配置文件中的指定。下面列出TCPGO的命令行字段:

-x conf_file_path , --conf conf_file_path

该选项指定TCPGO将读取的配置文件。缺省情况下读取当前工作目录下的my.conf。

-f pcap_file_path, --pcapfile pcap_file_path

该选项对应配置文件中的可选配置项MAIN. pcap_file_path,它指定TCPGO需要在正式工作前加载离线流量文件pcap_file_path。流量文件一般由tcpdump工具生成。

-d testing_server_ip, --dst-addr pcap_file_path

该选项对应配置文件中必选配置项MAIN.dst_addr,它指定测试服务器的IP地址,TCPGO将模拟用户向该IP发送报文。

-p testing_server_port, --dst_port testing_server_port

该选项对应配置文件中必须配置项MAIN.dst_port,它指定测试服务器的服务端口,TCPGO的请求报文将发向该端口。

-c concurrency, --concurrency-limit concurrency

该选项对应配置文件中的可选配置项MAIN. concurrency_limit,它指定TCPGO将同时最多维持多少TCP会话与测试服务器交互。

-r on_or_off, --random-port on_or_off

该选项对应配置文件中的可选配置项MAIN. onoff_random_port,这是一个开关值,0表示关闭,非0表示开启。开启时,真实客户机的IP包的源端口会被一个随机值填充。这样,方便播放离线流量文件。因为,如果在很短的时候向测试服务器发送相同源地址和源端口组合的IP报文,会有非常大的概率很到测试服务器的RST或者无法建立连接。此时,测试服务器的相应TCP会话还没有结束。所以,选择一个随机端口号规避这种情况。

-h, --help

该选项打印帮助信息。这个选项的功能很久没有维护了。

-v, --version

该选项打印版本信息。

2.3TCPGO的配置选项

TCPGO 0.8.2的配置选项分四大节: MAIN,SESSION,TESTSUITE,LOG。注释由分号;指示。

一个已知且不会被修复的BUG是,即使由分号;起头的注释行,如果该行有等号=,等号前的部分被认为是选项名,如果有重名,TCPGO会报告有重复的选项并退出。该BUG源于使用的配置文件解析库,没有计划修复它,如果遇到,简单地在行首加上任意字符规僻这个BUG。你很可能不会遇到这个BUG。

2.3.1 MAIN节:

本节中列出一些基本配置。

pcap_file_path:

可选非必需普通选择。它指定TCPGO在正式运行前读取的PCAP流量文件路径。

对应命令行中的-x或-- conf选项。

无缺省值。

dst_addr:

必选普通选项。它指定测试服务器的IP地址,TCPGO将模拟用户向该IP发送报文。

对应命令行中的-d或—dst_addr选项。

无缺省值。

dst_port:

必选普通选项。它指定测试服务器的端口。TCPGO将把IP报文发向该端口。

对应命令行中的-p或—dst-port选项。

无缺省值。

concurrency_limit:

可选非必需普通选项。它指定TCPGO将同时维持的TCP会话的最大数量。

对应命令行中的-c或--concurrency-limit选项。

0.8.2版缺省值为1000.

onoff_random_port:

可选非必需高级选项。建议开启为1。开启时,TCPGO随机改变客户机的源端口。原因参见命令行的-r或—random-port选项。

0.8.2版缺省值为1。

accidental_death_pcap_file_limit:

可选非必需高级选项。对于每个TCP会话,如果不是正常的四次挥手终止,这个会话的收发包记录会被记到一个pcap文件中,用于分析为什么这个会话会非正常终止,从而帮助定位分析问题。这个数值指定最多保存这类文件的数目。

没有对应的命令行选项。

0.8.2版的缺省值为100。

sniff_method:

该选项指定如何抓取测试服务器的回包,可以有:raw,pcap,tcp三种方式。当指定为raw方式抓取回复包时,TCPGO使用linux的RAW SOCKET抓取包;当使用pcap方式时,TCPGO使用libpcap库抓取包;当使用tcp方式时,TCPGO从1992端口抓取回复包。对于raw和pcap方式,需要测试服务器设置路由表把发往外网的IP包发到TCPGO的机器;而使用tcp方式时,虽然测试服务器仍然需要设置路由表,但并不必须使得发往外网的IP包路由到TCPGO的机器,而是通过tcpdump和netcat的命令组合向TCPGO供应测试服务器的回包。因此,使用tcp的嗅探方式,可以跨网段部署TCPGO。

没有对应的命令行选项。

0.8.2版的缺省值为RAW。

asio_thrd_num:

可选非必需高级选项。该选项指定TCPGO的PROACTOR服务器模型启用多少个线程。如果asio_thrd_num设置为负1或者0,TCPGO会检查机器上有多少个CPU核心。设核心数目是n,则asio_thrd_num被设置为max{n-1, 2}。建议用户设定这个选项的值为负1或者0,让TCPGO自行计算需要的线程数目。

没有对应的命令行选项。

0.8.2版的缺省值为负1。

pkt_pass_rate:

可选非必需一般选项。该选项指定实时导入的流量以多大的概率被TCPGO接收。它的单位是千分之一,如果设定为1000,则所有的流量都被接收。如果设定为0,则所有的流量都被丢弃。如果设定为500,则刚好一半的流量被接收。

没有对应的命令行选项。

0.8.2版的缺省值为1000。

2.3.2 SESSION节:

本节是用来调优TCP会话的配置选项。本文中所有的选项都没有对应的命令行选项。

session_count_limit:

可选非必需一般选项。该选项指定TCPGO存于内存中的TCP会话总数的最大值。这些会话有可能在执行状态,也有可能还在等待执行的状态。同时处于执行状态的TCP会话最大数目由MAIN节中的concurrency_limit选项指定。

如果TCPGO存于内存中的TCP会话数目超过了指定的最大值。TCPGO就不会再接受新的TCP会话的流量注入,开始执行流量控制的逻辑,所有在执行流量控制期间带来的新的TCP会话的流量会被丢弃。6

0.8.2版的缺省值为10000。

response_from_peer_time_out:

可选非必需高级选项。该选项指定测试服务器超时的时间,单位为百分之一秒。如果对于某个TCP会话,测试服务器在该时间段内没有响应,则该TCP会话会因服务器响应超时退出。

0.8.2版的缺省值为300,即3秒。建议调整这个值。

have_to_send_data_within_this_timeperiod:

可选非必需高级选项。该选项指定TCPGO模拟的用户必须在多长的时间内向服务器发送报文,单位为百分之一秒。如果对于某个TCP会话,模拟的用户在该时间段内没有发送报文给测试服务器,则该TCP会话会因模拟用户无响应退出。

0.8.2版的缺省值为300,即3秒。建议调整这个值。

injecting_rt_traffic_timeout:

可选非必需高级选项。在向TCPGO注入实时流量的时候,对于每一个新到的TCP会话,TCPGO会先记录下来,并继续等待属于这个会话的其它报文,一直等到握手报文和挥手报文,以及之间的报文都收完整。如果在一个比较长的时间内仍然没有收完整,这个会话就会被放弃。该选项指定的时间即这个等待时间阀值,单位百分之一秒。

0.8.2版的缺省值为4000,即40秒。建议调整这个值。

retransmit_time_interval:

可选非必需高级选项。对于一个TCP会话中的IP报文,如果过了一段时间还没有被对方确认,则该报文会被重发。该选项指定这个重发时限,单位百分之一秒。

0.8.2版的缺省值为25,即0.25秒。建议调整这个值。

wait_for_fin_from_peer_time_out:

可选非必需高级选项。如果TCPGO模拟的用户主动关闭会话,则会话会进入FIN_WAIT1或者FIN_WAIT2状态,此时会等待测试服务器发送FIN挥手报文。如果等待时间超时,测试服务器仍然没有发送FIN报文,则对应会话会退出。该选项指定这个超时时间,单位为百分之一秒。

0.8.2版的缺省值为400,即4秒。建议调整这个值。

enable_active_close:

可选,但必须清楚这选设定的高级选项。指定TCPGO模拟的用户会不会主动关闭。该值为1时,启用主动关闭,该值为0时,关闭主动关闭。假如测试服务器是Apache Web服务器,这个值应该设置为1,因为Apache服务器不主动关闭TCP会话。

0.8.2版的缺省值为0,即关闭。TCPGO用户务必清楚这项设定产生的后果。

clone:

可选非必须高级选项。

这个值指定:针对注入TCPGO的每个TCP会话的流量,将复制多少个相同类容的TCP会话。复制的会话和原会话的内容相同,源端口号相同,但是源IP地址不同。IP地址由更改原会话的源IP地址的主机号得到。如果该值为0,表示不复制。如果该值为1,表示复制一份。此项设定的最大值是253。

0.8.2版的缺省值为0,即关闭。

request_pattern:

可选非必须一般选项。

指定正则式筛选流量。如果启用这个选项,那么这个正则式会被应用到请求报文上,如果匹配,对应的TCP会话才会被发往测试机。

0.8.2版的缺省值是不指定该选项,也就是不启用正则式筛选流量功能。建议不需要这个功能时在配置文件中注释掉该选项,或者不指定。复杂的正则式匹配比较耗时,所以尽可能的使用简单正则式并使用anchor字符。

2.3.3 TESTSUITE节:

该节指定测试插件的相关选项,实际上编写的插件不仅仅可以用来测试。

lua_scripts_home:

可选非必须一般选项。指定lua插件所在的目录,插件有.lua扩展名。参见下文的TCPGO的插件部分。

so_home:

可选非必须一般选项。指定so插件所在的目录。

2.3.4 LOG节:

log_on:

可选非必须一般选项。指定是否开启日志。日志会写到当前工作目录下的h.log中。每次TCPGO运行,如果开启了日志,都会清空上次的所有日志。关闭日志将得到少许性能提升。

duplicate_log_to_stdout:

可选非必须一般选项。指定是否把日志内存复制到标准输出。这个选项只在调试,或者对性能无要求时使用。开启此选项后,每一行日志输出都会调用glibc函数fflush(),使标准C缓冲中的数据刷新到磁盘。

2.4部署TCPGO

设置路由:

部署TCPGO的必不可少的一步是让测试服务器的回复,发往外网的IP包不能走到外网。否则,一般情况下会从外网收到RST包,或者会干扰处于外网的真实TCP会话。

目前的做法是设置路由,让测试服务器的发往外网的IP包被发到一台没有路由功能的机器。这样,这台没有路由功能的机器就会把IP包丢弃。

一个参考做法是:

# route del default 删掉默认路由

# route add default gw 10.217.152.190 dev eth0 改默认路由为另一个不是路由器的机器

更多思考:

尝试设置iptable,让测试服务器的发往外网的IP包被丢弃。笔者不清楚通过iptable丢充发往外网的IP包,会不会妨碍抓取这些被丢弃的IP包。

同网段部署:

同网段部署指的是TCPGO和测试服务器在同一个网段,而对线上机是否和TCPGO在同一个网段不做要求。

同网段部署的一个例子如下图所示:

上图的第一个步骤更改路由,让测试服务器回复的IP包被路由到运行TCPGO的机器192.168.1.200,这样TCPGO就能抓取到这些回复包。另外,这些IP包将被192.168.1.200丢弃,不会发到外网。

第二个步骤运行TCPGO,在命令行简单的指定了两个选项。它们是测试服务器的IP地址和监听端口。实际上,也可以不指定命令行选项,而是定制配置文件。默认的配置文件是工作目录下的my.conf,参见-x命令行选项指定配置文件路径。

第三个步骤是可选的。它从离线流量文件中读取流量发给TCPGO。

第四个步骤是在线上服务器192.168.1.2用tcpdump抓取实时流量,发往标准输出;然后管道到netcat,netcat把从标准输入中读到流量,通过TCP转发给运行在192.168.1.200上的1993端口;TCPGO运行在192.168.1.200上,监听1993端口获得流量。

当然,可以同时从多台线上机器抓取流量供给TCPGO。

跨网段部署:

跨网段部署的操作和同网段部署差不多。只是,测试服务器和运行TCPGO的机器不在同一个网段时,测试服务器回复的IP报文不能通过路由的方式发到运行TCPGO的机器上。这时,通过TCP的方式在测试服务器用tcpdump抓取流量,再用netcat把流量跨网段发给TCPGO监听的1992端口。这个操作与抓取线上流量类似。这种情况下,TCPGO的配置文件的MAIN.sniff_method需要设置为TCP。

需要注意的是,仅管已经不是通过路由的方式向TCPGO发送测试服务器的回复报文。但设置路由表这一步仍然不可缺少,仍然需要把这些IP包发给与测试服务器同一网段的任意一台没有路由功能的机器。

跨网段发送测试服务器回复报文的技术也可用在同网段部署。

TCPGO的串联:

这个功能并没有被严格测试过,但在开发过程中验证到,证明切实可行。TCPGO的串联是为了解决单个TCPGO没有办法达到测试服务器期望的压力,需要多个TCPGO串联起来模拟。设计时的粗略想法是,假设带宽足够,抓包的丢包概率也很低,如果一个TCPGO支撑每秒钟完成3K个TCP短连接,两台TCPGO串联后支撑每秒钟完成6K个TCP短连接。

TCPGO的串联是由一个有名管道/tmp/horos.fifo支持的。每个运行的TCPGO都会把得到的测试机回复报文写到/tmp/horos.fifo。于是,可以用标准UNIX工具把回复报文从这个有名管道读出,再用netcat传给下一个TCPGO。如图所示:

上图的例子中,两个TCPGO被串联起来。第一个TCPGO从两台线上机上得到实时流量,第二个TCPGO从一台线上机上得到实时流量。测试服务器把回复IP包路由到运行第一个TCPGO的机器上。第一个TCPGO又把这些回复报文写往有名管道/tmp/horos.fifo。于是,用cat命令从该有名管道读出测试服务器的回复报文,再通过netcat发往第二个TCPGO。因此,亦可用同样的方式连接更多的TCPGO。

2.5TCPGO的Lua插件系统

TCPGO的插件系统基于Lua语言。所有的插件以扩展名.lua结尾,都放在一个目录下面,可以充许有子目录的树结构。这个存放插件的目录的路径由配置文件的TESTSUITE. lua_scripts_home选项指定。

该插件系统实际上只针对短连接的TCP实现,对于长连接的价值应该相当有限。TCPGO每完成一个TCP会话,会把客户机的IP,客户机的端口号,客户机的请求,测试服务器的回复这四个参数传给Lua插件。所有的Lua插件会得到这四个参数并顺序执行。

Lua插件可以随时修改,并可从运行时的TCPGO热拨插。参加TCPGO控制台的reload_testsuite()命令。

从Lua的语法的角度来讲,每一个lua插件都定义了一个lua模块。Lua模块的详细解释可参见文章:Lua Modules Tutorial http://lua-users.org/wiki/ModulesTutorial

TCPGO定义的Lua插件写法除了遵守Lua Module的写法外,额外的规定每个插件必须实现一个函数main,它接受三个参数:client_ip,client_port, req, resp。client_ip是字符串型,传入客户机的IP地址;client_port是数值型,传入客户机的端口号;req是字符串型,表示客户机的请求;resp是字符串型,表示测试服务器的回复。与C语言的字符串不一样,req和resp字符串中间有可能出现比特位全0的字节。

另外,Lua插件文件的名字,除去扩展名,会被注册到TCPGO的Lua虚拟机环境中,可被TCPGO的调试控制台使用。(对于调试控制台请参见下文。)假如,一个Lua插件名为foo.lua,则foo这个名字会被注册到Lua虚拟机环境中。从Lua语法的角度看,foo成为一个Lua全局变量,它指向一个Lua模块。对于熟悉Lua5.2语法的看官,可能会注意到,为了不污染全局名字域,Lua5.2标准的模块并不注册到Lua的全局全间。但为什么上文说到foo被注册到了Lua的全局空间咧,这是TCPGO额外做的工作。

举例说明,一个简单的Lua插件如下图:

插件的入口是main函数。入到main函数后,先打印客户机的IP和端口号,然后调用两个函数分别处理请求和回复。这两个函数亦都只做简单的打印。

看另一个稍微复杂的例子:

这个插件做的事情是:对于每个TCP会话,99%的概率会被忽略。对于其它1%的会话,它的请求会被写入一个文件,把回复写入另一个文件。文件名是IP地址加上端口号,再加上后缀req或者resp。在实际实现中,在文件写完成之前,文件名有.tmp扩展名,文件写完成后,.tmp扩展名被去掉。

在第三个Lua插件的例子,将使用一个供Lua使用的TCPGO定制的扩展API,它的名字是save_traffic(pcap_file_path),作用是把当前TCP会话的流量保存到文件pcap_file_path中。其次,第三个例子中还有意定义了一个自定义函数(非mail函数),这个函数将可以在TCPGO的调试控制台中被调用。

这个例子做的事情是:对于每个TCP会话,检查请求中是否匹配某个子字符串ad_type=TP&l=4002(实际上Lua的字符串匹配支持一个正则式的子集),如果匹配正确,则把匹配计算器加一。再检查匹配计数器是否小于10,而且响应报文的长度是否大于400,满足条件就把当前TCP会话的流量存在流量文件中。这个流量文件名由string.format()拼出来。此后,既然得到了流量文件,就可以再次播放这个流量文件。注意到这个插件中定义了一个函数desp()。该函数返回匹配的TCP会话次数。假如这个插件名为bar.lua,那么可以在TCPGO的调试控制台用命令 bar.desp() 得到命中条件的TCP会话次数。

TCPGO还有另一个插件系统,它基于动态链接态,但没有写完。暂时也没写完它的计划了。

2.6TCPGO的调试控制台

TCPGO的调试控制台系统是日志系统的一个非常有利的补充。它提供了一个便捷地,在运行时向TCPGO主动查询状态,发布命令的机制。

TCPGO开放了TCP 1994端口作为调试控制台的接入端口。可以在任意一台可以TCP连接到运行TCPGO的机器上,用netcat或者telnet进行连接。

比如:

# netcat 192.168.1.200 1994

会得到 Welcome to horos(TCPGO) console v0.8.2 的欢迎信息,和控制台提示符 horos>,在提示符后面键入命令。

为什么是命令提示符是horos,不是TCPGO呢,因为TCPGO以前叫Horos,提示符还没改过来。

TCPGO的调试控制台是基于Lua技术的,所以每个命令实际上是一个合法的Lua语句,被传给了TCPGO的Lua解析器执行。0.8.2版TCPGO的控制台几个命令是:version(), stat(), reload_testsuite(), log_on(), flush_log()。先详细介绍一下最重要的stat()命令,其它命令很简单,只做简单的描述。

如下图,进入TCPGO控制台后键入stat()命令,返回了很多与TCP会话有关的信息。实际上,这些信息都有了详细的自解释。

上图给出的信息依次是:

75935 sessions are now in memory:目前有75935个TCP会话在内存中。参见SESSION. session_count_limit选项指定

75851 sessions are healthy,其中的75851个会话已经接收完整了TCP会话需要的所有IP包。

0 sessions have aborted 还没有会话因为超时时还没收完整TCP会话的所有IP包而被放弃,参见配置文件的SESSION. injecting_rt_traffic_timeout选项。

10219 sessions ended via active close,已经有10219个会话由主动关闭的形式关闭。这个例子中,测试服务器是Apache,TCPGO的配置文件中开启了主动关闭,所以TCPGO模拟的客户机会在发完有负载的TCP报文后,继续发送FIN报文。因此大多数情况下,TCP会话会终止于主动关闭。

0 sessions ended via passive close,还没有会话以被动关闭的形式关闭。

0 sessions ended prematurely because of no response from peer within 300000 milliseconds. 300秒内没有测试服务器没有回复,则关闭会话。

0 sessions ended prematurely because sended FIN didn't elicit FIN from server within 250000 milliseconds. 如果模拟的客户端主动关闭,在FIN包发出后250秒内,测试服务器没有发送FIN,则强制关闭。

0 sessions ended prematurely because no traffice has been sent to peer within 200000 milliseconds. 模拟的客户端在200秒内没有发送内容给测试服务器。

361 sessions were killed by RESET. 361个会话是因为测试服务器回复了RESET。

Average Session Time Duration: 398.116 millisconds. 平均每个TCP会话的生命期是398毫秒。

Retransmit Rate: 0.0583178 每次发送IP包,该包存在5.8%的概率会在重发计时器超时后被重发,在重发计时器超时之内没有收到测试服务器对应的ACK。

Success Rate: 0.965879 有96.5%的会话是通过正常的四次挥手完成的。

Up 0 min(s) and 6 second(s). TCPGO已经运行了6秒钟。

Average Connections Per Second in the past 15mins, 5mins, 1min, 15seconds, 5seconds, 1second:

-1 -1 -1 -1 1731 1650 (active_closed + passive_closed) / time elapsed in second) 统计数据:每秒钟完成的TCP会话数目。统计的数据是在过去的15分钟,5分钟,1分钟,15秒钟,5秒钟,1秒钟内的平均每秒完成TCP会话数。如果显示负1,表示TCPGO运行的时间还不够长,这个数据还没计算出来。比如,TCPGO只运行了11分钟,则对应15分钟的统计数据显示-1。

下面简单的介绍一下TCPGO其它的命令:

version() 返回版本号。

stat() 返回TCP会话的详细信息,下文会重点介绍这个命令。

reload_testsuite() TCPGO卸载所有Lua插件,重新遍历放置Lua插件的文件夹,再加载所有找到的.lua文件。

log_on(true_or_false) 这个命令接受一个参数,如果调用log_on(true),会确保日志打开,如果调用log_on(false),日志会被停止。

flush_log() 把标准C文件缓冲区中的数据刷新到磁盘。这个命令没太大用处。

3TCPGO的原理

TCPGO用真实生产机器上的抓取的流量包作为素材,模拟出外网用户与测试服务器交互;又通过使得测试服务器发往外网的IP包不可能到达外网,而是被TCPGO截获,从而TCPGO通过截得的信息可以维持一个假的TCP会话,使测试服务器误以为在与外网用户交互。

TCP协议是一个点对点的,有状态的,设计初期非常简单的传输层协议。TCP本身没有现代密钥体系的身份验证,并不保证通信的对方是可信的。它区分每一个会话的唯一标志被称为SOCKET PAIR,它由四个字段构成:源IP地址,源端口,目标IP地址,目标端口。而IP协议也不校验源地址真伪。所以,理论上只要可以伪造SOCKET PAIR的四个字段,便可以入侵TCP会话。当然可以在IP层用IPSec做IP地址的可靠性验证,那就不能轻易入侵TCP会话了。

那么如何欺骗TCP连接方新建一个假的TCP会话,让TCP连接误以为在和某个(IP,PORT)通讯。

假如我要假冒IP 20.20.20.20,端口号2000与服务器30.30.30.30,端口号80通讯。于是,伪造一个SYN包,源地址端口号填上20.20.20.20和2000,目标地址填上30.30.30.30和80,然后把包发出去。服务器30.30.30.30,端口80便收到了SYN包,服务器回SYN+ACK给20.20.20.20,端口号2000。SYN+ACK翻山越水经过各种路由器,终于到达了真实的20.20.20.20。如果20.20.20.20真实在线的话,绝大多数情况下,20.20.20.20认为它没有向30.30.30.30发送过SYN,于是果断的回了一个RESET。如果20.20.20.20不在线,最后一跳路由可能会回一个DESTINATION UNREACHABLE的ICMP包给30.30.30.30。结果都是30.30.30.30立即撤消了这个TCP会话的创建,反应在应用层,则是accept()系统调用返回-1,设置相应的errno。如下图所示:

一次失败的TCP欺骗示例

这个问题如何解决呢,不让SYN-ACK(其它包也一样)发向20.20.20.20就解决了。这就是前文叙述如何使用TCPGO时要设置发往外网的路由要改成一台没有路由功能的机器的原因。这样,SYN-ACK被发到了一台没路由功能的机器,这台机器不是路由器,所以会把SYN-ACK丢弃,于是SYN-ACK到不了20.20.20.20,自然就收不到撤消会话的REST包或DESTINATION UNREACHABLE的ICMP包。如下图所示:

成功建立TCP会话

当然,还有其它的方法解决这个问题,比如使用IPQueue或者NFQueue内核模块。这两个内核模块用来在应用层编写防火墙,可以通知内核如何裁决每个包。因为公司有些机器上没有IPQueue或NFQueue模块,而且这两个模块的编程接口很容易出错,各种宏和各种指针偏移,相对设置路由的实现方式而言几乎没有什么优势,因此TCPGO里面使用的是设置路由的解决方案。

另外,TCP协议通过给字节流编序号,接收方ACK收到的序号,发送方重发没有被ACK的负载也是每个程序员公知的协议特性。如果能截获发送方发送的TCP报文,解决ACK的问题自然不在话下了。如何截获服务器发送的报文呢,上文提到的IPQueue和NFQueue就可以。另外,广泛使用的libpcap库和AF_PACKET协议族,SOCK_RAW原生套接字类型都是现成的解决方案。TCPGO可以使用三种方式截获测试服务器的回复报文。参见配置文件的MAIN.sniff_method选项。

至此,解决了两个主要问题:1.不让拥有真实IP机器或互联网上的路由器影响假TCP会话的建立。2.发送伪造的ACK让发送方认为对方已经成功接收。编写TCP欺骗工具在理论上已经没有障碍了。

4TCPGO的源代码

针对0.8.2版TCPGO。

4.1源文件

tcpsession.cpp,tcpsession.h:

实现了TCP会话的状态机转换。

ip_pkt.h, ip_pkt.cpp,ip_pkt_hdr_only.h,ip_pkt_hdr_only.cpp:

解析IP包。

session_manager.h, session_manager.cpp

管理所有TCP会话。

postman.h,postman.cpp,raw_postman.h,raw_postman.cpp,pcap_postman.h,pcap_postman.cpp,tcp_postman.h,tcp_postman.cpp

抓取回包和发送自填充的IP包。有三种方式,用RAW SOCKET,用libpcap库,用TCP方式,参见配置文件的MAIN.sniff_method选项。

postoffice.h, postoffice.cpp

字面意思邮政局,作为TCP会话和发包收包postman的中介。

statistic_bureau.h,statistic_bureau.cpp

字面意思统计局,当然负责统计TCPGO运行的各种数据。

realtime_capture.h,realtime_capture.cpp

从1993端口中得到实时TCP流量,和流量拥塞控制。

reactor.h,reactor.cpp

Reactor服务器模型。较新版TCPGO引入Proactor服务器模型后,大量以前依赖Reactor的代码改用Proactor实现,截止0.8.2只有少数代码使用reactor。

proactor.h,proactor.cpp

Proactor服务器模型,基于BOOST的asio库,是TCPGO的重要基础设施。

politburo.h,politburo.cpp

字面意思政治局,这是权力的中心,和政令发出的地方。

cascade.h,cascade.cpp

把TCPGO收到的测试服务器的回复报文再写入/tmp/horos.fifo有名管道,用来帮助串联多个TCPGO。

listmap.h

实现了一个STL-like的容器,它是map和list 杂交。既可以像map那样有O(log n)(红黑树map),O(1)(Hash Map)的查找时间复杂度,又可以像list一样存下来容器中插入元素的时序关系。

mylua.cpp,mylua.h

TCPGO嵌入的Lua虚拟机,支持Lua插件。调试控制台也在这里实现。

testsuite.h,testsuite.cpp

支持编写测试插件。最开始计划编写Lua和动态链接库两套插件系统,截止0.8.2已实现Lua插件系统,还未实现动态链接库的插件。

thetimer.h, thetimer.cpp

时钟系统,模拟Linux内核的jiffies,或HZ。还有一个非常简陋的时钟事件处理系统,早期的TCPGO用的比较多。因为后来采用了BOOST的asio,这个简单的时钟事务系统基本被弃用。但thetimer的jiffies仍然在TCPGO的代码中广泛使用。

utils.h,utils.cpp

一些全局的工具函数。

configuration.h,configuration.cpp

管理配置文件和配置选项。

cute_logger.h,cute_logger.cpp

一个非常简单的日志系统,没考虑非线程安全。将来可能会被BOOST日志库取代。

main.cpp

做一些初始化的工作。

4.2服务器模型

专有线程:

1.主线程:执行reactor模型。

2.发IP包线程:不停地从多个队列中得到需要发送的自构建IP包,并发送这些IP包。

3.收测试服务器回复报文的线程:配置文件MAIN.sniff_method选项指定接收测试服务器回复报文的方式。不停地接收回复报文,并把收到的IP报文分配到正确的队列。

4.运行Lua插件的线程。如果配置文件中的TESTSUITE.lua_scripts_home没有配置,该线程会一直阻塞。

5.把得到的测试服务器回复报文写到有名管道/tmp/horos.fifo的专有线程。实际上,如果没有进程读取有名管道/tmp/horos.fifo,该专有线程会一直阻塞。

Proactor的线程组:

TCPGO的Proactor模型的会根据CPU的核心数目自动计算最合适的线程数,用它运行Proactor模型。参见配置文件的MAIN.asio_thrd_num选项。Proactor不断地从多个队列中收取测试服务器的回包,并发送伪造的报文到发送多个队列,同时运转每个TCP会话的状态机。

5待改进和增强

对于TCPGO当前版本,在回放TCP长链接的流量时,会把一个TCP会话的所有TCP包一次性(不等待)发给测试服务器。所以,如果请求和回复没有上下文的联系,用TCPGO模拟用户请求没有问题。如果需要完美支持请求和回复有上下文联系的TCP长链接,TCPGO需要进一步开发一个如果回放长链接TCP流量的策略的机制,该机制决定TCP流量什么时候可以发送给测试服务器,什么时候需要等待测试服务器的回复。

TCPGO的统计信息还不够详细。因此,在排查问题的时候,会因为信息不够多而不能快速定位问题。一个改进方向是,增加详尽的统计信息,比如流量流入和流出的情况,更细粒度地统计TCP会话持续的时长,在需要时可以查询每个TCP会话的交互情况。

TCPGO的单机性能还有希望得到明显地提高。目前TCPGO代码不停地遍历所有得到机会发送IP包的TCP会话,用的是轮询的方式,非常的耗CPU。不同于网易tcpcopy,TCPGO运行在独立的机器上,CPU资源相对生产机器是廉价的,为了压缩开发时间所以写成了轮询。另外,线程模型也不是最优的。目前的线程模型是独立线程结合PROACTOR/BOOST ASIO线程组的方式。如果BOOST ASIO的线程组数量设置不合理,会抢占需要最多资源的独立线程。一个简单的改进点,则是把独立线程纳入BOOST ASIO的线程组做统一管理,保证独立线程有足够多的资源。

6已知严重问题

对于在某些Linux内核下运行的nginx(并不是所有),用TCPGO测试时,运行nginx的Linux就死机了!不知道是TCPGO触发了Linux的Bug,还是nginx的BUG。还是其它原因,还不清楚~~。

//////////////////////////

后记:

关键代码贴在这里 https://github.com/zausiu/tcpgo_another_tcpcopy_core

有一个小问题,当时对智能指针shared_ptr的理解不够,代码中很多函数没必要以传值的形式传shared_ptr,应该以传引用的方式传shared_ptr,这样能收获一点点性能提升。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

Presto内存调优及原理(基础篇)

Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。Presto支持在线数据查询,包括Hive, Cassandra,...

1485
来自专栏云计算教程系列

快来测一测你的网速吧!

本教程指导如何使用iPerf进行网络吞吐量测试,iPerf是一种命令行工具,通过测量服务器可以处理的最大网络吞吐量来诊断网络速度问题。它在遇到网络速度问题时特别...

2433
来自专栏JetpropelledSnake

Python Web学习笔记之面试TCP的15个问题

网络协议那么多,为什么面试喜欢问TCP?原因无外乎两个:1、TCP协议直接与进程打交道,写网络程序要用;2、TCP协议设计十分精巧,在一个不可靠的IP网络上实现...

5249
来自专栏杨建荣的学习笔记

​ssh免密码登录设置及问题总结

前几天写了一篇文章关于ssh命令的几个使用小技巧(r11笔记第27天),很多朋友给了不少的建议,其中郭亮同学整理了一篇文章发给我在此表示感谢。 关于ssh免密码...

41310
来自专栏张善友的专栏

TCPView for Windows

TCPView是一个用来显示系统中所有的TCP和UDP端点(endpoint)列表的Windows程序,包括本地和远程的网络地址,以及TCP连接的状态。在Win...

2147
来自专栏公有云大数据平台弹性 MapReduce

Presto内存调优及原理(基础篇)

Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。

1.5K8
来自专栏FreeBuf

DNS Tunneling及相关实现

*本文原创作者:novsec,本文属FreeBuf原创奖励计划,未经许可禁止转载 ? DNS Tunneling,是隐蔽信道的一种,通过将其他协议封装在DNS协...

6057
来自专栏FreeBuf

Arp欺骗原理及Android环境下的检测方法

测试环境说明 网关: IP:172.20.150.1 mac:24050FCE53 靶机(手机): IP:172.20.150.20 mac:000822...

36510
来自专栏啸天"s blog

安卓百度网盘Aria2下载脚本

2272
来自专栏涤生的博客

系统优化总结—帮你剖析系统问题

之前组内一位大佬分享了一些关于系统性能优化方面的干货,这里我将它整理成文并且加入自己平时常用的一些工具和技巧。由于关于系统性能优化涉及的内容非常多,我会分几篇文...

1672

扫码关注云+社区