Журнал LinuxFormat - перейти на главную

LXF84:Сравнение

Материал из Linuxformat
Перейти к: навигация, поиск
Каждый месяц мы сравниваем для вас тонны программ – а вы можете отдыхать!

Содержание

Сравнение: УТИЛИТЫ УДАЛЕННОГО УПРАВЛЕНИЯ

В этом месяце: Чтобы не держать на столе лишние мониторы, Дэвид Кулсон разбирается с удаленными рабочими столами.

Помогла бы вам иной раз возможность увидеть рабочий стол Windows вашего клиента на своей Linux-машине? Приходилось ли вам готовить доклад на понедельник в выходные? Или вы просто любите работать на дому, развалясь в пижаме? Вам, друзья мои, нужен удаленный рабочий стол.

Доступ к рабочему столу сервера или рабочей станции – функция, уже десятилетиями предлагаемая на платформах Unix, но до недавнего времени это был просто терминальный доступ, как у большинства пользователей. К счастью, в наши дни существуют разные варианты графического доступа. Пусть вы их еще не пробовали – вы тоже можете увидеть свой рабочий стол так, словно он установлен в другом месте (и даже на другой ОС), и открывать графические приложения. Движения вашей мыши и нажатия на клавиши будут отсылаться на сервер; в ответ обновления экрана отправятся к вашей удаленной машине. Есть несколько опций для кодирования и сжатия этой экранной информации, что- бы «перерисовка» всего графического рабочего стола точка за точкой не отнимала половину вашего канала и процессорного времени.

X11 и далее!

Рабочие столы Linux основаны на протоколе X11, со встроенными сетевыми возможностями, позволяющими удаленным системам запускать графические X-приложения на локальном X-сервере. Это имеет существенные недостатки: главным образом то, что вы не можете запустить удаленно X-сессию целиком и что это «отъедает» пропускную способность. Даже запустив X11 через Ethernet 100Mbit, вы можете ощущать задержку, способную кое-кого вывести из терпения. Мы рассмотрим X11 в этом Сравнении, но есть и альтернативы запуску «сырого» X по сети, которые мы тоже протестируем; многие из них включают дополнительные функции, далеко превосходящие возможности X11.

Всего мы рассмотрели семь решений удаленных рабочих столов: три полных клиентсерверных пакета, два сервера и два интерфейса (front-end), которые вам следует комбинировать, чтобы получить работающее решение удаленного рабочего стола.

Наши тесты

Удаленный рабочий стол должен обеспечивать пользователя всеми преимуществами рабочего стола (а не консоли) на удаленной машине. Ключевые факторы здесь таковы:

  • Скорость. Рабочий стол с непомерно медленной реакцией бесполезен.
  • Безопасность. Не рисково ли использовать его в незащищенной сети? Можно ли зашифровать данные и потребовать аутентификации?
  • Внешний вид. Хорошо ли воссоздается графический рабочий стол, возможно ли сжатие передаваемой информации?

Мы использовали две тестовых конфигурации. Первый тест был через локальную сеть 100 Мбит/сек, между двумя Linux-системами. Этот тест показал нам, на что способны протоколы при условии стабильной связи. Второй – через кабельное соединение 3 Мбит/сек с удаленной сетью, при задержке около 40 миллисекунд. Это типичные параметры сети для работы и из дома, и через WAN между офисами.

VNC Free Edition

Оригинальный мультиплатформенный протокол удаленного управления.


В середине 90-х сотрудники лаборатории AT&T в Кембридже соорудили довольно изящный протокол, Virtual Network Computing (VNC), спроектировав его для удаленного контроля, позволяющего любой платформе управлять любой другой. Серверы и клиенты VNC были разработаны для Unix, Windows и Mac OS, наряду с набором мобильных устройств. Многие из этих реализаций были почти бесполезны, но они демонстрировали гибкость VNC, обязанную использованию собственного внутреннего протокола – Remote FrameBuffer, или RFB. Спустя десять лет после выхода VNC, RFB продолжает быть основой почти всех систем удаленных рабочих столов в Linux.

Открытая реализация VNC, включающая сервер и клиентский просмотрщик (viewer) для удаленного доступа к данным, использовалась коммерческими компаниями и домашними пользователями с 1998 года. Но RealVNC, фирма, основанная выходцами из AT&T Laboratory, выпустила также три коммерческих VNC-решения, включая версии для предприятий и персонального использования. В нашем Сравнении мы тестировали свободную версию, известную также как RealVNC, используя ее с рабочим столом Gnome и кли- ентами Linux и Windows.

