Jak działa TeamViewer tak szybko?

158

Przepraszam za długość, to trochę konieczne.

Wprowadzenie

Tworzę oprogramowanie do zdalnego pulpitu (dla zabawy) w C # 4.0 dla Windows Vista / 7. Przeszedłem przez podstawowe przeszkody: mam niezawodny system przesyłania wiadomości UDP, stosunkowo czysty projekt programu, mam uruchomiony i działający sterownik lustrzany (bezpłatny sterownik lustrzany DFMirage z DemoForge) i zaimplementowałem przechodzenie NAT dla wszystkich Typy NAT z wyjątkiem symetrycznych NAT (obecnych w firmowych firewallach).

Jeśli chodzi o przesyłanie / udostępnianie ekranu, dzięki sterownikowi lustrzanemu, jestem automatycznie powiadamiany o zmienionych regionach ekranu i mogę po prostu przenieść stale zmieniającą się mapę bitową ekranu sterownika lustrzanego do mojej własnej mapy bitowej. Następnie kompresuję obszar ekranu jako plik PNG i wysyłam go z serwera do mojego klienta. Wszystko wygląda całkiem nieźle, ale nie jest wystarczająco szybkie. Jest tak samo wolny jak VNC (przy okazji, nie używam protokołu VNC, tylko niestandardowy protokół amatorski).

Od najwolniejszego oprogramowania do zdalnego pulpitu do najszybszego, lista zwykle zaczyna się we wszystkich implementacjach podobnych do VNC, następnie pnie się do Microsoft Windows Remote Desktop… a potem… TeamViewer. Nie jestem pewien co do CrossLoop, LogMeIn - nie korzystałem z nich, ale TeamViewer jest niesamowicie szybki. Dosłownie na żywo. Uruchomiłem treepolecenie w wierszu polecenia i zaktualizowałem je z opóźnieniem 20 ms. Mogę przeglądać Internet o kilka milisekund wolniej niż na moim laptopie. Przewijanie kodu w pionie w programie Visual Studio ma 50 ms opóźnienia. Pomyśl o tym, jak solidne musi być rozwiązanie do przenoszenia ekranu TeamViewer, aby to wszystko osiągnąć.

VNC używają haków opartych na ankietach do wykrywania zmian ekranu i przechwytywania / porównywania ekranu brutalnej siły w najgorszym przypadku. W najlepszym przypadku używają sterownika lustrzanego, takiego jak DFMirage. Jestem na tym poziomie. I używają czegoś, co nazywa się protokołem RFB.

Pulpit zdalny Microsoft Windows najwyraźniej idzie o krok wyżej niż VNC. Słyszałem gdzieś na StackOverflow, że Pulpit zdalny systemu Windows nie wysyła bitmap ekranu, ale rzeczywiste polecenia rysowania. To całkiem genialne, ponieważ może po prostu wysłać prosty tekst (narysuj ten prostokąt na tej współrzędnej i pokoloruj go tym gradientem)! Pulpit zdalny jest naprawdę szybki - i jest to standardowy sposób pracy z domu. I używa czegoś, co nazywa się protokołem RDP.

Teraz TeamViewer jest dla mnie kompletną tajemnicą. Najwyraźniej wydali swój kod źródłowy dla wersji 2 (TeamViewer jest wersją 7 od lutego 2012). Ludzie to przeczytali i powiedzieli, że wersja 2 jest bezużyteczna - to tylko kilka ulepszeń w stosunku do VNC z automatycznym przechodzeniem NAT.

Ale wersja 7 ... jest teraz absurdalnie szybka. To znaczy, jest faktycznie szybszy niż Pulpit zdalny systemu Windows. Strumieniowałem gry DirectX 3D z TeamViewer (przy 1 fps, ale Pulpit zdalny Windows nie pozwala nawet na uruchomienie DirectX).

Nawiasem mówiąc, TeamViewer robi to wszystko bez sterownika lustrzanego. Istnieje opcja zainstalowania jednego i robi się to trochę szybciej.

Pytanie

