Multiplexador de porta sslh: por que é tão intensivo em recursos?

Question

Acabei de descobrir a existência de sslh .

Eu tentei instalá-lo no meu 512MB RAM VPS rodando o Debian 7 wheezy. Depois de ter configurado o sslh , tentei conectar-me a um dos hosts virtuais do apache2, e imediatamente o uso da CPU aumentou para 50-60%, mesmo que o VPS fosse quase impossível devido à falta de recursos.

• Isso é normal?
• Existe alguma alternativa válida?

O problema que eu estava tentando resolver usando sslh é que muitos hotspots de wi-fi grátis bloqueiam quase todas as portas, exceto 80 e 443, e eu frequentemente preciso usar o OpenVPN para conectar ao meu servidor doméstico, que é chamado pelo meu ISP .

Você tem alguma outra solução para sugerir?

    

Answer 1

De uma resenha casual da fonte, parece que o (s) autor (es) estavam com excesso de zelo no uso de set_nonblock em sslh-select.c .

Se você sinalizar todos os soquetes (como faz) como não-bloqueantes, o loop

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

na linha 230 no arquivo vinculado se torna uma espera ocupada. Ou seja, mesmo que não haja dados disponíveis para leitura em qualquer soquete, selecione retorna instantaneamente e, em seguida, é chamado novamente imediatamente. Isso é bastante processador intensivo.

O autor chegou perto de acertar, com algum uso condicional do argumento timeout para select , mas isso não tem efeito se todos forem definidos como não-bloqueantes de qualquer maneira.

Eu não criei o perfil sslh , que é a melhor maneira de confirmar que essa é a causa real.

    

Answer 2

Portanto, esse problema agora é seguido aqui: link

A resposta de msw pode ser exaustiva, mas também está errada: select() bloqueará independentemente do status O_NONBLOCK do soquete, é basicamente para isso que serve e, de fato, o código que usa soquetes de bloqueio ao usar select() está errado . Do Linux ' select(2) : "No Linux, select() pode relatar um descritor de arquivo de soquete como" pronto para leitura ", embora, no entanto, um bloco de leitura subsequente".

Em outras palavras, não definir O_NONBLOCK ao usar select() pode resultar em bloqueio completo do programa.

Então, enquanto algo pode estar errado, não é isso.