在 frp 的说明文档中我看到了这个功能描述：

这个当然是一个很好的功能，但是对于是如何实现的以及有哪些特性和缺陷是作者没有提到的也是我关注的点，毕竟就负载均衡来说，可以考究的内容还是比较多的，比如：

• 这里是如何判断存活的 proxy 的，基于的标准是啥以及实现是否规范？
• 这里采用的负载均衡算法是啥？有什么讲究？
• 负载均衡有什么策略吗？会不会出现一些意想不到的情况？
• 万一同一个 group 的配置项不一样会怎么处理?
• 等等

这些都是我觉得可以去看看的，所以就带着这些问题，我来翻翻代码，这里需要注意的一件事情就是作者说了，目前只支持 TCP 的，那我理论上只看 TCP 部分就好了，但是有一个好奇心就是为啥 Http 和 Https 不支持了，应该会更简单实现才对呀？

Group 这个名词其实从前面看代码的过程已经见过了，首先第一步肯定是 Client 的读取配置说起，然而遍历 Client 的代码会发现不怎么看得到 Group 的相关代码，想想也是，这是 Server 端的功能，只不过在 Client 端配置上了，这里就引发了我的另外一个兴趣：如果两个不同机器的 frpc 共用一个 group id 会得到负载均衡吗？所以得从 Server 的代码找找看了，在遍历了非常深的地方我找到了：

这里其实逻辑和单个 TCP 的差不多，应该一个比较大的不同之处就与 listener 的构建和使用上吧，所以这里可以着重看一下 GroupListener 的监听和分发：

这里一个有意思的点就在于一个 Group 里面的所有 Proxy 共用一个真正的 Listener，那么至于当用户请求过来的时候，谁收到这个请求并且响应之类完全就是随机的，这符合作者的说明:

但是这种方式未免有点过于随性和不可控。

从这里来看，需要保持 group 和 groupKey 相同，并且对于我感兴趣的事情，不同 host 上的同一个 group 将会获得负载均衡的效果，只是这真的是很随机的负载均衡。