O sistema de compressão

O próprio X permite executar aplicativos remotamente de forma bastante completa e transparente. Ao obter a tela de login de outra máquina da rede via XDMCP, ou usar um terminal LTSP, você está justamente utilizando este protocolo nativo do X.

Originalmente, os dados são transmitidos da forma mais simples possível, sem nenhum tipo de encriptação. O servidor X, que roda na máquina cliente, recebe as informações enviadas pelos programas executados no servidor e as usa para montar as imagens que serão mostradas na tela. Cada janela é formada por um conjunto de instruções e coordenadas, texto e pixmaps, que são as imagens e os componentes gráficos usadas nela. Todos os componentes são posicionados de forma a criar a tela do aplicativo, como esta janela do kedit que você vê abaixo:

O protocolo nativo do X é interessante apenas para uso em redes locais, onde existe muita banda disponível e a questão da segurança não é um fator crítico. Para conexões via Internet, é possível encriptar as informações usando o SSH, basta que o arquivo “/etc/ssh/sshd_config” no servidor contenha a linha:

Com o X11Forwarding ativo (no servidor), você precisa apenas fazer uma conexão normal via SSH e chamar os aplicativos gráficos desejados através do terminal. Assim como ao usar o XDMCP, os aplicativos são executados no servidor e as instruções necessárias para exibir a imagem na tela são enviadas para o servidor X ativo no cliente. A diferença é que, neste caso, tudo é feito através do canal encriptado estabelecido pelo SSH.

Via rede local, este sistema funciona muito bem, os aplicativos rodam com um bom desempenho e de forma transparente. Mas, ao tentar usar o SSH para tentar rodar aplicativos gráficos via Internet (mesmo que através de uma conexão de banda larga) o desempenho se torna muito ruim, com os aplicativos demorando muito tempo só para abrir e continuando a apresentar um desempenho pífio depois disso. Via modem a situação é ainda pior.

O SSH permite encriptar a transmissão usando o zlib, o mesmo algoritmo que usamos para gerar arquivos .gz. Para ativar a compressão, você adiciona a opção “-C”, como em:

Usando um monitor de conexão, você pode notar que, ao ativar compressão, o SSH transmite uma quantidade de dados muito menor que o VNC (mesmo que ele esteja com a compressão via JPG ativa), mas, mesmo assim, o desempenho ao rodar aplicativos gráficos via Internet, usando o SSH, ainda é bem inferior. Os aplicativos continuam demorando pra abrir e demorando pra responder, muito diferente do que acontece ao usá-lo via rede local.

Se o X + SSH + Zlib é mais eficiente que o VNC na compressão dos dados, por que o desempenho via Internet é tão ruim?

Entra aí uma das principais desvantagens do protocolo X, os famosos “roundtrips”, ou pacotes de resposta. O X foi desenvolvido para trabalhar localmente, ou via rede local, onde o tempo de latência do link é muito baixo. Em uma rede local, o ping é muito baixo, pois o impulso elétrico viaja quase à velocidade da luz e a distância entre um micro e outro é muito pequena.

Para assegurar a integridade da transmissão, para cada instrução recebida é enviado um pacote de resposta. O servidor transmite a instrução seguinte apenas depois de receber a resposta para a primeira. Como disse, via rede local o ping é muito baixo, por isso estes pacotes de resposta não fazem muita diferença. Via Internet a coisa muda de figura, pois, ao invés de poucos nanosegundos, passamos a trabalhar com pings de 30 milessegundos ou mais.

Um aplicativo como o Firefox pode exigir a transmissão de mais de 2.000 pacotes de resposta durante seu carregamento inicial. Alguns aplicativos específicos chegam a transmitir mais de 6.000, o que pode fazer com que demorem vários minutos só para abrir. Nesse caso, o limitante não é a velocidade do link, mas sim o tempo de resposta.

O NX elimina este problema através de um duplo proxy. O primeiro proxy faz parte do próprio servidor NX, ele recebe os movimentos do mouse e texto digitado no teclado do cliente e os transmite para os aplicativos executados no servidor. O próprio servidor NX monta as telas e transmite todos os pacotes de resposta localmente (no próprio servidor) e depois transmite as atualizações de imagem “prontas” para o cliente, usando um protocolo próprio.

O proxy no servidor (chamado de “nxagent”) elimina quase que inteiramente os pacotes de resposta, acabando com o principal gargalo. O proxy sozinho seria suficiente para trazer o desempenho do NX a um nível similar ao obtido pelo VNC. Apesar disso, o NX vai além, implementando o sistema de compressão, um segundo proxy (desta vez no cliente) e um sistema de cache.

Ao contrário do VNC, o servidor NX não envia screenshots da tela, mas sim instruções, texto e componentes gráficos (ícones, imagens, etc.) que são usados pelo cliente para montar a tela. O algoritmo de compressão usado pelo NX é otimizado para esta situação específica, tratando as imagens, texto e instruções de forma diferente e aplicando seletivamente o tipo de compressão mais adequado para cada caso. As imagens, os ícones e outros elementos gráficos são compactados em JPG ou PNG, o texto é comprimido usando o Zlib e assim por diante.

No caso de instruções, imagens ou blocos de texto com poucas modificações em relação a outros já recebidos, é utilizado um sistema de transferência diferencial, similar ao rsync, que transmite apenas as partes que foram modificadas, reduzindo brutalmente o número de bits transmitidos.

As instruções usadas para montar a tela são transmitidas com uma prioridade mais alta do que imagens, o que faz com que a interface continue respondendo enquanto uma grande imagem (um papel de parede, por exemplo) é transmitida. A própria imagem do papel de parede é quebrada em vários pequenos pacotes, o que permite que as partes já transmitidas sejam mostradas na tela assim que recebidas.

O segundo proxy, que fica ativo no cliente (chamado de “nxproxy”), cria um cache que armazena as informações já recebidas e as reutiliza sempre que possível. O papel de parece pode demorar um pouco para ser transmitido se você está conectado via modem, mas a imagem é transmitida uma única vez. Depois de carregada, ela é utilizada indefinidamente, sem degradar a performance da conexão. O mesmo se aplica a ícones e outros elementos gráficos, instruções e até mesmo texto exibido dentro das janelas.

Este cache pode ser reutilizado em futuras conexões ao mesmo servidor, fazendo com que, a partir da segunda conexão, o volume de dados transmitidos seja reduzido substancialmente. Você pode ver mais detalhes sobre o funcionamento interno destes componentes no: http://www.nomachine.com/documentation.php.

A configuração do cache está disponível na seção “Advanced” na janela de configuração (no cliente). Existem dois caches, um mais rápido, feito na memória RAM e outro maior, armazenado no HD. Quanto maiores os caches, menos informações precisarão ser retransmitidas, melhorando o tempo de resposta, sobretudo em links lentos.

Outro detalhe que conta pontos para o NX é que o cliente possui uma interface fácil de usar (bem voltada para o usuário final), e existem clientes tanto para Linux quanto para Windows. A principal limitação é que o servidor em si existe apenas em versão Linux, já que o objetivo é acessar máquinas Linux remotamente. Se você precisar acessar uma máquina Windows, a melhor opção é o RDP (usado pelo Windows Terminal Services e pela assistência remota) que é o protocolo nativo de administração remota do sistema. O NX Server oferece a opção de encapsular o tráfego do RDP, de forma a melhorar a segurança ev reduzir o trafego de dados entre o servidor e o clinte, mas nesse caso os ganhos não são tão visíveis.