Как TeamViewer так быстро?


158

Извините за длину, это своего рода необходимо.

Введение

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

Что касается передачи / совместного использования экрана, благодаря драйверу зеркала я автоматически уведомляюсь об измененных областях экрана и могу просто перенаправить постоянно меняющееся изображение экрана драйвера зеркала в мое собственное изображение. Затем я сжимаю область экрана в формате PNG и отправляю ее с сервера моему клиенту. Все выглядит довольно хорошо, но это не достаточно быстро. Это так же медленно, как VNC (кстати, я не использую протокол VNC, просто пользовательский любительский протокол).

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

VNC используют основанные на опросе хуки для обнаружения изменения экрана и захвата / сравнения экрана методом грубой силы в худшем случае. В своих лучших проявлениях они используют зеркальный драйвер, такой как DFMirage. Я на этом уровне. И они используют то, что называется протоколом RFB.

Удаленный рабочий стол Microsoft Windows, очевидно, идет на один шаг выше, чем 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.

1
Вы пробовали реконструировать протокол? (Кажется, что они используют PKI для настройки сеанса, поэтому это может быть непросто, если вообще возможно)
Kimvais

3
Ожидание ответа на этот вопрос зависит от готовности компании поделиться своей коммерческой тайной. При этом их основной, тот, который держит их в бизнесе. У вас есть сильное «нет», единственный способ получить «да» - позвонить им. Спросите об их патентах, наверное.
Ганс Пассант

1
Имеет смысл. Я буду ждать больше предложений.
Джейсон

4
Странно. Я не нахожу это быстрее, чем удаленный рабочий стол сам - далеко не так! RDP для меня WAY быстрее - больше как с помощью локальной виртуальной машины. Вы на самом деле тестируете через Интернет или на какой-то локальной установке? Вы открыли свой брандмауэр, чтобы разрешить прямые подключения TeamViewer?
NickG

1
Похоже, вы тестируете только в локальной сети. Исходя из моего опыта, кажется, что TeamViewer использует сжатие с потерями (при медленном соединении качество иногда действительно отсутствует). Может быть, VNC использует больше времени обработки и меньше полосы пропускания, чем TeamViewer, и наоборот? Затем в зависимости от вашей среды (мощность процессора на обеих машинах и качество сетевого соединения) иногда VNC может быть быстрее, иногда TeamViewer.
Аксель

Ответы:


79

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

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

Производительность DirectX 3D в 1 FPS, кажется, в какой-то степени подтверждает мои предположения.


1
Theres бесплатный кодек захвата экрана TechSmith. Сжимает эффективно и без потерь.
sinni800

25

потребуется время для маршрутизации через серверы TeamViewer (TeamViewer обходит корпоративные симметричные NAT, просто передавая трафик через их серверы)

Вы обнаружите, что TeamViewer редко требуется передавать трафик через свои собственные серверы. TeamViewer проникает через NAT и сети, осложненные NAT, используя обход NAT (я думаю, что это пробивание UDP-дырок , как в Google libjingle ).

Они используют свои собственные серверы для посредников, чтобы выполнить рукопожатие и настройку соединения, но большую часть времени отношения между клиентом и сервером будут P2P (лучший случай, когда рукопожатие успешно). Если прохождение NAT завершится неудачно, TeamViewer действительно будет передавать трафик через свои собственные серверы.

Впрочем, я видел это только тогда, когда клиент был за двойным NAT.


5
Очень немногие корпоративные брандмауэры допускают прохождение NAT или UPnP, и это основной рынок TeamViewers. Я подозреваю, что большинство соединений передаются в реальной жизни ...
NickG

20
Иногда вы можете «пробиться» даже через корпоративные брандмауэры / NAT - скайп довольно хорош в этом. По сути, клиент A отправляет запросы, которые будут заблокированы NAT / firewall, и информирует внешний сервер об используемом порту. Затем клиент B получает информацию о порте с внешнего сервера и подключается к этому порту. NAT A будет думать, что это ответ на первый запрос (который действительно был заблокирован NAT B), и пропустить его. Когда A ответит на это соединение, NAT B пропустит его, потому что соединение было инициировано B. => У вас есть соединение.
Аксель

