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

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

Введение

Я разрабатываю программное обеспечение для удаленного рабочего стола (просто для удовольствия) на 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мое случайное предположение: 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.

Как ни странно. но по моему опыту 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.