我们有 100 多个嵌入式电路板，偶尔需要进行交流。
我们发现可靠地执行此操作的最佳方法（那里有一些奇怪的互联网连接）是让主板打开几个到我们服务器的反向 ssh 隧道。
目前每个板子开放 3 条隧道，总共约 300 条。这些隧道大部分时间都处于非活动状态。
这会给性能带来什么影响？假设我们的端口或文件描述符没有用完，那么最有可能让我们陷入困境的是什么？
编辑：我主要关心的是几百个不活跃客户端一次连接。每次只有少数隧道处于活动状态。
答案1
活动 SSH 连接数限制为 65,534 减去系统上使用的 TCP 端口数——如果我们要保守一点，就假设为 60,000（或者对于大多数实际用途来说为“无限制”）。您可能会遇到其他但是系统资源限制取决于您所连接的机器。
也就是说，您可能希望节省隧道数量（每个板真的需要三个连接吗？），并且如果您并不总是需要连接，您可能希望远程站点仅在需要时启动它们。
答案2
TL;DR：记忆。休息一下就好了（对于数百条隧道来说）。
假设我们不会用完端口或文件描述符，那么最有可能让我们陷入困境的是什么？
我认为可以安全回答：记忆。
一个快速实验显示，每个传入连接实际消耗 4.6 兆字节内存。实际实验会显示，其中一部分内存可能被共享。解决方法：添加交换空间。
此外，86 兆字节的寻址空间相当大。它很可能是共享的，否则 32 位服务器在 50 个连接之前就会耗尽寻址空间。解决方法：使用 64 位操作系统。
假设我们没有用完端口或文件描述符，
这个假设成立吗？
在数百的范围内，端口不会有问题，除非您的服务器也是其他服务器的高流量服务器。
文件描述符可能会耗尽。快速实验显示，每个传入 ssh 连接消耗 21 个文件描述符，不包括 shell。文件描述符的限制可以在系统范围内进行调整，因此它不应该是一个真正的阻碍因素。
（实验在 64 位 Debian 服务器上完成。）
答案3
当你需要连接到特定的远程计算机时，有些系统会按需创建反向隧道。这些系统包括AWS IoT 安全隧道和开源软件我出于同样的目的编写了这些。这些消除了同时打开太多反向隧道的担忧。
我的系统使用 MQTT 连接（更具体地说，AWS IoT Core，这是一个安全的 MQTT 代理，具有针对每个客户端的安全策略）来通知远程计算机使用代理上的随机端口打开到代理的反向 SSH 隧道。隧道打开后，远程计算机会将端口号报告给您的笔记本电脑/台式机，然后软件现在会通过代理建立一条通往远程计算机的隧道；您无需登录代理。可扩展性受远程计算机的活动 SSH 连接数限制，而不是受您可以连接的远程计算机总数限制。