Bagaimana TeamViewer begitu cepat?

Maaf tentang panjangnya, itu agak perlu.

pengantar

Saya sedang mengembangkan perangkat lunak desktop jarak jauh (hanya untuk bersenang-senang) di C # 4.0 untuk Windows Vista / 7. Saya telah melewati rintangan dasar: Saya memiliki sistem pesan UDP yang kuat, desain program yang relatif bersih, saya punya driver cermin (driver cermin DFMirage gratis dari DemoForge) aktif dan berjalan, dan saya telah menerapkan NAT traversal untuk semua Jenis NAT kecuali NAT Simetris (ada dalam situasi firewall perusahaan).

Mengenai transfer / berbagi layar, terima kasih kepada driver cermin, saya secara otomatis diberitahu tentang daerah layar yang berubah dan saya dapat dengan mudah menyusun bitmap layar driver cermin yang selalu berubah ke bitmap saya sendiri. Lalu saya kompres wilayah layar sebagai PNG dan mengirimkannya dari server ke klien saya. Hal-hal terlihat cukup bagus, tetapi tidak cukup cepat. Ini sama lambatnya dengan VNC (btw, saya tidak menggunakan protokol VNC, hanya protokol amatir khusus).

Dari perangkat lunak desktop jarak jauh paling lambat hingga yang tercepat, daftar biasanya dimulai dari semua implementasi mirip VNC, kemudian naik ke Microsoft Windows Remote Desktop ... dan kemudian ... TeamViewer. Tidak begitu yakin tentang CrossLoop, LogMeIn - Saya belum pernah menggunakannya, tetapi TeamViewer sangat cepat. Secara harfiah hidup. Saya menjalankan treeperintah pada Command Prompt dan diperbarui dengan penundaan 20 ms. Saya dapat menelusuri web hanya beberapa milidetik lebih lambat dari pada laptop saya. Kode gulir secara vertikal di Visual Studio memiliki jeda waktu 50 ms. Pikirkan tentang seberapa kuat solusi transfer layar TeamViewer harus menyelesaikan semua ini.

VNC menggunakan kait berbasis jajak pendapat untuk mendeteksi perubahan layar dan menangkap / membandingkan layar dengan kasar secara terburuk. Yang terbaik, mereka menggunakan driver cermin seperti DFMirage. Saya di level ini. Dan mereka menggunakan sesuatu yang disebut protokol RFB.

Microsoft Windows Remote Desktop tampaknya berjalan satu langkah lebih tinggi dari VNC. Saya mendengar, dari suatu tempat di StackOverflow, bahwa Windows Remote Desktop tidak mengirim bitmap layar, tetapi perintah menggambar yang sebenarnya. Itu cukup brilian, karena hanya bisa mengirim teks sederhana (gambar kotak ini pada koordinat ini dan warnai dengan gradien ini)! Remote Desktop sangat cepat - dan ini adalah cara standar untuk bekerja dari rumah. Dan ia menggunakan sesuatu yang disebut protokol RDP.

Sekarang TeamViewer adalah misteri bagi saya. Rupanya, mereka merilis kode sumber mereka untuk Versi 2 (TeamViewer adalah Versi 7 pada Februari 2012). Orang-orang telah membacanya dan mengatakan bahwa Versi 2 tidak berguna - bahwa itu hanya beberapa perbaikan dari VNC dengan NAT traversal otomatis.

Tapi Versi 7 ... sekarang sangat cepat. Maksud saya, ini sebenarnya lebih cepat dari Windows Remote Desktop. Saya telah mengalirkan game DirectX 3D dengan TeamViewer (pada 1 fps, tetapi Windows Remote Desktop bahkan tidak mengizinkan DirectX untuk menjalankan).

Omong-omong, TeamViewer melakukan semua ini tanpa driver cermin. Ada opsi untuk menginstal satu, dan itu mendapat sedikit lebih cepat.

Pertanyaan

Pertanyaan saya adalah, bagaimana TeamViewer begitu cepat?Itu tidak mungkin. Jika Anda memiliki resolusi 1920 x 1080 bahkan kedalaman 24 bit (kedalaman 16 bit akan terasa jelek), itu masih 6.220.800 byte mentah. Bahkan dengan menggunakan libjpeg-turbo (salah satu pustaka kompresi JPG tercepat yang digunakan oleh perusahaan besar), mengompresnya menjadi 30KB (mari kita menjadi sangat murah hati), akan membutuhkan waktu untuk merutekan melalui server TeamViewer (TeamViewer mem-bypass Symmetric NATs perusahaan hanya dengan mem-proxy lalu lintas melalui server mereka). Dan kompresi libjpeg-turbo akan membutuhkan waktu untuk dikompres. Kompresi JPG berkualitas tinggi membutuhkan 175 milidetik untuk screenshot 1920 hingga 1080 penuh untuk saya. Dan angka itu naik jika komputer host menjalankan prosesor Atom. Saya tidak mengerti bagaimana TeamViewer telah mengoptimalkan transfer layar mereka dengan sangat baik. Sekali lagi, gambar ukuran kecil mungkin sangat terkompresi, tetapi gunakan setidaknya puluhan milidetik untuk mengompres. Gambar ukuran besar tidak membutuhkan waktu untuk dikompres, tetapi membutuhkan waktu lama untuk melewatinya. Entah bagaimana, TeamViewer menyelesaikan seluruh proses ini untuk mendapatkan sekitar 20-25 frame per detik. Saya telah menggunakan monitor jaringan, dan TeamViewer masih tertinggal dengan kecepatan 500 Kbps dan 1 Mbps (perangkat lunak VNC tertinggal selama beberapa detik pada kecepatan transfer itu). Selama sayatreeCommand Prompt test, TeamViewer menerima data masuk dengan kecepatan 1 Mbps dan masih menjalankan 5-6 fps. VNC dan remote desktop tidak melakukan itu. Jadi bagaimana?

