frp所有版本都存在的一个严重问题

[hijk1234]

用frp来充当转发的角色，作者可以去百度，搜索gh0st随便下载个软件用来测试TCP长时间连接(七八个小时)。一个晚上就能测试出来所有问题，比如当一个tcp连接由于某种未知原因死了后(其实并不是真死，tcpview查看用户端网络连接状态其实还是ESTABLISHED)，frp没有能力及时的检测出来。通俗的来讲就是frp无法及时感知用户端和客户端之间（注意，用户端【gh0st软件服务端】和客户端【gh0st软件生成的客户端】）tcp连接的健康状态。这样就会导致假死连接。出现假死的时候只能在gh0st服务端手动去点一下，这个tcp连接才会释放。然后经过一段时间后（这个连上来的时间不知是多久，不会掉线后，立刻重新连接上来）才会重新连接上来。当同时有上百个gh0st客户端连接gh0st服务端，这个问题会导致gh0st服务端连接上来的客户端特别乱，基本没办法使用了。

[sunnyboy00]

我觉得在这个问题应该是后台服务来管理，frp 只做中继

[hijk1234]

你错了，经过测试。使用圣剑内网通的话，就不会存在这个问题。同样的客户端，服务端，用户端。用圣剑做反向代理TCP就没问题。，换了frp就出现很大的问题。说明frp的TCP模块还是有很大的问题的。这还是四五个电脑测试一个晚上的结果。如果是上百个电脑，那就大乱特乱了。

[yanggis]

这个问题我很早就报告过了，可惜作者一直没有重视:
https://github.com/fatedier/frp/issues/457

[yanggis]

现在的解决办法就是隔一段时间把frp客户端重启一次。

[yanggis]

@hijk1234 不过你也不用借机用商业软件来黑frp，虽然它有问题，我还是希望推荐更多的人用frp，把那些收费的内网通软件全部灭掉，包括你提到的什么软件。

[hijk1234]

@yanggis frp从第1版到现在最新版本，TCP模块都存在这个问题。只是向作者真实反馈问题，没有黑frp之说。

[xirotech]

单纯就问题来说 这是一个影响业务持续性的严重问题

不过我好想看到一个拥有上百只肉鸡的黑产老铁现身了。 呵呵呵

[dsf848dfgvs]

@fatedier frp确实有这个问题，老早以前就知道了。这个问题估计比较难，不然作者不会到现在也不修复哦。

[zhangcunxiang]

@dsf848dfgvs 确实是这样，我自己用erlang 撸的 一个 tcp 转发服务也存在这样的问题，莫名其妙连接就假死了，但是双方都认为对方是正常连接着的，之前试过 ngrok 1.7 也存在这个问题，不知道有没有大牛能够指点指点 解决方案

[fatedier]

@zhangcunxiang 双方都认为对方是正常的，你们的应用都不加心跳包的？

[hijk1234]

@fatedier 把frp换成圣剑内网通，其它都不变，就一切正常了。那还不能说明frp tcp方面存在问题吗？

[fatedier]

@hijk1234 你的逻辑有问题，XXXX 和 frp 没有关系，其他项目有的功能 frp 不一定会支持，取决于项目的发展和目的。

客户端和服务端的通信，需要考虑网络环境的各种异常，所以通常我们会在通信协议中加上心跳包，比如 frpc 和 frps 两者的交互，即使没有数据传输，也会定期发送心跳确认服务正常。所以即使你把 frpc 客户端机器上的网线拔了，frps 端也是可以感知到客户端异常。

同理，用户自己的程序也可以自己通过心跳维持服务正常，和中间的代理层没有关系。

[hijk1234]

@fatedier 不太明白你说的，感觉frp TCP设计的确实有缺陷，说不上来什么问题。还是觉得既然frp 支持tcp模块，还是做的完善一些比较好。

[fatedier]

@hijk1234 如果还不明白可以先去阅读一些相关的文章，TCP 协议，网络编程相关的，常见的服务器程序对于各种网络异常问题的处理，然后熟悉了之后再一起讨论讨论，看是哪方面的问题。

从我的角度来看，这个问题是在帮写的不完善的用户程序解决问题，暂时还没有这个计划。

[hulucc]

frp用在生产环境也遇到了类似的问题，工作一段时间以后就出现假死，必须重启，每月都会来几次。