Технология довольно проста. Сервер VNC запускается на машине Linux, предоставляя новую X-сессию, через которую запускаются приложения. Типичная X-сессия на рабочем столе Linux – :0.0, так что VNC следует искать запущенным на :1.0. Однако, в отличие от стандартного X-сервера, X-сервер VNC (Xvnc) не полагается на доступность физического видеоустройства, а запускается независимо от любого оборудования на локальной машине. Чтобы поработать с Xvnc, вы подключаетесь к нему удаленно через RFB, используя программу-клиента VNC (просмотрщик) – и готовая X-сессия открывается в окне.

Те, кто «подсел» на терминал, знакомы с программой screen – она позволяет запущенным удаленно (через SSH или Telnet) процессам выполнять свою работу и осуществлять вывод, даже если сессия была завершена. Позже пользователь позже может снова подключиться к машине, запустить screen и продолжать работу, как ни в чем ни бывало. VNC действует очень похожим способом: даже если ваша сеть «упадет», сессия Xvnc не прекратит работу, и все X-приложения – тоже. Это удобно: пользователь может отсоединиться от сессии, чтобы перезагрузить свою рабочую станцию или подключиться из другого места.

Кодирование

VNC предлагает ряд методов кодирования, предоставляющих множество способов перерисовки рабочего стола: от наиболее общей реализации «raw», которая обновляет буквально каждую точку, как только она изменится, до сложных методов hextile и corre, допускающих меньшую пропускную способность и перерисовывающих изменения быстрее. Впрочем, ни один из методов кодирования на самом деле ни сжимает данные, ни модифицирует их методом с потерями, так что VNC на медленном соединении будет слегка срываться (см. «Стоит ли ждать»). Однако на Ethernet 100Mbit VNC почти не отстает от обычной X-сессии – мы даже смогли через сеть проиграть DVD на Totem, без заметного дрожания или рассинхронизации звука и изображения.

Одна из довольно полезных возможностей VNC – слежение (shadowing) за рабочим столом, когда несколько пользователей могут подсоединяться к одному серверу Xvnc и либо разделить сессию, либо передать управление одному из них, а остальных – сделать наблюдателями. Это приложение идеально для тренингов или конференций, когда несколько человек работают над проектом вместе. Каждый, кому приходилось искать неисправности и кто хочет, чтобы поставщик или консультант понаблюдали за проблемным пользователем, найдет его бесценным.

Безопасность RFB

Свободная версия VNC не предусматривает шифрования, так что запуск сессии RFB через открытое интернет-cоединение сравним с использованием Telnet. Пароли для VNC-аутентификации и нажатия клавиш во время сессии передаются открытым текстом, и их легко перехватить. Однако в Linux уже есть многочисленные методы обеспечить безопасность IP-трафика, либо используя туннель VPN, либо туннелируя RFB-сессию через шифруемый порт SSH. С учетом доступности утилит шифрования и простоты их развертывания, все, кто планирует использовать VNC для работы, просто придут на готовенькое.

Если требуется удаленный X-доступ из Linux, использования в той или иной форме VNC практически не избежать. Но данная версия лишена функций сжатия и аутентификации, и пользователям, желающим чего-то большего, чем базовое решение, лучше присмотреться к TightVNC. Если какие-то из устройств его не поддерживают, всегда можно использовать в роли клиента обычный VNC и, благодаря обратной совместимости с RFB, иметь возможность подключаться к системам TightVNC.

Стоит ли ждать?

Те из нас, кто пользуется VNC несколько лет, в курсе, что он очень удобен и гибок на соединениях с высокой скоростью и низкой латентностью, но становится практически бесполезен, как только скорость передачи данных, требуемая для обновления экрана, превышает возможности локального соединения. Типичная ситуация, когда это становится проблемой – удаленный офис с ADSL- или кабельным соединением, где скорость исходящего потока заметно ниже, чем входящего. Пропихивание целой X-сессии через 256 кбит/сек не слишком радует, даже при обычном запуске Twm или Xterm.

TightVNC

Поднимает VNC на новые высоты.


