我用 Rust 重写（并重新设计）了 frp，性能和资源占用有很大改善

rathole - 安全、稳定、高性能的内网穿透工具，用 Rust 语言编写。

先博一下眼球，让各位有兴趣继续看下去：

TCP/UDP 最大吞吐量比 frp 高几倍
内存占用从 60~70MiB 减少到 10MiB 以下（ Rust vs Go ，这种结果并不意外）。
二进制文件精简，且支持编译时开关特性裁剪，最小二进制在 x86_64 上大小只有 500KiB 左右。
连接延迟和 frp 基本相同，但能承载更高并发。

如果你对性能和内存的测试数据感兴趣，可以直接拉到帖子下面的图表感受一下。

你可以先看看 README ，其中介绍了特性、配置和用法

下面写写我为什么要做这个工具，和我开发的时候在想什么。

frp 是优秀的基于内网穿透反向代理工具，方便易用，集成了很多功能。

但我对一个内网穿透工具的期望不太一样，我相信一个工具应该专注做一件事，通过简单优雅的设计接口来提供扩展能力。

我仔细思考了如何设计这样一个工具，它应该：

有安全和优雅的服务模型 服务端和客户端各自只负责自己的配置，并对外暴露配置 API （目前支持服务配置热重载，HTTP API 正在开发）。每个转发服务强制且单独鉴权。这样可以在易用性、安全性、灵活性间达到平衡：
- 通过支持外置配置管理程序（比如使用 rsync 安全地同步配置），使单租户时像 frp 一样易用。
- 服务配置分离。服务端 /客户端不需要有额外的信任关系
- 每个服务使用单独的 Token 鉴权，同时也提供了所有服务的默认 Token 设置项。这样可以支持租户身份的任意划分，同时又支持单个用户时快速编写配置的需要。
保持简单和专注 rathole 专注于内网穿透本身，而不是提供路由、复杂的鉴权和多租户管控、和各种运输层和应用层协议交互。这些需求应该通过和其他工具的组合实现，而不是集成到 rathole 中。这可以带来性能上的好处和更广泛的适用性，比如部署到嵌入式设备（路由器、工控机）中。
- 比如基于域名的路由可以和 nginx 组合使用来优雅的实现。
- 复杂的鉴权和多租户管控可以通过 API 来让外部程序实现一个 Dashboard 。实际上实现一个安全、高性能、且满足所有用户管理需求的单一内置 Dashboard 是不可能的事情。
- 如果需要特殊的运输层和应用层协议承载流量，则应该通过对应的隧道工具实现。

相比于 frp ，除了数据上的优势，rathole 还有更多的可能性：

低资源占用和特性可裁剪使其可能运行在中低端路由器、物联网设备上
高性能使其更容易支撑高并发或者大流量的场景，更稳定

未来

rathole 已经持续开发了一段时间，必要的特性已经趋于完善和稳定。我觉得是时候发布出来，让大家体验使用和反馈。

目前已经决定的开发计划有 HTTP API (或其他形式的 API ）。API 实现后，能够支持 Dashboard 和复杂动态管理需求的开发。

最后，如果你还没有查看项目 README ，这里是一个方便的链接。

性能测试

测试的具体数字随机器变化，测试方法见此，主要用 iperf3 测试 TCP/UDP 吞吐量, vegeta + nginx 测试 HTTP 吞吐量，同时检测内存占用

nbndco

2022-01-05 18:04:27 +08:00

@sgissb1 理论上来说资源占用是水平问题，水平不行的人写 rust 也不会快。

但是如果水平到达一定程度的话，其实就涉及到一个语言特性的问题。

有的时候，项目一旦复杂，或者想要设计的很灵活，那很多问题就希望能够进行抽象，但是不同语言的抽象成本差距非常大。

像 rust 很多时候几乎是 zerocost 的抽象，使得我们几乎都不需要任何 Box 就可以实现非常灵活的功能。这在 C ，go 里面几乎无法想象，基本是原理上的不可能。在 C++里面，由于模版本身的限制，使得大规模的使用模版的开发维护难度非常高，在实际工程中几乎不可能，只能在极少数性能敏感的库中使用。

另外很多功能比如 Iterator ，使得一个自然设计的 API 在使用时就几乎不会产生不必要的性能损耗。这在其他语言中只是理论上可实现，可由于难度过大或者过于繁琐而没有任何人会去做。

这些都几乎没法通过开发者的水平来弥补。