Як TeamViewer настільки швидкий?

Вибачте за довжину, це якось потрібно.

Вступ

Я розробляю програмне забезпечення для віддаленого робочого столу (просто для розваги) в C # 4.0 для Windows Vista / 7. Я пережив основні перешкоди: у мене надійна система обміну повідомленнями UDP, відносно чистий дизайн програми, у мене працює і працює драйвер дзеркал (безкоштовний драйвер дзеркала DFMirage від DemoForge), і я реалізував NAT-траверсал для всіх Типи NAT, крім симетричних NAT (присутні у корпоративних брандмауерах).

Що стосується передачі / спільного використання екрана, завдяки драйверу дзеркала я автоматично отримую сповіщення про змінені області екрана, і я можу просто змінити біт-карту екрана драйвера, що постійно змінюється, на мою власну растрову карту. Потім я стискаю область екрана як PNG і відсилаю його з сервера своєму клієнту. Речі виглядають досить добре, але це не досить швидко. Це так само повільно, як VNC (btw, я не використовую протокол VNC, а лише користувацький аматорський протокол).

Від найповільнішого програмного забезпечення віддаленого робочого столу до найшвидшого, список зазвичай починається з усіх VNC-подібних реалізацій, потім піднімається до Microsoft Windows Remote Desktop ..., а потім ... TeamViewer. Не зовсім впевнений у CrossLoop, LogMeIn - я не користувався ними, але TeamViewer шалено швидко. Це буквально в прямому ефірі. Я запустив treeкоманду в командному рядку, і вона оновилася із затримкою 20 мс. Я можу переглядати Інтернет лише на кілька мілісекунд повільніше, ніж на своєму ноутбуці. Код вертикально прокрутки у Visual Studio має затримку 50 мс. Подумайте, наскільки надійним рішенням для передачі екрана TeamViewer повинно бути все це.

VNC використовують гачки на основі опитування для виявлення зміни екрана та захоплення / порівняння екрана грубої сили в найгіршому випадку. У кращому випадку вони використовують драйвер дзеркал, як DFMirage. Я на цьому рівні. І вони використовують щось, що називається протоколом RFB.

Microsoft Windows Remote Desktop, мабуть, на крок вище, ніж VNC. Я почув звідкись із StackOverflow, що Windows Remote Desktop не надсилає растрові екрани, а фактичні команди малювання. Це досить геніально, тому що він може просто надіслати простий текст (намалюйте цей прямокутник за цією координатою та пофарбуйте його за допомогою цього градієнта)! Віддалений робочий стіл дійсно досить швидкий - і це стандартний спосіб роботи від дому. І він використовує щось, що називається протоколом RDP.

Зараз TeamViewer для мене повна загадка. Мабуть, вони випустили свій вихідний код для версії 2 (TeamViewer - версія 7 станом на лютий 2012 року). Люди прочитали його і сказали, що Версія 2 марна - що це лише кілька вдосконалень над VNC з автоматичним NAT-траверсією.

Але версія 7 ... зараз це смішно швидко. Я маю на увазі, це насправді швидше, ніж Windows Remote Desktop. Я передавав DirectX 3D-ігри за допомогою TeamViewer (на 1 кадрі в секунду, але Windows Remote Desktop навіть не дозволяє запускати DirectX).

До речі, TeamViewer все це робить без драйвера дзеркала. Є можливість встановити його, і він стає лише трохи швидше.

Питання

Моє запитання: наскільки TeamViewer настільки швидкий?Це не повинно бути можливим. Якщо у вас є роздільна здатність 1920 на 1080 навіть на 24-бітній глибині (16-ти бітова глибина буде помітно некрасивою), це ще 6,220,800 байтів. Навіть використовуючи libjpeg-turbo (одну з найшвидших бібліотек стиснення JPG, яку використовують великі корпорації), стискаючи її до 30 КБ (давайте будемо надзвичайно щедрою), знадобиться час, щоб пройти маршрутизацію через сервери TeamViewer (TeamViewer обходить корпоративні симетричні NAT, просто наближаючись до трафіку через їхні сервери). А для стиснення libjpeg-turbo потрібен час для стиснення. Високоякісне стиснення JPG займає 175 мілісекунд для повного скріншоту 1920 на 1080. І це число збільшується, якщо на комп'ютері хоста працює процесор Atom. Я просто не розумію, як TeamViewer так добре оптимізував їхню передачу екрана. Знову ж, зображення невеликого розміру можуть бути сильно стислі, але знадобиться принаймні десятки мілісекунд для стиснення. Знімки великого розміру не потребують часу для стискання, але потрібно пройти довгий час. Так чи інакше, TeamViewer завершує весь цей процес, щоб отримати приблизно 20-25 кадрів в секунду. Я використовував мережевий монітор, і TeamViewer як і раніше не відстає зі швидкістю 500 Кбіт / с та 1 Мбіт / с (програмне забезпечення VNC на кілька секунд затримується при цій швидкості передачі). Під час могоtreeТест командного рядка TeamViewer отримував вхідні дані зі швидкістю 1 Мбіт / с і все ще працює 5-6 кадрів в секунду. VNC та віддалений робочий стіл цього не роблять. Так як?

