[fatedier/frp]希望加强 IoT 设备方面的支持

1. 端口是 1:1 的，需要开启 N 个端口。
2. 自定义 tcp 协议的路由也在规划中，大致上就是根据用户配置，比如前几个字节的内容来将同一个端口的 tcp 请求路由到后端不同的服务上。但是能否支持 ssh 这样的协议还没研究。
3. 你说的第二点没太看懂，现在其实就是每个 frpc 对应一个配置文件，frpc 可以部署在多个不同的设备上。

第二点是 frps，frps 上面只有一个配置文件，如果我部署了上千个设备，那这个配置文件里面就要加入上千个配置，修改查询起来不方便。应该可以增加扫描目录之类的形式，每个设备对应一个配置文件，相对应的那个配置文件丢到目录里就好了。

设备数多了之后，基于配置文件的管理确实比较麻烦，目前可以采用特权模式来创建，就不需要在 frps 上面配置了。或者之后可能会考虑数据库存储的方式。

特权模式妥妥解决问题啊

特权问题有一个瑕疵，就是不知道服务器端口的占用情况。最好能添加自动纠错，frps分配的功能

@JimLee1996 提的需求很好，我认为实现方案有3种： 1.变通实现：c端写shell脚本实现循环调用frpc, 直到frpc不退出（这种方式感觉太笨了）？ 2.自动分配后，将端口号通过写file、socket、http调用 等反馈到第三方程序，以便其他电脑访问时知道端口 3.frps建立用户账户系统，需要用户先登记，登记时验证端口是否可用（或可自动随机分配端口），类似“报备”概念，即使端口还没用，“报备”后，别人也不能使用。

要想实现估计要写个后台了

@fatedier
你好，有几个问题不是很清楚，和 iot 支持有关，还是在这个 issue 下提问。frp 理论上能支持多少个客户端同时在线？能同时并发访问多少个已经在线的客户端？一个客户端能支持多少用户同时访问？实际上怎么样？

还有就是如果做压力测试的话怎么测试？我目前了解到的是可以在一个机器上起不同的客户端转发不同的端口给服务器，这种方式做压力测试会不会有什么问题？还有没有其他方式。谢谢！

@Jexbat 你有这方面的实际需求吗？考虑到目前的精力放在功能开发上已经有些吃力，对于大规模并发访问的测试以及优化还不在考虑中，会优先优化单个客户端的效率、资源占用和稳定性。

我个人觉得单台服务器能支撑1w的客户端同时在线就ok了，有哪些资源会成为瓶颈，没有测过还不知道。如果没有实际需求的话，可以暂时不用考虑太多这方面的问题，不用过度设计。

@fatedier 了解，今天写了些脚本晚上进行压力测试，目前测试的是1000个客户端在线并且连续并发访问这1000个客户端，看服务端和客户端是否还能继续正常运行，因为目前有这方面的需求。再次感谢这个项目，希望能一直开发下去，后续有精力也会学习推进这个项目，谢谢。

@Jexbat ,你好，本人也在做IoT方面的研发，首先感谢fatedier大神给的这么好用的工具。 然后我想问下你的压力测试做的怎么样？我也非常想知道他能扛得住多少并发。

我个人觉得性能良好的话，我会拿一台服务器做负载均衡，然后再把frp服务部署到各服务器上。

@LitleCarl 额，忘了反馈了，我测试的1000个客户端在线并连续并发访问这1000个客户端基本是可行的，因为我1000个客户端是在虚拟机里建了1000个 http server，前几分钟是没问题的，过几分钟虚拟机就崩溃了....我这边也没条件再做测试，所以就告一段落.....

我也很关心frps的并发性能，现在frps都是基于tcp的转发，所有流量都经过服务器，理论上支持IOT的应用会有问题，当然一般IOT设备的流量有限，通常的应用影响不会太大。但是作为IOT的场景实际的终端接入量怎么说也得超10K吧。对服务器转发还是有性能要求。要是frps支持UDP打洞，流量转发不经过服务器，而只是记录动态ip和端口就好了，这样才适合大规模部署的场景，否则还是只能个人用户随便玩玩。

做iot可以看看 dog-tunnel，支持p2p，tcp转发

感谢作者，很期待有P2P功能，已经捐赠过一次，如果有P2P愿意再捐赠，多一点都可以：）

如果是针对IoT的运维，可以通过MQTT，在需要时连接：

1. 由运维端发起运维请求 by MQTT
2. 设备端启动 frpc 进程，frps success后，MQTT 返回 remote_port
3. 运维端ssh连接

对IoT我有个想法，在一个内部互通的网络，有2~3台作为跳板连到frps，其它通过跳板连接。