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

Question

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

Введение

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

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

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

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

Удаленный рабочий стол Microsoft Windows, очевидно, на один шаг выше, чем VNC.Откуда-то в StackOverflow я слышал, что удаленный рабочий стол Windows отправляет не растровые изображения, а реальные команды рисования.Это довольно блестяще, потому что он может просто посылать простой текст (нарисуйте этот прямоугольник по этой координате и раскрасьте его этим градиентом)!Удаленный рабочий стол действительно очень быстрый - и это стандартный способ работы из дома.И он использует то, что называется протоколом RDP.

Теперь TeamViewer для меня загадка.По-видимому, они выпустили свой исходный код для Версии 2 (TeamViewer - Версия 7 по состоянию на февраль 2012 года).Люди прочитали его и сказали, что версия 2 бесполезна - это всего лишь несколько улучшений по сравнению с VNC с автоматическим обходом NAT.

Но Версия 7 ... сейчас это смехотворно быстро.Я имею в виду, что это на самом деле быстрее, чем Windows Remote Desktop.Я транслировал DirectX 3D-игры с TeamViewer (со скоростью 1 кадр / с, но Windows Remote Desktop даже не позволяет запускать DirectX).

Кстати, TeamViewer делает все это без aзеркальный драйвер.Есть возможность установить один, и он становится немного быстрее.

Вопрос

Мой вопрос: как 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 Command Prompt TeamViewer получал входящие данные со скоростью 1 Мбит / с и все еще работал со скоростью 5-6 кадров в секунду. VNC и удаленный рабочий стол этого не делают. Итак, как?

Ответы будут несколько сложными и запутанными, поэтому пожалуйста, не публикуйте свои 0,02 доллара, если вы только скажете, что это потому, что они используют UDP вместо TCP (вы полагаете, что они действительно используют TCP так же успешно, хотя).

Я надеюсь, что где-то здесь на StackOverflow есть разработчик TeamViewer.

Потенциальные ответы

Обновит это, как только люди ответят.

1. Прежде всего, я думаю, что TeamViewer имеет очень хороший контроль над сетью. Например, они разбивают большие пакеты на размер чуть меньше размера MTU и никогда не тратят время. Вероятно, у них есть все виды необычных хуков для обнаружения изменений на экране, а также очень быстрое сравнение изображений XOR.

Answer 1

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

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

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

Answer 2

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

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

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

Я когда-либо видел, чтобы это делалось только тогда, когда клиент был за двойным NAT.

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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