前言

最近闲着无聊又一次重构了这个项目：manager，这次算是最终比较完善的版本了

从去年断断续续的摸鱼到最近，总算整出了一套勉强能用的版本的。

其实rat原理上非常简单，无非就是控制端下发，然后被控端执行，最后把执行结果都给提交了上去。

从最开始的C/S，到现在的B/S，都尝试过，也用过C/PY/GOLANG分别写过马和控制端，先说说出我的经验吧。

架构选择

架构无非就是两种，一种C/S一种B/S，说是这么说，其实原理上也都是C/S，B/S只不过是再C/S的基础上加了个C/B通讯的过程而已。

如果你想要的是快速开发，重点在于可用性而不是易用性，那么我这推荐直接用C/S+cli，gui都不用写。方便快捷。当然如果要好用，而且还要好用的控制其他机器，那么gui肯定是必不可少的。

语言选择

如果不是对程序体积以及内存占用要求严格，在没有高超底层编写基础上，十分不推荐上C/C++来作为首选语言。虽然C/C++优点是这其中最多的，又快又小又灵活，但是同样缺点也很多，跨平台会很麻烦，并且不想其他"现代"语言一样有很多十分方便的库可以调用，想写一个东西直接调用就行，而且还和编写者水平挂钩，一不小心代码就会变的很shit（没错我的代码就是这么shit

golang暂时比较推荐，也是我目前再用的，然而，这编译出来的体积是真的不敢恭维，同时部署开发环境的时候也略微麻烦，但是优点也很明显，跨平台十分的轻松，而且语法也挺简单，C一样简单的语法C差不多的性能，如果没有这鬼畜的体积我绝对会吹爆golag

py是开发最轻松也是最灵活但也是最不灵活的。毕竟是脚本语言，会出现各种奇奇怪怪的问题，会整的你非常非常的迷惑，稳定性不能保证，但是作为控制端开发来说，py是最舒服的，毕竟他是脚本。同时还有个好处就是很多linux会自带python，但是还是归根一点，稳定性很捉急，所有东西都装了但是就是莫名其妙的跑不起来，非常的蛋疼

协议选择

TCP/UDP这类型的协议我就不说什么了，这里大家自行判断，我们这里说的是轮询类还是tcp那种长连接类保持。

tcp长连接类型的好处就是，操作反馈非常及时，最早的gh0st，上兴灰鸽子都是这种模式，然而缺点也很大，就是后台直溜溜的一个tcp链接，十分容易被发现。并且会收到网络波动影响。

轮询类的就是类似cs那种，缺点就是操作反馈不及时，必须等待各种间隔才能交换数据，这对于即时操作体验很麻烦。

所以最好的办法就是两种结合，普通模式轮询遇到特殊模式就建立tcp链接然后实时交换数据，然而这就也挺考研变成功底的

所以如果不考虑隐蔽性而注重体验那就直接走tcp最简单也最轻松，注重隐蔽性就走https，有时间有水平就上两者结合

服务端的一些小tips

接上条，如果选择轮询，还有一个优点是，你可以使用http/https，然后套个CDN，可以有效的隐蔽源服务端，当然这就肯定得预留个tips来设置http的请求头中CDN设置的客户的源IP

目前就想到这么多啦