Как TeamViewer так быстро?
извините за длину, это вроде как необходимо.
введение
Я разрабатываю программное обеспечение для удаленного рабочего стола (просто для удовольствия) в C# 4.0 для Windows Vista/7. Я прошел через основные препятствия: у меня есть надежная система обмена сообщениями UDP, относительно чистый дизайн программы, у меня есть драйвер зеркала (бесплатный драйвер зеркала DFMirage от DemoForge) и я реализовал обход NAT для всех типов NAT, кроме симметричных Nat (присутствующих в корпоративные ситуации брандмауэра).
Что касается передачи/совместного использования экрана, благодаря драйверу зеркала я автоматически уведомляюсь об измененных областях экрана, и я могу просто маршалировать постоянно меняющееся растровое изображение экрана зеркального драйвера на свое собственное растровое изображение. Затем я сжимаю область экрана как PNG и отправляю ее с сервера на мой клиент. Все выглядит довольно хорошо, но это не достаточно быстро. Это так же медленно, как VNC (кстати, я не использую протокол VNC, просто пользовательский любитель протокол.)
от самого медленного программного обеспечения удаленного рабочего стола к самому быстрому, список обычно начинается на всех VNC-подобных реализациях, а затем поднимается до удаленного рабочего стола Microsoft Windows...и...TeamViewer. Не совсем уверен в CrossLoop, LogMeIn - я их не использовал, но TeamViewer-это безумно быстро. Это довольно буквально жить. Я побежал tree команда в командной строке, и она обновляется с задержкой 20 мс. Я могу просматривать веб-страницы несколько миллисекунд медленнее, чем на моем ноутбук. Прокрутка кода по вертикали в Visual Studio имеет время задержки 50 мс. Подумайте о том, насколько надежным должно быть решение TeamViewer для переноса экрана, чтобы выполнить все это.
VNCs используют основанные на опросе крючки для обнаружения изменения экрана и захвата/сравнения экрана грубой силы в худшем случае. В лучшем случае они используют зеркальный драйвер, такой как DFMirage. Я на этом уровне. И они используют что-то под названием Протокол RFB.
Microsoft Windows Remote Desktop, по-видимому, идет на один шаг выше менее затратен. Я слышал, откуда-то на StackOverflow, что удаленный рабочий стол Windows не отправляет растровые изображения экрана, а фактические команды рисования. Это довольно блестяще, потому что он может просто отправить простой текст (нарисуйте этот прямоугольник в этой координате и раскрасьте его с помощью этого градиента)! Удаленный рабочий стол действительно довольно быстро - и это стандартный способ работы на дому. И он использует то, что называется протоколом RDP.
теперь TeamViewer является для меня полной загадкой. Видимо, их отпустили их исходный код для версии 2 (TeamViewer-версия 7 по состоянию на февраль 2012 года). Люди прочитали его и сказали, что версия 2 бесполезна - это всего лишь несколько улучшений по сравнению с VNC с автоматическим обходом NAT.
но версия 7...it-теперь до смешного быстро. Я имею в виду, это на самом деле быстрее, чем удаленный рабочий стол Windows. Я транслировал игры DirectX 3D с TeamViewer (на 1 fps, но удаленный рабочий стол Windows даже не позволяет запускать DirectX).
кстати, TeamViewer делает все это без драйвер зеркало. Есть возможность установить его, и он становится немного быстрее.
Вопрос
мой вопрос в том, как TeamViewer так быстро? это не должно быть возможно. Если у вас есть разрешение 1920 на 1080 даже на 24-битной глубине (16-битная глубина будет заметно уродливой), это все еще 6 220 800 байт raw. Даже с помощью libjpeg-turbo (одна из самых быстрых библиотек сжатия JPG, используемых крупными корпорациями), сжатие его до 30 КБ (давайте будем очень щедрыми) потребует времени для маршрутизации через серверы TeamViewer (TeamViewer обходит корпоративные симметричные NATs, просто проксируя трафик через свои серверы). И что сжатие 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 так же успешно, хотя).
Я надеюсь, что где-то здесь есть разработчик TeamViewer StackOverflow.
Возможные Ответы
обновит это, как только люди ответят.
- мои мысли, прежде всего, что TeamViewer имеет очень тонкий сетевой контроль. Например, они разделяют большие пакеты только до размера MTU и никогда не тратят впустую поездку. У них, вероятно, есть всевозможные причудливые крючки для обнаружения изменений экрана наряду с чрезвычайно быстрыми сравнениями изображений XOR.
5 ответов:
самое фундаментальное здесь, вероятно, заключается в том, что вы не хотите передавать статические изображения, а только изменения к изображениям, которые по существу аналогичны видео.
мое лучшее предположение-это очень эффективный (и сильно специализированный и оптимизированный) алгоритм компенсации движения, потому что большинство фактических изменений в общем использовании рабочего стола линейный движение элементов (прокрутка текста, перемещение окон и т. д. против преобразование элементов).
производительность DirectX 3D 1 FPS, похоже, в какой-то степени подтверждает мою догадку.
потребуется время для маршрутизации через серверы TeamViewer (TeamViewer обходит корпоративные симметричные NATs, просто проксируя трафик через свои серверы)
вы обнаружите, что TeamViewer редко нужно ретранслировать трафик через свои собственные серверы. TeamViewer проникает в NAT и сети, осложненные NAT, используя обход NAT (я думаю, что это УДП отверсти-пробивать, как libjingle от Google).
они используют свои собственные серверы для среднего человека, чтобы сделать рукопожатие и настройку соединения, но большую часть времени отношения между клиентом и сервером будут P2P (в лучшем случае, когда рукопожатие успешно). Если обход NAT не удастся, то TeamViewer действительно будет ретранслировать трафик через свои собственные серверы.
Я только когда-либо видел, как это делается, когда клиент был за double-NAT.
немного поздний ответ, но я предлагаю вам взглянуть на не известный проект на CodePlex под названием ConferenceXP
ConferenceXP-это исследовательская платформа с открытым исходным кодом, которая обеспечивает простой, гибкая и расширяемая конференц-связь и совместная работа с использованием сети с высокой пропускной способностью и расширенные мультимедийные возможности Microsoft Windows. ConferenceXP помогает исследователям и педагогам разработка инновационных приложений и решений, как широковещательное качество аудио и видео в поддержку распределенного в реальном времени сотрудничества и обучения.
полный источник (это огромный!) предоставляемый. Он реализует протокол RTP.
Это звучит действительно как потоковое видео больше, чем потоковое изображение, как кто-то предложил. Сжатие JPEG/PNG не предназначено для этих типов скоростей, поэтому забудьте о них.
представьте себе, что в вашей системе есть кодек записи, который может в реальном времени записывать входящий видеопоток (ваш экран). Возможно, немного похоже на Fraps. Затем представьте себе кодек воспроизведения видео на другой стороне (удаленный клиент). Как рекордеры HD может это сделать (записать видео и даже воспроизведение видео с того же БГ), поэтому следует ты, в конце концов. HD, конечно, не может доставлять изображения быстрее, чем вы можете прочитать свой дисплей, так что это не узкое место. Узким местом являются видеокодеки. Вы найдете кодер гораздо больше проблем, чем декодер, так как все декодеры в основном свободны.
Я не говорю, что это просто; я сам использовал DirectShow для кодирования видеофайла, и это далеко не в реальном времени. Но, учитывая правильный кодек, я убежден, что он может работать.
странно. но по моему опыту TeamViewer не быстрее / более отзывчив, чем VNC, только проще в настройке. У меня есть пара win-boxen, в которые я VNC над OpenVPN (так что есть еще один верхний слой), и это на дешевом кабеле (512 вверх), и я нахожу, что правильно настроенный TightVNC намного более отзывчив, чем TeamViewer к тому же boxen. RDP (естественно) тем более, что по большей части он отправляет команды рисования GUI вместо растровых плиток.
что приводит нас к:
Почему вы не используете VNC? Есть множество открытых исходных текстов решения, и плотно, вероятно, на вершине это игра прямо сейчас.
расширенные реализации VNC используют сжатие с потерями, и это, похоже, достигается лучшие результаты, чем ваш выбор PNG. Кроме того, IIRC остальная часть полезной нагрузки также сжато с помощью zlib. Bothj Tight и UltraVNC имеют очень оптимизированные algos, особенно для windows. На вершине этого плотного есть открытый исходный код.
Если win boxen является вашей основной целью, RDP может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (rdesktop)
Если * nix boxen - ваша основная цель, NX может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (FreeNX, хотя и не так оптимизирован, как проприетарный продукт NoMachine).
Если сжатие JPEG является проблемой производительности для вашего algo, я уверен, что сравнение изображений будет все равно заберите какое-то представление. Я бы поспорил, что они используют лучшее сжатие для каждой конкретной ситуации, т. е. потери для больших кадров, некоторые быстрые и грязные внутренние потери для меньших, сравнивают биты изображений и отправляют только различия в сортировке и кучу других трюков оптимизации.
и много таких уловок, которые должны присутствовать в ограниченном > 2.0, поскольку опять же, по моему опыту, это черт его производительность TeamViewer программное обеспечение Wyse, YMMV.
также выбор JIT-компиляции время выполнения над чем-то вроде C++ может занять часть от вашего края производительности, особенно в машинах с ограниченной памятью (большая настройка производительности идет в туалет, когда windows начинает интенсивно использовать файл подкачки). И вам понадобится память, чтобы сохранить предыдущие состояния изображения для внутреннего сравнения поверх того, что дает вам DF mirage.