TeamViewer nasıl bu kadar hızlı?

Uzunluk için üzgünüm, biraz gerekli.

Giriş

Windows Vista / 7 için C # 4.0'da bir uzak masaüstü yazılımı (sadece eğlence için) geliştiriyorum. Temel engellerden geçtim: Sağlam bir UDP mesajlaşma sistemim, nispeten temiz program tasarımım var, bir ayna sürücüm var (DemoForge'dan ücretsiz DFMirage ayna sürücüsü) ve çalışıyoruz ve herkes için NAT geçişi uyguladım Simetrik NAT'lar dışındaki NAT türleri (kurumsal güvenlik duvarı durumlarında bulunur).

Ekran aktarımı / paylaşımı ile ilgili olarak, ayna sürücüsü sayesinde, değiştirilen ekran bölgelerinden otomatik olarak haberdar oluyorum ve ayna sürücüsünün sürekli değişen ekran bit eşlemini kendi bitmap'ime marshal edebilirim. Sonra ekran bölgesini PNG olarak sıkıştırıyorum ve sunucudan istemcime gönderiyorum. İşler oldukça iyi görünüyor, ama yeterince hızlı değil. VNC kadar yavaş (btw, VNC protokolünü kullanmıyorum, sadece özel bir amatör protokol).

En yavaş uzak masaüstü yazılımından en hızlıya kadar, liste genellikle tüm VNC benzeri uygulamalarda başlar, daha sonra Microsoft Windows Uzak Masaüstü'ne yükselir ... ve sonra ... TeamViewer. CrossLoop, LogMeIn hakkında pek emin değilim - Onları kullanmadım, ancak TeamViewer inanılmaz derecede hızlı. Kelimenin tam anlamıyla canlı. treeKomut İstemi'nde bir komut çalıştırdım ve 20 ms gecikmeyle güncellendi. Web'e dizüstü bilgisayarımdakinden birkaç milisaniyede daha yavaş göz atabilirim. Visual Studio'da dikey olarak kod kaydırma 50 ms gecikme süresi vardır. Tüm bunları gerçekleştirmek için TeamViewer'ın ekran aktarma çözümünün ne kadar sağlam olması gerektiğini düşünün.

VNC'ler, ekran değişimini ve kaba kuvvet ekran yakalama / en kötü durumlarını tespit etmek için anket tabanlı kancalar kullanır. En iyi ihtimalle DFMirage gibi bir ayna sürücüsü kullanıyorlar. Ben bu seviyedeyim. Ve RFB protokolü adı verilen bir şey kullanıyorlar.

Microsoft Windows Uzak Masaüstü görünüşe göre VNC'den bir adım daha yükseğe çıkıyor. StackOverflow'da bir yerden Windows Uzak Masaüstü'nün ekran bitmap'leri değil, gerçek çizim komutları gönderdiğini duydum. Bu oldukça parlak, çünkü sadece basit metin gönderebilir (bu dikdörtgeni bu koordinatta çizin ve bu gradyanla renklendirin)! Uzak Masaüstü gerçekten çok hızlı - ve evden çalışmanın standart yolu. Ve RDP protokolü denilen bir şey kullanıyor.