Многие корпорации имеют только http прокси и не имеют NAT и вообще не маршрутизируют. Там Teamviewer туннелирует через http-порт 443. То есть tcp и teamviewer ОЧЕНЬ быстры, как ад.
sinni800

1
@Daniel: начните с чтения статей о «UDP дырокол» и «STUN» в Википедии.
Аксель

1
@DanielLiuzzi В libjingle Google с открытым исходным кодом есть перфоратор: developers.google.com/talk/libjingle/developer_guide . Они привыкли (и, возможно, все еще делают, я не знаю), использовать его для GChat, Hangouts и т. Д.
Джейми Эдвардс

14

Немного запоздалый ответ, но я предлагаю вам взглянуть на не очень известный проект на codeplex под названием ConferenceXP

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

Полный источник (это огромный!) Предоставляется. Он реализует протокол RTP .


1
Это отлично! Я скачал двоичные файлы, но в других комнатах, похоже, никого нет в сети. Я должен буду проверить с другим компьютером позже. Большое спасибо!
Джейсон

6

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

Представьте себе, что в вашей системе есть записывающий кодек, который может в реальном времени записывать входящий видеопоток (ваш экран). Возможно, немного похоже на Фрапса. Затем представьте кодек для воспроизведения видео на другой стороне (удаленный клиент). Как HD рекордеры могут это сделать (записывать в прямом эфире и даже воспроизводить в прямом эфире с того же HD), так и вы, в конце концов, должны. Безусловно, HD не может передавать изображения быстрее, чем вы можете прочитать на дисплее, так что это не является узким местом. Узким местом являются видеокодеки. Вы найдете кодер гораздо более проблемной, чем декодер, так как все декодеры в основном бесплатны.

Я не говорю, что это просто; Я сам использовал DirectShow для кодирования видеофайла, и это далеко не в реальном времени. Но учитывая правильный кодек, я убежден, что он может работать.


2

Мое случайное предположение: TV использует кодек x264, который имеет коммерческую лицензию (иначе TeamViewer должен был бы выпустить свой исходный код). В какой-то момент (более 5 лет назад), я помню, главный разработчик x264 написал статью об улучшениях, которые он сделал для кодирования с низкой задержкой (если вы задерживаете на несколько кадров, кодеры могут сжиматься лучше), плюс он упомянул некоторые другие улучшения, которые были актуально для использования в TeamViewer. В этом посте он упомянул о воспроизведении Quake через видеопоток без заметных проблем. В то время я был уверен, кто был спонсором этих улучшений, поскольку TeamViewer был практически единственным вариантом в то время. x264 - это реализация видеокодека H264 с открытым исходным кодоми это безумно хорошая реализация, это лучшая. В то же время он очень хорошо оптимизирован. Скорее всего, из-за очень хорошей реализации x264 вы получите намного лучшие результаты при использовании телевизора с меньшей нагрузкой на процессор. AnyDesk и Chrome Remote Desk используют libvpx, который не так хорош, как x264 (оптимизация и качество видео).

Тем не менее, я не думаю, что TeamView может побить RDP от Microsoft. На мой взгляд, это лучшее, но оно работает только между ПК с Windows или с Mac на Windows. Телевизор работает даже с мобильных телефонов.

Обновление: статья была написана в январе 2010 года, так что работа была выполнена примерно 10 лет назад. Также я допустил ошибку: он играл в долг, а не в землетрясение. Когда вы разместили свой вопрос, если я правильно понял, TeamViewer использовал эту работу в течение 3 лет. Прочтите эту запись в блоге из веб-архива: x264: лучшая в мире платформа для потоковой передачи видео с низкой задержкой . Когда я прочитал эту статью в 2010 году, я был уверен, что «автозапуск, который попросил не называть его имени», о котором упоминает автор, был TeamViewer.


Вы уверены, что AnyDesk использует libvpx? Они рекламируют DeskRT как свой собственный кодек, разработанный специально для настольных сред.
tunafish24

0

