Como o TeamViewer é tão rápido?

Desculpe o comprimento, é meio necessário.

Introdução

Estou desenvolvendo um software de desktop remoto (apenas por diversão) em C # 4.0 para Windows Vista / 7. Passei por obstáculos básicos: tenho um sistema de mensagens UDP robusto, design de programa relativamente limpo, tenho um driver de espelho (o driver de espelho DFMirage gratuito do DemoForge) em funcionamento e implementei o NAT para todos Tipos de NAT, exceto NATs simétricos (presentes em situações de firewall corporativo).

Com relação à transferência / compartilhamento de tela, graças ao driver de espelho, sou automaticamente notificado das regiões alteradas da tela e posso simplesmente organizar o bitmap de tela em constante mudança do driver de espelho no meu próprio bitmap. Em seguida, comprimo a região da tela como PNG e a envio do servidor para o meu cliente. As coisas parecem muito boas, mas não são rápidas o suficiente. É tão lento quanto o VNC (btw, eu não uso o protocolo VNC, apenas um protocolo amador personalizado).

Do software de desktop remoto mais lento ao mais rápido, a lista geralmente começa em todas as implementações semelhantes a VNC, depois sobe para o Microsoft Windows Remote Desktop ... e depois ... TeamViewer. Não tenho muita certeza sobre o CrossLoop, o LogMeIn - eu não os usei, mas o TeamViewer é incrivelmente rápido. É literalmente ao vivo. Eu executei um treecomando no prompt de comando e ele foi atualizado com um atraso de 20 ms. Posso navegar na Web apenas alguns milissegundos mais lento que no meu laptop. Rolar o código verticalmente no Visual Studio tem um atraso de 50 ms. Pense em quão robusta a solução de transferência de tela do TeamViewer deve ser para conseguir tudo isso.

Os VNCs usam ganchos baseados em pesquisas para detectar alterações na tela e captura de tela de força bruta / comparação na pior das hipóteses. Na melhor das hipóteses, eles usam um driver de espelho como o DFMirage. Eu estou neste nível. E eles usam algo chamado protocolo RFB.

A Área de Trabalho Remota do Microsoft Windows aparentemente vai um passo acima do VNC. Ouvi, de algum lugar no StackOverflow, que a Área de Trabalho Remota do Windows não envia bitmaps de tela, mas comandos de desenho reais. Isso é bastante brilhante, porque ele pode enviar texto simples (desenhe esse retângulo nessa coordenada e pinte-o com este gradiente)! A Área de Trabalho Remota é realmente muito rápida - e é a maneira padrão de trabalhar em casa. E usa algo chamado protocolo RDP.

Agora, o TeamViewer é um completo mistério para mim. Aparentemente, eles lançaram o código fonte da versão 2 (o TeamViewer é a versão 7 em fevereiro de 2012). As pessoas leram e disseram que a versão 2 é inútil - são apenas algumas melhorias em relação ao VNC com passagem automática de NAT.

Mas a versão 7 ... é ridiculamente rápida agora. Quero dizer, é realmente mais rápido que o Windows Remote Desktop. Transmitei jogos do DirectX 3D com o TeamViewer (a 1 qps, mas a Área de Trabalho Remota do Windows nem sequer permite a execução do DirectX).

A propósito, o TeamViewer faz tudo isso sem um driver de espelho. Existe uma opção para instalar um, e fica um pouco mais rápido.

A questão

Minha pergunta é: como o TeamViewer é tão rápido?Não deve ser possível. Se você tiver uma resolução de 1920 x 1080 em profundidade de até 24 bits (a profundidade de 16 bits seria notavelmente feia), isso ainda é 6.220.800 bytes brutos. Mesmo usando o libjpeg-turbo (uma das bibliotecas de compactação JPG mais rápidas usadas por grandes empresas), compactando-o para 30 KB (sejamos extremamente generosos), levaria um tempo para rotear pelos servidores do TeamViewer (o TeamViewer ignora os NAT simétricos corporativos, simplesmente proxyizando o tráfego através de seus servidores). E essa compactação libjpeg-turbo levaria tempo para compactar. A compactação JPG de alta qualidade leva 175 milissegundos para uma captura de tela completa de 1920 x 1080 para mim. E esse número aumenta se o computador do host executar um processador Atom. Simplesmente não entendo como o TeamViewer otimizou sua transferência de tela tão bem. Novamente, imagens de tamanho pequeno podem ser altamente compactadas, mas leve pelo menos dezenas de milissegundos para compactar. Imagens de tamanho grande não demoram a compactar, mas demoram muito tempo para serem concluídas. De alguma forma, o TeamViewer conclui todo esse processo para obter cerca de 20 a 25 quadros por segundo. Usei um monitor de rede e o TeamViewer ainda está sem lag a velocidades de 500 Kbps e 1 Mbps (atraso do software VNC por alguns segundos nessa taxa de transferência). Durante meutreeNo prompt do prompt de comando, o TeamViewer estava recebendo dados de entrada a uma taxa de 1 Mbps e ainda executando 5-6 fps. O VNC e a área de trabalho remota não fazem isso. Então como?

