e6e5psj

见过最方便的客户端是"灰鸽子"远控那样. 配置一些参数,主控端直接生成一个客户端的exe出来 . 这家伙连抠脚大汉都一分钟上手.三年级不及格小孩马上会用.

真实场景: 我用海思的板子做了一个采集器,通过硬件采集视频流,然后通过RTMP,WEBRTC,RTSP,SRT待输入把采集的视频流输出. 海思的板子跑的是Linux变种,所以跑FRPC是好跑的. 为什么以在板子上面跑FRPC? 因为我要远程监控和控制板子. 两个方面的控制 ,一是通过web控制台控制,二是通过SSH控制 .这两个是通过FRPC映射出来的. 还有哪方面使用到了FRPC? 我给每个硬件一个硬件ID, 通过硬件ID来标记和远程连接它. 比如硬件ID是12345,那这个硬件的地址就是: https://12345.device.abc.com; 我相当于使用FRPC组了一个局域网. 连接到FRPS后, 组成了一个可以反向连接的"物联网" 同时,这些硬件是要提供到每个客户那边,当板子断网的时候(反正各种原因无法连接网络),就要给客户root账号做辅助排查. 这里,FRPC就完全暴漏了. 所以,期望是FRPC编译出来 ,是一个可执行文件,直接丢到服务里跑就成.

> @zsinba 如果你担心手动重启后会影响到后续的重新运行，可以提供一种方式将 token 通过加密的方式存储在机器上，其他人也看不到，frpc 启动时可以读取加密的内容做解密后运行，加密的内容中可以加入一些机器信息，确保无法简单复制到其他机器上运行。 > > 编译进二进制，这个你可以自己修改代码来实现，实际上也并不复杂。 加密的方式也可以.这也是好办法. 期望能加入.

我猜想,是不是FRPS里,对一个端口的连接,做了上限限制,导致达到这个上限后,就不再处理. 但是表现并不太像,我查看了(netstat -ano >1.log)端口连接情况,并不是很多端口,系统所有连接加起来,也才一千左右. 没有其他办法,我只能重启FRPS,然后访问就恢复正常了. 所以问题应该还是在FRPS上面. FRPC我没有去动它.

> 可能需要更多点的信息： > > 1. “只接受,不应答“ 是否 frps 有哪些日志 日志可能用途不太大，没看出来 异常。如下日志。 > 2. 结合 frps dashboard 看看有没有信息，比如说 proxy connections 没有异常，正常的连接状态的。 > 3. 能不能提供一个复现的场景或者思路 我一共出现 了两次，每次间隔时间大概两周。 每次都是重启frps解决的

> 可能需要更多点的信息： > > 1. “只接受,不应答“ 是否 frps 有哪些日志 日志可能用途不太大，没看出来 异常。如下日志。 > 2. 结合 frps dashboard 看看有没有信息，比如说 proxy connections 没有异常，正常的连接状态的。 > 3. 能不能提供一个复现的场景或者思路 我一共出现 了两次，每次间隔时间大概两周。 每次都是重启frps解决的 日志在这里： 2021/01/21 23:05:47 [I]...

就是在出现了一堆 get a new work connection 后那段时间出的的问题。 我把日志脱敏了。

下面是FRPC的日志： 从这个时间开始出错的。所以只取了这个时间的。 2021/01/21 23:42:39 [E] [control.go:158] [b3c99ad587e6a41c] work connection closed before response StartWorkConn message: EOF 2021/01/21 23:42:39 [E] [control.go:158] [b3c99ad587e6a41c] work connection closed before response StartWorkConn message: EOF 2021/01/21 23:42:39...

请求高峰，上限不会超过200。 我是做了CDN过来的，有CDN服务器请求过来，高峰的时候，有20台服务器过来请求。 从服务器性能来看，普通的一台4核20G的服务器跑的FRPS； FRPC是64核128G内存的服务器。 主机性能应该不是原因， 因为仅有一个端口出现问题，当这个端口出现问题的时候，其他端口的映射是正常的，没有任何问题。 所以，我觉得可能是FRPS和FRPC通信的时候，对某一个指定的端口，请求时返回等待，或者并发请求稍高（我说是200左右，并不是几千那么高），FRPC和FRPS之间就出问题了。 而且，这并不是必现的问题，两周左右出现一次。在出现问题的时候，我排查了FRPS和FRPC两个服务器，CPU、内存、IO、网络等情况，没有任何异常。都是很低的值的。 所以，是针对某个端口造成的死锁，这个死锁是来自于FRPS的。这个可能性最大。

但是这个怎么解释，重启FRPS后，恢复正常了呢？ 我猜测原因肯定是与连接数有关。因为这个并不是马上出来 ，是运行一段时间后，积累了一些东西后才出来 与网络层情况相关的，这个不好跟踪了， 使用的是一台群晖的NAS（1618+），常年不关机的。