Jawabannya akan sedikit rumit dan rumit, jadi tolong jangan posting $ 0,02 Anda jika Anda hanya akan mengatakan itu karena mereka menggunakan UDP bukan TCP (apakah Anda yakin mereka benar-benar menggunakan TCP sama berhasilnya).

Saya berharap ada pengembang TeamViewer di StackOverflow.

Jawaban Potensial

Akan memperbarui ini setelah orang membalas.

1. Pikiran saya, pertama-tama, TeamViewer memiliki kontrol jaringan yang sangat baik. Sebagai contoh, mereka membagi paket besar menjadi tepat di bawah ukuran MTU dan tidak pernah membuang-buang perjalanan. Mereka mungkin memiliki segala macam kait mewah untuk mendeteksi perubahan layar bersama dengan perbandingan gambar XOR yang sangat cepat.

Hal yang paling mendasar di sini mungkin adalah Anda tidak ingin mengirimkan gambar statis tetapi hanya mengubah gambar, yang pada dasarnya analog dengan aliran video .

Dugaan terbaik saya adalah beberapa algoritma kompensasi gerak yang sangat efisien (dan sangat khusus dan dioptimalkan), karena sebagian besar perubahan aktual dalam penggunaan desktop generik adalah pergerakan linear elemen (menggulir teks, memindahkan jendela, dll. Menentang transformasi elemen).

Kinerja 3D DirectX 1 FPS tampaknya mengkonfirmasi dugaan saya sampai batas tertentu.

akan membutuhkan waktu untuk merutekan melalui server TeamViewer (TeamViewer memintas NAT Symmetric perusahaan dengan hanya mem-proxy lalu lintas melalui server mereka)

Anda akan menemukan bahwa TeamViewer jarang perlu menyampaikan lalu lintas melalui server mereka sendiri. TeamViewer menembus NAT dan jaringan yang rumit oleh NAT menggunakan NAT traversal (saya pikir itu adalah lubang-meninju UDP , seperti libjingle Google ).

Mereka memang menggunakan server mereka sendiri untuk orang tengah untuk melakukan handshake dan koneksi set-up, tetapi sebagian besar waktu hubungan antara klien dan server adalah P2P (kasus terbaik, ketika berjabat tangan berhasil). Jika NAT traversal gagal, maka TeamViewer memang akan menyampaikan lalu lintas melalui server sendiri.

Saya hanya pernah melihatnya melakukan ini ketika klien berada di belakang NAT ganda.

Jawabannya agak terlambat, tapi saya sarankan Anda melihat proyek yang tidak terkenal pada codeplex yang disebut ConferenceXP

ConferenceXP adalah platform penelitian sumber terbuka yang menyediakan konferensi dan kolaborasi sederhana, fleksibel, dan dapat diperluas menggunakan jaringan bandwidth tinggi dan kemampuan multimedia canggih dari Microsoft Windows. ConferenceXP membantu para peneliti dan pendidik mengembangkan aplikasi dan solusi inovatif yang menampilkan audio dan video berkualitas siaran untuk mendukung kolaborasi yang didistribusikan secara real-time dan lingkungan pembelajaran jarak jauh.

Sumber lengkap (sangat besar!) Disediakan. Ini mengimplementasikan protokol RTP .

Memang terdengar seperti streaming video lebih dari streaming gambar, seperti yang disarankan seseorang. Kompresi JPEG / PNG tidak ditargetkan untuk jenis kecepatan ini, jadi lupakan saja.

Bayangkan memiliki codec rekaman di sistem Anda yang dapat merekam secara realtime aliran video yang masuk (layar Anda). Agak seperti Fraps mungkin. Kemudian bayangkan codec pemutaran video di sisi lain (klien jarak jauh). Karena perekam HD dapat melakukannya (merekam langsung dan bahkan memutar langsung dari HD yang sama), Anda juga harus, pada akhirnya. HD pasti tidak dapat mengirimkan gambar lebih cepat daripada Anda dapat membaca tampilan Anda, jadi itu bukan hambatan. Hambatannya adalah codec video. Anda akan menemukan encoder lebih banyak masalah daripada decoder, karena semua decoder sebagian besar gratis.

