O problema com o encaminhamento contemporâneo X (não aquele "antigo" X quando a transparência de rede foi inventada) é com suavização de fonte: para suavizar cada glifo do texto renderizado em alguma superfície, o servidor X precisa obter o bitmap que está localizado sob a caixa delimitadora desse glifo do cliente que deseja renderizar esse glifo. (Isso é necessário para que o algoritmo de suavização funcione corretamente, pois leva o contexto no qual o glifo é renderizado.)
Por isso, com kits de ferramentas GUI contemporâneos, a quantidade de tráfego entre o servidor X e seus clientes é enorme: você pode ver isso ativando o TCP em seu servidor X local (esses dias normalmente são iniciados com -nolisten tcp
) e forçar algum cliente X baseado em GTK ou Qt a falar com o servidor via TCP:
$ DISPLAY=localhost:x11 /usr/bin/that/x-app
(consulte grep x11 </etc/services
para as portas padrão do servidor X).
Você notará imediatamente como o cliente se comporta lentamente, mesmo que o tráfego X não esteja deixando o host local: simplesmente porque o tráfego X é transportado por um soquete do domínio Unix que basicamente apenas copia bytes entre buffers na memória, sobrecarga, e agora percorre toda a pilha TCP / IP com todas as suas filas e lógica complicada. Agora, considere o que acontece quando esse tráfego é enviado no seu caso - agrupado em três camadas de protocolos de transferência de dados: túnel SSH transportado por túnel VPN transportado por TCP / IP transportado pela conexão.
Quanto ao que fazer sobre isso, não tenho tanta certeza.
Com mosh
estando fora do jogo , eu tentaria jogar com o IPQoS
opção do cliente OpenSSH.
Outra abordagem é atacar o problema de outro ângulo: tente o acesso baseado em VNC ao seu aplicativo. As opções variam aqui: