FullTclash 前后端模式设计思想（基于Userbot）
2023.11.7更新
经过接近半年的实验，userbot在面对高频率的转发请求，会极容易触发TG的风控，也就是常说的死号、被ban。因此仅适合个人有多个后端，转发频率不高的使用情景。多人使用极容易暴毙，如果你帐号多，随便玩。🙃
旧话
思来想去，最终还是向这个方向开发。起初我并不想开发所谓的前后端分离，FullTclash在设计之初的定位是 小众个人向网络代理链测试工具，毕竟我自己就是个人向的。
但是，由于大家对前后端分离的呼声很高，趁着五一假期结束，我就花一个星期做成了现在测试版。
事实上，我并没有进行想象中的前后端分离，分离意味着一边是前端，一边是后端。原有功能得不到充分应用。所以我想了另一个办法，使之拥有操控多种后端的能力。不同于miaoko（一种闭源的同类型测试产品）基于websocket进行前后端通讯的方法。这种方式需要一个公网ip，或者需要内网穿透支持，存在一定的技术门槛，还需要加密套件支持，否则传输流量会被中间人截获。
那么，有没有一种可能，一种天然的加密防护通讯可以实现呢，其实TGbot与TG服务器的通讯就已经是加密状态了，为什么不妨从TG端传输数据呢？我在大概2月份就已经想到了这种思路，真正让我将可能实现的，得益于Pagermaid（一款通过程序自动化控制你的TG账户的机器人项目）的思想。他们（指民间使用者）将其称之为自走机器人，就是说通过代码模拟一个正常的TG账户进行活动。
所以，前后端模式正式有了实现思想：
这里我称之为前后端模式，是因为两者并不存在严格的功能区分，即双方既可以是前端，也可以是后端。大致的通讯流程为（这里将前端亦可称之为主端bot。后端对应为后端bot）：
我这里分两种模式分开讲解。
对于主端bot：
首先需要一个userbot，也就是自走机器人，userbot是以程序来自动化控制模拟正常TG账户的一种行为（bot）。比方说你发一条消息： 你好 ，你首先需要打出 ”你好“ 二字，点击发送才发送出去，而通过程序也是可以做到的，而且做重复工作往往更有效率。
然后需要对接后端。
对接后端约定为使用：
/connect <后端bot的用户名> <备注> <连接密码>
进行对接。这条指令背后做的工作是：利用userbot获取用户名是否合法，若合法则读取其中id和消息中的用户名、备注、连接密码参数写入到本地配置文件config.yaml，连接密码需要与后端协定。
userbot中转连接请求，本质是userbot转发主端bot的消息（经过处理）
后端bot收到连接请求（消息），做userbot白名单校验（白名单校验请查看后端bot实现细节），通过校验则受理请求，接受主端发来的连接密码，保存主端信息到配置中。完成对接。
测试阶段：
发起测试。同样的操作，主端bot整理好测试的各种参数，反序列化成json字符串，通过密钥加密（加密方式为chacha20）后，请求userbot转发测试请求。
后端bot收到测试来自userbot转发的测试请求，开始解密数据，得到测试的各种参数，开始进行测试，这里测试依然遵循队列机制。测试完成后将结果数据打包反序列化成json字符串，然后加密数据请求userbot转发给主端。
主端bot收到测试结果，进行解密数据，开始根据测试结果绘制图片，最后发送到TG前端。整个测试流程结束。
对于后端bot
由于是后端模式，所以并没有太复杂的逻辑，仅需要将主端bot的userbot的用户id写入到白名单，不写入白名单会视为不合法的”连接“对接请求，会拒绝本次请求。对于添加白名单，我们约定使用
/sconnect <主端botID> <连接密码> <userbot的ID>
进行一次添加白名单，添加完成后需要重启bot让配置生效。
--------------------------------------------------------------------------------------
总之，userbot在整个过程仅仅扮演转发请求的角色，为了防止userbot窃取转发的数据，我们规定userbot由主端bot的拥有者提供。至于如何使用开启userbot，很简单，在配置文件写入:
userbot:
enable: true
重启后要求进行TG的登录验证，因为要模拟人的行为，程序需要进行登录授权，根据提示登陆成功后，下次重启就不需要输入验证码了。
杂谈
1、是否会窃取我（指读者）的用户数据？
对于安全性，本项目是开源项目，无任何第三方后门行为，我们源代码分发在GitHub上和TG官网频道 @FullTclash 。请勿轻易从其他途径下载。
2、userbot是否会违反TG官网的用户政策？
我们综合考量了这种可能性，在本项目中，userbot仅充当转发消息的角色，并未进行大规模的滥用行为，如果您是指像Pagermaid那样极度容易导致的封号行为，这里不敢做任何保证，所以在这里有必要声明：userbot有一定概率会受到不明原因导致的封号风险，介意请勿开启userbot模式。
3、测试过程中加密传输的数据有被破解的风险吗？
天下没有不透风的墙，有一些原因会导致数据泄露：
弱的连接密码。如果攻击者极度了解FullTClash的工作流程，并且拥有usetbot的控制权，是可以进行解密的。
userbot的登录密钥（my_user.seesion）泄露。如果您的机器被其他人光顾过，那个可能此密钥已泄露，他也可以同样进行登录TG的操作，操作与正常账户无异。因此，物理机器的安全性也需要防护。
5、未来是否会使用其他的对接后端方式（比如websocket）？
最终还是做了这个，现已支持两种对接方式。
6、我（指读者）有更好的想法可以提建议吗？
如果您有更好的建议，可以前往我们的github项目发起issue进行建议。我们非常鼓励这种行为。
如果您有更好的代码开发贡献，可以fork本项目后发起Pull Request 请求。我们非常欢迎这种行为。
Last updated