TightVNC – это VNC, сделанный лучше, быстрее... компактнее [tight – компактный, сжатый, – прим. пер.]. Созданный командной российских разработчиков как улучшенная версия VNC, TightVNC предлагает альтернативные расширения для протокола RFB, предоставляющие улучшенную технологию сжатия для пользователей с медленными соединениями. Это достигается ценой небольшого увеличения латентности, пока рассчитывается сжатый рабочий стол, а также увеличения нагрузки на процессор, но это не повод для беспокойства для процессоров, созданных за последние лет пять.

Как и RealVNC, мы тестировали TightVNC с рабочим столом Gnome и клиентами Linux и Windows. Методы сжатия могут быть либо «без потерь», либо JPEG. Варианты «без потерь» включают «fast» (быстрое), для наиболее отзывчивого рабочего стола, и «best» (наилучшее). Хотя опция JPEG (сжатие с потерями) может попортить ясность и четкость рабочего стола, она реально снижает требования к пропускной способности. Результирующее качество варьируется от «почти оригинал» до «клякса какая-то». JPEG-сжатие с низким качеством определенно полезно, но оно не для тех, кто любит мелкие шрифты или заинтересован в детальном изображении. При низком качестве удаленного стола шрифты, изображения, меню и т.д. фактически нечитаемы, потому что все они растровые, и просмотр интернет- страниц почти невозможен. Зато JPEG-сжатие работает через модем 56 кбит/сек – всяко лучше, чем ничего.

В TightVNC отсутствует «родное» шифрование, но имеется ряд скриптов, которые позволяют ему работать через stunnel (оболочка к SSL-шифрованию), предоставляя TCP-сессию между клиентом и сервером, зашифрованную с помощью SSL.

Нужен быстрый удаленный доступ через медленное соединение? TightVNC как раз для вас. Нужен быстрый локальный доступ через LAN? Все равно берите TightVNC, потому что все функции обычного VNC у него есть. Короче говоря, пусть все пользуются TightVNC.

X11

Linux-сервер, используемый удаленно.


Все, что вы делаете с X, работает через протокол, основанный на сокетах, либо TCP, либо Unix. Мы вспомнили об этом в Сравнении удаленных рабочих столов, потому что X позволяет приложениям подключаться через сеть и к локальной X-сессии, и к другой системе. Все возможности X-сервера будут доступны клиенту: например, если удаленная машина не поддерживает GLX (как же мы без OpenGL?), вы все равно сможете запускать GLX-приложения, хотя производительность слегка пострадает. X – это сервер, но клиентом является приложение: вы ничем не подсоединитесь к нему. Мы тестировали X.Org 7.1.

Все X-приложения полагаются на переменную DISPLAY; изменив ее, чтобы она указывала на другую систему, вы можете прозрачно запускать приложения (но не весь рабочий стол) на другой машине, как будто они работают локально. Ликуйте все, кто работает на нескольких машинах и кому уже некуда ставить дополнительные мониторы! Один из основных недостатков X11 – очень простой, основанный на событиях протокол, и вы вряд ли захотите запускать его через общедоступную сеть. Поскольку все работает с использованием TCP, «обернуть» сессию в SSH или stunnel довольно легко; и как только туннель будет построен, можно будет исполнять различные приложения с использованием шифрованного соединения. Но и тогда вы должны убедиться, что сессия SSH работает постоянно, не то по завершении сессии все X-приложения бесславно погибнут.

X11 через сеть может пригодиться, но вообще-то он проектировался для использования исключительно в среде LAN. Он умеет работать через VPN, но опасность потерять все ваши X-приложения из-за кратковременного сбоя сети, в общем, слишком велика, чтобы он стал действительно полезным.

X11vnc

Используется с VNC-просмотрщиком для экспорта сессий X11.


Написанный в 2002 году, X11vnc запускается как клиент к любой сессии X11, которую вы хотите экспортировать для удаленного доступа, предоставляя рабочий стол как VNC-сервер по сети. Поскольку это VNC-сервер, он использует протокол RFB, а не X11. Когда X11vnc запущен (мы испытывали его с X.Org 7.11 и клиентом TightVNC), удаленный пользователь может подключиться к рабочему столу, либо разделяя сессию, либо только в режиме просмотра. Для просмотра рабочего стола можно использовать различное кодирование, допускающее сжатие и изменение качества JPEG при отображении на стороне клиента, так что даже если у вас на рабочем столе творится нечто безумное, все равно можно будет поглядеть на это через VNC.

