Encaminhamento SSH / x11 mais rápido sem instalar software no servidor

Question

Alguém sabe alguma maneira de acelerar o encaminhamento do X11 no SSH, exceto pelo uso de uma codificação e compactação mais rápidas, sem instalar nenhum software no servidor? No meu caso, não tenho permissão para instalar software no servidor. Pertence à minha universidade. No entanto, gostaria que os programas GUI executados no servidor e exibidos em meu computador doméstico fossem realmente utilizáveis .

    

Answer 1

Tunneling X11 a ssh é bastante caro em termos de largura de banda e o protocolo X não é ideal para altos links RTT. Você pode simplesmente não ter largura de banda suficiente ou latência suficiente para ser utilizável.

Você parece já ter reduzido as opções que você tem:

• opções que requerem a instalação de software em ambas as extremidades (um otimizador de protocolo X, como x2go, FreeNX ou outros, ou outro protocolo além de X sobre SSH, como VNC ou Área de Trabalho Remota)

• usando compressão (ou não, deve ser melhor com mas tente ambos): opção -C

• usando um protocolo de codificação mais barato, como BlowFish-CBC ou arcfour (o segundo é menos seguro): adicione a opção -c blowfish-cbc

O único que você parece ter perdido é se o seu programa X é o Firefox, caso em que parece que definir network.http.pipelining e usar a multiplexação ssh poderia faça uma diferença .

    

Answer 2

Eu uso ssh-hpn , uma série de correções para o código SSH oficial para melhor desempenho, para qualquer momento eu preciso de SSH de alto desempenho. Algumas plataformas como o FreeBSD o incluem de fábrica, em outros você pode instalá-lo através de um gerenciador de pacotes, ou você pode compilá-lo a partir do código-fonte e adicionar as correções em si mesmo.

Se você estiver em uma plataforma popular, provavelmente poderá encontrar uma distribuição binária de ssh-hpn (embora, por razões óbvias de segurança, construir a partir da fonte seja sempre melhor com um software como esse).

Se você realmente não se importa com segurança, pode usar o X11 sobre o netcat (também conhecido como nc ) em vez de ssh. É provável que já esteja instalado em sua máquina.

    

Answer 3

Idéia # 1: desative a compactação. Sim, desativado. É possível que seu problema não seja sobre largura de banda, mas sobre latência. Ter compressão no canal faz normalmente uma latência muito ruim para aplicativos de GUI. Se você tiver uma boa largura de banda, sugiro que uma boa tentativa pareça estranha no primeiro ponto: desative a compactação em todos os lugares.

Idéia # 2: Tente usar outra implementação ssh. Em seguida, openssh é um pouco notório sobre sua velocidade. Provavelmente, sua razão parcial é que seus desenvolvedores estão se concentrando na segurança, e a velocidade é uma coisa secundária para eles. A causa da latência é provavelmente não a lentidão dos algoritmos de criptografia, mas o manejo ineficiente dos eventos de transferência de dados simultâneos (em várias direções, tanto de entrada quanto de saída), e também o cálculo / compressão / criptografia coisas em um single-threaded, software não orientada a eventos. (Por exemplo: trabalho típico do software: primeiro ele criptografa um bloco de dados, envia-o para a rede, finalmente lê o que o lado remoto nos enviou e o descriptografa. Parece perfeitamente correto, mas contém uma latência terrível: blocos de dados chegados não serão lidos até que a compressão real do bloco não esteja pronta ... Deve ser implementada de uma maneira multithread, ou pelo menos assíncrona, e o openssh é muito, muito, muito ruim nisso).

Idéia # 3: Verifique a configuração em ambos os lados. A compactação pode ser definida no servidor e também na configuração do cliente. Parece-me não irrealista, que talvez você só tenha montado em um dos lados. Verifique, realmente verifique se isso realmente acontece em ambos os lados (embora provavelmente no lado de envio não seja realmente importante, porque os movimentos do mouse e os acessos do teclado não usam muita largura de banda para isso. Talvez uma solução assimétrica, também comprimindo a grande operações de imagem no lado do servidor e do cliente, enquanto envia dados descompactados de servidor de cliente e baixa latência prometem o melhor resultado.