Şimdi TeamViewer benim için tam bir gizem. Görünüşe göre, Sürüm 2 için kaynak kodlarını yayınladılar (TeamViewer Şubat 2012 itibariyle Sürüm 7'dir). İnsanlar bunu okudu ve Sürüm 2'nin işe yaramaz olduğunu söyledi - otomatik NAT geçişi ile VNC üzerinde sadece birkaç iyileştirme olduğunu.

Ama Versiyon 7 ... şimdi çok hızlı. Yani, aslında Windows Uzak Masaüstü'nden daha hızlı. TeamViewer ile DirectX 3D oyunlar yayınladım (1 fps'de, ancak Windows Uzak Masaüstü DirectX'in çalışmasına bile izin vermiyor).

Bu arada, TeamViewer tüm bunları bir ayna sürücüsü olmadan yapar . Bir tane yüklemek için bir seçenek var ve sadece biraz daha hızlı hale geliyor.

Soru

Sorum şu: TeamViewer nasıl bu kadar hızlı?Bu mümkün olmamalı. 24 bit derinlikte bile 1920 x 1080 çözünürlüğe sahipseniz (16 bit derinlik fark edilir derecede çirkin olurdu), yine de 6.220.800 bayt ham. Libjpeg-turbo (büyük şirketler tarafından kullanılan en hızlı JPG sıkıştırma kitaplıklarından biri) bile kullanıldığında, 30KB'ye kadar sıkıştırılması (son derece cömert olalım), TeamViewer sunucuları üzerinden geçiş yapmak zaman alacaktır (TeamViewer, kurumsal Simetrik NAT'ları trafiği proxy üzerinden geçirerek zaman alacaktır sunucuları). Ve bu libjpeg-turbo sıkıştırmasının sıkıştırılması zaman alacaktı. Yüksek kaliteli JPG sıkıştırma benim için tam 1920 x 1080 ekran görüntüsü için 175 milisaniye sürüyor. Ve ana bilgisayarın bilgisayarı bir Atom işlemci kullanıyorsa bu sayı artar. TeamViewer'ın ekran aktarımını nasıl bu kadar iyi optimize ettiğini anlamıyorum. Yine, küçük boyutlu görüntüler oldukça sıkıştırılmış olabilir, ancak sıkıştırmak için en az on milisaniye sürün. Büyük boyutlu görüntülerin sıkıştırılması zaman almaz, ancak geçmesi uzun zaman alır. Her nasılsa, TeamViewer saniyede yaklaşık 20-25 kare elde etmek için tüm süreci tamamlar. Bir ağ monitörü kullandım ve TeamViewer 500 Kbps ve 1 Mbps hızlarında hala gecikmiyor (VNC yazılımı bu aktarım hızında birkaç saniye gecikiyor). SırasındatreeKomut İstemi testi, TeamViewer 1 Mbps hızında gelen verileri alıyordu ve hala 5-6 fps çalıştırıyordu. VNC ve uzak masaüstü bunu yapmaz. Nasıl?

Cevaplar biraz karmaşık ve karmaşık olacak, bu yüzden eğer sadece TCP yerine UDP kullandıklarını söyleyecekseniz, 0,02 $ 'ınızı göndermeyin (aslında TCP'yi başarılı bir şekilde kullandıklarına inanırsınız).

StackOverflow üzerinde bir yerde bir TeamViewer geliştirici olduğunu umuyorum.

Potansiyel Yanıtlar

Kullanıcılar yanıtladıktan sonra bunu güncelleyecek.

1. Düşüncelerim, her şeyden önce, TeamViewer'ın çok iyi bir ağ kontrolüne sahip olduğudur. Örneğin, büyük paketleri MTU boyutunun hemen altına bölerler ve asla bir yolculuğu boşa harcamazlar. Muhtemelen son derece hızlı XOR görüntü karşılaştırmalarıyla birlikte ekran değişikliklerini tespit etmek için her türlü süslü kancaya sahiptirler.

Buradaki en temel şey muhtemelen statik görüntüleri iletmek istemezsiniz, ancak yalnızca video akışına benzer olan görüntülerde değişiklik yapar .

Benim en iyi tahminim, bazı çok verimli (ve çok özel ve optimize edilmiş) hareket telafisi algoritmasıdır, çünkü genel masaüstü kullanımındaki gerçek değişikliklerin çoğu , öğelerin doğrusal hareketidir (kaydırma metni, hareketli pencereler vb. Öğelerin dönüştürülmesine karşı).

1 FPS'nin DirectX 3D performansı, tahminimi bir ölçüde doğruladı gibi görünüyor.

