Bagaimana TeamViewer begitu cepat?


158

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.

1
Sudahkah Anda mencoba rekayasa balik protokol? (Tampaknya mereka menggunakan PKI untuk pengaturan sesi sehingga mungkin tidak mudah, jika layak sama sekali)
Kimvais

3
Mengharapkan jawaban atas pertanyaan ini bergantung pada kesediaan perusahaan untuk membagikan rahasia dagang mereka. Yang utama pada saat itu, yang membuat mereka dalam bisnis. Anda mendapat jawaban yang kuat, satu-satunya cara untuk mendapatkan jawaban ya adalah dengan menelepon mereka. Tanyakan tentang paten mereka, kurasa.
Hans Passant

1
Masuk akal. Saya akan menunggu saran lainnya.
Jason

4
Itu aneh. Saya tidak menemukan ini lebih cepat dari desktop jarak jauh - jauh dari itu! RDP untuk saya adalah WAY lebih cepat - lebih seperti menggunakan mesin virtual lokal. Apakah Anda benar-benar menguji melalui Internet atau pada beberapa jenis pengaturan lokal? Sudahkah Anda membuka firewall Anda untuk mengizinkan koneksi teamviewer langsung?
NickG

1
Sepertinya Anda hanya menguji pada jaringan lokal. Dari pengalaman saya sepertinya TeamViewer menggunakan kompresi lossy (melalui koneksi lambat kualitasnya kadang-kadang benar-benar nad). Mungkinkah VNC menggunakan lebih banyak waktu pemrosesan dan bandwidth dibandingkan TeamViewer dan sebaliknya? Kemudian tergantung pada lingkungan Anda (kekuatan prosesor pada kedua mesin dan kualitas tautan jaringan) kadang-kadang VNC mungkin lebih cepat, kadang-kadang TeamViewer.
Axel

Jawaban:


79

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.


1
Ada codec tangkapan layar TechSmith gratis. Kompres secara efisien dan tanpa kehilangan.
sinni800

25

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.


5
Firewall perusahaan sangat sedikit yang memungkinkan NAT traversal atau UPnP dan itulah pasar utama TeamViewers. Saya menduga sebagian besar koneksi disampaikan dalam kehidupan nyata ...
NickG

20
Terkadang Anda dapat "mendorong jalan Anda" bahkan melalui firewall perusahaan / NAT - skype cukup bagus dalam hal ini. Pada dasarnya, klien A mengirimkan permintaan yang akan diblokir oleh NAT / firewall, dan memberi tahu server eksternal tentang port yang digunakan. Klien B kemudian mendapatkan informasi tentang port dari server eksternal dan menghubungkan ke port itu. NAT A akan menganggapnya sebagai balasan untuk permintaan pertama (yang benar-benar diblokir oleh NAT B) dan membiarkannya masuk. Ketika A menjawab koneksi itu, NAT B akan membiarkannya lewat karena koneksi diprakarsai oleh B. => Anda memiliki koneksi.
Axel

Banyak perusahaan hanya memiliki proksi http dan tidak ada NAT dan perutean ke luar sama sekali. Ada terowongan Teamviewer melalui http port 443. Thats tcp dan teamviewer MASIH sangat cepat.
sinni800

1
@Daniel: mulai dengan membaca artikel tentang "lubang meninju UDP" dan "STUN" di wikipedia.
Axel

1
@DanielLiuzzi Google opensource libjingle berisi lubang puncher: developers.google.com/talk/libjingle/developer_guide . Mereka dulu (dan mungkin masih melakukannya, saya tidak tahu) menggunakannya untuk GChat, Hangouts dll.
Jamie Edwards

14

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 .


1
Ini luar biasa! Saya mengunduh binari tetapi sepertinya tidak ada orang lain yang online di kamar lain. Saya harus menguji dengan komputer lain nanti. Terimakasih banyak!
Jason

6

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.


2

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.


Apakah Anda yakin AnyDesk menggunakan libvpx? Mereka mengiklankan DeskRT sebagai codec mereka sendiri yang dirancang khusus untuk lingkungan desktop.
tunafish24

0

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.


9
Itu mengganggu saya ketika orang menyarankan VNC sebagai alternatif untuk TeamViewer. Saya menyarankan bahwa mungkin Anda belum menggunakan TeamViewer untuk mengetahui kelebihan yang diberikannya dari perangkat lunak bebas seperti VNC? VNC mungkin baik-baik saja untuk mengakses komputer Anda sendiri, tetapi untuk berbagi layar dan hosting dll, ia bahkan tidak samar-samar membandingkannya. Terakhir kali saya memeriksa, VNC bahkan tidak memiliki server relay terbuka, sehingga bahkan tidak akan berfungsi dalam 95% kasus karena akan diblokir (kecuali jika Anda memiliki dan mengoperasikan firewall atau server Anda sendiri).
NickG

5
Diskusi ini bukan tentang alat klien VNC versus TeamViewer (yang saya gunakan sangat banyak setiap hari, saya mengoperasikan banyak firewall dan server dan memiliki beberapa). Diskusi adalah tentang kerja internal protokol dan penerapannya
Bojan Markovic

Baru saja mencoba UltraVNC dan TeamViewer melalui jaringan 3G yang lambat, dan perbedaan kinerja sangat besar. Dengan UltraVNC, saya mengalami penundaan 1-2 detik antara mengklik sesuatu di komputer jarak jauh dan melihat responsnya. Lambat agar bermanfaat. TeamViewer jauh lebih cepat (secepat RDP) dan cukup cepat untuk dapat digunakan pada tautan yang sama.
John Reynolds

2
Ya. Saya harus setuju dengan NickG. SIAPA PUN yang masih berusaha menempatkan VNC secepat TeamViewer harus belum pernah menggunakan TeamViewer. Penegasan yang konyol. Jawaban ini seharusnya tidak dipilih. Saya telah menggunakan semua trik yang disarankan dalam posting ini dengan VNC, dan bahkan tidak jauh dibandingkan dengan kinerja TeamViewer.
naksir

Saya harus masuk hanya untuk memilih jawaban ini. Saya menggunakan NoMachine, VNC, apa pun yang ada di sana, dan bahkan spasi, Wired XDisplay di Android, dan Anda tahu apa? Teamviewer adalah yang tercepat, jauh lebih cepat daripada streaming video spacedesk. Semua orang menyarankan VNC = tidak pernah menggunakan Teamviewer.
Ken Le
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.