Moje pytanie brzmi: w jaki sposób TeamViewer jest tak szybki?To nie może być możliwe. Jeśli masz rozdzielczość 1920 na 1080 przy nawet 24-bitowej głębi (16-bitowa głębia byłaby zauważalnie brzydka), to nadal 6220800 bajtów surowych. Nawet użycie libjpeg-turbo (jednej z najszybszych bibliotek kompresji JPG używanych przez duże korporacje), skompresowanie jej do 30 KB (bądźmy niezwykle hojni), zajęłoby trochę czasu, aby przejść przez serwery TeamViewer (TeamViewer omija korporacyjne Symmetric NAT, po prostu przekazując ruch przez ich serwery). Kompresja libjpeg-turbo zajęłaby trochę czasu. Wysokiej jakości kompresja JPG zajmuje dla mnie 175 milisekund dla pełnego zrzutu ekranu 1920 na 1080. Ta liczba rośnie, jeśli komputer hosta obsługuje procesor Atom. Po prostu nie rozumiem, w jaki sposób TeamViewer tak dobrze zoptymalizował przesyłanie ekranu. Obrazy o małym rozmiarze mogą być mocno skompresowane, ale kompresja zajmuje co najmniej kilkadziesiąt milisekund. Obrazy o dużym rozmiarze nie wymagają czasu na kompresję, ale przejście przez nie zajmuje dużo czasu. W jakiś sposób TeamViewer kończy cały proces, uzyskując około 20-25 klatek na sekundę. Użyłem monitora sieci, a TeamViewer nadal działa bez opóźnień przy prędkościach 500 Kb / s i 1 Mb / s (opóźnienie oprogramowania VNC przez kilka sekund przy tej szybkości transferu). Podczas mojegotreeTest wiersza polecenia, TeamViewer odbierał dane przychodzące z szybkością 1 Mb / si nadal działał 5-6 fps. VNC i zdalny pulpit tego nie robią. Więc jak?

Odpowiedzi będą nieco skomplikowane i zawiłe, więc nie wysyłaj swoich 0,02 USD, jeśli chcesz tylko powiedzieć, że to dlatego, że używają UDP zamiast TCP (czy uwierzyłbyś, że faktycznie używają TCP tak samo skutecznie).

Mam nadzieję, że gdzieś tutaj w StackOverflow jest programista TeamViewer.

Potencjalne odpowiedzi

Zaktualizuje to, gdy ludzie odpowiedzą.

  1. Przede wszystkim myślę, że TeamViewer ma bardzo dobrą kontrolę sieci. Na przykład dzielą duże pakiety do rozmiaru tuż poniżej MTU i nigdy nie marnują podróży. Prawdopodobnie mają różnego rodzaju fantazyjne zaczepy do wykrywania zmian na ekranie, a także niezwykle szybkie porównania obrazów XOR.
Jason
źródło
1
Czy próbowałeś odtworzyć protokół? (Wygląda na to, że używają PKI do konfiguracji sesji, więc może to nie być łatwe, jeśli w ogóle możliwe)
Kimvais
3
Oczekiwanie odpowiedzi na to pytanie zależy od chęci firmy do ujawnienia swojej tajemnicy handlowej. To ich główny, który utrzymuje ich w biznesie. Masz zdecydowane „nie”, jedynym sposobem na uzyskanie odpowiedzi jest wezwanie ich. Chyba zapytaj o ich patenty.
Hans Passant
1
Ma sens. Poczekam na więcej sugestii.
Jason
4
To dziwne. Sam nie uważam, że jest szybszy niż zdalny pulpit - daleki od tego! RDP jest dla mnie DUŻO szybszy - bardziej przypomina korzystanie z lokalnej maszyny wirtualnej. Czy faktycznie testujesz przez Internet lub na jakiejś konfiguracji lokalnej? Czy otworzyłeś zaporę ogniową, aby umożliwić bezpośrednie połączenia Teamviewer?
NickG
1
Wygląda na to, że testujesz tylko w sieci lokalnej. Z mojego doświadczenia wynika, że ​​TeamViewer używa kompresji stratnej (przy wolnym połączeniu jakość jest czasami naprawdę niska). Czy to możliwe, że VNC zużywa więcej czasu przetwarzania i mniejszą przepustowość niż TeamViewer i odwrotnie? Następnie w zależności od środowiska (moc procesora na obu maszynach i jakość łącza sieciowego) czasami VNC może być szybsze, czasami TeamViewer.
Axel

Odpowiedzi:

79

Najbardziej podstawową rzeczą jest prawdopodobnie to, że nie chcesz przesyłać statycznych obrazów, a jedynie zmiany w obrazach, co zasadniczo jest analogiczne do strumienia wideo .