Звучит хорошо; но затем возникает вопрос: «Умеет ли X11vnc делать то-то и то-то?». Беглый взгляд на X11vnc -h даст ответ, правда? После просмотра 40 страниц опций, ключей и других аргументов, вы, может быть, найдете то, что искали, а может, и нет. X11vnc – из тех приложений, куда люди приходят и говорят: «Мне нужно это» – и «это» добавляется, будь оно хоть рукомойником или другим столь же нетипичным приспособлением. Многие дополнения и разумны, и полезны, но когда нужен всего-навсего X-дисплей, в поисках помощи можно зарыться в горах информации и навеки. Впрочем, беда невелика: подробное ЧАВО (FAQ) на сайте прекрасно посодействует заставить общую X-сессию вести себя как надо.

Если у вас есть X11 и вам нужно издалека добираться до своего рабочего стола, берите X11vnc и не ищите ничего другого – разве что захотите попользоваться инструментами, встроенными в Gnome или KDE; но даже они и близко не подходят к некоторым из возможностей X11vnc. Если вы уяснили все опции командной строки и оптимально настроили конфигурацию, X11vnc станет лучшим средством экономии времени и продуктивным инструментом, необходимым каждому рабочему столу X11.

NX

Новаторская, быстрая, но проприетарная альтернатива VNC.


RFB – прекрасный протокол для базовых однопользовательских соединений. Но ему недостает реальной системы аутентификации, и в более крупных системах проверка машин и слежение за подключениями превращается в кошмар. NX не использует ни RFB, ни протокол RDP (Remote Desktop Protocol, протокол удаленного рабочего стола, широко применяемый в Windows) – у него собственный протокол для туннелирования сжатого X и различных протоколов через зашифрованный канал.

Четыре сервера уровня предприятия доступны по отдельности и за плату, а открытый настольный сервер можно скачать с http://www.nomachine.com, но вам придется использовать его с клиентом NX и узлом, бесплатными, но не свободными. Мы рассмотрели один из пакетов уровня предприятия NX 2.0.0, протестировав его с X.Org 7.1 и Windows XP Pro.

NX необычен тем, что дает возможность удаленного доступа к системе и позволяет приложениям X-клиентов получать доступ к удаленному X-серверу. Это решает проблему отсутствия хорошего способа шифрования или сжатия данных между X-сервером и клиентом: NX запускает X Agent, в итоге получается конфигурация в стиле «X внутри X», где один X-сервер посылает обновления другому как события вызова от клиента.

Имея возможность пересылать звук и файлы через одно и то же NX-соединение, NX превосходен для всех, кто использует удаленный доступ в ежедневной работе. Хотите проиграть Flash-ролик на удаленной машине? Аудио автоматически передается через шифрованное соединение на локальной машине, обеспечивая полное мультимедиа-взаимодействие с вашим удаленным рабочим столом. Как и предоставление файлов в общий доступ, это много лет входило в RDP на Windows, но NX приносит это на открытый рабочий стол, плавно интегрируя существующие хосты Windows и новые Linux-инсталляции.

Tsclient

Многосторонний инструмент Gnome для протоколов RDP и RFB.


Управление системами, к которым мы получаем удаленный доступ, довольно нудная штука: нужно помнить все имена хостов или IP-адреса и все пароли, используемые для обеспечения безопасности. Для решения этой проблемы можете попробовать Tsclient – приложение Gnome, предоставляющее интерфейс ко всем обычным клиентам удаленных рабочих столов, включая VNC Viewer (интерфейс к RealVNC или TightVNC) и Rdesktop, что позволяет получать удаленный доступ и к Linux-, и к Windows-системам, а фактически ко всему, что поддерживает RFB. Для этого Сравнения мы испытывали его с серверами TightVNC и RDP.

Tsclient изрядно примитивен. Конфигурация каждой хост-системы сохраняется в файле, загружаемом через интерфейс. Хотелось бы, конечно, небольшого меню, включающего все хосты, а то и организующей их древовидной структуры; зато можно сохранять сессии как для хостов RFB, так и RDP, и учесть все ваши потребности к доступу в одном приложении.

Перейдем к недостаткам. Богатство настроек для RDP компенсируется бедностью ассортимента опций VNC. Мы не смогли назначить ни свое кодирование, ни степень сжатия, или поместить его в SSL-туннель. Правда, все больше людей использует удаленный доступ с VNC и он интегрируется в большее число окружений рабочих столов, так что опции хостов VNC явно ждет улучшение.

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