Відповіді будуть дещо складними і хитромудрими, тому, будь ласка, не публікуйте свої $ 0,02, якщо ви лише збираєтесь сказати, що це тому, що вони використовують UDP замість TCP (чи вважаєте ви, що вони насправді так само успішно використовують TCP).

Я сподіваюся, що десь тут, на StackOverflow, є розробник TeamViewer.

Потенційні відповіді

Буде оновлено, як тільки люди відповідуть.

1. Думаю, насамперед, що TeamViewer має дуже тонкий мережевий контроль. Наприклад, вони розбивають великі пакети майже під MTU і ніколи не витрачають поїздку. У них, ймовірно, є всілякі фантазійні гачки для виявлення змін екрану разом із надзвичайно швидкими порівняннями XOR.

Тут, мабуть, найбільш фундаментальне те, що ви не хочете передавати статичні зображення, а лише змінювати зображення, що по суті є аналогом відеопотоку .

Моя найкраща здогадка - це дуже ефективний (і спеціалізований та оптимізований) алгоритм компенсації руху, оскільки більшість фактичних змін у загальному використанні робочого столу - це лінійний рух елементів (прокрутка тексту, переміщення вікон тощо) на противагу перетворенню елементів.

Продуктивність DirectX 3D 1 FPS, здається, певною мірою підтверджує мої здогадки.

знадобиться час, щоб пройти маршрутизацію через сервери TeamViewer (TeamViewer обходить корпоративні симетричні NAT, просто надаючи трафік через свої сервери)

Ви побачите, що TeamViewer рідко потребує ретрансляції трафіку через власні сервери. TeamViewer проникає в NAT і в мережі, ускладнені NAT, використовуючи NAT обхід (я думаю, це UDP-пробивання отворів , як Libjingle Google ).

Вони використовують власні сервери для посередників для того, щоб здійснити налаштування рукостискання та з'єднання, але більшість часу стосунки між клієнтом і сервером будуть P2P (найкращий випадок, коли рукостискання буде успішним). Якщо NAT-траверсія не вдасться, TeamViewer дійсно буде ретранслювати трафік через власні сервери.

Я коли-небудь бачив це робити, коли клієнт відстає від подвійного NAT.

Трохи запізніла відповідь, але я пропоную вам ознайомитись із невідомим проектом кодексу під назвою ConferenceXP

ConferenceXP - це дослідницька платформа з відкритим кодом, яка забезпечує просту, гнучку та розширювану конференцію та співпрацю за допомогою мереж високої пропускної здатності та розширених мультимедійних можливостей Microsoft Windows. ConferenceXP допомагає дослідникам та викладачам розробляти інноваційні програми та рішення, які містять аудіо та відео з високою якістю трансляції для підтримки співпраці в режимі реального часу та дистанційного навчання.

Повне джерело (це величезне!) Надається. Він реалізує протокол RTP .

Це справді звучить як потокове відео більше, ніж потокове зображення, як хтось запропонував. Стиснення JPEG / PNG не орієнтоване на такі типи швидкостей, тому забудьте про них.

Уявіть, що у вашій системі є кодек для запису, який може записувати вхідний відеопотік у реальному часі (на екрані). Можливо, трохи схожий на Фрапса. Потім уявіть кодек відтворення відео з іншого боку (віддалений клієнт). Як HD-рекордери можуть це робити (записувати в прямому ефірі і навіть відтворювати наживо з одного HD), так і в кінці кінців. HD напевно не може доставити зображення швидше, ніж ви можете прочитати ваш дисплей, так що це не вузьке місце. Вузьким місцем є відеокодеки. Ви знайдете кодер набагато більше проблеми, ніж декодер, оскільки всі декодери здебільшого безкоштовні.