Saya tidak mengatakan itu sederhana; Saya sendiri telah menggunakan DirectShow untuk menyandikan file video, dan sejauh ini tidak realtime. Tetapi mengingat codec yang tepat saya yakin itu bisa bekerja.

Tebakan acak saya adalah: TV menggunakan x264 codec yang memiliki lisensi komersial (jika tidak TeamViewer harus melepaskan kode sumbernya). Pada beberapa titik (lebih dari 5 tahun yang lalu), saya ingat pengembang utama x264 menulis sebuah artikel tentang perbaikan yang ia buat untuk penyandian penundaan yang rendah (jika Anda menunda dengan beberapa frame penyandi dapat memampatkan lebih baik), ditambah ia menyebutkan beberapa perbaikan lain yang relevan untuk penggunaan seperti TeamViewer. Dalam posting itu ia menyebutkan bermain gempa di atas aliran video tanpa masalah yang nyata. Saat itu saya agak yakin siapa yang menjadi sponsor dari perbaikan ini, karena TeamViewer adalah satu-satunya pilihan saat itu. x264 adalah implementasi open source dari codec video H264, dan ini implementasi yang luar biasa baik, ini yang terbaik. Pada saat yang sama itu dioptimalkan dengan sangat baik. Kemungkinan besar karena implementasi x264 yang sangat baik Anda mendapatkan hasil yang lebih baik dengan TV pada beban CPU yang lebih rendah. AnyDesk dan Chrome Remote Desk menggunakan libvpx, yang tidak sebagus x264 (pengoptimalan dan kualitas video).

Namun, saya tidak berpikir TeamView dapat mengalahkan RDP microsoft. Bagi saya ini adalah yang terbaik, namun hanya berfungsi di antara PC windows atau dari Mac ke Windows saja. TV bekerja bahkan dari ponsel.

Pembaruan: artikel ditulis pada Januari 2010, sehingga pekerjaan dilakukan sekitar 10 tahun yang lalu. Juga, saya membuat kesalahan: dia memainkan panggilan tugas, bukan gempa. Ketika Anda memposting pertanyaan Anda, jika tebakan saya benar, TeamViewer telah menggunakan pekerjaan itu selama 3 tahun. Baca posting blog itu dari arsip web: x264: platform streaming video latensi rendah terbaik di dunia . Ketika saya membaca artikel itu pada tahun 2010, saya yakin bahwa "startup - yang meminta untuk tidak disebutkan namanya" yang penulis sebutkan adalah TeamViewer.

Anehnya. tetapi dalam pengalaman saya TeamViewer tidak lebih cepat / lebih responsif daripada VNC, hanya lebih mudah untuk setup. Saya punya beberapa win-boxen yang saya VNC lebih dari OpenVPN ke (jadi ada lapisan overhead lainnya) dan itu pada Cable murah (512 ke atas) dan saya menemukan pengaturan TightVNC dengan benar menjadi jauh lebih responsif daripada TeamViewer ke boxen yang sama. RDP (secara alami) bahkan lebih karena sebagian besar mengirimkan perintah menggambar GUI bukan ubin bitmap.

Yang membawa kita ke:

1. Mengapa Anda tidak menggunakan VNC? Ada banyak solusi open source, dan Ketat mungkin di atas permainan itu sekarang.

2. Implementasi VNC canggih menggunakan kompresi lossy dan yang tampaknya mencapai hasil yang lebih baik daripada PNG pilihan Anda. Selain itu, IIRC sisa muatannya juga tergencet menggunakan zlib. Bothj Tight dan UltraVNC memiliki algos yang sangat optimal, terutama untuk windows. Selain itu Ketat adalah open-source.

3. Jika win boxen adalah target utama Anda, RDP mungkin merupakan opsi yang lebih baik, dan memiliki implementasi opensource (rdesktop)

4. Jika * nix boxen adalah target utama Anda, NX mungkin merupakan opsi yang lebih baik dan memiliki implementasi open source (FreeNX, meskipun tidak dioptimalkan seperti produk eksklusif NoMachine).

Jika mengompresi JPEG adalah masalah kinerja untuk algo Anda, saya cukup yakin bahwa perbandingan gambar masih akan menghilangkan beberapa kinerja. Saya berani bertaruh mereka menggunakan kompresi kasus terbaik untuk setiap situasi tertentu yaitu lossy untuk frame besar, beberapa internall cepat dan kotor losless untuk yang lebih kecil, membandingkan bit gambar dan hanya mengirim berbagai jenis dan banyak trik optimasi lainnya.

Dan banyak dari trik itu harus ada di Ketat> 2.0 karena sekali lagi, menurut pengalaman saya, ini mengalahkan kinerja TeamViewer, YMMV.

Juga pilihan runtime yang dikompilasi JIT atas sesuatu seperti C ++ mungkin mengambil sepotong dari tepi kinerja Anda, terutama di mesin memori terbatas (banyak penyetelan kinerja pergi ke toilet ketika windows mulai menggunakan pagefile secara intensif). Dan Anda akan membutuhkan memori untuk menjaga status gambar sebelumnya untuk perbandingan internal di atas apa yang diberikan DF mirage kepada Anda.