☰

端口多路复用器 sslh：为什么它如此占用资源？

tag-icon • tag-icon debian networking vps
端口多路复用器 sslh：为什么它如此占用资源？

我刚刚发现了 的存在sslh。

我尝试将其安装在运行 Debian 7 的 512MB RAM VPS 上。配置完成后sslh，我尝试连接到我的一台 apache2 虚拟主机，CPU 使用率立即上升到 50-60%，甚至由于缺乏资源而无法通过 ssh 连接 VPS。

  • 这是正常的吗？
  • 有任何有效的替代方案吗？

我试图解决的问题sslh是，许多免费 WiFi 热点几乎封锁了除 80 和 443 之外的所有端口，而且我经常需要使用 OpenVPN 连接到我的家庭服务器，这是由我的 ISP 提供的。

您还有其他解决方案可以建议吗？

答案1

从对来源的随意审查来看，作者似乎过于热心地使用set_nonblock了sslh-select.c。

如果将每个套接字（正如它所做的那样）标记为非阻塞，则循环

while(1) {
    select(… a bunch of non-blocking sockets …);
}

在链接文件的第 230 行左右，变为忙等待。也就是说，即使任何套接字上没有可供读取的数据，select 也会立即返回，然后立即再次调用。这是相当处理器密集型的。

作者几乎做到了正确，有条件地使用了参数timeoutto ，select但如果无论如何都设置为非阻塞，则没有效果。

我没有介绍sslh确认这是真正原因的最佳方法。

答案2

所以这个问题现在就在这里：https://github.com/yrutschle/sslh/issues/24

msw 的答案可能很详尽，但也是错误的：select()无论套接字的O_NONBLOCK状态如何，都会阻塞，这基本上就是它的用途，事实上，在使用时使用阻塞套接字的代码select()是错误的。来自Linux' select(2)：“在Linux下，select()可能会将套接字文件描述符报告为“准备好读取”，而随后的读取会阻塞”。

也就是说，O_NONBLOCK使用时不设置select()可能会导致程序完全被阻塞。

因此，虽然可能有问题，但事实并非如此。

相关内容