TeamViewer sunucuları arasında geçiş yapmak zaman alacaktır (TeamViewer, sunucuları üzerinden trafiği proxy ile kurumsal Simetrik NAT'ları atlar)

TeamViewer'ın nadiren kendi sunucuları üzerinden trafiği yayınlaması gerektiğini göreceksiniz. TeamViewer NAT geçişi kullanarak NAT ve NAT tarafından karmaşık ağlara nüfuz eder (sanırım Google'ın libjingle gibi UDP delici ).

El sıkışma ve bağlantı kurulumunu yapmak için kendi sunucularını orta adam olarak kullanıyorlar, ancak çoğu zaman istemci ve sunucu arasındaki ilişki P2P olacak (en iyi durum, el sıkışması başarılı olduğunda). NAT geçişi başarısız olursa, TeamViewer gerçekten kendi sunucuları üzerinden trafik iletir.

Ancak bunu bir istemci double-NAT'ın arkasındayken yaptığını gördüm.

Biraz geç cevap, ama ben KonferansPP adlı kodplex üzerinde iyi bilinmeyen bir projeye göz atmanızı öneririm

ConferenceXP, yüksek bant genişlikli ağları ve Microsoft Windows'un gelişmiş multimedya özelliklerini kullanarak basit, esnek ve genişletilebilir konferans ve işbirliği sağlayan açık kaynaklı bir araştırma platformudur. ConferenceXP, araştırmacıların ve eğitimcilerin gerçek zamanlı dağıtılmış işbirliği ve uzaktan eğitim ortamlarını desteklemek için yayın kalitesinde ses ve video içeren yenilikçi uygulamalar ve çözümler geliştirmelerine yardımcı olur.

Tam kaynak (çok büyük!) Sağlanır. RTP protokolünü uygular .

Gerçekten birisinin önerdiği gibi, görüntü akışından daha fazla video akışı gibi geliyor. JPEG / PNG sıkıştırması bu tür hızlar için hedeflenmediğinden, bunları unutun.

