Usando o FreeNX Server

Ao invés de simplesmente tirar screenshots da tela e comprimir as imagens, como faz o VNC, ele abre uma seção remota do X (como ao usar o XDMCP), onde são transmitidas as instruções e pixmaps usados para montar a tela que será exibida no cliente. Estes dados são compactados usando um algoritmo próprio (mais eficiente que sistemas tradicionais de compressão de dados, como o Zlib) e encriptados usando o SSH, o que torna o FreeNX mais rápido e mais seguro que o VNC, tanto em links lentos (sobretudo conexões via ADSL ou modem) quanto em redes locais, onde banda não é problema.

Assim como no VNC, o FreeNX exibe uma janela contendo um desktop do servidor. O tamanho da janela é ajustável e cada seção é independente, permitindo que dezenas de clientes (Linux ou Windows) se conectem ao mesmo servidor.

Ao encerrar a seção, você tem a opção de suspendê-la, o que permite reconectar mais tarde (a partir do mesmo cliente), sem perder as janelas e trabalhos abertos.

O FreeNX consome menos processamento e menos banda que o VNC. Numa rede local isto permite abrir mais seções simultâneas a partir do mesmo servidor, usar micros mais antigos como clientes e ainda assim executar os aplicativos de forma transparente, com tempos de resposta muito baixos. Os ganhos são ainda mais notáveis ao acessar máquinas remotamente através de conexões lentas.

Um ADSL de 256k já é suficiente para trabalhar confortavelmente, acessando seu micro do trabalho de casa, por exemplo. Surpreendentemente, mesmo uma conexão via modem se revela bastante utilizável.

No site da NoMachine (http://www.nomachine.com/) você pode fazer um testdrive, acessando um servidor NX da empresa. Este servidor está localizado na Europa e fica congestionado em muitos horários, por isso é uma boa amostra do desempenho ao acessar servidores congestionados e distantes geograficamente.

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 componentes gráficos usadas nela. Todos estes 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:

X11Forwarding yes

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 isto é 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 disto. 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 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. Numa 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ó pra abrir. Neste caso, o limitante não é a velocidade do link, mas sim o tempo de resposta.

O FreeNX 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 FreeNX a um nível similar ao obtido pelo VNC. Mas, o FreeNX 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, í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 (como por exemplo um papel de parede) é 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.

Melhor ainda, 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. 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.

Na mesma tela está disponível a configuração do teclado. Por padrão, o FreeNX mantém a mesma configuração de teclado usada no cliente, ou seja, se você usa uma teclado ABNT2, as teclas de acentuação continuarão funcionando corretamente, mesmo ao acessar um servidor com um teclado Americano, configurado com o layout Turco. Você pode também especificar manualmente um determinado layout de teclado, opção usada geralmente para solucionar problemas.

Outro detalhe que conta pontos para o FreeNX é 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, o VNC ainda é a melhor opção.

O NXserver nasceu como um produto comercial, distribuído pelo http://www.nomachine.com como uma solução para redes com terminais leves. O servidor é pago e o cliente disponível para download gratuito.

Apesar disso, todas as bibliotecas usadas são open-source, o que possibilitou o desenvolvimento do FreeNX Server, que é gratuito. Usamos então o servidor FreeNX em conjunto com o cliente da NoMachine, chegando a uma solução completamente gratuita.

Por incrível que possa parecer, o FreeNX é desenvolvido com o apoio da NoMachine, que inclusive contribui com o projeto. Embora tenham funcionalidade similar, o servidor comercial possui uma interface muito melhor acabada, é mais fácil de instalar e conta com o suporte oficial. Isso faz com que o público corporativo (que são os principal clientes da NoMachine) paguem pelo cliente comercial, enquanto o FreeNX permite atrair uma massa de usuários e colaboradores, que ajudam no desenvolvimento das bibliotecas base.

Este é, na minha opinião, um dos melhores exemplos de como uma empresa pode manter um modelo de negócios viável e ao mesmo tempo desenvolver código aberto, que beneficia um grande número de usuários