Moim najlepszym przypuszczeniem jest jakiś bardzo wydajny (i mocno wyspecjalizowany i zoptymalizowany) algorytm kompensacji ruchu, ponieważ większość rzeczywistych zmian w ogólnym zastosowaniu pulpitu to liniowy ruch elementów (przewijanie tekstu, przesuwanie okien itp. W przeciwieństwie do transformacji elementów).

Wydajność DirectX 3D 1 FPS wydaje się w pewnym stopniu potwierdzać moje przypuszczenia.

Kimvais
źródło
1
Jest bezpłatny kodek do przechwytywania ekranu TechSmith. Kompresuje się wydajnie i bez strat.
sinni800
25

zajęłoby trochę czasu, aby przejść przez serwery TeamViewer (TeamViewer omija korporacyjne Symmetric NAT, po prostu przekazując ruch przez ich serwery)

Przekonasz się, że TeamViewer rzadko musi przekazywać ruch przez własne serwery. TeamViewer penetruje NAT i sieci skomplikowane przez NAT przy użyciu translacji NAT (myślę, że jest to dziurkowanie UDP , jak libjingle Google ).

Używają własnych serwerów jako pośrednik w celu uzgadniania i konfigurowania połączenia, ale w większości przypadków relacja między klientem a serwerem będzie miała charakter P2P (w najlepszym przypadku, gdy uścisk dłoni się powiedzie). Jeśli przechodzenie NAT się nie powiedzie, TeamViewer rzeczywiście przekaże ruch przez własne serwery.

Jednak widziałem, jak robi to tylko wtedy, gdy klient stoi za podwójnym NATem.

Jamie Edwards
źródło
5
Jednak bardzo niewiele firmowych zapór sieciowych umożliwia przechodzenie przez NAT lub UPnP i jest to główny rynek TeamViewers. Podejrzewam, że większość połączeń jest przekazywana w prawdziwym życiu ...
NickG,
20
Czasami można „przepchnąć się” nawet przez firmowe zapory sieciowe / NAT - skype jest w tym całkiem niezły. Zasadniczo klient A wysyła żądania, które będą blokowane przez NAT / firewall, i informuje serwer zewnętrzny o używanym porcie. Klient B otrzymuje następnie informacje o porcie z serwera zewnętrznego i łączy się z tym portem. NAT A pomyśli, że jest odpowiedzią na pierwsze żądanie (które naprawdę zostało zablokowane przez NAT B) i przepuści. Kiedy A odpowie na to połączenie, NAT B przepuści je, ponieważ połączenie zostało zainicjowane przez B. => Masz połączenie.
Axel
Wiele firm ma tylko serwery proxy http i nie ma w ogóle NAT i routingu na zewnątrz. Tam Teamviewer przechodzi przez tunele http 443. To tcp i teamviewer są NADAL szybkie jak diabli.
sinni800
1
@Daniel: zacznij od przeczytania artykułów na temat „dziurkowania UDP” i „STUN” na Wikipedii.
Axel
1
@DanielLiuzzi Google opensource libjingle zawiera dziurkacz: developers.google.com/talk/libjingle/developer_guide . Kiedyś (i nadal może to robić, nie wiem) używali go do czatu, Hangoutów itp.
Jamie Edwards,
14

Trochę późna odpowiedź, ale proponuję przyjrzeć się niezbyt znanemu projektowi na codeplex o nazwie ConferenceXP

ConferenceXP to platforma badawcza typu open source, która zapewnia proste, elastyczne i rozszerzalne konferencje oraz współpracę przy użyciu sieci o dużej przepustowości i zaawansowanych możliwości multimedialnych systemu Microsoft Windows. ConferenceXP pomaga naukowcom i nauczycielom w opracowywaniu innowacyjnych aplikacji i rozwiązań, które oferują dźwięk i obraz o jakości nadawczej, wspierając rozproszoną współpracę w czasie rzeczywistym i środowiska uczenia się na odległość.

Zapewnione jest pełne źródło (jest ogromne!). Implementuje protokół RTP .

Simon Mourier
źródło
1
To jest wspaniałe! Pobrałem pliki binarne, ale w innych pokojach nie ma nikogo innego online. Później będę musiał przetestować na innym komputerze. Wielkie dzięki!
Jason,
6

Rzeczywiście brzmi to bardziej jak strumieniowe przesyłanie wideo niż strumieniowanie obrazu, jak ktoś sugerował. Kompresja JPEG / PNG nie jest przeznaczona dla tego typu prędkości, więc zapomnij o nich.