Как ни странно. но по моему опыту TeamViewer не быстрее / более отзывчив, чем VNC, только проще в настройке. У меня есть пара win-boxen, в которые я подключаю VNC через OpenVPN (так что есть еще один уровень служебных данных), и это по дешевому кабелю (512 и выше), и я считаю, что правильно настроенный TightVNC гораздо более отзывчив, чем TeamViewer, к тому же самому boxen. RDP (естественно) тем более, что по большей части он посылает команды рисования графического интерфейса вместо растровых плиток.

Что приводит нас к:

  1. Почему вы не используете VNC? Существует множество решений с открытым исходным кодом, и Tight, вероятно, сейчас находится на вершине своей игры.

  2. Расширенные реализации VNC используют сжатие с потерями, и это, кажется, дает лучшие результаты, чем ваш выбор PNG. Кроме того, IIRC, остальная часть полезной нагрузки также сокращается с использованием zlib. Bothj Tight и UltraVNC имеют очень оптимизированные алгоритмы, особенно для Windows. Вдобавок к этому Tight с открытым исходным кодом.

  3. Если win boxen - ваша основная цель, RDP может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (rdesktop)

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

Если сжатие JPEG является проблемой производительности для вашего алгоритма, я уверен, что сравнение изображений все равно снизит производительность. Могу поспорить, что они используют сжатие в лучшем случае для каждой конкретной ситуации, то есть с потерями для больших кадров, некоторые быстрые и грязные внутренние, без потерь для меньших, сравнивают биты изображений и отправляют только разного рода сортировку и кучу других приемов оптимизации.

И многие из этих трюков должны присутствовать в Tight> 2.0, так как, по моему опыту, это чертовски сильно сказывается на производительности TeamViewer, YMMV.

Кроме того, выбор JIT-компилируемой среды выполнения над чем-то вроде C ++ может отнять часть вашей производительности, особенно на машинах с ограниченным объемом памяти (большая производительность настраивается, когда окна начинают интенсивно использовать файл подкачки). И вам понадобится память, чтобы сохранить прежние состояния изображения для внутреннего сравнения поверх того, что дает вам DF mirage.


9
Меня раздражает, когда люди предлагают VNC в качестве альтернативы TeamViewer. Я бы предположил, что, возможно, вы не использовали TeamViewer, чтобы узнать о преимуществах, которые он дает по сравнению с такими бесплатными программами, как VNC? VNC может подойти для доступа к вашему компьютеру, но для общего доступа к экрану, проведения совещаний и т. Д. Он даже не дает четкого сравнения. В прошлый раз, когда я проверял, у VNC даже не было открытых серверов ретрансляции, поэтому он даже не работал бы в 95% случаев, так как он был бы защищен брандмауэром (если у вас нет собственного брандмауэра или сервера).
NickG

5
Речь шла не о клиентских инструментах VNC, а о TeamViewer (которым я ОБЫЧНО пользуюсь как ежедневно, так и у меня много брандмауэров и серверов, и у меня их немало). Обсуждение было о внутренней работе протоколов и их реализации
Боян Маркович

Только что попробовал UltraVNC и TeamViewer в медленной сети 3G, и разница в производительности была огромной. С UltraVNC я испытывал задержки в 1-2 секунды между щелчком чего-либо на удаленном компьютере и получением ответа. Вяло быть полезным. TeamViewer был намного быстрее (так же быстро, как и RDP) и достаточно быстрым, чтобы его можно было использовать по той же ссылке.
Джон Рейнольдс

2
Ага. Я должен согласиться с NickG. НИКТО все еще пытается установить VNC так быстро, как TeamViewer никогда не использовал TeamViewer. Смешное утверждение. Этот ответ должен быть отклонен. Я использовал все приемы, предложенные в этом посте, с VNC, и он даже отдаленно не сравнится с производительностью TeamViewer.
раздавить

Я должен был войти в систему, чтобы проголосовать за этот ответ. Я использовал NoMachine, VNC, что угодно, и даже Spacedesk, Wired XDisplay на Android, и знаете что? Teamviewer - самый быстрый, намного быстрее, чем потоковое видео Spacedesk. Кто-нибудь предлагает VNC = никогда не использовать Teamviewer.
Кен Ле
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.