As respostas serão um pouco complicadas e intricadas, portanto , não publique seus US $ 0,02 se você só diz que é porque eles usam UDP em vez de TCP (você acreditaria que eles realmente usam TCP com o mesmo êxito).

Espero que haja um desenvolvedor do TeamViewer em algum lugar aqui no StackOverflow.

Respostas potenciais

Isso será atualizado assim que as pessoas responderem.

1. Meu pensamento é, antes de tudo, que o TeamViewer tenha um controle de rede muito bom. Por exemplo, eles dividem pacotes grandes até um pouco abaixo do tamanho da MTU e nunca perdem uma viagem. Eles provavelmente têm todos os tipos de ganchos sofisticados para detectar alterações na tela, além de comparações de imagem XOR extremamente rápidas.

A coisa mais fundamental aqui provavelmente é que você não deseja transmitir imagens estáticas, mas apenas alterações nas imagens, o que é essencialmente análogo ao fluxo de vídeo .

Meu melhor palpite é um algoritmo de compensação de movimento muito eficiente (e altamente especializado e otimizado), porque a maior parte da mudança real no uso genérico da área de trabalho é o movimento linear de elementos (rolagem de texto, movimentação de janelas etc. em oposição à transformação de elementos).

O desempenho do DirectX 3D de 1 FPS parece confirmar meu palpite até certo ponto.

levaria tempo para rotear pelos servidores do TeamViewer (o TeamViewer ignora os NATs simétricos corporativos, simplesmente fazendo proxy de tráfego nos servidores)

Você verá que o TeamViewer raramente precisa retransmitir tráfego por meio de seus próprios servidores. O TeamViewer penetra o NAT e as redes complicadas pelo NAT usando o percurso do NAT (acho que é um furo UDP , como o libjingle do Google ).

Eles usam seus próprios servidores para intermediar, a fim de fazer o handshake e a configuração da conexão, mas na maioria das vezes o relacionamento entre cliente e servidor será P2P (na melhor das hipóteses, quando o aperto de mão for bem-sucedido). Se o percurso da NAT falhar, o TeamViewer realmente retransmitirá o tráfego através de seus próprios servidores.

Só o vi fazer isso quando um cliente estava atrás de NAT duplo.

Resposta um pouco tardia, mas sugiro que você dê uma olhada em um projeto pouco conhecido no codeplex chamado ConferenceXP

O ConferenceXP é uma plataforma de pesquisa de código aberto que fornece conferência e colaboração simples, flexíveis e extensíveis usando redes de alta largura de banda e os recursos avançados de multimídia do Microsoft Windows. O ConferenceXP ajuda pesquisadores e educadores a desenvolver aplicativos e soluções inovadoras que apresentam áudio e vídeo com qualidade de transmissão para apoiar ambientes de colaboração distribuída em tempo real e ensino a distância.

A fonte completa (é enorme!) É fornecida. Ele implementa o protocolo RTP .

Parece realmente mais o streaming de vídeo do que o streaming de imagens, como alguém sugeriu. A compactação JPEG / PNG não é direcionada para esses tipos de velocidade, então esqueça-os.

Imagine ter um codec de gravação em seu sistema que pode gravar em tempo real um fluxo de vídeo recebido (sua tela). Um pouco como Fraps, talvez. Imagine um codec de reprodução de vídeo do outro lado (o cliente remoto). Como os gravadores HD podem fazer isso (grave ao vivo e até reproduza ao vivo a partir do mesmo HD), você deve fazer isso no final. O HD certamente não pode fornecer imagens mais rapidamente do que você pode ler sua tela, então esse não é o gargalo. O gargalo são os codecs de vídeo. Você encontrará o codificador muito mais problemático que o decodificador, pois todos os decodificadores são gratuitos.