Sisteminizde, gelen bir video akışını (ekranınızı) gerçek zamanlı olarak kaydedebilen bir kayıt codec bileşenine sahip olduğunuzu düşünün. Belki biraz Fraps gibi. Sonra diğer tarafta (uzak istemci) bir video oynatma codec bileşeni düşünün. HD kaydediciler bunu yapabildiğinden (aynı HD'den canlı olarak kayıt yapın ve hatta canlı olarak oynatın). HD, elbette ekranınızı okuyabileceğinizden daha hızlı görüntü sağlayamaz, bu nedenle bu darboğaz değildir. Darboğaz video kodekleri. Tüm kod çözücüler çoğunlukla ücretsiz olduğu için kodlayıcıyı kod çözücüden çok daha fazla sorun bulacaksınız.

Basit demiyorum; Ben kendim bir video dosyasını kodlamak için DirectShow kullandım ve bu şimdiye kadar gerçek zamanlı değil. Ama doğru codec bileşeni göz önüne alındığında çalışabileceğine ikna oldum.

Rastgele tahminim: TV, ticari lisansa sahip x264 kodek kullanıyor (aksi takdirde TeamViewer kaynak kodunu yayınlamak zorunda kalacak). Bir noktada (5 yıldan fazla önce), x264'ün ana geliştiricisinin düşük gecikmeli kodlama için yaptığı iyileştirmeler hakkında bir makale yazdığını hatırlıyorum (birkaç kare kodlayıcı tarafından daha iyi sıkıştırabilirseniz), ayrıca diğer bazı iyileştirmelerden bahsetti. TeamViewer benzeri kullanım için uygun. Bu yazıda, belirgin bir sorun olmadan video akışı üzerinde deprem oynadığından bahsetti. O zamanlar TeamViewer'ın o zamanlar için tek seçenek olduğu için bu gelişmelerin sponsoru kim olduğundan emindim. x264, H264 video codec bileşeninin açık kaynaklı bir uygulamasıdırve bu inanılmaz derecede iyi bir uygulama, en iyisi. Aynı zamanda son derece iyi optimize edilmiştir. Büyük olasılıkla x264'ün çok iyi uygulanması nedeniyle, daha düşük CPU yükünde TV ile çok daha iyi sonuçlar elde edersiniz. AnyDesk ve Chrome Uzaktan Masaüstü, x264 (optimizasyon ve video kalitesi açısından) kadar iyi olmayan libvpx kullanır.

Ancak, TeamView'in microsoft'un RDP'sini yenebileceğini düşünmüyorum. Benim için en iyisi, ancak Windows PC'ler veya Mac'ten Windows'a kadar çalışıyor. TV cep telefonlarından bile çalışır.

Güncelleme: makale Ocak 2010'da yazıldı, böylece iş yaklaşık 10 yıl önce yapıldı. Ayrıca, bir hata yaptım: deprem değil, görev çağrısı oynadı. Sorunuzu yayınladığınızda, tahminim doğruysa, TeamViewer bu işi 3 yıldır kullanıyordu. Bu blog gönderisini web arşivinden okuyun: x264: dünyanın en iyi düşük gecikmeli video akış platformu . Makaleyi 2010 yılında tekrar okuduğumda, yazarın bahsettiği "başlangıç ​​- isimlendirilmesini istemeyen" in TeamViewer olduğundan emindim.

İşin garibi. ancak tecrübelerime göre TeamViewer VNC'den daha hızlı / daha duyarlı değil, sadece kurulumu daha kolay. OpenVPN içine VNC kazandığım bir çift kazan-box'ım var (bu yüzden başka bir havai katman var) ve bu ucuz Kabloda (512 yukarı) ve TightVNC'yi TeamViewer'dan aynı kutuya çok daha duyarlı olacak şekilde düzgün bir şekilde ayarladım. RDP (doğal olarak) daha da büyüktür, çünkü büyük ölçüde bitmap döşemeleri yerine GUI çizim komutları gönderir.

Bu da bizi şuraya getiriyor:

1. Neden VNC kullanmıyorsunuz? Çok sayıda açık kaynaklı çözüm var ve Tight muhtemelen şu anda oyunun başında.

2. Gelişmiş VNC uygulamaları kayıplı sıkıştırma kullanır ve bu, PNG seçiminizden daha iyi sonuçlara ulaşıyor gibi görünüyor. Ayrıca, yükün geri kalanı IIRC de zlib kullanılarak ezilir. Bothj Tight ve UltraVNC, özellikle pencereler için çok optimize edilmiş algoslara sahiptir. Üstelik Sıkı açık kaynak.

3. Kazanmak boxen birincil hedef ise RDP daha iyi bir seçenek olabilir ve bir açık kaynak uygulaması (rdesktop)

4. * Nix boxen birincil hedefinizse NX daha iyi bir seçenek olabilir ve açık kaynak kodlu bir uygulamaya sahip olabilir (FreeNX, NoMachine'in tescilli ürünü kadar optimize edilmemesine rağmen).

JPEG sıkıştırmak algo için bir performans sorunuysa, görüntü karşılaştırmasının yine de biraz performans alacağından eminim. Bahse girerim, büyük çerçeveler için kayıplı, daha küçük olanlar için kayıpsız, hızlı ve kirli bazı stajyerler için en iyi durum sıkıştırmasını kullanırlar, görüntülerin parçalarını karşılaştırırlar ve sadece diğer optimizasyon hilelerinin çeşitlerini ve gruplarını gönderirler.

Ve bu hilelerin birçoğu Tight> 2.0'da mevcut olmalı, çünkü deneyimime göre TeamViewer performans wyse YMMV'nin cehennemi yeniyor.

Ayrıca, C ++ gibi bir şey üzerinde bir JIT derlenmiş çalışma zamanı seçimi, özellikle bellek kısıtlı makinelerde bir performans dilimi alabilir (pencereler sayfa dosyasını yoğun bir şekilde kullanmaya başladığında birçok performans ayarı tuvalete gider). Ve önceki görüntü durumlarını DF serapının size verdiği şeyin üzerinde dahili karşılaştırma için tutmak için belleğe ihtiyacınız olacak.