Wyobraź sobie, że masz w systemie kodek do nagrywania, który może nagrywać w czasie rzeczywistym przychodzący strumień wideo (Twój ekran). Może trochę jak Fraps. Następnie wyobraź sobie kodek odtwarzania wideo po drugiej stronie (klient zdalny). Ponieważ nagrywarki HD mogą to zrobić (nagrywać na żywo, a nawet odtwarzać na żywo z tego samego HD), tak samo powinieneś w końcu. HD z pewnością nie może dostarczyć obrazów szybciej, niż możesz odczytać wyświetlacz, więc to nie jest wąskie gardło. Wąskie gardło to kodeki wideo. Przekonasz się, że koder jest znacznie większym problemem niż dekoder, ponieważ wszystkie dekodery są w większości bezpłatne.

Nie mówię, że to proste; Sam użyłem DirectShow do zakodowania pliku wideo i zdecydowanie nie jest to w czasie rzeczywistym. Ale biorąc pod uwagę odpowiedni kodek, jestem przekonany, że może działać.

Ruud van Gaal
źródło
2

Moje przypadkowe przypuszczenie to: telewizor używa kodeka x264, który ma licencję komercyjną (w przeciwnym razie TeamViewer musiałby udostępnić ich kod źródłowy). Przypominam sobie, że w pewnym momencie (ponad 5 lat temu) główny twórca x264 napisał artykuł o ulepszeniach, które wprowadził do kodowania z niskim opóźnieniem (jeśli opóźnisz o kilka ramek, kodery mogą lepiej kompresować), a także wspomniał o innych ulepszeniach, które były odpowiednie do użytku w stylu TeamViewer. W tym poście wspomniał o graniu w quake over video bez żadnych zauważalnych problemów. Wtedy byłem pewien, kto jest sponsorem tych ulepszeń, ponieważ TeamViewer był wtedy właściwie jedyną opcją. x264 to otwarta implementacja kodeka wideo H264i jest to niesamowicie dobra implementacja, najlepsza. Jednocześnie jest niezwykle dobrze zoptymalizowany. Najprawdopodobniej dzięki wyjątkowo dobrej implementacji x264 uzyskasz znacznie lepsze wyniki z telewizorem przy mniejszym obciążeniu procesora. AnyDesk i Chrome Remote Desk używają biblioteki libvpx, która nie jest tak dobra jak x264 (pod względem optymalizacji i jakości wideo).

Jednak nie sądzę, że TeamView może pokonać RDP firmy Microsoft. Dla mnie jest najlepszy, jednak działa tylko między komputerami z systemem Windows lub z komputera Mac na system Windows. Telewizor działa nawet z telefonów komórkowych.

Aktualizacja: artykuł został napisany w styczniu 2010 roku, więc praca została wykonana około 10 lat temu. Poza tym popełniłem błąd: zagrał wezwanie do służby, a nie trzęsienie. Kiedy zamieściłeś swoje pytanie, jeśli moje przypuszczenia są prawidłowe, TeamViewer korzystał z tej pracy przez 3 lata. Przeczytaj ten post na blogu z archiwum internetowego: x264: najlepsza na świecie platforma do strumieniowego przesyłania wideo o niskim opóźnieniu . Kiedy przeczytałem ten artykuł w 2010 roku, byłem pewien, że „startupem - który zażądał, aby nie być nazywane”, o którym wspomina autor, to TeamViewer.

Pavel P.
źródło
Czy na pewno AnyDesk używa libvpx? Reklamują DeskRT jako własny kodek zaprojektowany specjalnie dla środowisk graficznych.
tuńczyk 24
0

Dziwnie. ale z mojego doświadczenia wynika, że ​​TeamViewer nie jest szybszy / bardziej responsywny niż VNC, tylko łatwiejszy w konfiguracji. Mam kilka win-boxenów, do których podłączam VNC przez OpenVPN (więc jest kolejna warstwa napowietrzna) i to na tanim kablu (512 w górę) i uważam, że prawidłowo skonfigurowany TightVNC jest znacznie bardziej responsywny niż TeamViewer do tego samego boxena. RDP (naturalnie) nawet bardziej, ponieważ w dużej mierze wysyła polecenia rysowania GUI zamiast kafelków bitmapowych.