Não estou dizendo que é simples; Eu próprio usei o DirectShow para codificar um arquivo de vídeo, e não é de longe o tempo real. Mas, dado o codec certo, estou convencido de que pode funcionar.

Meu palpite aleatório é: a TV usa x264 codec que possui uma licença comercial (caso contrário, o TeamViewer precisaria liberar o código-fonte). Em algum momento (há mais de 5 anos), lembro que o desenvolvedor principal do x264 escreveu um artigo sobre melhorias que ele fez para a codificação de baixo atraso (se você atrasar alguns codificadores de quadros pode compactar melhor), além de mencionar outras melhorias que foram relevante para uso semelhante ao TeamViewer. Nesse post, ele mencionou o terremoto por transmissão de vídeo sem problemas perceptíveis. Naquela época, eu tinha certeza de quem era o patrocinador dessas melhorias, pois o TeamViewer era praticamente a única opção naquele momento. x264 é uma implementação de código aberto do codec de vídeo H264 , e é incrivelmente boa implementação, é a melhor. Ao mesmo tempo, é extremamente bem otimizado. Provavelmente, devido à implementação extremamente boa do x264, você obtém resultados muito melhores com a TV com menor carga de CPU. O AnyDesk e o Chrome Remote Desk usam libvpx, que não é tão bom quanto x264 (otimização e qualidade de vídeo).

No entanto, não acho que o TeamView possa superar o RDP da Microsoft. Para mim, é o melhor, no entanto, funciona apenas entre PCs com Windows ou do Mac para o Windows. A TV funciona mesmo em celulares.

Atualização: o artigo foi escrito em janeiro de 2010, de modo que o trabalho foi realizado há aproximadamente 10 anos. Além disso, cometi um erro: ele jogou call of duty, não terremoto. Quando você postou sua pergunta, se meu palpite estiver correto, o TeamViewer utilizava esse trabalho há 3 anos. Leia a postagem do blog no arquivo da web: x264: a melhor plataforma de streaming de vídeo de baixa latência do mundo . Quando li o artigo em 2010, eu tinha certeza de que a "inicialização - que solicitou não ser nomeada" mencionada pelo autor era o TeamViewer.

Estranhamente. mas, na minha experiência, o TeamViewer não é mais rápido / responsivo que o VNC, apenas mais fácil de configurar. Eu tenho um par de win-boxen em que eu VNC via OpenVPN (para que haja outra camada aérea) e que esteja no Cable barato (512 up) e acho que o TightVNC configurado corretamente seja muito mais responsivo do que o TeamViewer ao mesmo boxen. RDP (naturalmente) ainda mais porque, em grande parte, envia comandos de desenho da GUI em vez de blocos de bitmap.

O que nos leva a:

1. Por que você não está usando o VNC? Há uma infinidade de soluções de código aberto, e Tight provavelmente está no topo de seu jogo agora.

2. Implementações avançadas de VNC usam compactação com perdas e isso parece alcançar melhores resultados do que a sua escolha de PNG. Além disso, o restante da carga útil do IIRC também é esmagado usando o zlib. Bothj Tight e UltraVNC têm algos muito otimizados, especialmente para janelas. Além disso, o Tight é de código aberto.

3. Se o win boxen for o seu destino principal, o RDP pode ser uma opção melhor e possui uma implementação de código-fonte aberto (rdesktop)

4. Se o * nix boxen é o seu destino principal, o NX pode ser uma opção melhor e possui uma implementação de código aberto (FreeNX, embora não tão otimizado quanto o produto proprietário da NoMachine).

Se a compactação JPEG for um problema de desempenho para o seu algo, tenho certeza de que a comparação de imagens ainda prejudicará o desempenho. Aposto que eles usam a compactação de melhor caso para cada situação específica, como perdas para quadros grandes, algumas rápidas e sujas sem perdas para os menores, comparam bits de imagens e enviam apenas diferenças de classificação e vários outros truques de otimização.

E muitos desses truques devem estar presentes no Tight> 2.0, mais uma vez, na minha experiência, supera o desempenho do TeamViewer, YMMV.

Além disso, a escolha de um tempo de execução compilado pelo JIT em vez de algo como C ++ pode levar um pouco da sua vantagem de desempenho, especialmente em máquinas com restrição de memória (muitos ajustes de desempenho vão para o banheiro quando o Windows começa a usar intensamente o arquivo de paginação). E você precisará de memória para manter os estados anteriores da imagem para comparação interna sobre o que o mirage DF fornece.