Я не кажу, що це просто; Я сам використовував DirectShow для кодування відеофайлів, і це далеко не в режимі реального часу. Але з огляду на правильний кодек, я переконаний, він може працювати.

Моя випадкова здогадка: телевізор використовує кодек x264, який має комерційну ліцензію (інакше TeamViewer повинен був би випустити свій вихідний код). У якийсь момент (більше 5 років тому), я пригадую, головний розробник x264 написав статтю про вдосконалення, які він вніс для кодування з низькою затримкою (якщо затримка на кілька кадрів кодери можуть стиснутись краще), а також він згадав про деякі інші вдосконалення, які були актуально для використання, подібного TeamViewer. У цій публікації він згадав відтворення землетрусу над відеопотоком без помітних проблем. Тоді я був певним чином впевнений, хто є спонсором цих удосконалень, оскільки TeamViewer був майже єдиним варіантом на той час. x264 - реалізація відео кодеків H264 з відкритим кодом, і це шалено хороша реалізація, найкраща. Водночас це надзвичайно добре оптимізовано. Швидше за все, завдяки надзвичайно гарній реалізації x264 ви отримуєте набагато кращі результати завдяки телевізору при меншому навантаженні процесора. AnyDesk та Chrome Remote Desk використовують libvpx, що не так добре, як x264 (оптимізація та якість відео).

Однак я не думаю, що TeamView може перемогти RDP microsoft. Для мене це найкраще, однак він працює між комп'ютерами Windows або з Mac для Windows. Телевізор працює навіть з мобільних телефонів.

Оновлення: стаття була написана в січні 2010 року, так що робота була виконана приблизно 10 років тому. Також я помилився: він грав призовом, а не землетрусом. Коли ви опублікували своє запитання, якщо я гадаю, правильно, TeamViewer використовував цю роботу протягом 3 років. Прочитайте цю публікацію в блозі з веб-архіву: x264: найкраща платформа потокового відео з низькою затримкою . Коли я читав статтю ще в 2010 році, я був впевнений, що "стартап, який просив не називати його", про який згадує автор, був TeamViewer.

Як не дивно. але, на мій досвід, TeamViewer не швидший / більш чуйний, ніж VNC, лише простіший у налаштуванні. У мене є кілька виграшних боксерів, на які я VNC над OpenVPN (тому є ще один накладний шар), і це на дешевому кабелі (512 вгору), і я вважаю, що налаштування TightVNC набагато чуйніше, ніж TeamViewer на той же боксен. RDP (природно) ще більше, оскільки великою частиною він надсилає графічні команди GUI замість растрових плиток.

Що приводить нас до:

1. Чому ви не використовуєте VNC? Існує безліч рішень з відкритим кодом, і Tight, ймовірно, на вершині своєї гри вже зараз.

2. У вдосконалених реалізаціях VNC використовується стиснення втрат, і це, здається, досягає кращих результатів, ніж ваш вибір PNG. Крім того, IIRC решту корисного вантажу також видавлюють за допомогою zlib. Bothj Tight і UltraVNC мають дуже оптимізовані альги, особливо для вікон. Крім цього, Tight є відкритим кодом.

3. Якщо win boxen - ваш основний цільовий RDP, може бути кращим варіантом, і він має реалізацію з відкритим кодом (rdesktop)

4. Якщо * nix boxen є вашою основною ціллю, NX може бути кращим варіантом і має реалізацію з відкритим кодом (FreeNX, хоч і не настільки оптимізований, як фірмовий продукт NoMachine).

Якщо стиснення JPEG є проблемою продуктивності для вашого algo, я майже впевнений, що порівняння зображень все-таки позбавить певної продуктивності. Б'юсь у заклад, вони використовують найкращі компресії для кожної конкретної ситуації, тобто втрату для великих кадрів, швидку та брудну внутрішню програму для менших, порівняння бітів зображень та надсилання лише різних сортів та оптимізацій.

І багато цих хитрощів повинно бути присутнім у Tight> 2.0, оскільки, на моєму досвіді, це перемагає пекло виступу TeamViewer, YMMV.

Крім того, вибір JIT, скомпільованого під час виконання щось подібне до C ++, може сприйняти фрагмент від вашої продуктивності, особливо в машинах з обмеженою пам’яттю (багато налаштування продуктивності йде в туалет, коли Windows починають інтенсивно використовувати сторінку файлів). І вам знадобиться пам'ять, щоб зберегти попередні стани зображень для внутрішнього порівняння зверху того, що дає вам mirage DF.