Как 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. Откуда-то в Stackru я слышал, что 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 так же успешно).
Я надеюсь, что где-то здесь на Stackru есть разработчик TeamViewer.
Потенциальные ответы
Обновлю это, как только люди ответят.
- Прежде всего, я думаю, что TeamViewer имеет очень хороший контроль над сетью. Например, они разбивают большие пакеты до размера чуть меньше размера MTU и никогда не тратят время. Они, вероятно, имеют всевозможные причудливые приемы для обнаружения изменений экрана вместе с чрезвычайно быстрым сравнением изображений XOR.
5 ответов
Вероятно, наиболее фундаментальная вещь здесь заключается в том, что вы не хотите передавать статические изображения, а только вносить изменения в изображения, что по сути аналогично видеопотоку.
Мое лучшее предположение - какой-то очень эффективный (и сильно специализированный и оптимизированный) алгоритм компенсации движения, потому что большая часть фактического изменения в общем использовании рабочего стола - это линейное перемещение элементов (прокрутка текста, перемещение окон и т. Д., Противоположное преобразованию элементов).
Производительность 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 для кодирования видеофайла, и это далеко не в реальном времени. Но, учитывая правильный кодек, я убежден, что он может работать.
Моя случайная догадка такова: телевизор использует кодек x264, на который есть коммерческая лицензия (в противном случае TeamViewer пришлось бы выпустить свой исходный код). В какой-то момент (более 5 лет назад), я вспоминаю, что главный разработчик x264 написал статью об улучшениях, которые он сделал для кодирования с низкой задержкой (если вы задержите на несколько кадров, кодеры могут сжать лучше), плюс он упомянул некоторые другие улучшения, которые были актуально для использования в стиле TeamViewer. В этом посте он упомянул проигрывание Quake через видеопоток без каких-либо заметных проблем. Тогда я был отчасти уверен, кто спонсировал эти улучшения, поскольку TeamViewer в то время был практически единственным вариантом. x264 - это реализация видеокодека H264 с открытым исходным кодом. , и это безумно хорошая реализация, самая лучшая. В то же время он очень хорошо оптимизирован. Скорее всего, из-за очень хорошей реализации x264 вы получите гораздо лучшие результаты с ТВ при меньшей загрузке процессора. AnyDesk и Chrome Remote Desk используют libvpx, что не так хорошо, как x264 (оптимизация и качество видео).
Однако я не думаю, что TeamView может превзойти RDP от Microsoft. Для меня это лучший вариант, но он работает только между ПК с Windows или с Mac на Windows. ТВ работает даже с мобилы.
Обновление: статья написана в январе 2010 года, значит, работа была проделана примерно 10 лет назад. Еще я ошибся: он играл в call of duty, а не в quake. Когда вы разместили свой вопрос, если мое предположение верно, TeamViewer использовал эту работу в течение 3 лет. Прочтите это сообщение в блоге из веб-архива: x264: лучшая в мире платформа для потоковой передачи видео с низкой задержкой. Когда я прочитал статью еще в 2010 году, я был уверен, что "стартап, который попросил не называть его имени", о котором упоминает автор, был TeamViewer.
Как ни странно. но по моему опыту TeamViewer не быстрее / более отзывчив, чем VNC, только проще в настройке. У меня есть пара win-boxen, в которые я подключаю VNC через OpenVPN (так что есть еще один уровень служебных данных), и это по дешевому кабелю (512 и выше), и я считаю, что правильно настроенный TightVNC гораздо более отзывчив, чем TeamViewer, к тому же самому boxen. RDP (естественно) тем более, что по большей части он посылает команды рисования графического интерфейса вместо растровых плиток.
Что приводит нас к:
Почему вы не используете VNC? Существует множество решений с открытым исходным кодом, и Tight, вероятно, сейчас находится на вершине своей игры.
Усовершенствованные реализации VNC используют сжатие с потерями, и это, кажется, дает лучшие результаты, чем ваш выбор PNG. Кроме того, IIRC остальная часть полезной нагрузки также сокращается с использованием zlib. Bothj Tight и UltraVNC имеют очень оптимизированные алгоритмы, особенно для Windows. Вдобавок к этому Tight с открытым исходным кодом.
Если win boxen - ваша основная цель, RDP может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (rdesktop)
Если *nix boxen - ваша основная цель, NX может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (FreeNX, хотя и не так оптимизирован, как собственный продукт NoMachine).
Если сжатие JPEG является проблемой производительности для вашего алгоритма, я уверен, что сравнение изображений все равно снизит производительность. Могу поспорить, что они используют сжатие в лучшем случае для каждой конкретной ситуации, то есть с потерями для больших кадров, некоторые быстрые и грязные внутренние, без потерь для меньших, сравнивают биты изображений и отправляют только разного рода сортировку и кучу других приемов оптимизации.
И многие из этих трюков должны присутствовать в Tight > 2.0, так как, по моему опыту, это чертовски сильно сказывается на производительности TeamViewer, YMMV.
Кроме того, выбор JIT-компилируемой среды выполнения над чем-то вроде C++ может отнять часть вашей производительности, особенно на машинах с ограниченным объемом памяти (большая производительность настраивается, когда окна начинают интенсивно использовать файл подкачки). И вам понадобится память, чтобы сохранить прежние состояния изображения для внутреннего сравнения поверх того, что дает вам DF mirage.