Co prowadzi nas do:

  1. Dlaczego nie używasz VNC? Istnieje mnóstwo rozwiązań open source, a Tight prawdopodobnie jest teraz na szczycie swojej gry.

  2. Zaawansowane implementacje VNC wykorzystują kompresję stratną, która wydaje się osiągać lepsze wyniki niż wybór PNG. Ponadto IIRC reszta ładunku jest również zgniatana za pomocą zlib. Zarówno j Tight, jak i UltraVNC mają bardzo zoptymalizowane algorytmy, szczególnie dla systemu Windows. Poza tym Tight jest open-source.

  3. Jeśli twoim głównym celem są wygrane boxen, RDP może być lepszą opcją i ma implementację open source (rdesktop)

  4. Jeśli * nix boxen jest twoim głównym celem, NX może być lepszą opcją i ma implementację open source (FreeNX, choć nie tak zoptymalizowany jak zastrzeżony produkt NoMachine).

Jeśli kompresja JPEG jest problemem z wydajnością twojego algo, jestem prawie pewien, że porównanie obrazów nadal zmniejszyłoby wydajność. Założę się, że używają kompresji w najlepszym przypadku dla każdej konkretnej sytuacji, tj. Stratnej dla dużych klatek, niektórych szybkich i brudnych wewnętrznych bez przegranych dla mniejszych, porównują fragmenty obrazów i wysyłają tylko różne typy i kilka innych sztuczek optymalizacyjnych.

I wiele z tych sztuczek musi być obecnych w Tight> 2.0, ponieważ znowu, z mojego doświadczenia, bije to piekło w wydajności TeamViewer wyse, YMMV.

Również wybór skompilowanego środowiska uruchomieniowego JIT zamiast czegoś takiego jak C ++ może trochę zmniejszyć wydajność, szczególnie na maszynach z ograniczoną pamięcią (wiele dostrajania wydajności idzie do toalety, gdy Windows zaczyna intensywnie używać pliku stronicowania). Będziesz potrzebował pamięci, aby zachować poprzednie stany obrazu w celu wewnętrznego porównania tego, co daje DF mirage.

Bojan Markovic
źródło
9
Denerwuje mnie, gdy ludzie sugerują VNC jako alternatywę dla TeamViewer. Sugerowałbym, że być może nie korzystałeś z TeamViewer, aby poznać zalety, jakie daje w porównaniu z wolnym oprogramowaniem, takim jak VNC? VNC może być w porządku, jeśli chodzi o dostęp do własnego komputera, ale w przypadku udostępniania ekranu i organizowania spotkań itp. Nie jest nawet niejasny. Ostatnim razem, gdy sprawdzałem, VNC nie miał nawet żadnych otwartych serwerów przekaźnikowych, więc w 95% przypadków nie działałby, ponieważ byłby zaporą ogniową (chyba że jesteś właścicielem i obsługujesz własną zaporę lub serwer).
NickG
5
Dyskusja nie dotyczyła narzędzi klienckich VNC w porównaniu z TeamViewer (z których BARDZO używam zarówno na co dzień, chociaż obsługuję wiele zapór ogniowych i serwerów, a posiadam kilka). Dyskusja dotyczyła wewnętrznej pracy protokołów i ich wdrażania
Bojan Markovic
Właśnie wypróbowałem UltraVNC i TeamViewer w powolnej sieci 3G i różnica w wydajności była ogromna. W przypadku UltraVNC zauważyłem opóźnienie 1-2s między kliknięciem czegoś na zdalnym komputerze a wyświetleniem odpowiedzi. Powolny, by być użytecznym. TeamViewer był znacznie szybszy (tak szybki jak RDP) i wystarczająco szybki, aby można go było używać na tym samym łączu.
John Reynolds
2
Tak. Muszę się zgodzić z NickG. KAŻDY, który nadal próbuje założyć, że VNC jest tak szybki jak TeamViewer, nigdy nie używał TeamViewer. Śmieszne stwierdzenie. Ta odpowiedź powinna zostać przegłosowana. Użyłem wszystkich sztuczek sugerowanych w tym poście z VNC i nawet nie porównuje się to zdalnie z wydajnością TeamViewer.
zmiażdżyć
Musiałem się zalogować tylko w dół głosować na tę odpowiedź. Użyłem NoMachine, VNC, cokolwiek tam, a nawet spacedesk, Wired XDisplay na Androida i wiesz co? Teamviewer to najszybszy i znacznie szybszy niż streaming wideo spacedesk. Nikt nie sugeruje VNC = nigdy nie używaj Teamviewer.
Ken Le