Krdc

KDE-интерфейс для доступа к хост-системам.


Пусть Tsclient фокусируется на пользователях Gnome; поклонникам KDE тоже не дадут пропасть. Krdc – это ответ KDE на требования доступа к сессиям RDP и RFB на удаленных машинах, и (говоря не для драчки Gnome vs KDE) он куда лучше, чем Tsclient. Все хорошо организовано, есть список сохраненных хостов, доступных по двойному щелчку мыши.

Персональные настройки чисто базовые, но Krdc дает выбор быстрого, среднего или медленного типа соединения, в противоположность Tsclient, где вообще нет интерфейса для сжатия. В основном, Krdc прилично подбирает сжатие для различных скоростей соединения, но его утверждению, что средний уровень достаточен для некоторых DSL- или кабельных соединений, не очень верится. Как всегда, требуется время, чтобы все настроить и добиться хорошей работы. Tsclient предоставляет функцию, которой нет в Krdc – это поддержка RDP 5, она пригодится, если нужно вырезать и вставлять текст между удаленной Windows-системой и локальным хостом. Мы лишь установили соединение RDP 4 с помощью Krdc; иными словами, копировать данные с хоста на хост непросто.

Эх, вот бы нам интегрированный клиент удаленного рабочего стола, позволяющий размещать иконки, или даже простые меню, на рабочих столах удаленных машин! С длинным хвостом хостов, накопленным Krdc, пора уже сделать небольшую панель инструментов для быстрого доступа к серверам или рабочим станциям. Определенно, грань между локальным хостом и удаленной системой должна стираться для конечных пользователей, которые не вполне уловили концепцию возможности доступа к их рабочему столу из другого города.

Так или иначе, Krdc опережает Tsclient по удобству и простоте, хотя обоим нужна доработка, чтобы быть на уровне.

ВЕРДИКТ

TightVNC 9/10

Поскольку из рассмотренных нами приложений все, кроме двух, ведут свою родословную от VNC, понятно, что TightVNC – наиболее успешная реализация. При своей гибкости сжатия сессий для удаленного использования и поддержке VNC-кодирования без потерь, TightVNC удовлетворяет требованиям всех пользователей. Кодирование TightVNC поддерживают многие сервера, включая RFB-клиенты и сервера только для Windows, в том числе, UltraVNC. Это абсолютный победитель данного Сравнения.

По серверной части X11VNC оставляет в кильватере всех. На беду, здесь так много опций, что заставить его работать правильно удастся не сразу. Мы готовы подтвердить его способность упрощать жизнь, поскольку наблюдали, как приложение остается запущенным удаленно, пока мы просто «перепрыгиваем» на машину через SSH и запускаем X11VNC для соединения с рабочим столом. Gnome и KDE предлагают функции удаленного рабочего стола на базе X11VNC, чтобы интерфейс пользователя стал понятнее и поделился набором опций во всей полноте. Опытным пользователям X11VNC под силу соединяться с не-X11 устройствами, включая фрейм-буферы или даже интерфейсы Video4Linux.

Локальное решение

X11 имеет свое место под солнцем, и так как это оконная система de facto на Linux, еще некоторое время будет его сохранять. Простой вызов удаленного приложения через локальную сеть делает X11 трудным соперником, а ведь ему присуща еще и гибкость, обеспеченная сетевыми возможностями стоящего за ним X-протокола. Конечно, попытки сделать что-то сумасшедшее типа проигрывания DVD по сети или запуска Flash-анимации – жесточайшие надругательства над сетью.

Протокол RFB, безусловно, дает пользователям выбор смешивать и согласовывать возможности клиентов и серверов, чтобы подобрать самую подходящую пару для своих целей. Это ваше дело, как назначить поведение вашего рабочего стола или функции сжатия, шифрования и упрощения для взаимодействия с нужными удаленными системами или рабочими станциями. Конечно, по большому счету, ваше решение будет определяться скоростью имеющегося интернет-соединения и временем, которое вы захотите потратить на настройку приложения. Как ни печально, при доступе к рабочему столу KDE на PDA с использованием GPRS, даже с самым сильным сжатием, продуктивно не поработаешь. LXF

Как работает удаленный доступ

LXF84 comp8.png

Таблица функций

LXF84 comp9.png

[1] Через SSH [2] Посредством инструментов сторонних производителей

Персональные инструменты
купить
подписаться
Яндекс.Метрика